I remember using Delphi 2 when I was younger, that's how I learned programming. If you don't mind hearing my personal story, keep reading, otherwise move on to another comment.
By an interesting coincidence I was given a CD with tons of software on it, including Delphi 2. I started playing with it and quickly realised I could create my own programs using that tool.
Later I went to the book store and found a book about it that I couldn't afford. So I came back every week to read as much as I could, then heading back home to try it on my illegal copy of Delphi. (I was 11)
Then I realised there was a help manual embedded in the distribution, so I learned as much English as I could so I could understand that manual.
Little by little I learned about conditions, loops, object programming and made a bunch of terribly crappy yet working games.
No amount of studies could have taught me as much as I learned through using that software. No manual work could have given me the fun I had when programming my very own games. Reading "Delphi" as a headline on hacker news made me feel nostalgic and I figured I'd share my story here.
So thanks Borland, the 11 year old me may not have paid to use that software, but it was enough of a revelation to make me the programmer I am today.
Same thing here! I never would've learned English if it wasn't for GW BASIC and Windows 98 - certainly not in the crappy schools of the post-war Bosnia!
Twenty years later, I'm still writing way too much Basic code (VB6 legacy apps and some VB.NET). I do appreciate a lot of things about the syntax and wish C# had picked them (no semicolons and no case sensitivity).
Hey, it sounds very similar to how I learned programming. That's how I started too, apart from the fact that I had a simple Turbo Pascal book from the beginning, but I also learned writing programs using an illegal Delphi 2 CD.
Ditto! I feel the same way. I learned both English and programming on Delphi 3. The first program I wrote showed and hid a picture on the screen. I wrote a few games, but didn't understand types and generics until years later.
For nostalgia's sake, may I ask what games/software you developed at the time ?
On my end, I did:
- Snake, and a Snake level editor,
- Sokoban, and a Sokoban level editor,
- an adventure game Zelda (NES) alike (but was not fun at all !)
- Graphic calculator (to help me visualize the change of parameters quickly),
- a software to visualize my grades compared to the rest of the group
- I made a software to search and categorize html tags
(during my high school years)
What impressed me the most at the time, was that my binary file compiled on Windows ME would work directly on my other computer with Windows 3.1.
This is something I still really enjoy today with Go(lang); the fact that I can just compile for other platforms and run it natively.
It's really cool to see how many people shared the same experience!
In random order, and off the top of my head:
- pong
- some various demo where I would simulate fireworks or
traveling through star (in other words particles that are
rendered by drawing dots and circles on screen)
- a car racing game viewed from the top
- an RPG engine but never actually made a level
- a claw machine
- and finally my own remake of space invader where you could
play up to 4 in coop and upgrade your weapons. It had bosses
and swarms of enemies. I learn then there was a limit of how
many keys you can press on a keyboard before your computer starts beeping.
This is one thing I really really liked about Go, but unfortunately I don't really like the rest of Go very much. What are other languages that have this property? Building an ".exe" I can send to a Windows user is not a pleasant exercise in Python.
For windows, you can use .Net (which usually comes by default on windows distributions, so you should be able to send it and run without any issues). C# is a good language that uses it.
So it's not really native (it runs on a VM), but it produces the .exe that can be easily shared.
On the topic of Delphi, try FreePascal / Lazarus? Free, dependency free development even with GUI designer. FreePascal (non-GUI) supports an ungodly number of platforms!
Otherwise, can't recall much else, discounting cheating with e.g py2exe.
I started programming in basic (first on ZX spectrum clone, then QBasic) but really started writing meaningful programs in BP7 and then Delphi. On the other hand I'm pretty sure that I learned english by printing out the whole readme for Build engine that was on the Duke Nukem 3D CD and reading that.
This is pretty much my story as well, I learned how to program for real on Delphi 2. Though I was able to get someone to buy me the book. Thanks for sharing.
Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment. It's much easier than QT/GTK and you usually get a standalone .exe with no external dependencies.
I really want to cry when I see the current alternatives... Node/Electron with dozens of MB of runtime and all that Javascript stuff? What went wrong that we end up with this?
IMO Pascal is a good, clean language and Borland was a top engineering shop that built Delphi as a rapid development tool that supported Windows. At the time there was nothing comparable for Windows development. There was a huge marked for Windows consumer applications and games (Linux was not a household name yet) and very little outside of clumsy Visual Studio to write them. I recall reading at WSJ at the time that Borland CEO was the only person whom Bill Gates feared as a competitor.
That said, it was 20 years ago. Now there are IMO much better cross platform tools for RAD (Python, Tcl/Tk, ...) and Delphi is showing its age (no Linux targets?). Unless I have to live in a Pascal world there are much better tools today. My 2c.
Linux is coming in the next release - there will be a blog on that soon. It already has Mac, iOS, and Android on top of its Windows support.
Honestly, I do not believe that Python or Tcl/Tk count as "good" RAD cross-platform tools. Only if you've never used something like modern Delphi to compare them to. We regularly have customers give feedback about their productivity with Delphi/C++Builder, versus Python, C#, etc, and they say they get apps completed and released twice as fast or often more. "5x" is quoted often in our marketing material, and that number is not marketing, it's based on numbers people tell us.
- David (one of the PMs at Embarcadero; I work with the blog author Marco.)
There were some other issues then (I worked for Borland at the time, QAing Kylix) including not really understanding the FOSS community and GPL-the-social-movement part very well.
There was a particularly big flap over them not stripping the corporate audit clause from the free Kylix Open Edition version targeted at OSS dev; and another regarding enforcing the mandatory "Made with Kylix Open Edition" splash screen that was linked into your app at the compiler level, since all the library code was technically modifiable per licensing.
I also seem to recall that they managed to standardize on Red Hat 7.2, which I think had the much maligned gcc 2.96 fork in it and possibly an older glibc, and then had problems with later kernel/glibc/something along those lines versions such that you were locked into the "bad" version of Red Hat using it.
I probably have some of the tech details jumbled 16 years later, but the TL;DR was that the development community for Linux is nothing like the development community for Windows, especially back then. There were simply different cultural expectations and a hugely diverse set of environments to target, along with a swiftly moving ecosystem to link against.
Upshot, Kylix more or less flopped and Borland switched gears to Java/JBuilder-based IDEs for C++ compilation (C++BuilderX), then back around full circle later focusing on single-platform IDEs for .NET/native Windows.
> Only if you've never used something like modern Delphi to compare them to.
The last time I used Delphi it was on version 5. I never used anything for desktop GUIs on Python or Tcl/Tk (or any other language) that comes even close to it. That requirement of "modern" is too outreaching.
But I'm impressed by Python's kivy (but still didn't really use it), and there are some interesting things happening on Haskell circles. I'm optimist in that Delphi's decades old title may fall soon.
David, thank you for the work on Delphi! I think my post was seen as bashing Delphi. It was not the intent; the fact that Delphi has a thriving user community willing to defend it is a proof to its usefulness.
To each his own. I work in a cross platform world with a roughly equal mix of Linux and Windows and my personal preferences are with the standard Unix toolset.
The beauty is in the eye of the beholder (and I put IMOs liberally in my post). The OP mentioned GUI prototyping and I was viewing Tk in this context. For rapid prototyping, Tk is a better solution for me, by far.
It is a very simple, script language that allows creating dynamic GUIs on the fly. I can make a simple GUI and hang calls on buttons and menus with a few lines of text. No compiling. No library mismatches to deal with. Whiteboard sketch to a working prototype often takes less than an hour, almost never more than a day.
It is cross platform and text based, so we can email prototypes around for people to try it on their Windows, Linux and Mac machines, click on buttons and report what they want to change. It is text, and does not require installing software. This is a noticeable advantage in locked-down environments, where installing Tk once and running 10 scripts is much easier than installing 10 revs of software.
Due to the language simplicity we had people who said they have no idea about it (and no plans to learn it -- they just wanted a prototype) making and sending back mods within a few days of getting the prototype. This is great -- then we know that this is what they want.
Tk is long in the tooth and has many limitations, but for rapid GUI prototyping it is one of the most useful tools for me.
Of course for more than trivial built-in behaviours you'll be writing code, but for a UI prototype, especially if it's just CRUD forms etc., you can get it built in a few minutes with no code. Drop a database connection component and set the connection properties, and you'll get live data and properly typed and bound controls on the form too.
Compilation takes fractions of a second, so that's not an impediment to design iteration - but you don't need to compile or run to see what it looks like since it's effectively a WYSIWYG form designer.
Problem with Delphi-style RAD tools is that there is huge step in complexity between things that can be done in the designer and these that can not. And this invites particular style of "programming" that consists of searching the internet for existing components and connecting these components together with horrible hacks. It is perfectly possible to write well-structured application in Delphi, but most are not.
[Edit: hit reply too soon] Tk model of UI programming does not promote this that much, because causing stuff to happen by writing code is the default way. Also Tk-style approach of writing GUI definitions in code and letting the toolkit to deal with details like positioning (in fact, using HTML for UI is mostly similar) is more productive.
I don't really want to get into a long-winded discussion, but (a) the GUI definition in Delphi is also code (specifically: there's a declarative syntax for constructing a tree of components with property values); and (b) positioning is handled by the VCL. Typically you specify things like alignments and borders in the designer, and the VCL takes care of keeping things positioned.
I really wish HTML was as easy to design with as the VCL designer. Trying to e.g. create vertically centered children is far, far easier in the VCL than in HTML + CSS.
I'm assuming this person hasn't actually used Delphi...or Python Tcl/Tk.
I can throw together a very nice looking GUI app in one sitting in Delphi, where laying out the elements and binding and defining events is absolutely trivial.
In Python, with Tcl/Tk, I don't. I use C#, qt, or even flask. Tcl/Tk is absolutely not appropriate for RAD GUI development, unless it's at some hello world level of complexity.
For my scientific needs, it was more than adequate, and scientists are a big part of programmers (but not necessarily professionals). However in that league eye candy does not count, instead saving lives or making our world better are of bigger priority. Tcl/TK or in its incarnations ScicolsLab/Tkinter/ Ocaml-Tk have saved the day very often.
For Tcl/Tk, there's vTcl which resembles Visual Basic 3.0 (for Windows) as far as laying things out. It supports all three of Tk's geometry managers (grid, pack, place) and you can simply drag-and-drop your way to a GUI in seconds if you're into that kind of thing.
Further, there are several experimental projects that support running Tcl/Tk over HTTP/HTML rather than X11, Win32, SDL, the current Mac OS X/macOS GUI system.
They produced Kylix not that long ago - I had an original box set once upon a time. I have no idea why that didn't take off, but it was an excellent environment really.
To clarify: dependency on wine means that the IDE was essentially windows application (stripped-down delphi) running on top of wine . Wine was not required for deployment of applications.
Kylix was doomed from day one; I saw an official presentation (IIRC by Marco Cantù himself) ages ago and was shocked by its slugginess. At that time I was playing with Delphi2 at home and using Delphi 4 at work, and both of them literally run circles around Kylix.
Today Delphi on Linux to me is called Lazarus. Some nasty bugs plaguing it are long gone since like 3 years and is very stable at the moment. You can even install it on a ARM based board (Orange PI PC here) which means it doesn't simply cross compile the code but the IDE itself runs on ARM architecture!
20 years ago, RAD meant that you could drop visual components on a form, add some events, set some properties, and hit the green run button to compile and run it.
A very visual way of programming.
QtCreator with it's visual designer comes close, but then you have to suffer a more unforgiving syntax (C++), a complex macro compiler (MOC) and not at all easy cross-compilation / distribution.
In 1994, I was looking at languages for a Windows GUI project, and I narrowed my options down to Borland ObjectVision (a sort-of "predecessor" to Delphi) and Visual Basic 3.0. I went with VB3 because the userbase was larger, but I've always wondered how my career would have played out if I'd chosen the other path.
You're probably thinking of Object Windows Library (OWL) [1], a C++ library that was available to both Turbo Pascal for Windows and Borland C++, and which was briefly available for other platforms, including several Unix variants.
Borland also had the older Turbo Vision toolkit, but that was for MS-DOS. OWL was designed a very similar class hiearchy.
The strong point of Electron is easy _cross-platform_ application development and packaging (spits out .exe, .app and Linux binary), with no further dependencies. Ever tried packaging a QT application for Mac, Windows and Linux? I can tell you it's a painful experience, one I don't want to repeat.
Also HTML+CSS allows for extremely versatile styling and fine-grained control of appearance.
> Ever tried packaging a QT application for Mac, Windows and Linux? I can tell you it's a painful experience, one I don't want to repeat.
Qt guy here... Windows and Linux are a breeze, pretty much dead simple as I thought they'd be, just run winqtdeploy, make installer out of resulting directory, copy other libraries, done. On Linux, just ship it and install dependencies on target or make a package appropriately.
OS X however is a nightmare if you need other libraries beyond Qt unless you know all the voodoo of install_name_tool. But maybe that's just my experience showing.
A weak point, though, is JavaScript — quite possibly the worst popular computer language in history. I honestly think I'd rather starve than write another line of JavaScript again. Even reading JavaScript diffs from other guys on my team is a horrible, terrible experience. It's just a sad, awful, miserable, verbose, broken language.
As a compilation target from a better language, I suppose it's mostly acceptable. But on its own? Never again.
It's not just that the language is bad, it's also that the ecosystem encourages bloat and terrible implementations with layers of fixes glued on top of each other.
My current main work laptop (a pre-TouchBar generation MBP) can only barely run a "heavy" JS-application like Slack and something like IntelliJ at the same time.
Migrating Slack into an IRC client reduces the CPU & memory footprint of _sending, receiving and displaying text_ by over 90%.
Something went seriously wrong somewhere and we're only going deeper into the hole.
>My current main work laptop (a pre-TouchBar generation MBP) can only barely run a "heavy" JS-application like Slack and something like IntelliJ at the same time.
Is this hyperbole? I run both of these with IntelliJ memory settings maxed out on a MPB no problem. Granted, I have 16GB of memory, so understandably YMMV.
No. Just checked and this is an 8GB machine, running Slack with ~9 simultaneous networks (unfortunately lots of open source projects are moving to half-deserted Slack networks instead of IRC channels) can easily use more than half of that.
"Worst popular computer language in history." That's a bit strong, isn't it? It certainly has its faults, but so did VB6 (and other BASIC variants, for that matter). PHP gets widely slagged off as well. Does it deserve it? Possibly, to some extent, but people still manage to successfully build useful software with it.
With JavaScript, the problem isn't so much the language (though there are many ways to use and misuse it) as its ubiquity and ease of entry. Because it's so popular it attracts many novice programmers who write terrible code (but that's how we all start). If we're going to have any good, experienced engineers in future then we need those novices now.
If C++, Haskell, Ruby, or Scala were as popular as JavaScript - particularly if one of them were the standard for client-side web programming - there'd be just as much terrible code written in those languages; it would just be differently terrible.
I disagree. Languages like Haskell are much less tolerant of terrible code, which is a large part of the reason why beginners struggle with it.
I work with other peoples Haskell code daily; and some of this code has been written by domain experts. Nevertheless, Haskell mostly forces them into line. Our competitors use Python because it is superficially "easy", I can only imagine what horrors they must be dealing with.
Part of this is that with Haskell it's much more like there's one right way to do things, and that's it. JavaScript is a multi-paradigm language and so in that way it's always possible to get into more of a mess. I could say the same about, for example, C++.
Maybe beginners do struggle with Haskell but, if you want my two cents, the reason nobody really bothered with it back when I was at university - except for assignments where we had to use it - was because there was no call for it out in the world (this is going back 17 years). Most people built their projects in C, C++, or Java because those were what you needed to get a job. I'd also observe that the same people that struggled with Haskell also struggled with C, C++, and Java [1].
Again, based on the assignments where people did write Haskell I'd have to suggest that it absolutely is (or was) possible to write terrible code in Haskell. Certainly it's possible to write broken, fragile, or barely functional code that's hard to understand.
[1] This is of course anecdotal evidence based on a small sample size - maybe 40 people on the course.
Funny, because I would hire a person straight from university as a junior developer, if she chose to write all the assignments with Haskell instead of going with C/C++/Java/whateverpopularlanguage. That would be a really good sign.
I think times have changed though. Functional languages just weren't big back then the way they are now. Back in those days Haskell was sloooooooow. There's 17 years of runtime and compiler optimisation, not to mention MUCH faster hardware, that's been developed in between. It's now totally realistic to use the expressive power of functional languages on real-world workloads in a way that it mostly wasn't back in Y2K.
There's a continuum of restriction of style. The Python guys say the same thing about Perl. "We can handle our diversity, but the Perl guys are completely out of control so I don't know how anyone can handle that."
Imagine being a clothing designer and told to make something. The output could be anything from Beyonce's grammy dress to a famous deceased CEO who wore black turtlenecks all the time. That extreme diversity of style is both the greatest strength and the greatest weakness of allowing a wide allowable spectrum of style. On the other hand a men's business suit tailor is much more restricted in that everything kinda looks the same which makes things both very easy to muddle thru and very difficult to stand out at the same time.
I'm not sure I like your clothing analogy, it implies that Haskell deliverables are somehow restricted in functionality, which isn't true. The "style" that Haskell prohibits is hiding side-effects and mutable state behind something that pretends to be a function. If you are honest and upfront about what you are doing, i.e. you fully understand what you are doing, then Haskell has no problem letting you do it.
Every programming language has it's warts. JavaScript is in a unique position in terms of the level of backwards compatibility it is required to maintain. It integrates some powerful features with it's lisp-y functional style and closures. It's implementation of prototypal inheritence isn't the greatest I've seen, but it's by far the most successful prototype based language and that is something I personally wouldn't mind seeing become more mainstream.
Despite thinking JavaScript itself has some really great qualities; I generally don't think Electron is a great solution for desktop applications. Executables are too large and slow compared to a good old fashioned native application.
The problem with it as a compilation target in my experience is that interacting with other libraries becomes challenging - the JS ecosystem is now huge, but if you want to use many of those libraries from a wrapping language, it's possible but might present many challenges.
Like Typescript definition files. Producing them on a massive libraries is near impossible for a single individual to undertake. I've seen some people try to process them from docstrings, but the result was really kludgey.
I think writing Typescript definitions for a massive library is usually pretty straight forward and I've got a few that I haven't minded writing/helping maintain. "Good enough" typings can be very quick and easy to build and "Perfect" typings take time sometimes but nowhere near "impossible".
Furthermore, Typescript recently made it much easier to work with libraries that have no typings at all. If you don't mind implicit anys, things might just work. If you are strict about no implicit anys then the minimum boiler plate to define a module with any type has dropped to a bare minimum:
declare module 'module-name'
If I have a complaint in that space, it's that sharing typings is a lot more complex than I think it should be. DefinitelyTyped is a single megarepo where most typings originate and has developed a culture of trying to get typings perfect. Unfortunately, perfect is the enemy of the good, and "good enough" typings for lesser used libraries often languish in PR obscurity, at least in my experience.
Beyond DefinitelyTyped, libraries can embed their own typings in their npm packages, which is great, but not every library author is thrilled to "own" Typescript typings. (All in all, I still feel like I have better luck contributing typings directly to library authors than DT, though.) Beyond that there are tools like Typings to grab typing files from arbitrary GitHub repos, for instance, but there's not much of a good way to advertise types that way because most people will only check NPM now.
Sorry, this seems to have turned into more of an off topic rant than I at first intended.
I haven't tried the new versions, so I don't know how easy it is, but Delphi claims to do easy cross-platform now, too, for Windows, OSX, iOS, and Android.
> Ever tried packaging a QT application for Mac, Windows and Linux?
How long ago? I've never done Linux, but Mac it comes with a script that does everything and spits out a .dmg. On Windows it spits out everything into a folder you can zip up or create an installer.
I miss VB6 and VB.net desktop apps as well. still my go to platform for personal apps, so easy to write. Not really sure why for internal company apps people are moving to webapp.
We use web apps at my company because almost all developers know how to make them, not all computers are windows PCs, and you don't need to install anything of download anything for someone to use them.
If you're talking about electron apps, that's a whole other ballgame. We don't build electron apps for internal stuff afaik.
To be fair to him, it used to be that everyone knew how to make desktop apps and no-one knew how to make web apps. So that's definitely not the reason.
I can tell you with 100% certainty that the primary reason we build webapps for internal products at my company is because all the developers already know it. I understand this is more of an anecdote, but I really find it hard to believe other companies aren't making similar decisions.
I can tell you that I agree completely with that. But, that's not at all what I'm disputing.
People within companies are building web apps because thats what they know. The world has changed in the past 10 years. In response to that, you took a hard line stance that this is "definitely not the reason." I disagree.
I _think_ you're trying to argue about why developers -- as a whole -- have moved towards web apps, but its hard to say because that's not at all what I'm talking about and you haven't made that part clear.
Gone were the days of having dB passwords on every machine and wandering from PC to PC with a floppy or CD.
And that was the problem with desktop apps 10 years ago.
Even when MS fixed deployment for desktop apps they still left it massively overcomplicated. It should have been a simple one click in visual studio to build an installer and it never was.
One click deployment was/is pretty awful too that came out just as Google pioneered background updates.
I miss them too. VB6 was usually the fastest way to build something that simply did the job.
Now that I'm older and can't mode switch between languages as quickly as I could when I was younger, I find myself just using Node for my personal stuff.
Honestly, it's because the approval required to get an executable onto an employee's computer is absurd. If we can get chrome or firefox on the system image, then all we need to do is point them at a URL. Actually adding software to their computer requires all manner of support tickets and manager approval for them, so they won't do it.
It was always my impression that Delphi is significantly more productive for LOB CRUD than VB. In Delphi you can create meaningful CRUD applications in which all the manually written code consist of single-line methods of the FooForm.ShowModal variety.
Web has a good deployment/discover-ability/accessibility story, Node/Electron/Cordova are just there to reuse the work you already did.
It's not technically superior but it's economically superior since you usually get maximum reach with web and then minimize cost with the hybrid approach.
Distribution is the number one reason we do webapps at all. I feel this point is sometimes lost on younger generations that have barely seen on-site deployments at all.
Sometimes you don't need the distribution magic that webapps allow, and can dispense with the huge overhead that comes with it. That's where tools like Deliphi/Windows Forms et al can make your life easier. Today it's a corner case, but it's worth keeping in mind that it's still an option.
> Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment.
Try Unity3d component-based uGUI that you can edit live during the "playmode". After building complex UIs in it, going back to Xcode Interface Builder is like moving from iOS to a smartphone from 2005.
I fully agree. I sometimes wonder, why so many people jump to fancy frameworks like WPF where you need to create the markup yourself. I can spit out interfaces for desktop apps in no time with good old winforms but struggle to write data-bindings, triggers and what not in other frameworks. And it even looks consistent and the tools are generally easy to adjust and extend.
You don't need to write the markup yourself with WPF. You can drag components into the designer just the same as with winforms assuming you are using Visual Studio, and everything will look pretty standard unless you go out of your way to change it.
As to the databinding, I find that WPF has more upfront work in databinding, in that you actually have to write some code, but that it's a lot more flexible in the long run. When I used to write winforms, I usually ended up with a lot of business logic embedded in hooks. It was a mess and was hard to reason about.
I think there is an interesting learning curve point where once a developer gets used to WPF layouting/templating, databinding, and MVVM patterns that developer will forever after be way more productive on WPF than WinForms.
i fully agree! though technically, there is a pretty big dependency there - the .NET Framework...
however, Mono supports WinForms on all platforms, and is able to compile everything into one standalone EXE. to be honest, i have not tried either, so i cannot say much about how that works in practice. from my experience with Mono, it can be dangerous. every now and then a new version breaks threading, causing mysterious pauses or crashes, and i've read (i think a text by Ayende) that the GC can also be buggy. but for the stuff that Delphi was good at, for smaller RAD apps, it might be worth a try.
Windows Forms was (and is) primitive compared to how easy qt/gtk and just about every windows toolkit ever made. It was built for machines to generate, not for humans to code, so when the code generation breaks (and it will) so does winforms.
> Node/Electron with dozens of MB of runtime and all that Javascript stuff? What went wrong that we end up with this?
I'll tell you. Microsoft and Apple need to protect their native app license revenue, so they hobbled Netscape, brought browser development in house, and made a prohibition on allowing web pages to be integrated tightly into the OS.
If those electron apps could get the same OS integration in the browser as native apps get, the distributable could be kilobytes, even smaller than your Delphi executable.
But how would Microsoft and Apple make money if they're just a host for web apps? They're not going to turn themselves into a commodity/utility.
There is simple counterargument: there is integrated runtime for webapps in windows since at least windows 98 (probably since 95 desktop update bundled with IE4). Just rename HTML file to .hta. Running that gets you IE window without any browser UI and scripts in the page run outside any sandbox and can interact with windows API anyway they want. Various windows components are exactly this.
Why users have to rename anything? Do they have to rename .exes or .msi?
In early '00s, there surely were apps made and distributed as .hta files. Not much as .exes, of course, because even with ActiveX, DHTML was quite limited.
Heck, when I was in school, me and a buddy wrote a desktop web chat client using that tech (we wanted fancy text formatting and image posting that "official" webchat page hadn't, but we had - because it server lacked proper HTML sanitization, lol)
This seems... backwards. What integration could MS give to web apps that they aren't already? Microsoft replaced their help file format with HTML starting with Vista. HTML and JS are first-class languages for building UWP apps. If anything, it's Netscape's lawsuit against MS for bundling IE that kept them from doing more to integrate web pages into the OS, not the moving of browser development in-house.
Start menu integration, USB device access, graphics and sound APIs, notifications...
Just look at the Windows APIs there are a wealth of things Microsoft doesn't want in browsers if they can avoid it.
Well... there are people on the browser team trying their best, but the resource constraints keep investment where it needs to be to protect Windows and Office licensing.
Historically, the web version of office is not really a stand-alone product, and is designed to be a helpful feature for people who primarily use office on a Windows PC.
I think Office 365 can definitely stand alone and compare with something like Google Apps (GSuite). That many people use it in conjunction with offline Office is more a result of offline Office being the incumbent during the transition.
Rebol/View (& SDK) was a great alternative. An extremely light weight language, library & cross-platform GUI (exe was under 1mb). Ideal for very rapid GUI prototyping...
NB. I say "was" because Rebol 2 SDK has (i believe) been discontinued. Rebol 3 & Red do offer new GUI / encapping replacements but not at same level of maturity.
Shout-out to Lazarus/FreePascal. It is like all the best parts of Delphi 5-7, and it is open source, free, and you can make commercial applications in it!
I have started using it in earnest and it is wonderful - and a company can never take it away from you; there's no "we're shifting focus..." announcements. No paid support for broken updates.
I can confirm this. I have used it a couple of years ago for a GUI app I needed at work (1): Lazarus was a real time saver! When a colleague asked me if he could use my app under Windows, the porting process was 100% painless: all the code (~1000 lines of code) recompiled in an instant and the application worked like a charm.
"Borland lost its way when executive management decided to change the company to pursue a different market.
...
...
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."
> 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."
And he is 100% correct. It's way easier to double the profit from 100 customers than it is 1 million.
Correct only for money. But a language MUST go for reach.
Is no that is bad to try to catch the fat-money, is that them forget the rest.
This make Delphi fade. And impossible to some of us to even continue using it.
---
The current free version is something new, however this have been try before but never consistently, so is unsure if I get Delphi free now it will continue.
Can't do much with free. It's a waste of time. Give us some affordable professional options (i.e. Windows only professional for 300 bucks or so). Have a look at Jetbrains, they have figured it out.
At work, I inherited maintenance of an in-house application a coworker that left the company wrote for our accounting department. In Delphi.
When people speak highly of Delphi, they always mention how great the IDE is. Personally, I am not a big fan of IDEs. I was not disappointed, but my mainly, what I do is read and edit the source code.
And I have to admit, that part was a pleasant surprise! I had never looked at or touched Pascal code before, but I was able to make a change to the source - and it worked, the very first time! - within a few days. And the majority of that time was spent figuring out how the code was structured[1] and what the accountants wanted me to do (they always talk to me as if I knew the first thing about accounting).
But after that, it was smooth sailing. It sure helped that my predecessor wrote very readable code, but it seems that ObjectPascal made it very easy to write it that way.
Or, more briefly: Happy Birthday!
[1] The application is about a 10 KLOC in total, which is not small in my book, but not "very large", either. Also, I was both a developer and a sysadmin and a helpdesk monkey, so the phone was ringing about every fifteen minutes.
As a pascal user since the early 80's, then an Object Pascal user, then a Delphi user since the first version, I love Delphi but to be honest I cannot afford the yearly updates.
For someone that uses it for home projects, $916 for an upgrade is out of the question.
Rambling here, but... Delphi 3/5/7 were incredible design packages. I feel they lost focus when they jumped on the .NET bandwagon - maybe it is just my perception, but maybe some of their internal developers were less focused on native code. Anders leaving was also a big hit. Kylix was yet another distraction.
The documentation and help pages that came with Delphi were absolutely the best documentation I ever had. Every topic came with examples that you could copy and reuse. Not just snippets but fully functional blocks of code. It was brilliant.
You've reminded me of the reason I loved Delphi's help. I think what I found most helpful (and most unusual for the "state of the art") was that most help pages had "see also" links. This allowed me to look up something similar to what I needed and just follow the links to what I really wanted.
I was able to use the Help pages as (almost?) my sole reference for the API. Something that just wasn't happening with Delphi's big competitor, VB.
I was a Delphi Developer when I started developing software professionally. I loved programming in it. I jumped ship when Anders Hejlsberg, the Chief Architect of Delphi moved to Microsoft to be a lead architect of C#.NET. I used Delphi 6 and 7. When it was time to move to Delphi 8, Borland decided to target .NET.
The choice was between learning Delphi 8 for .NET or learn Visual Studio .NET. I chose MS.NET because MS is the custodian of the .NET Framework. They are the ones on the driving seat, not Borland.
Looking back, I don't regret the move because Delphi is dying. Posts requiring Delphi are nowhere to be seen on job sites in South Africa.
Same except after D7 I veered into web development with Coldfusion (I know how to pick a winner!) and then PHP. Ruby & Python much later. I didn't realize how good I had it with Delphi's IDE and interactive debugger.
I have no idea what you did, but I find that hard to believe, and this is with GNAT.
I have a hello.adb program, 99bytes, compiled 25k
-rwxrwxr-x 1 seg seg 25352 Nov 2 01:26 hello
-rw-rw-r-- 1 seg seg 99 Nov 2 01:23 hello.adb
-rw-rw-r-- 1 seg seg 1409 Nov 2 01:26 hello.ali
-rw-rw-r-- 1 seg seg 1576 Nov 2 01:26 hello.o
Older versions of GNAT used to statically link by default IIRC.
So you'd inevitably get some clueless complaints that Ada was so much bloat compared to C, based on comparing the size of a statically linked executable to a dynamically linked executable.
End of the 1990s with GNAT 3.1xx on Windows. IIRC there were several libraries and runtime elements included "just in case" and I didn't know that I had to deselect them. Perhaps it was the default setting in the GNAT Programming Studio (GPS) that I used at this time. Didn't experience that with later GNATs (without GPS) on Linux.
I still laugh about my first Hello World. My friends mocked me for my megabyte-sized beginner programs. It totally was in line with the image of Ada being a bloated, bureaucratic DoD monster. GPS made things feel extra complicated and ugly.
That said, I'm considering to use Ada 2012 for several of my upcoming works.
There's just no way to develop a GUI application (especially a cross-platform one) without shipping something large.
You can use Electron (and basically bundle Chrome), or JavaFX (and bundle a Java runtime), and they're about the same size. But even if you ship all of the Qt dynamic libs, or all of the GTK dependencies, or even wxWidgets... it's still a far cry from "light".
It just takes tens of megs to make a window appear.
After watching a few 64k demoscene demos, a 380MB Electron-based minimalist text editor just seems horribly bloated. (I'm currently writing a cross-platform Windows/Linux/Mac GUI app in Xojo, and the macOS version is 11.6MB at the moment.)
Yes, they are. There are small, concise GUI toolkits that go a long way in a small volume. I am very fond of FLTK, which IIRC produced standalone (depending only on system libraries) fast, tens-of-widget-types featured executables at ~200k on each of Win, Linux and Mac.
Adding Unicode support (independent of the Platform) probably bloats every executable an additional 100k. The horror.
I like it a lot, I find it really fast to prototype ideas & get something working. I mostly use it for in-house utility tools (business dashboards, small database stuff) where I wanted the business to be platform agnostic but still native. There's an ecosystem of plugins to extend the built-in Xojo controls (like Delphi has), mostly from MonkeyBread Software and Einhugur Software. It reminds me of the early pre-corporate Delphi days.
I love that Xojo's IDE is cross-platform too, and that I can make my Windows & Linux builds from the Mac IDE. It's been easier for me than Qt anyway, and without any of the licensing or renewal issues.
It doesn't have to be so big. Modern GUI toolkits are just really bad about keeping their sizes down for some reason.
I wrote my own personal GUI toolkit on top of OpenGL/GLFW for developing special purpose editors (for gamedev), and the resulting executables plus required shared libraries and resources (minus system libraries like libGL that shouldn't be distributed directly with the application) are only about a megabyte or two total. That includes a full blown custom scripting language interpreter, resizable rich text widget with bold/italics/color support + optional text wrapping and scrollbars, JSON parser and serializer, vector math library, a basic image loader and saver for several formats (using stb plus a little custom code for a few less common formats), various routines for software manipulation of surfaces (e.g. drawing lines, triangles, alpha blending images, and so on)... written in C++, with debugging info turned on, and using templates where appropriate. (It'd be even smaller if I stripped debug info and packed the whole thing into one executable.) I'm developing it on Linux, but I could rebuild it for Windows (and probably Mac) without too much effort.
I don't know what the hell the GUI libraries are doing to get so big.
You haven't heard about Red (http://www.red-lang.org), have you? With some Kb you can ship GUI executables for Windows, Android, OSX and Linux. (OSX and Linux soon).
Try it and report back the amount of Kb (not Mb) used.
Java implies it needs the JRE, so add that to it as well. Of course, Electron probably relies on OS-specific UI libraries as well (although only a little), which should also be considered I guess.
> There's just no way to develop a GUI application (especially a cross-platform one) without shipping something large
If you compiled a Delphi program without using the UI stuff the resulting .exe files were usually only a few dozen kb in size. People used this fact in combination with using raw Win32 API in order to create very small sized UI apps with no external dependencies.
There were tons of tutorials on how to use Win32 API in combination with Delphi.
You're right, but the key point (at least for me) is the cross platform. We recently had a client send us their environment setup. Everything ran on AIX except for our stuff. That means they had to specially buy windows server licences just for our product. feelsbadman.
Ouch, thats pretty inefficient IMHO. I have a Windows database client written in Delphi XE2 that covers the whole MRP for a winery including built in reports and report writer that clocks in at 14MB http://rodyne.com/?page_id=375
That's because your Windows app is most likely VCL based and does not have a huge overhead on trying to built all of the GUI parts itself.
On macOS the GUI parts are in Firemonkey (FMX) and that is an abstraction layer that does all of the drawing of the controls by itself instead of using the native controls as supplied by the OS.
This creates some extra overhead. There's pro's and cons here. Personally I'd rather had they used native controls instead of FMX as that would look a lot better.
But it is what it is.
From there the app doesn't grow as fast, so it is not all bad.
edit: Just looked at the GUI on my app [0] and without any resources it comes in at 16.2MB (so my estimate was a bit on the high end of things)
I remember when we developed "remote administration tools" (trojans) we used Delphi but we made it as console application. The executables ended up on 15 kb for a full-featured RAT.
In the 90s I met this guy in IRC that used Delphi 2 to program a RAT called Hacker's Paradise.
He was very kind with me (I was much younger than him apparently) and shared the source code so I could learn from it since I was constantly asking him programming stuff.
Then later he renamed the tool "Master's Paradise" so he could go legit and sell it to companies and compete with MS BackOffice.
I enjoyed talking with him so much, even though I could barely understand OOP, but the thought of talking to a real developet left me an impression
Yes, but "to me" is hardly relevant in a general discussion, if 99% of devs will use either GCC or Clang. Except if we're talking about a niche domain.
With Lazarus you can create programs which do not require any platform dependencies [1]. The result of it is the user of your program does not need to install any further packages, libraries or frameworks to run your software.
[1] Linux/BSD applications may depend on GTK2 or alternatively QT. Some add-on packages may also add dependencies of their own
Can be used in commercial projects
Some IDEs restrict their license to only non-commercial development. Lazarus is GPL/LGPL [2][3] which permits using it in building commercial projects.
[2] LGPL with additional permission to link libraries into your binaries.
[3] Some additional packages come with various licenses such as GPL, MPL, ...
"
I wish some company started promoting Lazarus. It's a great product and has a wonderful community, but the whole project somehow lacks enough traction to make it a serious alternative to more mainstream tools. I bet the moment a big player backs it up the attitude of developers will change. You can really produce prototypes of native apps rapidly.
Lazarus and Free Pascal has made me return to the wonderful world of RAD and Object Pascal. :)
I was a Delphi addict in the 90's.
After Borland screwed up Delphi - including the Kylix disaster - and since I am now a full time Linux user - Lazarus is the only option.
I have been following the Lazarus / Free Pascal project for years, and I think now is a good time to pick it up.
No traction because it's a mess. No git, no markdown, no clear organization, dated look in almost everything. Very unuserfriedly to just 'hop in'. No money unfortunately and most (all?) devs do it in their sparetime. Splitted between different attempts, FreePascal, MSE, Oxygene, Smartpascal, Newpascal, maybe more?
Nevertheless, Lazarus and Free Pascal is very good and important work. Wish they would modernize to the 21 century though (but whatever works for them is fine - only it's difficult regarding the traction then).
I am actively using Lazarus. It is not split into anything other than Free Pascal (the language) and Lazarus (IDE and visual component library).
Don't blame the forks, mods and spin offs on Lazarus / Free Pascal.
It is a sign that the project is alive and doing well, IMO.
The looks?
It looks like any other Qt / GTK 2/3 application. Fairly modern.
But I agree with you on some of the points - but the part that I like the best is the fact that it's fully open source. It's really nice to be able to look at the source to everything when developing your own applications.
Yes, the site itself, including the docs, looks dated and does a poor job of selling it.
That's Open Source, the good and the bad.
Edit:
The project does have a (mandatory these days, I reckon) Github mirror, if that would make you more happy. :)
I'd also think "It's $1400 cheaper than Delphi" would be a good selling point.
I started using Turbo Pascal in college when it was $49. Given that Embarcadero Delphi is competing with a lot of stuff that is free and high-quality, I doubt it's got anywhere to go but down from here.
Borland screwed up across the board. There's an entertaining, if somewhat depressing, discussion of their woes in Merrill Chapman's "In Search of Stupidity".
I attended a Clipper user group in Atlanta in the mid 1990's, with my dad. He was into Clipper, was trying to get me interested. The Clipper folks were also into Turbo Pascal. A Borland rep was there to give out swag and talk up the imminent release of Borland Delphi. The Clipper crowd was divided--some excited, some not so much. The older guys, like my dad, had come up programming with punched cards and tape drives. For them, a PC with Clipper and Turbo Pascal was plenty advanced enough for small business apps. Dad never did go for Delphi. 20+ years later, I'm doing a quick study of Object Pascal to prep for working on a legacy application at my work, in Delphi.
Hah, that's how I started programming too. A bit of BASIC. Then I graduated to Clipper and Turbo Pascal because that's what my dad used. Then to Delphi 1.0, then 2.0, I think we skipped 3. Delphi 4 was a mess. Quality got pretty variable in the later releases.
I used Clipper back in the day. CA ruined it when they bought it. I was waiting for CA's new product "visual objects" in the meantime Delphi shipped and I've been using it since Delphi 1. I think it's unparalleled for building desktop applications for Mac and windows.
Turbo Pascal 6.0/TASM for applications that required performance or system programming like, and Clipper Summer '87 (shortly replaced by the 5.0 OOP version) for database frontends.
Delphi was a great environment, but Anders and other key persons leaving Borland, while the company lost track which customers they should target, besides the "clever" idea to change the company's name, killed it.
I know of a few companies in Germany and Netherlands that still use it, but it is hard to get offers.
And we had to wait 15 years until .NET started to offer a compilation model similar to Delphi (only for UWP apps).
While Java kind of outsourced it to third party JDK vendors due to Sun's attitude against AOT compilation, oh well at least Java 9 will bring the first steps towards support it.
> While Java kind of outsourced it to third party JDK vendors due to Sun's attitude against AOT compilation, oh well at least Java 9 will bring the first steps towards support it.
I'm just curious. How would AOT improve Java's ability to have better RAD. I guess I'm just missing the association. Is it bundling/distribution? Startup time? Integration with native libraries?
I would imagine hot code swap probably doesn't work with AOT (aka JRebel) so that would hurt RAD.
Java has worse RAD support than Delphi, yet Delphi AOT compiles to native code.
AOT compiling to native code, as standard option, would have improved Java's acceptance as safe language for desktop applications, due to better bundling, distribution and startup time.
To the point that even Oracle does reckonize this, and is delivering an initial way of partially AOT compiling on GNU/Linux x64, with support for other platforms planned for Java 10.
> I would imagine hot code swap probably doesn't work with AOT (aka JRebel) so that would hurt RAD.
Sure it does, that can be done with dynamic libraries. Many game engines make use of this approach.
Other environments like Eiffel and Lisp, have a set of JIT/AOT compilers, JIT during development and AOT for deployment.
One of the first environments I ever programmed was Delphi. Had lots of fun with it, and it had a special place in my heart...
Fast forward 20 years, and I'm a hardware developer using Altium a lot. As some here may be aware, Altium is a multi-gigabit piece of CAD/EDA behemoth written - and still maintained - in Delphi. 3D, DirectX, everything in Delphi.
Just yesterday and today I had easily reproducible BSODs by using a very basic feature (routing nets). Memory leaks galore - most people I know have the habit of shutting Altium down now and then just to avoid a crash. Success is low - it crashes a lot, I'm getting tired of unhandled exceptions windows.
And this way, I realize even great development tools age badly. Of course this is not all Delphi's fault, but it shows how tech is a Red Queen's race: you must run faster and faster to keep in the same place.
We used EurekaLog (https://www.eurekalog.com/) to get nice exceptions and stack traces, even for access violations :) Imagine that: you have a native app, but you also have stack traces like in C# and Java.
I loved to use Delphi in the early- and mid-2000s, but unfortunately Delphi jobs disappeared, and I had to switch to C# and Java development.
I agree but a large program in one of those languages will still have more bugs than a small one, that's just the nature of things and the increase in bugs isn't linear either in my experience.
I half agree with you. It surely shows the massive complexity of large software, for sure.
On the other hand, the tool should help prevent these issues. Altium has visible exceptions and lots of memory leaks that are much easier to prevent or solve with modern development tools and languages.
Also, C aged badly, but the tools (ecosystem seems to be the hip name nowadays) for C evolved, and in a smaller scale, even the language itself has evolved. Object Pascal and Delphi doesn't seem to be catch up so well.
Modern Delphi has a simple flag that you can set that will show you a log of every memory leak in your application when you shut it down, and there are 3rd party exception handling and profilers/analyzers that can be purchased for a few hundred dollars that will take care of finding/fixing AVs/performance bottlenecks. It's actually quite easy to create solid and reliable applications using Delphi if you follow solid software development practices.
The thunar-crashing thing was introduced. A few years back it was stable, then sometime around a year or 2 ago it broke. Sad to see a good piece of software take a step back (proper testing should have prohibited that, shouldn't it ?).
I got my start programming with Delphi 5. It was an excellent environment to learn in, since I could always see something happening based on what I had done.
Better: the Delphi component libraries made writing a GUI application easy. I've never seen anything of their quality and ease up through today, and I still miss being able to get an application running by just subclassing some standard components and writing the core logic I needed.
Oh yes, I absolutely loved the tinkering with Delphi and Kylix before I was a professional programmer. I remember Borland distributed Delphi6 for free for personal use and I had a lot of fun with it.
In the end I landed a job as a web developer, worked in PSPad and left Delphi forgotten until the day — a decade or so later after I used Delphi the last time — I opened Eclipse the first time in my life.
Never hated a tool, my profession and the IT industry more than at that moment… Why take the compilation so much time? Why are the fonts so ugly? Why does this tool needs more time at startup than the good old Delphi 6 on my 800 Mhz PC ten years ago? And why nobody seems to care about it?
Yep. I don't use Eclipse for these same reasons. It really seems someone hates IDE and we arrived on hell for paying back something we did in a past life.
I switched to Netbeans. Slightly better: bigger icons, better looking UI. I like the key combinations there. Still nowhere good compared to Delphi IDE with useful code snippets built-in and easy-to-use creation of UI apps.
Netbeans is indeed better. Used it on some mid-size PHP projects and liked its neat UI and responsiveness.
Nowadays I'm a happy IntelliJ user, but hope Netbeans will stay alive. It's definitely one of the better tools around and deserves a place under the shiny sun.
I am bit older than average so I used Delphi in its golden days. Even today few of the old customers need old apps maintained so I keep Delphi 7 ready.
When it comes to quickly developing native line of business applications (the niche between excel spreadsheets and commercial off the shelf) I've still not seen anything that can beat Delphi, the .Net stuff has gotten very good.
Delphi is quite good, but I really truly think it killed a lot of careers: Many of the people that I worked with on a Delphi project late 90s/early 2000s just never let it go, and their job prospects collapsed to the last few residual shops still using Delphi. I suppose this happens with all technologies (e.g. some people clutch on and make Cobol their lifetime effort, etc), but every time I see a Delphi advocacy piece it makes me a little sad remembering the countless emails looking for possible Delphi engagements.
I learned VB3 at 13, and moved to delphi at 14. It was amazing. As easy as VB, but all the power of C++. I made my own DLL's to use in VB, just because I could. It was the coolest thing ever.
Fast forward years later, and plenty of intermediate languages (C, C++, Java, ...) I got hired into my first professional software developer job ... as a delphi developer in a company with a big multi-million line delphi codebase they wanted to migrate to the web. I had done some web development, so I ended up writing features on both the delphi and web teams, often the same feature. So I became intimately familiar with the trade-offs of delphi vs web development.
The thing about delphi: it was/is insanely productive. In the beginning it took about 3 to 5 times as long to write a comparable feature on the web side. It ended up driving me to research cutting edge web dev techniques to find some way to approach the productivity levels that delphi gave. In the end we almost got there, using rich frameworks and a component-driven UI. But to this day the delphi team can still get a feature done faster than the web team, and that's despite an IDE which is much weaker than webstorm/intellij. Object Pascal and the VCL are just that good.
However, I wouldn't do a new project in Delphi. You're locked into an ever more expensive product with an uncertain future, and the productivity advantages just aren't worth it anymore. You can get close enough using an open source dev stack, and the value of having all your tools be open and free is significant.
> I think Delphi will die, but only because it costs a fortune today.
I agree with your diagnosis. The problem is that Embarcadero doesn't understand that, and when it does (or when someone else buys Delphi), it may well be much too late to revive it.
They could really position various versions of the product in a different way, making the lower tier more affordable.
I think they do understand that, they just see their opportunity elsewhere. The reason is the only price that would satisfy the complainers is free, which isn't going to be very profitable.
There is a community of locked in customers who are wiling to pay to keep their projects going, it makes sense for Embarcadero to milk them.
That market can only possibly be diminishing over time. I mean sure, $bigco can afford ~3k/user/year, but eventually, that's gonna dry up.
Charging for basic development tools in 2017 just seems weird, and I'm afraid by the time they realize that the company is dying, the mindshare will be gone, never to return.
There's no money in devtools for general desktop app development. Embarcadero knows that the only way to grow the delphi userbase is to make it free, so they're instead trying to milk it for all it's worth on the way down.
I had a bit of hope for delphi with mobile app support, but the pricing really killed it now that microsoft offers xamarin for free.
Plus, object pascal is too weird for js coders. C-style syntax is a must, even though object pascal is in many ways a better language.
I don't agree making it free is the only option. Delphi is now multiplatform. There are several companies with a development tool targeted at just one of these platforms, charging money for it - usually not much, but the subscription model makes it more expensive in the long run.
Imagine having just Delphi for Android free. If I could release the same app for iPhone by coughing up $200, why shouldn't I?
They could also release a basic version at a very low price, unlocking features in the more expensive editions. Yes, they can actually study the usage cases and examine what extra features are indispensable for current paid customers but could be removed in the basic version without much problem for an average developer. There are so many ways they could play this out, I'm really disappointed they've chose this route.
Yes it will dry up but by then I expect they will have made a ton of money. This isn't an unusual pattern, I've seen it with a few platforms I've worked with.
You're right. The IDE has grown outdated, we just need the old Delphi (no .NET stuff) with an updated IDE.
Funny enough, I can produce Delphi executables that run perfectly on Linux and Mac using Wine. That means executables that run on anything from Windows 95 to any modern desktop operating systems available today.
Why the heck did they decided to kill such a good platform.
I've moved to Java back in 2010. From my perspective was the best next thing (platform agnostic, rock-solid) but still miss my Delphi IDE to create good looking UI apps with ease.
>I think Delphi will die, but only because it costs a fortune today. If it had a resonable price, many people would continue to use it indeterminately.
Did you try it? I try it every year (I was a Delphi fan and full time Delphi programmer from Delph-1 to 6) but it is not very good. The Pascal compiler is brilliant and fast but Lazarus itself is unusable every time I try. It often begins by failing to build the basic form until I go through a bunch of steps to fix the install. That's going to put most people off as Delphi never had that issue; it was install-and-go. And after that it depends a bit on the position of the moon what happens. For instance, I just installed it again because of your post and when I press Run, I get http://imgur.com/a/blFNC . But even when you have it running, it keeps being highly unstable. Maybe it's just me but I doubt it.
Installing Lazarus from the package managers in Linux really does suck even today, I wish they would fix it or just remove it from those repositories.
I Finally got the Linux version running on Mint by downloading and installing the files from their repository as recommended and it was a nice experience after that
Windows is another matter entirely, just download the setup, run it and go
Lazarus is a very active project, currently I rate it up there with delphi XE2 (the version I use currently) and it can only improve
I've been working with Lazarus on a daily basis for a while now (I work at a mostly Delphi company, but our server code runs on Linux so we write it in Lazarus). Can't say I have the same problems as you do. My host is a ubuntu machine, and I did install the latest version from their website, not from the package manager. This seemed to fix most of my issues with Lazarus.
Ah sorry about that; I am in China and internet is very slow & often broken (HN is very fast though). Probably the image did not (fully) upload. It was an error telling the application crashed. Just the empty default form after pressing run.
Or $0, if you use the Starter edition. It's free for hobbyists, students, startups etc, with the clause that if you start making over a certain amount of revenue you're asked to buy it.
It's the same for almost all of the great programming environments of the 80s and 90s that still exist. Commercial CommonLisps are also super-expensive, so is Xojo (=Realbasic).
They should have license fees based on how much money the developer earns, but I guess it's too hard to calculate long-term revenue and to ensure that the developers don't cheat.
Yes, the cost is ridiculous. Delphi used to be an affordable tool. I've been a big fan of Delphi and would still be developing Windows apps in Delphi, except for the excessive pricing. Stopped renewing my licenses two years ago.
Delphi had the flexibility of Visual Basic without the deployment problems.
Unlike VB, all the controls and libraries were written in Delphi itself, which allowed you to walk through each and every library when debugging problems.
My first gig was writing telecoms software using Delphi 3. Good times! Then Inprise bought Borland and shipped a buggy version of Delphi 4 which was a pain. Like many others I jumped ship when I heard what Anders was doing with C#. I don't regret the move but I thought Delphi was great.
I never used Delphi, but I have a couple of friends that were die hard Delphi fanatics. Eventually they moved on to C# as all of the Delphi jobs dried up with Delphi's continually decreasing use. They still swore how they thought it was the best thing they ever worked with, but at the end of the day you have to pay the bills.
Maybe it really is great, I don't know. I was a bit surprised looking at Tiobe (http://www.tiobe.com/tiobe-index/) that they rank it as the 9th most popular language right now. Where is this actually being used? And the price tag is incredible!
When you're making half a million or more each year writing vertical market software, the price tag for a Delphi/RAD Studio license each year is irrelevant. This is especially true when Delphi was the reason why you're making all that money in the first place.
It's kind of a "you had to have been there..." type of story, but if you get a chance, talk to a developer that was trying to create Windows applications for businesses back in the 90's and you will know what I mean. The really sad part is that while .NET and C# have done an okay job of providing a replacement (I think that MS has a hard time staying on-point when it comes to dev tools and make their tools too much of a moving target), you really cannot find anything exactly like Delphi/RAD Studio today. The primary reason why it's so sad is that Delphi created millions upon millions of dollars of revenue for independent software vendors all over the world, and you would think that companies would be trying to replicate that success. Alas, it's hard to contemplate even attempting such an endeavor when developer tools are not valued properly according to the money that they make the developer. If the software world finds a way to start making money from developer tools again, then you'll see another Delphi and it will be a lot cheaper.
I've seen it appear in bottom-up development areas. Top down would be the COBOL(s) of the 21st century that being Java or PHP/Javascript. Very little seems to come from non-software company megacorp enterprise HQ that isn't Java, PHP, or Javascript.
The very bottom tier of bottom up development is making business critical systems depend on Excel and some impenetrable write only undebugable macros. The next tier up is where I've see Delphi apps mostly in sorta integrative and peculiar reporting roles. Oh and ETL of all places too.
At least that's where I've seen it. It works well there, too.
It's used a lot since there are lots of legacy apps written in Delphi. You can't throw away hundreds of thousands or more lines of code just because Delphi "went out of fashion" (I know the situation is more complex than that, though).
Delphi is used a lot, desktop has first class Win10 support (store included) and mobile clients are cross-platform. Also fast server code -- now coming to Linux. Skype for Windows is still written in Delphi! But I'm very biased
I was just having this conversation with an acquaintance about the software glut. When you do something well, you don't have to do it again, just enough to keep it compatible with the other things it needs to work with. So it takes a team of 50 people to make a product and then 10 people to maintain it forever. So where do those 40 people go?
FWIIW, where I work, I started using Delphi 5 when it came out. As of now we have about a dozen D5 desktop applications all essential for the core business that are in active use and supported as necessary, running happily on Windows 10. I don't see why it won't continue like this for another 15 years... The bosses (who are non-programmers) don't really care that D5 is out of fashion - because it all just works (and rocks).
The only reason I couldn't upgrade to a later version (Unicode is one thing that would be useful) is I am stuck with one critical and long discontinued grid component.
Looking back I am not sure how we could have lived w/o Delphi. Well maybe it's an exaggeration, but certainly life would have been more difficult. Everything else from before .NET/C#/Windows Forms looks like a nightmare.
I know about this one and others, thanks. The problem is TopGrid, it is further customized, so flexible and so entrenched in my code that it would be an enormous undertaking to replace it. Even if UI was perfectly separated from the business logic, which it isn't :-)
We ended up switching to cxGrid to move away from delphi 5. It does absolutely everything, but it can be hard to figure out how to configure it so it does exactly what you need it to.
Would Qt count in this? I've made some applications with Qt Creator, aside from not knowing much C++ they were built almost like I would expect in C# , Delphi and VB6. I think C# is the successor to Delphi today, and if Microsoft makes WinForms somehow cross platform and an official part of C# it would get very interesting. The guy in charge of C# at Microsoft made Turbo Pascal and worked on Delphi back in the day as well.
Try Red (www.red-lang.org)!
It's not version 1.0 yet, GUI for OSX and Python is coming, for Windows and Android has already arrived.
Small, light, great.
Well, buy IntelliJ Ultimate edition and you can go ahead and create apps like you would have done with Delphi. It has good tools for database access, rapid iteration, you can design Swing GUIs with a built in GUI designer tool, etc.
Half in jest and half seriousness... Excel fill this void for many many things corporate. Two decades later it is almost as good as Delphi was, just no .exe.
What my former company called 'End User Computing'. This meant developing small or not-so-small programs in the only tool capable in a corporate environment: Excel (often linked to SharePoint as a data store). Otherwise lots of forms and procedures would have to be gone through making it a tech project.
Background: Operations (not tech) mega-corporate bureaucracy where these apps were helpers.
Solution: Open up Excel, and start to code and design GUIs on the worksheet via VBA built in to Excel (and all of Office). It was a stunningly similar experience to hazy memories of Delphi in terms of GUI and code, but ultimately was using a spanner to do a screwdriver's job. Memories of Delphi were certainly hazy at this point, but it was more similar than any other tools I'd used the the decade+ since that point.
I might be a few years out of date now (no WPF since 2011) but all I remember of Blend is it was so complex to learn and use that it was easier just to hand-code my XAML. Not at all like the GUI builders of yore. That may have changed though.
For sure, and I'm not saying Blend's a bad tool (far from it). It was just total overkill for what I wanted to do and, if I wanted to use Blend well, I had to read another 800-1000 page book, after the one I'd read to learn WPF and XAML. It just didn't justify the time in terms of what I needed to achieve on a relatively short timescale at that point.
I too often see a fundamental misunderstanding of what made Delphi so great. Yes, you can drag and drop controls onto a form in a lot of tools. It can compile native code. And yes, Object Pascal was nice to read and maintain.
But the real issue is rapid database applications. Being able to create business apps very rapidly was always Delphi's thing. It was a really fantastic replacement for Paradox and brought Turbo Pascal and Paradox together to create something amazing.
For that there still isn't anything. There are a lot of things that are close, but nothing with the same level of power and speed. The closest thing I've found is Django. Hopefully that clarifies: it's not about GUI anything.
Delphi vs VB
TASM vs MASM
Borland C++ OWL vs Microsfot C++/MFC
Philippe Khan vs Gates
Delphi was the raddest RAD tool. The free VCL components for it were often better than commercial VB ActiveX components. Delphi executables were faster. Delphi could statically link everything.
I eventually had to move to VB when my Delphi job dried up. VB felt like a downgrade. I remember constantly referring to Dan Appleman's book so I could use Win32 APIs to work around the limitations of VB. I'm not knocking VB as it's one of my favorite tools too, but Delphi was the cream of the crop.
First time I used a C++ compiler I thought it had frozen because the hello world took so long to compile. The notion that something could compile for longer than a split second (for trivial things) didn't occur to me.
Thanks for making me feel so old... we had a programming lecture twice a week and I was carrying one of those 10 kg "Delphi The Bible" book in my backpacks... that made me feel like a programmer somehow.
I guess I should have started on a greenfield project.
For me it was less rosy.
I remember my boss trying to get me started on Delphi.
We basically had two or three Delphi developer workstations available because setting up one that could compile the projects we had in our vcs was a three day task - and it was only possible with the help of our resident Delphi consultant.
Stuff like that has made me love Maven and Java.
Same goes for Visual Basic that I once used to love.
Still I feel I could have loved it if I didn't start with 10 years of accumulated references to unsupported packages. :-/
The way delphi finds its units is similar to how java finds its classes, so it can be smooth sailing or an absolute nightmare depending on how the project is laid out.
I've written tons and tons of code in Delphi and remember it fondly. A few issues I had with it toward the end included Hjelsberg turning it into a kitchen sink, me too language, much like IMO the direction C# has gone in, and walking into projects with tons of business logic right behind the forms, empty except blocks, and codebase full of warnings when compiled. Fix your warnings people.
I don't think many ever thought the language itself was ever "the best". It was the way the libraries and visual components (together, the "VCL") were designed, and the way things worked within the IDE, that many thought made Delphi the best. The Delphi/ObjectPascal language on its own, however, was pretty good.
>It was the way the libraries and visual components (together, the "VCL") were designed
Agreed. One thing that prevented me from loving python. The language was great...but how the fk do I get a clickable button without some mish-mash of half developed 3rd party libraries?
I learned UCSD Pascal on an Apple 2e, and then Turbo Pascal on an IBM PC XT in high school. 1984 to 1986. It helped me learn more languages like Ada, we had Janus Ada for DOS.
Delphi 1.02 I got from some CD in a UK magazine sold in the USA. They gave away free copies of commerical software for buying the magazine for $10 or so.
I did better in Visual Basic because I got jobs that required it.
Might be worth considering fronting it with something like Cloudflare. I pay them about £20/month and reckon I could handle 10k hits a day on a t2.micro instance in AWS (in reality I'm actually only getting about 10 - 20 visitors a day myself on the site in question, which I'm quite happy with at the moment due to reasons).
My first job out of college was as a tech support intern for Delphi, first answering pre-sales and installation calls, and eventually moving up to answering paid support calls. From there, I joined a consulting company and wrote and maintained LOB applications written in Delphi. Good times. Jumped ship to .NET in 2003.
Back then there was no internet and I knew no programmers.
I remember seeing the yellow borland boxes at PC World and not really understanding what borland were.
Afterwards I bought my first copy of vb secondhand (lots of manuals came with it), from someone who was getting into Delphi instead.
Back in early 2000's when I used it a lot, the word was that the even numbered versions of Delphi (2, 4, 6) were all poor efforts, and the odd numbered (3,5,7) were all good. I used 6 and didn't think it was bad, but 7 was better. Many Delphi users had remained at version 5.
The latest Seattle and Berlin versions have pretty solid IDEs that start up very quickly and the runtime/VCL has seen a lot of improvements/fixes over the last few years.
People seem to forget that some Delphi libraries are intertwined with assembly and work around Delphi inefficiencies. This made some libraries very hard to port to FreePascal. A typical example is DevC++ and its dependencies.
I remember a tool called "Dirty Little Helper" (if I am not mistaken), which had all the Delphi answers, I would ask SO nowadays (eg. how to make a windows tray icon?)
But it was an offline application.
I used to code in Clipper in a past life. Many ex-Clipper devs became Delphi devs when the Great Fragmentation happened (multiple competing OO frameworks for Clipper).
I started with QuickBasic/QBasic and Pascal. Though I went with VB4-6 instead of Delphi.
It's sad that RAD isn't popular anymore. 1995 - 1999 was great with Win95 era, everything was so consistent, good documentation. Then Microsoft realised their "The Microsoft Network" lost against the open free WWW and then the announced dotNet (which took until 2003 for them to release v1) - that was the beginning of the end of the great Win32 platform and RAD. HTML with Frontpage and Dreamweaver was just an okay RAD andbthe situation got worse with "no tables, use div" and XHTML 1/2 movements.
Very true, even now. The professional market for WinForms is probably dead, though.
Yet ironically, I use Winforms in personal code way more today than any of Microsoft's other GUI technologies. Winforms is a great way to get a Windows app up extremely quickly that needed a simple GUI. There are plenty of ways to get a quick command line style app up, but I really don't know too many solutions that allow you to drag and drop functional GUIs as quickly as Winforms (other than VB and Delphi).
For a fully fledged app, Winforms makes no sense to me these days. But Microsoft specific syntax like WPF or UWP no longer makes that much sense to me either. Might as well spend the time on HTML+CSS+Javascript and get cross-platform support...
By an interesting coincidence I was given a CD with tons of software on it, including Delphi 2. I started playing with it and quickly realised I could create my own programs using that tool.
Later I went to the book store and found a book about it that I couldn't afford. So I came back every week to read as much as I could, then heading back home to try it on my illegal copy of Delphi. (I was 11)
Then I realised there was a help manual embedded in the distribution, so I learned as much English as I could so I could understand that manual.
Little by little I learned about conditions, loops, object programming and made a bunch of terribly crappy yet working games.
No amount of studies could have taught me as much as I learned through using that software. No manual work could have given me the fun I had when programming my very own games. Reading "Delphi" as a headline on hacker news made me feel nostalgic and I figured I'd share my story here.
So thanks Borland, the 11 year old me may not have paid to use that software, but it was enough of a revelation to make me the programmer I am today.