It is a project that I've built 8 years ago. Delphi was already a "strange think" on that time, it was declining fast. I think Java killed Delphi - "One codebase for all platforms, even your freezer will have Java!" - this was the cool sentence on that time.
Since I started with Delphi when I was 14 (I am now 33), a lot of thinks changed to me. Now I mainly work in back-end field, building APIs, Bots, Crawlers and Queues to do massive things (like receive million SMS per hour in a voting system for a TV Reality Show program)
When I am programming, 70% of my time is Nodejs, 10% Python and 20% Vuejs.
But I still miss the old days of drag-N-drop GUI of Delphi, really easy.
Almost the exact same experience: started at 14 and now close to 30.
Back in the day, we used to exchange game CDs in my small town, and by a mistake I got one with Delphi 5. I knew nothing about programming, just installed it, clicked around, somehow managed to run the default app, and got an empty window. We didn't have internet, so I had to ask around what this thing was about, someone said all other programs were done with it. There were no books about Delphi in local bookshops, the closest I found was an introductory book about Visual Basic. Armed with a book on VB and Delphi 3, by trial and error I had managed to produce my first ever working apps.
Few months later I was a well-known "programmer" in my town and wrote my first production ready app: a management system for a taxi company that managed exactly 20 cars. Why twenty? Because I haven't figured out loops and all my loops over those 20 cars were "unrolled" - 20 consecutive lines of if/else statements! But it worked! I don't know for how long, but it was still in use when I moved from the town few years later.
> 20 consecutive lines
Haha that's nice think about trial and error.
I would like more people to experience what was the way of creating software with Delphi, seamless and easy, really closing the loop between creating and the resulting application and then look back at what unnecessary complexity we are dealing with every day when working with software. (nb I think there was a blog somewhere by one of Delphi's creators where they explicitly mentioned that the language and IDE were designed to be simple to use).
If I will be teaching programming to my children I will dig up old installation of Delphi 7 and just let them play.
Might be nostalgia speaking, but even if it doesn't lag behind, I'm pretty sure it hasn't gotten better. I guess QT Creator actually comes close.
(Plus: Compile times were never ever an issue...)
Now for the web, nevermind.
Java has Netbeans Matisse for Swing, Eclipse WindowsBuilder for Swing and SWT, Scene Builder for JavaFX, Android Studio designer. Not sure what InteliJ offers.
Objective-C and Swift have the XCode GUI design tools, based on the NeXTStep development environment.
C++ has UI designers for Qt/QML, C++ Builder, UWP/XAML.
Object Pascal has Delphi and Lazarus.
Xojo as Visual Basic dialect also has its own designer.
Commercial Common Lisp environments like Alegro CL and LispWorks also have their designers in the tradition of Lisp Machines.
Smalltalk environments also have GUI designers.
These are just some examples that come to my mind.
I often think nostalgically back to my NT4 system. A full office suite, photoshop, and delphi IDE running side by side in 128 MB of RAM, with room to spare, and very zippy. I see some functional improvements in modern day software, but nothing that warrants the incredible bloat.
I notice that the software industry as a whole still lives in the assumption that hardware can fix slow software. However, that doesn't seem to be the case. If you look at single-threaded performance the improvements are much less than they used to be. We may reach a point where CPUs stop getting faster at all. At what point should we go back to micro-optimizing our code?
I also start with Pascal (Turbo 3, 4, 5, 5.5 (greatest!), 6 and little bit 7). Then jump to Delphi (all 1-7) and then abandon it.
Much kudos must go to Anders Hejlsberg, who wrote the compiler in assembly language, starting on it at age 20. Hejlsberg went on to create Delphi, J++, C#, and TypeScript.
I still regard TP 1.0 as one of the best software products I've used, and feel it is a testament to brilliant, performant, compact software development - and to its developer.
How many years later and the web still does not catch up.
1) JS isn't discoverable from the perspective of the IDE. There's no static typing and no way for the IDE to hook up code to UI elements, and vice-versa. You need a statically-typed language that can transpile to JS without too much "impedance mismatch".
2) HTML layout functionality isn't really geared for the type of layouts that are present in desktop applications. Document-oriented layouts have a completely different set of requirements.
3) You have to solve the design-time/run-time issue, and this is not an easy issue to solve due to 1). You can't just use a browser engine at design-time for the WYSIWYG portion, so you need to create a whole "browser emulation" layer in the IDE, along with an execution environment for your statically-typed language.
Our product, Elevate Web Builder, solves these issues and implements a Delphi-like IDE for developing single-page web applications:
We've got a new version coming out soon that will also offer server-side coding in Object Pascal, giving developers a single-source-language approach to developing complex web applications.
Re: patterned functions: you can't rely on patterned functions in a full-featured IDE that allows any class method to be an event handler/delegate for another class instance. What you end up may look like what Delphi is doing, but it is just an approximation of the real thing that won't work very well for general-purpose usage. There's going to be all sorts of edge cases that don't work correctly because you can't get a reliable signature for a given method.
Previously, systems like Squeak used a pattern where objects had a collection of "dependents" that would be updated when sent the `changed` message. I think this is still how input events -- keys, mouse, etc -- work in Morphic.
In either case, the "handler" is whatever you want it to be, so long as the target object implements the appropriate message.
As for discoverable, I'd say most things in a Smalltalk are easily discoverable, though some of the patterns can get convoluted if you're inheriting an ancient object structure.
By "discoverable", I mean can the IDE:
1) Compile/analyze the code in the component library/run-time,
2) Figure out which type of method can be used for a certain type of event property for a given class, and
3) Display all matching methods in the current unit/module for the user to select.
This is what Delphi does (and Visual Studio with WinForms), and all of it is done at design-time, meaning that your application is not getting compiled in order to determine any of this.
From what you're describing, I don't think Smalltalk is doing the same thing. However, it could be doing something similar if it enforces (at design-time) this part:
"so long as the target object implements the appropriate message"
It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk itself) for some end-user or goal. Because a Smalltalk image is simply a snapshot of the state of the whole system, you can use a development image to generate a more bare-bones, customer image/application if you so choose. In other words, you can configure a Smalltalk image however you want for a client. This would be the equivalent of the kind of "compiling" that creates a usable end product. You are manipulating a live system and configuring it for some purpose rather than describing a system in text files, compiling it, and then giving it to people to use.
On a technical level, you are compiling all of the time when working in a Smalltalk. Every time you save, the changes recompile and execute, live, as instantly as these things can.
Of course this means that Smalltalk is highly self-aware, and therefore there can be / are some of the IDE features you've listed. One of my favorites is the ability to provide example inputs and example outputs and see recommended objects/messages and implement the method for doing it. It probably exists in other Java IDEs or something, but I've never seen it elsewhere myself.
I will definitely try Pharo and see how it all works. I've read a bit here and there about Smalltalk over the years, and the whole environment seems really cool. I'm especially interested in the whole "not requiring static types", because that may give some ideas on how to do a JS IDE without losing the functionality that we wish to maintain. The "liveness" of the Smalltalk environment is also very much in line with how JS/HTML are used, so there may be a natural fit there.
That is the top comment by him in that sub-thread. My question to him is 2nd reply below, then he replied at even greater length. Some pretty deep stuff..
(In another of his comments - this one, in a different thread: https://news.ycombinator.com/item?id=14677396 - he also mentioned that Lisp and Smalltalk are two of only a few languages that share some of the features he talks about.)
I recommend getting the Adele Goldberg "Smalltalk: The Language and its Implementation" (colloquially known as the "Blue Book"). I find it to be the second best programming book ever, aside from The Little Schemer.
So I guess another way of saying it is that older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences. The aesthetic and the experience as a whole is important.
>older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences.
Not talking about web sites here, but web apps, which in the modern sense are much more aligned with desktop apps than websites of old.
Regardless, there's nothing that precludes you from wrapping any control you desire into an interface that makes it droppable and configurable through a GUI editor, then have it generate code. Likewise, for the creation of different layout managers, though in practice I don't think you'd find a ton of variability there. Most "experiences" boil down to grid-based and responsive.
So, I'm not sure which precise experiences you imagine couldn't be created. It's all just code. But, if there are some, then they'd be the exception, not the rule.
You can already create simple websites with tools like above. But non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
It's not that the web hasn't caught up to GUI editor paradigm that has been around for decades. In fact WYSWYG web editors were common when the web was in its infancy.
Yeah, you've kind of repeated variations of that vague statement, to which I've replied with specific capabilities/features that SPAs and modern webapps tend to use. I've suggested that they represent very common features/layouts that can readily be constructed with the aid of a GUI tool.
But, here, you've now responded with a few website builders that are not intended to be used for the kinds of SPAs/modern webapps we're discussing. That doesn't make a point, except to say that "other things exist".
Do you have specific examples of SPA/webapp functionality that cannot be readily built with the aid of a GUI tool?
Controls in desktop apps are not just "cookie-cutter" (if I understand correctly what you mean by that). They can be subclassed in C / C++ / Delphi etc. code, to add to, or override, the functionality as well as the appearance of the superclass control. (And individual desktop app developers can, did, and still do this. It is not necessary to buy or downloads such custom controls, anyone can write them - like you say for the web.) This was being done way back in Windows (from as early as Windows 3.x ) and probably in Unix too (X-Windows). In fact, X-Windows may be the source, or one of the early examples, of the famous saying "provide mechanism, not policy" , which is related to this topic. (What that saying implies is that policy - which often involved look-and-feel - could be, and was, provided by higher layers, than the lowest layer, Xlib, which provided the mechanism (for X's style of client-server GUI programming.) I've not checked their implementation details, but probably both GNOME and KDE (which both look and behave rather differently from each other, though both are fundamentally Unix desktop environments), are built on top of X-Windows (in its newer avatar of XFree86 or whatever it is called these days).
 I just did this Google search for the term "paul dilascia windows programming book", and the first search result is:
which is a book by him called "Windows ++: Writing Reusable Windows Code in C++ (The Andrew Schulman Programming Series)" - which was considered an influential book at the time (see Wikipedia page link below). I had read it, years ago, out of interest, even though I was not doing much GUI programming at the time. It showed (with code) how to use C++ to wrap the procedural (WndProc), event-driven Win 32 GUI API in C++ classes, not only for more reusable code (as the book title says), but also how to subclass existing Windows controls and add more functionality to them, or change their appearance, etc. In fact, IIRC, his Windows++ framework completely hid (from the developer) the traditional, error-prone, manually coded WndProc window procedure style of programming, that was the staple of raw Win32 GUI programming. I was quite junior as a programmer at the time when I read the book, but remember thinking even then, that it was something significant that he was writing about, and the book helped me to understand some of those deeper topics to some extent. To describe it another way, the book basically contained the full C++ code for something like a smaller version of MS's MFC or Borland's Delphi or other OO Windows GUI frameworks that wrapped the lower-level raw Win32 GUI API, which involved writing a lot of low-level procedural boilerplate code (with a hand-coded event loop for each app you wrote). That was some general background and history, but more relevant to your point, it shows that customizing controls is very much possible and done in desktop apps too (not just in web apps). And you do not need to write your own GUI framework in order to customize controls, either. You can just take classes from an existing GUI framework that you use, and subclass those classes, and add or override functionality, including both look-and-feel and behavior. The second search result is Paul Dilascia's Wikipedia page - https://en.wikipedia.org/wiki/Paul_Dilascia .
(above page's subtitle: "Creating Owner-Drawn Controls")
Using Visual Styles with Custom and Owner-Drawn Controls:
But I've never seen any layout render engine with the same feature set as modern HTML/CSS engines.
HTML has more features about layout. Also styling is more flexible in HTML.
XAML has better rendering (esp. in WPF), better alpha blending (esp. in UWP), much better animations, better vector graphics, and better editor (you can create acceptable layouts using WYSIWYG, not touching raw markup). Also it has templating, data binding, and other features not found in HTML.
Other technologies cited are very limited, not even close to what current web technologies offer.
Because until recently even basic stuff like centering text or grid layouts were an exercise in frustration.
Not to mention the magical incantation dance with CSS transforms to try to force a browser to use hardware acceleration.
Or nonsense like Shadom DOM to be able to define some sort of components, which are only properly supported on Chrome.
UWP isn't a failed experiment by most measures, and you may not directly notice the API transition in many major Windows components from Win32 to UWP, but it's happening.
For what it is worth, the RAD experience for UWP is pretty good and if you want to make a not-very-well-architected "VB6-ish code behind" app with Visual Studio RAD tools, you can knock it out in about the time it would have taken you in VB6.
There are already people playing with prototyping language runtimes into it.
The pricing is just out of this wolrd. You get the impression that they try to squeeze every last penny out of their existing user base.
People always say one of the main advantages of Delphi is programming of database centric (CRUD) applications but compared to the SAP system it's still inferior. I think the principle of RAD itself may be flawed/dangerous. Sure, for small CRUD Apps with a single window operating directly with the db components (Grid, and those "mapped" Fields) you will quickly have results and it will work. But for larger Applications that all falls apart.
The trouble I see for Delphi is that the whole eco system is rotten. In my perception there are only a hand full suppliers of components and libraries left. Some of those components are barely maintained and even worse documented. There is lots more knowledge and up-to-date examples available for C#.
I used to think that about Delphi, various commercial Lisp implementations, etc. But after some time I've changed my view a little.
My change is because I realized that Delphi had its chance, and kept on trying as the chance slipped away. No amount of competitive pricing today is going to make a resurgence of Delphi happen. That door is closed, for all practical purposes.
The alternative is to offer products and support in a sustainable way and given the small number of people using Delphi professionally today, that means charging somewhat hefty amounts. IOW, their target market is business that has Delphi products that are worthwhile to maintain. In order to stay in business and provide service they have shed casual users.
I disagree. Delphi is still great, and with a less tone-deaf it could get very well.
Note that Delphi still have a healthy position today:
(Position 9, above Ruby! and others!)
(As much as we can debate about Tiobe and other indexs, is important to note that is still way higher that many will expect, and the flow of information we see in the community is very good, much more than many other hispers options)
The thing is that price is in fact the main problem. This kill the open source ecosystem options around it.
I will totally, like many others (I know, I'm moderator in on of the most important forum in Latin-America) work more for it but without a way to reach a large audience it kill many ideas we have.
Delphi was the most sucesfully opensource but commercial (as, you have the source) with many thirdy-party options. Think like the current React-Components market but maybe larger and years ago.
If you're right and companies just can't see that or make it work, can the community do more with Lazarus? I have not played with that so I don't know how good it is.
We (the community) have tell Borland and sub-sequent owners exactly what to do, and have been never been heared.
To see why it failed, read :
In the height of the enterprise transformation, I asked Del Yocam, one of many interim CEOs after Kahn, "Are you saying you want to trade a million loyal $100 customers for a hundred $1 million customers?" Yocam replied without hesitation "Absolutely."
This is it. Management trade a large and healthy ecosystem chasing the rainbows.
This will fail for sure.
Lazarus is ok, except that suffer from the same disease of most open source projects: Lack of focus and good funding.
Look at every other Delphi competitor from the time period. Microsoft is giving Visual Studio away to casual users and Visual Basic is now VB.Net. Eclipse and IntelliJ come in free versions. There is no longer a market for a million loyal $100 customers for a programming language and ecosystem. There are too many high-quality free languages, compilers and IDEs to make that business model work anymore.
We know the old model will not apply here. That is clear. That is not what we have tell them.
What we have tell them is that the tool must have a opensource compiler, and free tier and a reasonable pro tier. Xamarin was a good sample.
Also, take in account that the millon loyal customer is not that unreasonable to find:
Until JetBrains came on to the scene.
The only options available were a few 4GLs that cost more than even Delphi licenses are worth nowadays.
One of the many things I loved about Delphi compared to other RAD tools of the time was that it was the only one that supported and encouraged modular separation of logic and UI. In most others (VB!), the IDE did nothing to help you, and most people ended up with all their logic mixed into the UI code, simply because the UI code was the focus of the whole IDE.
The Windows platform was awful so I ran away to Unix, and trying to find something even close to Delphi was just impossible. The best thing we had was Tcl/Tk, which I used a fair bit.
I tried Java at the time and remember saying to myself: You got to be kidding me.
Eventually I gave up on GUI development for Unix and embraced the web browser is the UI philosophy and develop the back-end in Python (then a fairly new language). Best career move I ever made.
I'm still fond of Delphi, it was a great product.
I'm 100% with you. That's why I switched from Delphi IDE to Visual Studio Code with OmniPascal (www.omnipascal.com). It's much nicer to work in a state-of-the-art editor.
IIRC the average SAP deployment is in the region of $10 million.
Sure, for enterprise-level things that's justifiable, but most businesses don't have that sort of money to throw around.
The provider plays nicely with the client dataset and let's you interact with UI elements, sending automatic updates to the database through the soap service.
So when I switched to the Linux build, I noticed that data provider component in the components toolbar was disabled. That means it isn't supported on Linux.
Tricking the IDE with a Windows project, placing the provider in a data module and switching it to Linux target, I tried to get it to work on Apache. No response from soap.
After a couple of hours of eyeballing and recompiling the provided Delphi sources, I realized that the support is actually there, but there were some programming errors such as not implementing the entire interface, and somehow the memory manager behaved weirdly on Linux, causing another interface to go nil while refcount still didn't reach zero.
All in all, Delphi makes it easy to build Windows applications, complete with data layers and Model-view style. I just wish they would hurry up with the Linux server support.
If you haven't tried Lazarus/FreePascal, you're missing out. It's really amazing, and it's truly free.
That aside, one thing that I like about FP is their text-mode IDE. They basically copied Borland's original Turbo Pascal (circa 7.0) IDE for DOS. Except this one runs on Linux etc. And, of course, has a lot more features. There's something about that TUI goodness that is hard to capture in modern GUI IDEs - and then it's also blazing fast (you think Sublime is fast? ha).
Builds to Linux, ARM/x86/x64, macOS, iOS, android, Windows, freeBSD and I'm sure I'm missing a few.
It actualy surpassed Delphi in some ways. You can develop native programs on non x86 platforms. The IDE and compiler installs and runs fine on the Raspberry/Nano/Orange PI boards, and others, so if you want to write a GUI to view sensors and actuators status, or maybe a display for a homemade KSP controller, the tools are there already. Free both as in beer and speech.
Still I feel that going with Qt is more future proof.
In all frankness I don't get why Embarcadero doesn't copy Qt's licensing. If they make a free GPL version, Delphi-based open source could thrive while just about everybody who buys a license now would still be required to buy a license.
It's the same with commercial CommonLisps, I'd love to use one, but the pricing is ridiculous for small companies / hobby programmers. That doesn't add up, you'd have to be 100% sure that you'll earn more than X dollars with your application and you can never be sure of that.
Plus I want it to have a tiny memory/CPU footprint and while .NET/WPF is better than the average Electron app I still notice a difference.
EDIT: Just saw your second addition... not so sure I'd agree though, the performance on startup of .NET applications these days is quite excellent and I haven't been able to tell for years, but I've been on SSDs with lots of RAM on recent chips I suppose.
I'm probably ending up with prototyping in Racket and writing the final application in Qt or Lazarus.
TP and Delphi, obviously, require no apologies.
And C++ powers Google, Facebook, 100% of AAA games, 90% of mainstream OSes, and 90% of all top-of-the-line commercial programs (from browsers and office apps, to Photoshop and AutoCAD).
Nothing to apologize about RoR either.
And yes, the language itself is a joy to code in. Which is opinion, not fact, I realize that.
No need to apology for them.
Until a couple of weeks ago anyway. I'm working on an emulator for an 8 bit Fantasy computer that uses an avr compatable instruction set. I recalled that there was a avr target available for freepascal and gave it a go.
I had to build a trunk version of Freepascal with my own modifications to support my Emulator. It has almost no run-time library. It's just the language, and I really enjoyed using it.
Coming back to Pascal after using so many other languagese in between provides an interesting perspective. You become more aware of the strengths and weaknesses. There are now a few things I would change If I were to make my ideal Pascal dialect.
So yeah, everyone moved on from Delphi, it's currently on palliative care, probably won't die any time soon, but it's becoming irrelevant as time goes by. If it wasn't for this post I wouldn't even remember it. We have much better technologies and IDE today. Good riddance Delphi.
The project might have started in 1999 (actually the codebase is slightly older according to their history page) but it took a decade for it to be usable.
Of course today things are much better. It is the most stable environment i've worked with (as long as you stick with the official stable releases anyway - note that releases from getlazarus.org are not official and often contain immature code) and even though it isn't as fast as Delphi in terms of compilation speed (and sadly the FPC devs do not care about compilation speed... what is with compiler devs these days giving zero care about compilation speed? Sometimes it feels like only Borland cared about it) it still is faster than most environments (except Borland's) i have used.
Now open source and vendor tools have completely won that space, and its only possible to profit from developer tools indirectly. So not just Delphi, but the entire associated business model has become irrelevant.
Sure, I would love to rewrite the whole thing in Lisp (which is the language that lets me keep my soul), but we are all in all still very happy with the current code base.
A complete recompile is less than 20 minutes, and then about half that time is spent in guile for macro expansion (we have a macro DSL). We have considered porting it to chez scheme, but we rarely do full recompiles.
Pascal lends itself well to big codebase, but will probably never again be a new cool thing. I do however believe that being able to test a big change on a Dev machine in less than 10s gives us a pretty big advantage over similar solutions in other languages.
A kind salute to you, fellow Lisper!!
However i've used Delphi in the past and found it a remarkably good language, i wouldn't think to port something from Delphi to Lisp.
OTOH: We are now at a position where I am pretty sure we are a perfect fit for Greenspun's tenth rule.
The amount of time we spent to make a large part of our code stateless is mind-boggling. We now have the luxury of being able to copy the state of almost 100% of the user-facing stuff and send it back home for us to test. That would have been so much easier with something like Allegro CL.
I have actually implemented a pretty neat macro system in guile scheme that I am in the process of cleaning up for an open source release. We write parethesised, prefix pascal for our macros that gets expanded to regular pascal (easy for most algol-like languages). Having a proper macro system made it possible to remove _a lot_ of boilerplate, even though we primarily use it to generate code that the compiler can optimize easier.
- Delphi 7
- Delphi 10.2
- CrossKylix (http://crosskylix.untergrund.net)
- CrossFPC (http://www.crossfpc.com)
And are able to compile native code to a gigantic amount of platforms, all from within a single IDE. Web stuff we also do, with ExtJS as a front-end.
If anyone is looking for a hardcore Object Pascal job in Germany, let me know :)
How do you build for iOS, for example? I thought you had to use Xcode.
How do you convince clients that ObjectPascal is the right solution?
That is, are client concerned that you're not using Java/ C#/ C++?
I've always thought Germany was fairly conservative in this respect.
"My colleague told me to abandon Delphi, it’s obsolete, Silverlight is the future.”
delphi outlasted silverlight
honestly myself i was surprised by how easily and relatively fast microsoft abandoned silverlight, i really liked their rad tool, lightswitch , but it seems it was strongly coupled to silverlight, and got abandoned soon after it was announced that silverlight will not be further developed
makes you think, you cant bet on a product, because it is supported by a large company
Although that is a proper conclusion, the majority of successful programming languages always had a corporate sponsor driving their adoption and development, even the ANSI/ISO ones.
It has been that way since well before I started using Object Pascal.