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?
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.)
Developing on Linux desktop at that time probably wasn't ready for this.
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.
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.
It is a nice start again though.
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.
That's why I wrote "in combination with easy deployment". Yes, you can do faster RAD in Python but good luck with easy deployment.
Tk is the better than Delphi RAD tool?
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.
Very limited ones. And ones clients will have a shock when seeing. And still coding it all together.
With Delphi you can drag and drop great looking (and more full featured) prototypes in zero time.
It will be limited to Windows, though, I'll give you that.
Can you clarify "coding it all together" part. I have no idea what you meant.
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.
[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 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.
Rather, it'll be limited to Windows, macOS, iOS and Android. :)
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.
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.
TkWeb and WubTk are examples of this.
- It was a wrapper around Qt
- Had some dependencies on Wine
- The set of available controls was small
- It was closed source
- They expected GNU/Linux developers to be willing to pay for it
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.
Netbeans Swing support also comes close.
Borland also had the older Turbo Vision toolkit, but that was for MS-DOS. OWL was designed a very similar class hiearchy.
:)
TCL/TK is about 20 years old if not more.
As the saying goes, if you can't beat 'em...
Also HTML+CSS allows for extremely versatile styling and fine-grained control of appearance.
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.
As a compilation target from a better language, I suppose it's mostly acceptable. But on its own? Never again.
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.
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.
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 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.
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.
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.
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.
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.
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'
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.
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.
If you're talking about electron apps, that's a whole other ballgame. We don't build electron apps for internal stuff afaik.
And there's a really good reason everyone switched.
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.
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.
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.
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.
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.
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.
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.
Shifting of priorities.
I remember when people used to complain that Delphi executables were 'bloated' and large - 200KB was the minimum size?
At that time the complaints didn't seem absurd when we were connecting via 36k dialups.
Admittedly we have probably swung too much in the other direction.
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.
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)
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.
You can get all that through UWP, though, can't you?
[1] https://developer.microsoft.com/en-us/windows/bridges/hosted...
I don't really understand. I never paid a license to create and distribute native applications.
But also you provide the content which makes Windows licenses have value. If there were no Windows apps, they couldn't price it higher than Linux.
Before the .NET age, Microsoft was very active with ideas about bringing Web on desktop.
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.
* http://www.rebol.com/rebol-view.html
* http://www.rebol.com/docs/sdk/
* http://re-bol.com/business_programming.html
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.