[HN Gopher] I come here not to bury Delphi, but to praise it (2019)
___________________________________________________________________
I come here not to bury Delphi, but to praise it (2019)
Author : open-source-ux
Score : 93 points
Date : 2023-08-21 15:09 UTC (7 hours ago)
(HTM) web link (accu.org)
(TXT) w3m dump (accu.org)
| smokel wrote:
| How is it possible that one man was responsible for the creation
| of Turbo Pascal, Delphi, C#, and TypeScript? [1] I don't look up
| to many people, but here's one.
|
| [1] https://en.wikipedia.org/wiki/Anders_Hejlsberg
| unsubstantiated wrote:
| He didn't spend all his time shitposting
| BBS/Newsgroups/Slashdot/HN while pretending he knew the one
| simple trick to obviate global political and economic turmoils?
| malkia wrote:
| I started with Turbo Pascal 3, Moved to 4, 4.5, 5, 6 then Delphi.
| Somewhere in there moved to "C" and then "C++".
|
| Couple of observations: - Using C (Borland or
| Microsoft) required two floppy disks - one for the compiler, one
| for the linker. With most of the Pascal versions you end up just
| needing one floppy disk, later it didn't matter as we moved to
| HDD. - First "terrible" experience (by a friend) -
| he moved from Pascal to C and placed all his code in the .h-eader
| file, and was wondering why it takes so much to compile (oh, yes
| nowadays it's fashionable to have header-only libs, lol), but
| then it was awful. - Pascal Units enforced you (as
| explained in the article) to figure out cyclic dependencies,
| unfortunately lots of us thought of this as a limitation, which
| C/C++ did not had. How wrong we were! - There was
| barely any use of preprocessor (yes there was), and it was more
| into the language, than some external pre-processor.
| - Mark/Release was superior, but also harder to understand the
| idea than plain old malloc/free * Mark -
| "Records the state of the heap in a pointer variable".
| * Release - "Returns the heap to a given state".
| * So you can quickly release memory in one hop (like nowadays
| what json parser might need to do). - Turbo Pascal
| 3.0 was only 30-40kb - Even later Borland could keep up to a
| single disk. Assembly was approachable from it -
| Peephole optimization!
| glonq wrote:
| I regret completely missing the boat on Delphi.
|
| I used Turbo Pascal 3 thru 6, but after college migrated
| towards C/C++ and never had reason to use Delphi professionally
| or personally.
| malkia wrote:
| Most of the demo coders that I followed (I wanted to become
| one, but never did anything significant there), and demo docs
| were done using Pascal. Eastern europeans (like myself) seemed
| to prefer it more for some reasons.
|
| TSR applications while a bit large than pure .asm were
| possible!
| smokel wrote:
| When working on demo effects, I found it extremely important
| to have lightning fast edit-compile-run cycles. Before
| interactive demo editing tools became a thing, we had to
| modify code and recompile it to see anything. With Turbo
| Pascal (or TASM for that matter) you'd have results in under
| a second. Every now and then your demo would crash, but
| having set up AUTOEXEC.BAT to start Turbo Pascal, you'd be
| back in your editor in a few seconds.
|
| I just don't understand how people can put up with waiting
| for compilers, Docker image downloads, and "continuous
| integration" builds that take upwards of whole minutes.
| Granted, it takes some effort to get things fast, but it is
| perfectly possible on modern hardware to have lightning fast
| compilation, and runtime replacement of modules. For some
| reason most people just don't care, and it sometimes makes
| one feel terribly lonely.
|
| Also, inline assembly was really nice! asm
| mov ax, 13h int 10h end;
| fuzztester wrote:
| Can't resist reposting:
|
| https://news.ycombinator.com/item?id=36659349
|
| See the thread title to get it (90s developer ...)
|
| And:
|
| Why use Pascal?
|
| https://news.ycombinator.com/item?id=36646890
| msla wrote:
| > I started with Turbo Pascal 3, Moved to 4, 4.5, 5, 6 then
| Delphi. Somewhere in there moved to "C" and then "C++".
|
| I never understand why people use "C" as opposed to C.
|
| Does anyone use "Pascal" as opposed to Pascal?
| electroly wrote:
| I assume they are doing that to distinguish the Borland
| products (Borland C and Borland C++) from the programming
| languages. Everything in that sentence is the name of a
| Borland product.
| kylecazar wrote:
| I hadn't seen it before this. Stood out to me.
| dminvs wrote:
| If it was Borland's compiler suite it may or may not have
| been perfectly standards-compliant, hence the quotation
| marks. The Borland suite from the early 90s seemed to be
| pretty relaxed/forgiving about what was valid C/C++.
|
| My school utilized Turbo C++ 3.0 for instruction (and later
| 4.5), which implemented some weird subset that was pre-C++98.
| Plenty of things that I was doing when targeting the Borland
| compiler barfed terribly when compiled with GCC (or G++).
|
| I'd definitely consider what we were writing in those days
| "C" or "C++" but not anything that resembles modern
| software...
| ptspts wrote:
| Borland C++ was released before 1993. No wonder it didn't
| support C++98 at that time.
| coliveira wrote:
| Not only that, but Borland also had extensions in their
| C++ compiler to simplify the development of GUI code
| (similar but different to the tricks Microsoft also used
| in their compilers).
| HumblyTossed wrote:
| Pascal is objectively verbose. But there's something very
| aesthetically pleasing about the blockiness of it.
| idlemind wrote:
| Also a great teaching language, as used at London Imperial
| College Electrical and Electronic Engineering dept. in the early
| 00s. Gave you lots of power but not too much, and enough rules to
| force you to learn without doing mad things. I have fond
| memories. And I miss the compilation speeds!
| rileyphone wrote:
| https://web.archive.org/web/20230821150934/https://accu.org/...
| ilyt wrote:
| Well, to throw extra praise it ran GUI faster on the triple digit
| single core CPUs than near-any current JS abominations on quad
| digit multicore CPUs do nowadays...
| dver wrote:
| The quarterly Delphi posting, "We will not go quietly...."
| pjmlp wrote:
| I get a bit of nostalgia when coding in Typescript, Kotlin,
| Swift.
|
| It is a sweet revenge that most modern languages, have decided
| to go with the Pascal influenced approach (yes some ML as
| well), even most of the C++ wannabe replacements (with
| exception of Circle).
| zengid wrote:
| Maybe it could be called the 'Hejlsberg effect'. (With no
| disrespect to Wirth)
| baq wrote:
| Yeah go is basically Pascal with C/Java syntax and first
| class coroutines.
|
| What could have been.
| pjmlp wrote:
| Go has a different path, though, but Niklaus Wirth presence
| is still there, thanks to Oberon-2 influence, coupled with
| Limbo.
| panki27 wrote:
| BEGIN
|
| Delphi was what I had to use in my first apprenticeship/job, over
| 7 years ago now.
|
| Came home after the first day and my dad told me that's what he
| made his first Windows programs with, too - but 25+ years ago!
|
| After learning other languages, I still have to say it's great
| for quickly putting together GUIs and filling them with life. The
| community is rather thin these days though.
|
| END
| superdisk wrote:
| I know he's talking about Delphi here, but FreePascal+Lazarus is
| still one of my secret weapons. It has some sort of supernatural
| force field which causes people to ignore it and unfairly
| denigrate it; meanwhile I whip up desktop applications in hours
| that would normally take days.
| open-source-ux wrote:
| A roadmap for Lazarus just released on 19 Aug 2023 (3 minutes
| video)
|
| https://www.youtube.com/watch?v=ixQ2LZTzVJQ
| pjmlp wrote:
| Thanks for sharing!
| wiseowise wrote:
| Is there text form?
| open-source-ux wrote:
| Only the Lazarus video roadmap:
| https://www.blaisepascalmagazine.eu/roadmap-for-fpc-and-
| laza...
| lockhouse wrote:
| The best part is that Lazarus is write once, compile anywhere.
| It works on all major desktop OSes and even some less
| mainstream ones.
| badsectoracula wrote:
| Yeah though in practice it is more "write once, compile
| anywhere, debug everywhere" :-P as there are often minor (and
| sometimes major) inconsistencies between the underlying
| widget libraries (not Lazarus' fault though, if anything
| there is a lot of effort put into providing as much
| consistency as it can).
| ctoth wrote:
| Last time I looked at this I couldn't really find an easy
| standard way to make HTTPS API calls and parse JSON, but only
| spent an hour or two playing with it. Can you point me at the
| canonical way to do this? What's the Requests of FreePascal?
| Pompidou wrote:
| Fun, I struggled with json parsing for a long time, and have
| done it for the first time with freepascal. Maybe this can
| help you : https://medium.com/@marcusfernstrm/freepascal-and-
| json-337c0... ?
| ctoth wrote:
| That is way easier than the stuff I was reading before
| which said I needed some sort of 3rd party paid component
| for it, nice.
| loa_in_ wrote:
| Third party paid component for parsing strings into basic
| data types and making http requests? That doesn't sound
| right even for late 20th century
| sammyjoe72 wrote:
| Does superobject compile under Lazarus?
| badsectoracula wrote:
| Free Pascal has fcl-web which should provide a HTTP/HTTPS
| client (among other things, it can be used to make web apps),
| though it comes with libcurl bindings out of the box so you
| could also use that too. fcl-json provides a JSON parser.
| FWIW "fcl" means "Free Component Library" which contains
| various tools (mainly exposed as classes).
|
| The packages[0] directory of FPC contains a lot of stuff that
| come out of the box with the compiler and they often have an
| "examples" and/or "tests" directory with code you can check.
| There is some documentation[1] but sadly FCL is really not
| that well documented - you just have to check the sources for
| most things.
|
| Note that this is for Free Pascal itself. Lazarus builds on
| it (LCL, the "Lazarus Component Library", is built on top of
| FCL) and adds a bunch of additional components of its own.
| Though usually for non-GUI stuff you just use the Free Pascal
| classes, Lazarus has some of its own "wrappers" that
| integrate with the IDE and the form/object designer. The
| "weblaz" package (it comes with Lazarus but you need to
| install it manually from Package -> Install/Uninstall
| Packages) provides a bunch of components for working with the
| web (mainly for making web apps), including the
| "TFPHttpClient" component which can be used to make HTTP
| requests. As a simple example, if you throw a TMemo
| (multiline text editor) control in a form, throw a
| TFPHttpClient component and then doubleclick on the form to
| edit the code to execute during the form's creation you can
| type "Memo1.Text:=FPHTTPClient1.Get('https://news.ycombinator
| .com/');" and it will put the HTML code for this forum in the
| memo (note that you may also need to add the opensslsockets
| unit in the uses section at the top of the code). Of course
| that is a very simple example but if you browse the
| properties and events of the component in the object
| inspector as well as the available methods by typing
| "FPHTTPClient1." and pressing ctrl+space in the code editor
| you can find most of the other functionality the component
| provides.
|
| [0] https://gitlab.com/freepascal.org/fpc/source/-/tree/main/
| pac...
|
| [1] https://www.freepascal.org/docs-
| html/current/fcl/index.html
| malbs wrote:
| The one negative I've found with Lazarus... And this is purely
| if you were someone coming from a Delphi background, or were
| planning on Lazarus being your "get out of jail free" card if
| [Embarcadero/(whoever owns it now)] decides to stop updating
| Delphi (and even then you could probably manage it's lack of
| updates for years, hell I stayed on Delphi 2007 for a good 8 or
| 9 years after XE, XE1, XE2 et al had been out).. Anyways, back
| to my point, the one major negative I've found with Lazarus is
| you simply can not take Delphi code, and compile it straight in
| Lazarus... There are many many many very subtle differences.
| Totally fine and understandable, but if you were planning on
| taking the attitude of "Stuff Delphi, lets take our 400k line
| project and move to Lazarus", you are going to have a bad time.
|
| Having said that I've done a couple of my own projects at home
| in Lazarus. It's fine, it feels dated, going back to the
| original Delphi / VB style of RAD tool with form designer/code
| editor as floating windows etc. The intellisense leaves
| something to be desired, but I can't be too critical because
| it's not like I'm putting my hand up to contribute to the
| project. If you look at what you get for what you pay for, it's
| quite literally amazing.
| codr7 wrote:
| Whipping was never the problem with Delphi, long term
| maintenance was.
| kwhitefoot wrote:
| > long term maintenance was.
|
| How so?
| codr7 wrote:
| Because it's all proprietary, and continuously deprecated
| to blend better with the latest hype.
|
| I did 13 years with Delphi, full time.
| Gormo wrote:
| Fair enough re Delphi, but the previous comment pertained
| to FreePascal with Lazarus, which are FOSS and well-
| maintained.
| pjmlp wrote:
| It is still slower than Web fronted "today's framework to
| take over the world!".
| fuzztester wrote:
| With the emphasis on "today's".
|
| As in, new one tomorrow, or in a week. Wish project
| timelines matched ;-)
| magicalhippo wrote:
| We have a fair bit of code in production that was written
| over 20 years ago. It just works. It has gone through
| strings switching from 8-bit to Unicode (16-bit) with
| hardly any modification.
|
| We upgrade every year or so, and in almost all cases it's
| smooth sailing.
|
| Delphi has been quite good so far when it comes to long
| term maintenance.
| codr7 wrote:
| Not my experience.
|
| First they deprecated the bundled DB bindings, after
| hyping them to hell and back; then the bundled report
| generator. We had more than a million lines of code
| depending heavily on those.
| thijsvandien wrote:
| Proprietary, with almost full sources to the standard
| library, however. There is indeed a bunch of half-assed
| stuff, but that's easy to ignore. In general, Delphi
| moves slowly and hardly ever breaks backward
| compatibility. Only the transition to Unicode in D2009--
| oddly not mentioned in the article, along with generics--
| was a little rough. Apart from that, decades old code
| keeps compiling/running without issue. It's mostly third
| party components needing updates sometimes, especially if
| they're shipped as compiled units or integrate with the
| IDE.
| malbs wrote:
| Mate I've got a project whose first lines of code were
| struck back in the 80s in Turbo pascal. Your
| "continuously deprecated" argument doesn't hold a lot of
| water from where I sit... In terms of actual language
| features/changes that have caused deprecated status,
| those are very few and far between. Maybe some VCL
| database controls, for sure it would have sucked to have
| built stuff relying on interbase, but that is not a
| language/compiler feature, that was CodeGear EOL that
| particular project (I had to manage the exit strategy on
| one of our projects where it relied on that crapware)
|
| Even library developers are pretty good at pumping out
| versions of their libs that have support for even Delphi
| 5. I know of at least 2 people who are still doing
| windows dev on Delphi 5 or maybe 7, I can't recall.. the
| very definition of "from my cold dead fingers".
|
| Suffice to say if you were one of those real hold-outs,
| not updating to the latest.. you wouldn't have generics,
| dynamic arrays, lambdas/anonymous functions, and you
| would probably struggle to grab much code written in the
| last decade and compile it straight up.. but that would
| probably be the case for a number of languages that have
| had core features added to them over time.
|
| The fact that the system is proprietary certainly is an
| issue, but every install always ships with all the source
| code of the RTL, VCL, and clear instructions on how to
| compile it with a "you're on your own now" sense of
| adventure.
| lockhouse wrote:
| I find Pascal based languages to be much more readable than
| most JavaScript and C++ code bases.
| mike_hearn wrote:
| The no-circular-dependencies rule was a huge pain though. It
| allowed the compiler to be very fast (along with it basically not
| optimizing), but no other language has copied this because
| combined with weak to non-existent refactoring tools it was just
| a constant pain to be hitting this limitation whilst developing.
| Sure, if you're an architecture god who plans out all their
| internal interfaces in advance on paper it was OK, but I was 15.
|
| Delphi could have potentially navigated into the web era quickly
| enough, but was slow to do so. It was essentially a Windows
| product at its core. They made a half-hearted attempt to port it
| to Linux but did so using Wine(lib) which back then was very
| rough, so Kylix had a poor UX and of course the problem was that
| the Delphi widget toolkit was the Windows toolkit which Linux
| didn't have. IIRC it was also quite slow to even get things like
| an HTTP stack, which had to be produced by a third party company.
|
| The focus on visual componentization back then was kinda great
| though. That's definitely something that went AWOL somewhere
| along the line. The good database integration is also sorely
| missing in more modern languages and frameworks.
| mdekkers wrote:
| > Sure, if you're an architecture god who plans out all their
| internal interfaces in advance on paper it was OK, but I was
| 15.
|
| Us Architecture Gods don't need planning. The internal
| interfaces have been immaculately conceived in our mental
| space. It's the regular peasantry of architecture that need to
| do the planning.
| tjalfi wrote:
| F# requires code to be in dependency order. You can't refer to
| types unless the compiler has seen them.
| JaggerJo wrote:
| Yeah, this is quite nice once you are used to it.
| pjmlp wrote:
| > The no-circular-dependencies rule was a huge pain though. It
| allowed the compiler to be very fast (along with it basically
| not optimizing), but no other language has copied this
|
| C++20 Modules, .NET Assemblies, D modules, Ada packages, and
| plenty of other othes.
|
| Also, Turbo Pascal did indeed allow for circular dependencies
| between units, as long as the related _uses_ statements were
| written in the _implementation_ section of the unit, and there
| were no public dependencies.
|
| Thanks to bitsavers, Turbo Pascal 5 manual, page 97,
|
| http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...
| mike_hearn wrote:
| Modules and assemblies are different. Lots of languages ban
| circular dependencies between modules (most!). Delphi units
| were single source files though, and that's a much more
| painful proposition because it forcibly links source file
| size and program architecture. I saw a lot of _big_ unit
| files in Delphi code bases.
| pjmlp wrote:
| Apparently no one read the part about dependencies being
| allowed between implementations section, and I imagine also
| never looked into Delphi packages, in regards to code size
| and organising units.
| kgeist wrote:
| >The no-circular-dependencies rule was a huge pain though. It
| allowed the compiler to be very fast (along with it basically
| not optimizing), but no other language has copied this
|
| Go forbids circular dependencies.
| malkia wrote:
| I was just thinking how the ideas behind Turbo/Borland Pascal
| and Delphi reminded me of Go, I know it should've been
| Dotnet, but Dotnet got complicated right from the start with
| it's deployment model (lots of dlls, assemblies, blah, blah
| blah).
| avg_dev wrote:
| indeed it does; i've run into it a few times. just last week
| i was writing some go code in vscode and it wasn't working
| because i had a circular dependency. vscode was reporting
| something in the "problems" window like a "go list" failure
| due to "no go files". i couldn't make head or tail of it for
| a few minutes. it took me some time to note that the path
| listed in the issue was one i had just edited. in fact, i
| didn't even notice the path at first -- i tried running `go
| list` from my repo root and didn't see the error, but when i
| saw the path and changed to that dir and tried again, i saw
| the `go list` error as reported by vscode, and i think that
| when i opened the file i had just edited in vscode it
| displayed a more understandable cyclic import message in the
| offending import, and it was easy to go from there.
| bleeding wrote:
| Yes, and I usually find when I run into this that I should be
| doing something differently in our package/interface design.
| I think it's overall very helpful though also annoying to
| detangle if you the cycle is deep enough.
| duped wrote:
| Life is better without circular dependencies
| badsectoracula wrote:
| > They made a half-hearted attempt to port it to Linux but did
| so using Wine(lib) which back then was very rough, so Kylix had
| a poor UX and of course the problem was that the Delphi widget
| toolkit was the Windows toolkit which Linux didn't have.
|
| I think the UX was fine as it was made to work with KDE1/Qt1
| which was very Windows-like (in appearance and behavior) at the
| time, but the real issue was that instead of trying to make VCL
| work crossplatform (like Lazarus' LCL does) they made a
| different framework (IIRC it was called CLX) which used Qt1 and
| was very incompatible.
|
| They released a free version with the limitation that your
| program had to be GPL, though at the time it was fine as GPL
| wasn't the boogieman it is today. Sometimes i wonder if Borland
| had released the entirety of Kylix under GPL and thus gained
| mindshare among open source programmers at a time when Linux
| had started becoming more popular among programmers if things
| would be different for Delphi - if nothing else it wouldn't be
| seen as some ultra-expensive tool that people only use because
| they have no way to move away from. At the time Borland made
| money from enterprises (which would buy the expensive
| enterprise version anyway) and proprietary desktop software
| developers (which wouldn't use the GPL version anyway) so
| having Delphi as a GPL'd program wouldn't affect them much but
| instead have the tool's mindshare expand and even have
| developers help Borland fix bugs with their framework and
| improve their compiler.
|
| I was thinking that a couple of years ago when i tried the free
| version of Kylix under my Linux installation and it failed to
| work with all sorts of errors despite my efforts - but errors
| that should be simple to fix if the source code was available.
| Then i tried it in a VM running some Linux version from the
| early 2000s and it worked, which made me think how nice it'd be
| if it was a GPL'd software i could modify.
|
| After that nostalgia session, i deleted the VM, downloaded the
| latest version of Lazarus and fixed the Gtk1 support[0] because
| i could as that is open source (ok ignore the broken images,
| that is because the shot is from a few months ago when i tried
| to remove the gdk_pixbuf dependency, normally they look fine
| but that is the only screenshot i had around :-P). FWIW the
| fixes were merged in (and i made some extra fixes since then).
|
| [0] https://i.imgur.com/su9JCUY.png
| dvh wrote:
| $4400 per seat (of which $1000 is annual fee) for a windows-only
| product with zero job postings?
| slt2021 wrote:
| $0 if you use open source lazarus
| sema4hacker wrote:
| Having started with FORTRAN in 1970, then discovering the beauty
| of IF-THEN-ELSE in PL/I, then using ALGOL W in college, all made
| Pascal a natural successor for me out of school (first MacPascal
| on Macintosh then Delphi on Windows). Still using Delphi 6 for
| projects to this day.
|
| What was/is particularly nice about Delphi is the library of GUI
| objects, single .EXE output with no dependencies, and the ease
| with which arbitrary-length strings can be used.
| unsubstantiated wrote:
| Perhaps unknown to the HN community is that C# periodically gets
| Delphi features reintroduced in it in one way or another.
|
| More recently, C# 9 and 10 have returned the concept of `records`
| (preferably immutable objects) along with the `with` keyword for
| making copies with some of the properties changed from the source
| to the dest object.
|
| It has been an interesting decade watching HN metaphorically (and
| sometimes literally i'm sure) shift around uncomfortable in their
| chair as the all-encompassing-nightmare M$FT creates two
| languages that are more and more dominating of developer
| marketshare - C# and TypeScript.
| rahen wrote:
| Well, Anders Hejlsberg, the creator of C#, is also the creator
| of Delphi.
| tracker1 wrote:
| C# and TypeScript have both been pretty open (in nature and
| source) for roughly a decade. Which I appreciate. Although, I'm
| somewhat apprehensive about some of MS's moves with the .Net
| community, and their holding back on quality of life
| improvements for C# projects in VS Code.
|
| Although, MS hasn't caused me to generally avoid .Net so much
| as the more "enterprise" nature of most of the projects I've
| had experience with. I started with .Net (C#) in 2001, and to
| this day think there is a lot to like there. Of course these
| days, I'd appreciate the opportunity to work with Rust more
| than C#.
| treprinum wrote:
| If RAD Studio/C++ Builder allowed building Linux desktop apps, I
| would have likely bought the architect edition. VCL is so much
| faster to develop than any other framework.
| xamomax wrote:
| In the early days of Delphi I considered it to be a huge
| competitive advantage in terms of productivity and speed against
| everything out there. As time went on, though, it slowly died,
| and it became increasingly difficult to find and integrate 3rd
| party libraries, or find developers to work in the system. The
| user interface aspects of it also became dated and difficult to
| make modern.
|
| Too bad, as I really liked it, especially the language. I liked
| the AMIGA as well, which also was ahead of its time and seemed to
| suffer a similar fate.
___________________________________________________________________
(page generated 2023-08-21 23:01 UTC)