
I miss Delphi - jlebrech
Why can&#x27;t web development be as simple as delphi?
======
codr4life
I did professional development in Delphi for 13 years, writing and maintaining
a sprawling 700k line reservation system. I don't miss it much. It was a great
learning experience to have to fill in all the gaps in the standard libraries
by twisting and turning Pascals rigid rules into something semi-useful;
writing foreign function interfaces to WinSock to get around the limitations
in the provided toy socket implementation; finding ways to convince the over-
engineered pixie-dusty data-layer to issue effective SQL; and trying to keep
up with Borland's, nay Inprise's, wait Embarcadero's, ever changing priorities
and price hikes.

I don't even find the GUI-builder that amazing. It's very easy to use, and up
to a certain scale it's very convenient; but it encourages and rewards
coupling the implementation to the interface at every turn, making any attempt
to do the right thing an uphill struggle.

One of the most painful memories I have from software, the stuff that haunts
me in my dreams; is writing stored procedures for Delphi's favorite database,
Interbase. Whenever you did something wrong, it would give you an error saying
'Error at BLR offset 283729' or similar, offset being the offset in the
compiled code where the error supposedly happened; thereby forcing an inhuman
level of discipline when making changes. I had to write and maintain thousands
of lines of that bullshit; since by the time we dug that deep into the
performance of the BDE, the entire application was fused to it on UI level.
Switching meant going through every single stupid form in the application and
carefully translating event logic, bindings and properties to pure SQL.

Thank you Borland, but no thank you; I'm out.

~~~
radarsat1
My one brush with Borland C++'s GUI builder was that the developers were doing
things like setting the colour of a UI component based on some state (like the
background colour of a text box for example), and then elsewhere in the
program, checking the colour of that component to make some decision...

I don't blame this on Borland. Nonetheless.. I ran.

~~~
jacquesm
When used well Borland C++ builder was one of the most productive tools for
application development on windows.

One day someone will make something like it for the web and make a few
billion.

~~~
jhoechtl
It was called Dreamweaver

~~~
diamondo25
Oh the days of WYSIWYG HTML editors. I still find websites that have the
Dreamweaver change-image-on-hover JavaScript. They still work on older
browsers though...

~~~
flukus
I doubt they work on mobile though, everything was in hard coded dimensions.

------
Svip
I work with Delphi professionally. And we maintain a code base of about
150,000 lines of Pascal and about 300,000 lines of T-SQL (written to work in
both Sybase and Microsoft SQL).

Delphi may be easy, but it's not simple. Once you get into the meat of things,
Delphi's ecosystem truly becomes a limitation.

Delphi's main drawback is its lack of library availability. If you are in the
marked for modern technology, using Delphi is a major hindrance. And if you do
find something, it's usually not of the same quality as the alternatives for
other languages.

I have nothing against Pascal, per say, but I do feel that I am being
deliberately terse for the sake of the compiler, rather than for clarity.
Indeed, having to declare all variables at the beginning of a method doesn't
necessarily make it more clear, sometimes the reverse.

Even a popular tool like Indy for Delphi doesn't correctly implement the HTTP
protocol, and therefore doesn't respond as you'd expect on malformed headers,
so you have to handle those calls yourselves.

Delphi was leading the pack in the 1990s, but has since fallen behind greatly.

I've written a web server - and maintain a web server - in Delphi, and it's
not something I would wish on anyone else.

~~~
clouddrover
> _I 've written a web server - and maintain a web server - in Delphi_

Are you using a framework for that or is it your own implementation? I've
found mORMot to be useful:

[https://synopse.info/fossil/wiki?name=SQLite3+Framework](https://synopse.info/fossil/wiki?name=SQLite3+Framework)

~~~
Svip
To truly understand and appreciate a language, I believe one must write these
features first without a framework (that at least let's someone appreciate the
point of a framework more).

However, in this case, this is our own implementation. And unfortunately, this
is due to a large number of corner cases we need to handle (such as Sybase
support, own SQL driver support, because of multiple result sets, etc.), I
don't believe a framework could replace our implementation.

Trust me, though, if we were to rewrite this all from scratch, a completely
new approach would be taken.

But generally speaking, if a company is still using Delphi, it's probably
because they don't have the liquidity to actually re-write their code base.

~~~
clouddrover
> _To truly understand and appreciate a language_

Personally I just want to Get Stuff Done.

> _I don 't believe a framework could replace our implementation._

It's pretty easy to use as much or as little of mORMot as you like. I use it
for its webserver and websocket implementation but I don't, for example, use
its database layer (using FireDAC in preference).

~~~
traviscj
Different goals are allowed to have different execution strategies.

------
mtkd
If anyone using Delphi to build big apps in early 90s was told that to do the
same function in 25 years time they would need HTML, CSS, JS, Ruby or PHP or
similar, some SQL, some Rust or Go and probably a few DSLs - it would take
months longer to build - require multiple servers - and would need more test
code than app code to get it 98% as stable - you wouldn't have believed a word
of it.

Every single time I have to use a grid control online I shake my head.

I strongly suspect the generation after this will rediscover the power of
desktop apps and some of the dev tools that were around at that time. Web
interfaces just don't work efficiently for some roles - especially in
enterprise environments.

~~~
supercoder
You're still using Rust / Go ? I've been using Luna on the Rocket stack, with
Huston for distribution and Apollo for stack management, and it fixes mostly
all the problems you've mentioned.

~~~
Yetanfou
Just make sure to avoid Apollo release nr. 13 as it is rumoured to contain a
nasty bug. Something with some storage method causing it to blow up I think it
was.

~~~
btschaegg
I thought someone proposed a fix for the AGC module?

So, you should be safe with v. 11...

------
dvh

        - empty form will have 24+16 lines of code in 2 files
        - you will have to pay 3000 per seat per 6 months to make a website
        - it only works on windows
        - hello world have full access to all user's data
        - you paid 3000 and it still cannot reliably add main icon to your app (XE6)
        - you cannot increment build number from command line
        - no job posting in last 12 months
        - nobody is using it

~~~
jlebrech
fair point, still no one is in the RAD market anymore.

~~~
eb0la
I guess the RAD market vanished with Rails and its competitors.

Back in 1998 - suddenly - it was possible to develop quickly a web application
with a CRUD web scaffold behind to start feeding data.

The problem we have now we is the need to maintain loads of dependencies and
libraries nobody knows who's in charge its development: they're just "popular"
and have some documentation.

That's the bad part.

~~~
jlebrech
the quick web development totally was bait and switch.

~~~
eb0la
Totally aggre on that. But there will be a fix soon. Why? you cannot waste 2-3
days setting up your dev computer just to print hello (again) world.

------
Mister_Snuggles
While I don't necessarily want a Delphi-like thing for Web development, I do
want a Delphi-like thing for developing GUI desktop applications.

So far I've tried out a few things, but for some reason they don't "feel" the
same as Delphi did. Maybe it's because I'm older and have moved on to
different tools, or maybe it's because I haven't made the time to properly
invest in these.

Anyways, here's what I've played with:

\- NetBeans - Has a form builder, I'm comfortable with Java, it's cross-
platform enough. I'm not sure why I've never used it for my personal GUI apps,
even though I've built a bunch of little things to use for work.

\- SharpDevelop - Looks great, checks all the boxes for doing GUI development,
but I'm not comfortable enough with C# or VB.NET to use it effectively.

\- Lazarus - Currently playing with this now. Feels a lot like Delphi (as it
should!). I'm disappointed in how much Object Pascal/Delphi I've forgotten
though. It brings back a lot of good memories though.

~~~
spangry
I'm a little embarrassed to admit it, but just today I was thinking about how
I miss Visual Basic 6... Such a great IDE for slapping together a crummy GUI
with buttons, textboxes and labels all slightly misaligned :) I'd love to have
something similar for Python.

~~~
Odoth
Best approximation I've found is PyQt/PySide with Qt Designer. My template
projects:

[https://bitbucket.org/Odoth/pyqt5-template](https://bitbucket.org/Odoth/pyqt5-template)

[https://bitbucket.org/Odoth/pyside-
template](https://bitbucket.org/Odoth/pyside-template)

------
cwbrandsma
There is an inherent "HOLY SH*T" moment that happens to all desktop developers
when they transition to Web. You are used to one type of interaction when
doing native that is pretty simple and straight forward.

The real killer is the move to asynchronous development for everything. In
Delphi (and C# desktop), most calls can be made synchronously be default, and
simply. No so in the web (yes, you can do synchronous web calls...but you
shouldn't). And that is ignoring the whole statically-type-and-compiled
language to JavaScript issue. And then dealing with a huge array of libraries,
patterns, and best practices that are completely unknown.

Then comes out "why can't this be simple like what I was used to?" Actually,
what you were doing wasn't simple at all, you were just used to it. You
understood the complexity, so it seems simple. Web development also becomes
simple once you understand it. But first you have to be willing to learn
again.

------
TimJYoung
I hope that isn't considered too much self-promotion, but it's on topic.

You can have what you want with our product, Elevate Web Builder. It creates
single-page web applications in a Delphi-like IDE:

[http://www.elevatesoft.com/products?category=ewb&type=web](http://www.elevatesoft.com/products?category=ewb&type=web)

(examples at the bottom)

We're releasing version 2.06 shortly, and it has much-improved designer
drawing performance and design-time/run-time layout performance. The layout
performance improvements greatly improve the initial load performance.

The Delphi RAD model of development is actually perfect for single-page web
applications because you're inherently only writing one layer of the
application, the UI.

~~~
i336_
I had a quick look and decided to try the audio player. The volume control
isn't draggable. Also, I was a bit baffled at the framework's decision to
inline the page font, which is unlikely to change.

It looks like you're using your own HTTP server solution which doesn't seem to
have caching, so all content is being redownloaded each visit. ETags and Last-
Modified are very easy to implement, FWIW. (Note: I say that from the
standpoint of reassurance, not insult!)

This seems kind of interesting, but my immediate concerns are interoperability
with plain JS and how rapidly blocking issues are resolved since this isn't
open source.

I'm very curious to see what HN would make of this system; have you ever
posted it? Maybe that could be considered after the TreeView component and a
TodoMVC example were available.

Note that I'm not dissing this at all. It's clear to me that this has a niche
of people that are very happy and productive using this because it lets them
reuse knowledge they gained years ago. (I've looked at Pascal a bit, but never
really played with it. Lazarus is somewhere on my todo list, just to get a
feel for things.)

~~~
TimJYoung
Thanks for the feedback, it is always appreciated.

I'll take these one at a time:

1) The "volume control" is a cheat - I created that demo and used a progress
bar instead of an actual draggable horizontal gauge (not available).

2) The font is the icon font (a trimmed-down version of Font Awesome) used for
the icons in the applications. It's the preferred way of doing vector icons in
Elevate Web Builder, at least for now, but you also have the option of turning
off both embedding of the icon font and whether the icon font is included at
all (both are compiler options). In general, Elevate Web Builder always tries
to keep the number of requests required to load the application to a minimum,
hence the very aggressive in-lining of everything.

3) The If-Modified problem is a bug, and a really embarrassing one at that
(I'm installing a fixed server this afternoon). There's a millisecond file
timestamp comparison issue that is causing the If-Modified to never kick in.
The web server that we provide is just a "nice to have" thing because it
automatically handles the database JSON API for loading datasets and consuming
transactions, so that's how it's typically used, with less usage for static
resources. Larger customers typically implement their own back-end database
handling for IIS, Apache, etc. It's pretty easy to implement and the JSON API
is very simple.

4) In terms of interoperability with JS, you can include external JS source
with any project and it will get deployed with the project. After that, you
also need an external interface to the JS code so that the compiler knows how
to resolve any of the JS symbols:

[http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&t...](http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=External_Interfaces)

5) As for issues and how they are resolved: we're pretty responsive regarding
support/bugs, but Elevate Web Builder includes source code to the entire run-
time and component library, so you're free to modify most of the product and
we're able to give immediate hot fixes for most issues (~90% of issues/bugs
are in this code and not in the IDE/compiler). In fact, you could take the
command-line compiler that we separately provide and use it to create your own
Object Pascal <\--> JS IDE/product.

6) We've mentioned the product here before and it's received mixed reactions.
It is, without a doubt, an odd product for most developers coming from
traditional web development. :-) There are a lot of design choices that go
against what one would recommend when hand-coding an HTML/JS/CSS application,
but work beautifully when you're talking about a compiler doing the work for
you. The main point of the product is to capture the productivity that Delphi
provided in the desktop arena and bring it to web applications. This means an
intense focus on performance, reducing dependencies and deployment issues, and
ensuring that one can concentrate on the business task at hand.

Here is a "Hello World" in Elevate Web Builder:

a) Select File/New Project from the main menu. b) Drop a button on the main
form. c) Double-click the button and type in:

ShowMessage('Hello World');

d) Hit F9 to run the application.

You've now created a web application that shows a modal dialog with "Hello
World" when you click on the button, and it will run on any modern browser (>=
IE9), including mobile. Contrast that with the setup/coding involved to get
any sort of hand-coded web application up and running. You can see how this
works in more detail here:

[https://www.youtube.com/watch?v=o1cU0KoJU8Q](https://www.youtube.com/watch?v=o1cU0KoJU8Q)

If you download a trial version, you can get a feel for the technology in the
product by looking at the WebUI unit (WebUI.wbs). It's a ~13k-line UI layer
that implements both the design-time external interface and a run-time virtual
DOM that allows for very fast performance due to its BeginUpdate..EndUpdate
reference-counted update cycle functionality. The run-time avoids
interrogating or touching the DOM like it has the plague. ;-) It will also
show how the animation primitives work, along with how the control interfaces
are implemented. The control interfaces allow you to selectively skin controls
on a per-control, per-project basis, with on-demand loading of the customized
skins for each project at design-time.

~~~
i336_
Wow, thanks for taking the time to reply!

> _1) The "volume control" (...) used a progress bar instead of an actual
> draggable horizontal gauge (not available)._

Ah, that's the name of what I was looking for. I think HTML5 sliders can be
styled similarly to how the volume control looks, but I understand you're
targeting a wide variety of Web browsers here.

The reason I mentioned it was because I'm used to being able to drag volume
controls directly - I'm not used to them being output-only. I guess I was
deliberately looking for cracks in the design, to be honest :)

> _2) (...) [Y]ou also have the option of turning off both embedding of the
> icon font and whether the icon font is included at all (both are compiler
> options). In general, Elevate Web Builder always tries to keep the number of
> requests required to load the application to a minimum, hence the very
> aggressive in-lining of everything._

Oh, loading as a separate resource is is available as an option. Cool.

While somewhat unintuitive, I have indeed learned that fewer bigger requests
can load quicker than many small requests - which does makes sense, I guess
obsessing about caching isn't everything.
([https://news.ycombinator.com/item?id=13601451](https://news.ycombinator.com/item?id=13601451)
/ [https://danluu.com/web-bloat/](https://danluu.com/web-bloat/) \-
particularly the 3G bits, since lots of people tether)

> _3) The If-Modified problem is a bug, and a really embarrassing one at that
> (I 'm installing a fixed server this afternoon). There's a millisecond file
> timestamp comparison issue that is causing the If-Modified to never kick
> in._

Ah, I see. Comparison between 1488416112 and 1488416112.336420126? Completely
understandable.

> _The web server that we provide is just a "nice to have" thing because it
> automatically handles the database JSON API for loading datasets and
> consuming transactions, so that's how it's typically used, with less usage
> for static resources._

Ah, I see, that's the app server.

> _Larger customers typically implement their own back-end database handling
> for IIS, Apache, etc. It 's pretty easy to implement and the JSON API is
> very simple._

That makes perfect sense.

> _4) In terms of interoperability with JS, you can include external JS source
> with any project and it will get deployed with the project. After that, you
> also need an external interface to the JS code so that the compiler knows
> how to resolve any of the JS symbols: (...)_

Oh, _nice_! So you _do_ have interop. That makes quite a lot more possible.

Now I'm wondering whether your UI architecture is abstracted enough that end-
users could build UI components out of JS... hmm, that probably wouldn't work,
the UI designer wouldn't be able to control them. (I'm guessing you can design
your own controls in Pascal?)

> _5) As for issues and how they are resolved: we 're pretty responsive
> regarding support/bugs, but Elevate Web Builder includes source code to the
> entire run-time and component library, so you're free to modify most of the
> product and we're able to give immediate hot fixes for most issues (~90% of
> issues/bugs are in this code and not in the IDE/compiler). In fact, you
> could take the command-line compiler that we separately provide and use it
> to create your own Object Pascal <\--> JS IDE/product._

That's a great development model, and one I've considered myself (providing
source to a large portion of the codebase to accelerate urgent fixes).

I was wondering how the Pascal bit worked for a while there. I'm curious if
you pulled in another language implementation or built your own; I'm guessing
you went full crazy and made your own implementation, considering you compile
to JavaScript? :) (not sure though, Wikipedia mentions that Smart Mobile
Studio have a JS-targeting implementation)

> _6) We 've mentioned the product here before and it's received mixed
> reactions. It is, without a doubt, an odd product for most developers coming
> from traditional web development. :-)_

Yep. I can see the niche for this though. Plus, diverging from the mainstream
means you get to neatly sidestep the frenetic insanity associated with the
cutting edge, which can be really really nice if you find something that pays
well. :) (Still looking for my own one of that)

> _There are a lot of design choices that go against what one would recommend
> when hand-coding an HTML /JS/CSS application, but work beautifully when
> you're talking about a compiler doing the work for you._

Unfortunately modern Web development has gotten so caught up with layers and
layers of tooling and compilation, even hand-coded apps are beginning to
resemble sprawling enterprise apps. :/

But you make a good point.

> _The main point of the product is to capture the productivity that Delphi
> provided in the desktop arena and bring it to web applications. This means
> an intense focus on performance, reducing dependencies and deployment
> issues, and ensuring that one can concentrate on the business task at hand._

Yeah.

> _Here is a "Hello World" in Elevate Web Builder:_

> _(...)_

> _Contrast that with the setup /coding involved to get any sort of hand-coded
> web application up and running. You can see how this works in more detail
> here: (...)_

Before I watched the video I was half-scared this was a slightly more built-
out Pascal-based iteration of the old BAT2EXE "batch compilers" that could
never do anything. My apologies :)

I can now see this is essentially a GUI builder connected to a Pascal>JS
transpiler. That's really cool.

And yeah, this is _much_ quicker than finding a grid display library that
actually works, building an efficient data model to load data into it,
handling network issues... _hides under box_

> _If you download a trial version, you can get a feel for the technology in
> the product by looking at the WebUI unit (WebUI.wbs)._

With signing up... really like the "Real name" vs "Displayed name" vs "User
ID" distinction! Hm, idea: <label>s for the input fields on the new user
form... oh, and what's the automatic signup rate with your current captcha?...
ahh, consider _NOT_ sending the user password back through failed forms...
definitely definitely consider HTTPS for at least the signup form (!!!)... and
maybe redirect the user to the page they were on when they clicked the signup
link. The site design is very nice though.

(Regarding the captcha system, you have me confused and very curious. Are you
hashing the current time, or adding hash codes to a DB...? The PNG URL has no
parameters in it! :P)

> _It 's a ~13k-line UI layer that implements both the design-time external
> interface and a run-time virtual DOM that allows for very fast performance
> due to its BeginUpdate..EndUpdate reference-counted update cycle
> functionality. The run-time avoids interrogating or touching the DOM like it
> has the plague. ;-)_

It could be very fun to pit your virtual DOM against React's. :D

I wouldn't be surprised at all if yours won out - I think React tries to
"guess" by itself when to push its virtual DOM to the screen, and it
constantly gets it wrong of course. A reference-counted approach with "don't
update for a minute" boundaries sounds very simple and elegant. So I'm
serious, benchmarking your system against React's could be quite interesting;
but the problem would of course be in finding React-based controls to compare
against.

Also, Pascal doesn't actually look that bad. I've been meaning to get around
to having at least a passing knowledge of it for a while...

> _It will also show how the animation primitives work_

Ah, the world of HTML4.999999999999

> _along with how the control interfaces are implemented. The control
> interfaces allow you to selectively skin controls on a per-control, per-
> project basis, with on-demand loading of the customized skins for each
> project at design-time._

Huh, very nice. That's really cool.

\---

I thought I'd mention: the designer itself seems to actually work in Wine (in
that it didn't crash on me, and is in fact running in another virtual desktop
right now), but I got an error message that the web server failed to bind.
Happy to do further digging if you like.

Also, shift+scroll doesn't scroll horizontally in the designer. Something I've
gotten used to from Chrome, thought I'd mention it.

\---

I was also curious: have you ever considered pitching this for mobile UI
development? With a pixel-perfect grid-based system like this (that does
admittedly offer some very impressive snapping options) the only way would be
to create mobile-specific forms - but such an approach could potentially work
quite well. The only other thing I can think of would be (re)designing
controls that play nice with primarily touch-based environments, and
implementing views with slide animations and such. I don't _think_ this would
be a doomed idea, I'm guessing you've already thought about it.

~~~
TimJYoung
> While somewhat unintuitive, I have indeed learned that fewer bigger requests
> can load quicker than many small requests - which does makes sense, I guess
> obsessing about caching isn't everything.
> ([https://news.ycombinator.com/item?id=13601451](https://news.ycombinator.com/item?id=13601451)
> / [https://danluu.com/web-bloat/](https://danluu.com/web-bloat/) \-
> particularly the 3G bits, since lots of people tether)

There are some valid points to be made about bloat, and Elevate Web Builder's
monolithic applications _do_ tend to be on the larger side. However, the big
issue is always perceived load time, and that's what we always work on
improving first. The size of the application itself only really matters on the
first load after a change/re-compile/re-deploy, provided that you don't have a
bug in your web server that complete negates this performance improvement. ;-)

> Ah, I see, that's the app server.

Yeah, and it's going to be getting some attention before summer, specifically
with GZip and SSL support. The general idea is that (eventually) we're going
to be adding the Object Pascal run-time engine that is currently used in the
IDE at design-time to the web server, thus offering the same language for the
entire stack. When you work with controls/components in the designers in the
IDE, the run-time actually executes code from the component library, which is
why scrollbars work and you can click on buttons in controls to add new sub-
controls, etc. It's nice for a control/component developer because they only
need to set a simple flag that indicates that they want design-time events for
a given control, and the IDE/component library takes care of the rest.

> Now I'm wondering whether your UI architecture is abstracted enough that
> end-users could build UI components out of JS... hmm, that probably wouldn't
> work, the UI designer wouldn't be able to control them. (I'm guessing you
> can design your own controls in Pascal?)

That's a very astute observation, and 100% correct. :-) The easiest way to use
external JS controls in Elevate Web Builder is to use a TBrowser control,
which is simply an iframe control that will isolate the control from the
"normal" UI controls. However, it's also very easy to just create a wrapper
control in Object Pascal that interfaces with the JS, which is what we did
with the TMap control for Google Maps support.

The whole IDE is designed around the idea of creating and installing your own
controls/components, just like in Delphi. And, more importantly, it is a _lot_
easier because there are simple UI element building blocks (in the virtual
DOM) to use for building up controls, with the UI elements doing all of the
heavy lifting and modifications being simple property changes/method calls.

> That's a great development model, and one I've considered myself (providing
> source to a large portion of the codebase to accelerate urgent fixes).

It's pretty much been the "Delphi" way of doing things since it was first
created and sold by Borland, so we can't really take credit for it. It' funny,
though, because it pre-dates open source. I never used Turbo Pascal, but I
think it did something similar, and it _really_ pre-dates open source.

> I was wondering how the Pascal bit worked for a while there. I'm curious if
> you pulled in another language implementation or built your own; I'm
> guessing you went full crazy and made your own implementation, considering
> you compile to JavaScript? :) (not sure though, Wikipedia mentions that
> Smart Mobile Studio have a JS-targeting implementation)

We had some experience doing an interpreter in our SQL implementations for our
database engine products, so it was a natural move for us. The most difficult
portion was building the run-time execution engine, mentioned above.

(continued below)

~~~
i336_
>> While somewhat unintuitive, I have indeed learned that fewer bigger
requests can load quicker (...)

> _There are some valid points to be made about bloat, and Elevate Web Builder
> 's monolithic applications do tend to be on the larger side. However, the
> big issue is always perceived load time, and that's what we always work on
> improving first._

Totally makes sense. Taking bandwidth into account too is important, but yeah,
user perception... :)

> _The size of the application itself only really matters on the first load
> after a change /re-compile/re-deploy, provided that you don't have a bug in
> your web server that complete negates this performance improvement. ;-)_

Cool view :)

There's also the fact that browser caching can be terribly broken: I
unfortunately can't find it right now but I read somewhere of how a dev found
Safari on their iPhone was only caching a few KB (!!!!) of Web content.
Obviously something was broken somewhere (maybe Safari used a disasterously
incorrect percentage-of-free-space calculation) but yeah. I have to admit that
I'm considering hand-rolled ServiceWorker-backed caching systems myself; the
only infuriating question is where to actually store the data (ref
[http://stackoverflow.com/q/42288596/3229684](http://stackoverflow.com/q/42288596/3229684)).

>> Ah, I see, that's the app server.

> _Yeah, and it 's going to be getting some attention before summer,
> specifically with GZip and SSL support._

Nice!

> _The general idea is that (eventually) we 're going to be adding the Object
> Pascal run-time engine that is currently used in the IDE at design-time to
> the web server, thus offering the same language for the entire stack._

Oh _coool_.

> _When you work with controls /components in the designers in the IDE, the
> run-time actually executes code from the component library, which is why
> scrollbars work and you can click on buttons in controls to add new sub-
> controls, etc. It's nice for a control/component developer because they only
> need to set a simple flag that indicates that they want design-time events
> for a given control, and the IDE/component library takes care of the rest._

I noticed that from the video! Really cool feature.

>> Now I'm wondering whether your UI architecture is abstracted enough that
end-users could build UI components out of JS... hmm, that probably wouldn't
work, the UI designer wouldn't be able to control them. (I'm guessing you can
design your own controls in Pascal?)

> _That 's a very astute observation, and 100% correct. :-) The easiest way to
> use external JS controls in Elevate Web Builder is to use a TBrowser
> control, which is simply an iframe control that will isolate the control
> from the "normal" UI controls._

Oh, of course....

> _However, it 's also very easy to just create a wrapper control in Object
> Pascal that interfaces with the JS, which is what we did with the TMap
> control for Google Maps support._

It might be a very interesting idea to create wrappers for popular libraries.
I'm not quite sure _which_ libraries to support, but "look at this island
written in Pascal" is suddenly very interesting when you go "and here's the
dead-simple interop to this bunch of other things you already know".

> _The whole IDE is designed around the idea of creating and installing your
> own controls /components, just like in Delphi. And, more importantly, it is
> a lot easier because there are simple UI element building blocks (in the
> virtual DOM) to use for building up controls, with the UI elements doing all
> of the heavy lifting and modifications being simple property changes/method
> calls._

I have to admit that I really like the visual design way of doing things. I
played with Visual Basic just under a decade ago but I'm glad I moved on from
it as it didn't impose enough architectural structure. I poked Lazarus
recentlyish; it's on the todo list. :P (especially considering its Linux
support)

>> (...) (providing source to a large portion of the codebase to accelerate
urgent fixes).

> _It 's pretty much been the "Delphi" way of doing things since it was first
> created and sold by Borland, so we can't really take credit for it._

Ah, interesting!

> _It ' funny, though, because it pre-dates open source. I never used Turbo
> Pascal, but I think it did something similar, and it_ really _pre-dates open
> source.

"Shared source"?

>> I was wondering how the Pascal bit worked for a while there. (...)

> _We had some experience doing an interpreter in our SQL implementations for
> our database engine products, so it was a natural move for us. The most
> difficult portion was building the run-time execution engine, mentioned
> above.*

I think you're referring to WebUI.wbs...? 13k LOC (5448 without {...} blocks,
6076 with {$IF}s, apparently) is pretty crazy, yeah.

------
partycoder
You have major open source libraries like GTK, wxWidgets, Qt. Also .NET, Java
which offer multiple ways of doing forms that are tied to the target platform.
In addition, RealBasic (now Xojo) and... Delphi.

After Borland, other companies continued working with Delphi, namely,
Embarcadero:
[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi)

Now, the prices can be a bit prohibitive. I would try one of the open source
ones.

~~~
insertnickname
Note that Vala is apparently more or less dead.

~~~
pjmlp
Yep, GNOME seems to be adopting Rust, with librsvg and GNOME Builder being the
first places to spot it.

~~~
partycoder
Awesome. I will take a look at it, it seems I haven't kept up with the times.

From what I see, it comes with a profiler, which is an excellent addition and
the UI seems to be very similar to XCode.

------
Joeboy
I guess this is rather tangential, but I recently returned to professional web
development and I'm finding a shocking amount of the work is either rewriting
websites according to the whims of SEO consultants, or updating things to new
releases when the old versions stop getting security updates. Neither of which
are really issues for Delphi projects.

------
oneweekwonder
Me to! I'm still of the opinion Lazarus apps looks the best cross-platform,
compared to QT, GTK, wxWidgets.

I wonder if there is work out there for objects pascal. Because I would like
to apply.

But for now... _twoot_ twoot* hybrid train, here we come :'(

~~~
pjmlp
> I wonder if there is work out there for objects pascal. Because I would like
> to apply.

Delphi is still kind of popular in Europe, we even have conferences.

[https://entwickler-konferenz.de/](https://entwickler-konferenz.de/)

------
mamcx
Because web development is broken by design.

Or more exactly, web development was turned (badly) into app development.

------
BatFastard
If you haven't written apps in Delphi, you can't appreciate how easy it was to
write interactive GUIs.

It was a freaking miracle, and I wonder how we have managed to lose SO much
ground.

~~~
pjmlp
We let the kids run the show and turn a platform for interactive documents
into some sort of VM.

~~~
TomMarius
Well the bigger problem is it's (apparently) what the customer demands. The
problem being that we, the old and better developers, didn't come up with a
better solution than these kids.

~~~
Alex7691
Actually, that's not what customers demand. Customers demand a SOLUTION. IT
managers demand less work and that's why web is so prevalent. IT teams just
need to run a script to release version 2.0 of your application, being used by
hundreds, thousands or millions of users.

------
jcalfucura
In Delphi, IT IS that simple to create Web Apps:

\- For fast drag and drop RAD style development use UNIGUI, great interfaces,
plain and simple delphi development.

\- If you want a modern, optimized and responsive Web UI in full javascript
(but with typed and gentle Object Pascal), use "Smart Pascal Studio", it´s
like typescript but includes a GUI editor, widgets, node.js backend etc. check
out their full js desktop
[https://www.youtube.com/watch?v=ee_kXdueV_4&feature=youtu.be](https://www.youtube.com/watch?v=ee_kXdueV_4&feature=youtu.be)
(impressive).

\- If you want to bring your existing client-server delphi apps to the web,
use Thinfinity.

\- For a incredibly fast, low resource consumption, REST ready ORM, use
MORMOT.

\- For a nice, elegant and simple ORM use TMS Aurelius.

Please keep an eye in Smart Pascal Studio, it shares some ideas with
Typescript but their tools are way ahead in development, they started some
time before Typescript, it is a glimpse into the future of Web-desktop-mobile
development.

And don't forget FMX.

------
anotherevan
Twenty years ago, I wrote an application for the taxation office to help
businesses calculate payroll tax. It was written in Delphi for maximum
portability, because it had to run on Windows 3.1x, 95 and NT and was
distributed to 16,000 businesses on 3.5" diskettes. Talk about old school.

~~~
bbcbasic
Ah the days when you only had to care about Windows.

------
meredydd
I'd love to hear what you think of Anvil
([https://anvil.works](https://anvil.works)) - it sounds like exactly what
you're asking for.

It's a very Delphi-like (or VB-like) tool for building web apps: Drag and drop
for visual layout, then write code with a simple object model behind it. (It's
2017, so Python rather than Pascal - but more similar than it is different.
Also built-in git repo, a built-in database, code completion, integration with
services like Google Drive/auth/mail, etc.) I'm a cofounder, so I'm interested
to know whether it scratches your itch.

~~~
degenerate
I just tried the demo "MyCorp" anvil app: [https://secure-
portal.anvilapp.net/](https://secure-portal.anvilapp.net/)

It definitely feels bloated -- slow loading, tons of JS, overly engineered.
Perhaps the demo should do something more substantial.

~~~
meredydd
Thanks - yeah, there's a lot of optimisation still to do on load times. (We
need some JS to let you write client-side code in Python, but we know we can
load it a lot faster.)

I'm intrigued what smelt "overly engineered" to you, though. We're trying
quite hard to keep the programming interface simple, so if something there
offended you, that's good to know. (Or if it was another comment about load
time, then...yeah. That just went up the bug tracker a bit.)

~~~
degenerate
I mean the demo feels over-engineered. Create an account, activate account by
email, and login... just to download a 1-page pdf. I understand that the point
of the demo was to show the ability to create a working web-app, but a better
demo would showcase something with more meat than a single file download.
Perhaps a simple twitter clone with file attachments or something along those
lines instead of a file download app that has no other functionality.

Thanks for the reply!

~~~
meredydd
Aha! Yeah, that makes sense. It descends from a use case a consulting client
had a while ago (for which they ended up with a $X0,000 Salesforce deployment
instead of something I could build in an afternoon with Anvil, and in a few
days without it). Clearly not an obviously accessible example - we'll fix that
up a little :)

("Twitter clone with attachments" is one we use in workshops, actually - it
fits neatly into a single session. Guess I should write that up.)

------
pjmlp
Me too, that is why I try to stick with native development with Java, .NET
(all its variants), Android, iOS stacks whenever possible.

~~~
pron
I recently had to write a desktop GUI app, and chose Electron[1] because I
figured that for once I'd try something new and hip with lots of OSS libraries
because it wasn't too critical and I needed to pass it on to someone else and
figured there are lots of frontend web devs around. Well, it's _kinda_ OK, but
man, that thing is held together with spit and baling wire, and you feel like
it's all going to come down with the slightest breeze. The previous GUI app
I'd built was in Java/Swing, and while I wouldn't call the experience
particularly pleasant, at least it felt solid.

[1]: + TypeScript + Polymer

~~~
pjmlp
What I mostly hate in webdev is exactly that, helding together with spit and
baling wire, a pile of HTML tags meant for document publishing, CSS and
JavaScript, while pretending the browser is a proper application VM.

Than switching browsers, including the same one but a different version, and
start implementing workarounds. Multiplying this experience for each
browser/version/OS required by the customer.

~~~
pron
And it's not just web. I also used Julia in that project, and while the
language itself is really awesome for numerics (especially as I had to migrate
a lot of existing Matlab code, which is a pleasure with Julia), good luck
trying to package a standalone app (especially if you're using native
libraries). Oh, and the startup time? It's funny how some people complain
about the JVM in that regard.

Every once in a while I try to pull my head out of the JVM world to try other
stuff, see what else is out there, and people seem to be putting up with a lot
of pain that's downright unacceptable with more established tech. I'm guessing
people may be coming over from scripting languages where they're used to this
stuff (and they may it jarring to work on the JVM). Even when things aren't
that bad, like with NPM, they're miles behind the sturdiness of the Maven
ecosystem (which is far from perfect in itself).

~~~
pjmlp
Julia's startup time is the biggest issue holding people to leave Python
behind, as I understand from some talks I saw online.

Still I am hopeful that they will overcome them, as Julia is an interesting
language for those of us that know Dylan.

~~~
pron
Oh, don't get me wrong -- Julia is a great language and I hope I get the
chance to use it again. But its biggest issue right now isn't even the startup
time, but the fact that you can't even write a self-contained application with
it (well, you can, sometimes, and with great care).

------
chadcmulligan
There's this [http://www.unigui.com](http://www.unigui.com) make all your web
apps in Delphi :-), they've been in beta for a long time but seems to work.

~~~
acqq
Good find. Some opinions:

[http://stackoverflow.com/questions/3649969/what-do-you-
think...](http://stackoverflow.com/questions/3649969/what-do-you-think-of-
unigui-the-framework-for-creating-web-applications-and-win/3658904#3658904)

~~~
chadcmulligan
it has some negatives imho:

No source for bits of it which makes it risky since it seems there's only one
guy developing it.

Looking at it's comms it seems pretty lightweight, though it does generate a
lot of messages.

Last time I looked the Sencha library it used was fairly old

That said if you've got a low-medium weight web app you want to build and
don't care if it looks like windows, then it's dead easy (really 1 day or so,
it's that easy).

------
TurboHaskal
What I miss is Pascal.

Delphi and other drag & drop RAD tools are easy, not simple.

~~~
hjahre
What about Lazarus [[http://www.lazarus-ide.org](http://www.lazarus-ide.org)]
or Free Pascal [[http://www.freepascal.org](http://www.freepascal.org)]?

~~~
TurboHaskal
It's pretty cool.

------
realharo
Simple is subjective. I find the React way of making web UIs, where you just
write a `render` function, way simpler than manually mutating existing UI
widgets to match the data every time it changes. Or some weird manual data
binding via model wrappers.

Maybe it's a tiny bit more code in the very beginning, but it becomes worth it
_very_ soon (as soon as you get past hello world pretty much).

That being said, we could always have better tooling, even for this paradigm.

~~~
muraiki
You may be surprised to learn that React's paradigm is basically how Windows
GUI apps have been written from 1.0 up through at least Windows 7:
[https://bitquabit.com/post/the-more-things-
change/](https://bitquabit.com/post/the-more-things-change/)

~~~
realharo
Maybe there's a similarity in how it worked under the hood, but the users of
those APIs most definitely could not write UIs in that style.

In Win32 code, you still have persistent windows with child "windows" (UI
controls/widgets) on them, that have UI-specific internal state (such as text,
position, links to their own child windows, etc.) that is different and
separate from your application's state (variables, data structures).

Then you have to manually mutate (SetWindowText, ListView_InsertItem,
CreateWindowEx, DestroyWindow etc.) the UI when something in your
application's data changes.

Unless you don't use any native UI controls and just draw everything manually
I guess, but people generally didn't do that.

~~~
candiodari
> In Win32 code, you still have persistent windows with child "windows" (UI
> controls/widgets) on them, that have UI-specific internal state (such as
> text, position, links to their own child windows, etc.) that is different
> and separate from your application's state (variables, data structures).

I don't get it. This is a property of every UI toolkit. In other words, this
goes for the web as well. In the underlying structures, all data exists
independently of your application.

If you mean that there's libraries for the web (angular 1) that make it easy
to pretend this isn't true, that the contents of your variables are really on
screen, similar libraries exist for windows apps as well. Hell, all of those
database things like Access, in a way, have just this concept (the
language/tooling pretends that the form field for field X IS field X, through
bidirectional synchronization).

Also, except for windows 3.0 apps, nobody ever called things like
SetWindowText themselves.

Persistence, and the lack of options to turn it off is one the of major pain
points with the web as a platform. Even canvas is persistent, which makes no
sense at all to me.

And for me at least, there's two huge differences. On windows, very big apps
could work together and be open a dozen at a time. A dozen of single-page-app
tabs will, on the other hand, slow my Xeon-backed chrome to a crawl. Secondly,
I have never seen any webapps that approach the complexity of normal windows
apps. The most complex web apps currently are things like Google Docs, and the
average is something like a webform. How many years of the web platform do we
need to conclude that it has found some way to prevent feature-full
applications from being written ?

I've developed plenty of applications for both windows desktop and for the
web, and it's pretty clear to me: the web enforces extremely complex methods
of doing things. Markup, javascript, RPC (can be HTTP), other language,
another data language is the default layer. Adding a single field to a single
record type requires knowing HTML, JavaScript, HTTP (how to use HTTP and
encode stuff in it), and then backend language (let's say Java), then SQL. ALL
of them need to be modified to just modify a record type.

The web is extremely lacking in performance, and is far, far more complex than
it needs to be.

"Worse is better" ... Indeed.

------
gregmac
In short: because the web is inherently stateless and it's much harder to deal
with than stateful UIs.

I last used Delphi back around the turn of the century, so I'm remembering it
as a drag-and-drop Windows UI framework/builder. ASP.NET WebForms is the most
similar thing I've used (and it's been at least 5 or 6 years since I last
really used it). I would not recommend investing a lot of time in it.

WebForms is great when you are starting. It is drag-and-drop, with 'controls'
like text boxes, drop-downs, check boxes, grids, labels and pictures, and
there are a ton of 3rd party control toolkits.

WebForms abstracts away the stateless nature of the web, and attempts to make
it look like it's stateless. The trouble is it's a leaky abstraction, and at
some point it's unavoidable that you will have to deal with it either
indirectly or directly.

Indirectly, you deal with slow load times as a crazy amount of 'state' storage
is required to maintain the abstraction. I dealt with an app at one point that
had a grid with many text box controls in it, where the 'state' information
was well over 1MB -- which gets sent as part of every request to the server.

As your app gets more complicated, you start running into more direct
problems. In my experience, as soon as you're build any type of interaction
that's not something built-in (can be done by clicking in the IDE), you start
fighting with the framework. The lifecycle is necessarily complicated in order
to support the stateful abstraction, and you must understand it very deeply to
know where to put your code. The lifecycle is a series of events that happen
between initializing, loading posted data, rendering output, etc.

At some point you realize the framework is getting in your way more than it is
helping, and switch to just developing for stateless directly (which basically
means MVC, or a stateful single-page app + stateless REST API).

~~~
TimJYoung
Single-page web applications that get loaded once and stay loaded, and are
primarily driven by JS code, don't have any of these negative attributes.
State is kept in memory, just as it is with a desktop application. There is no
need to shuttle around large amounts of state, other than what is needed to
authenticate against/communicate with the back-end APIs.

------
paulajohnson
The problem with Delphi and its relatives is that they are walled gardens. As
long as you are working on the kind of application envisaged by the designers
(roughly, CRUD with a SQL backend) everything is easy. As soon as you step
outside that domain your foot disappears into a sucking quagmire.

~~~
barrkel
I don't really agree. Delphi made writing native code on Windows really
pleasant, primarily because it had (a) a built-in string type with reference
counting and (b) strong conventions around object ownership and construction /
destruction.

The built-in string type interacted really well with the Win32 API, and it was
universal - there wasn't one string type to deal with the platform, and
another string type for your own code, and yet another string type for third
party code, all too common in C++, especially in the 90s.

The object model - zero-initialized reference types with a Destroy method that
was safe to call on null values - avoided one of the biggest pains in C++
exception safety, in particular safely destroying partially constructed
instances. The idioms in Delphi don't catch all cases (e.g. if a destructor
throws, you're potentially going to leak), but they work really well 99% of
the time without convolutions or RAII wrappers.

Delphi did exceptions very well too. Because of the strong conventions around
try/finally to wrap creation and destruction of objects, exceptions never felt
dangerous or uncontrolled. I don't think anyone who used Delphi in anger pined
for nothrow, explicit exception specifications or wholesale replacement of
exceptions with error codes.

The point is that it was a high-level native language language that was far
easier to use correctly than C++.

------
kriro
I only wrote a couple of non-GUI toy programs in Pascal "back in the day" and
did some disassembling for fun because someone told me it won't look like C
disassemblies (they were right!) but tbh, Delphi from what I remember (only
saw it used, never used it) isn't wow-ing me more than current state of the
art GUI-builders (like say Storyboards for the Apple ecosystem) so I suppose
it's mostly nostalgia? Not sure comparing it to web development is fair but
(all those wicket corner cases aside) I actually like the simplicity of web
layouting as well. With a decent reset or bootstrap or whatever (and maybe
flexbox) I think pure HTML+CSS is very direct and can be prototyped rather
quickly via "textfile change and see".

------
Entangled
I miss Visual FoxPro. I have never been more productive in my whole life. Of
course compared to today's languages that's an abomination to say, but the
tools, the data browser and the sql embedded in the language made it shine on
its own merits.

~~~
dragonbonheur
Why are today's languages better when none of the tools have caught up with
what we had then, both in terms of efficiency and simplicity?

~~~
Entangled
The languages have advanced in so many directions, I just took a look at old
foxpro code and it was damn ugly, all caps and ENDIF ENDFOR everywhere. That's
ugliness if I've seen it.

Now tools, they were unbeatable in their simplicity and effectiveness as you
say. A data browser is the most powerful UI and the ability to connect it with
a data source by its cursor name can't get any simpler. Try doing that even in
Swift and it is a rain dance of sorcery to make it work.

A data source to a report, bam! As simple as that. A data source to a table,
bam! to a form, bam! to any UI control, bam! That was productivity if I've
ever seen it.

------
robocat
What killed Delphi:

1\. Embarcadero nee Borland always building new "cool" features (e.g. IoT)
rather than core functionality (64 bit only recently, compiler slow, IDE
crashes).

2\. User base now mostly supporting old applications so require high level
levels of backwards compatibility (with poor or broken APIs).

3\. Loss of good libraries. Originally they had good libraries (and culturally
the source was available for a few extra $$). Now libraries are poor, there is
little incentive to make new libs, and the target is fragmented for library
writers (many Devs are stuck on a variety of older versions - upgrades are
costly, and upgrade reliability is erratic).

------
pengo
I started developing in Delphi after Delphi 1 came out, have worked in Java
and C++ along the way, but I've been largely a LAMP stack web developer for
the last ten years. I've looked at the code output from various Delphi web
builders; it's not pretty, not inherently responsive, not accessibility
compliant.

I still use Object Pascal in Lazarus for writing widgets and utilities. It
cross-compiles to Linux, MacOS and Windows and lets me do things that would be
difficult or impossible with a web app. But these get about 1% of my
attention.

------
petra
Want simple development ? go for low-code environments, that simplify a lot
and use gui tools where possible(models, workflows, forms,etc). There are
plenty tools of those sort, and at least the best of them(mendix/outsystems)
may scale pretty well in complexity of applications created in them.

------
Fredej
We're maybe 50-100 Delphi developers and most of us can't wait to jump to C#.

To each his own :)

~~~
clouddrover
> _most of us can 't wait to jump to C#_

Why?

~~~
nottorp
Little historical fact, Microsoft nicked Andreas Hejlsberg, the creator of the
Borland flavor of Pascal (starting from the Turbo Pascal days), and had him
architect C#.

So if you trust microsoft, or you're doing boring bussiness software where you
don't care about anything but the paycheck, C# may be an improvement.

~~~
pjmlp
Yep, Delphi's soul lives a little bit in C#. Also a reason why I was quite
disappointed of .NET being NGEN + JIT, instead of pure native compilation like
Delphi.

At least, WP 8.x brought us MDIL, followed by .NET Native and CoreRT.

Also Anders and his team work on Typescript is quite good.

~~~
jlebrech
yes, it's the same DNA. my missing Delphi I mean IDE that inherited from it's
philosophy.

text editors and command line scripts seem like a backwards step.

------
peter_d_sherman
This is why:

[https://www.joelonsoftware.com/2008/03/17/martian-
headsets/](https://www.joelonsoftware.com/2008/03/17/martian-headsets/)

------
jarjoura
Delphi had its place in 2001 along with NeXT's WebObjects. Products of their
time for sure.

However, the developer inspectors alone inside of Chrome and Safari are 100x
more powerful than any of those old UI tools of the past.

~~~
hboon
100x more powerful than the Visual Builder in VisualAge suite of products [1]
and Dolphin Smalltalk's MVP-based tool and code browsers [2]?

While those (along with Delphi's VCL) are now a shadow of their past or
completely defunct, I doubt anything comes close to them technically, let
alone 100x more powerful than them.

PS: I just missed that this is about Web development though. Will just leave
the comment here for posterity.

[1]
[http://www.edm2.com/index.php/VisualAge_for_Java_Professiona...](http://www.edm2.com/index.php/VisualAge_for_Java_Professional)

[2]
[http://www.samadhiweb.com/blog/2015.12.31.dolphin.nbsqlite3....](http://www.samadhiweb.com/blog/2015.12.31.dolphin.nbsqlite3.html)

~~~
acqq
Have you tried to use VAJava _at that time_ (middle nineties of the previous
century)? Or maybe you were involved in producing it, or simply like
Smalltalk?

"As mentioned before, VAJava is written in SmallTalk. As expected, the
environment is not going to set any speed records for Java performance"

"I used the JGL benchmarks to test the performance of the Java virtual
machine. When running under VAJava, the benchmarks took significantly longer
to run than they did under version 1.1.5 of Sun's JDK. Therefore, I would not
recommend VAJava for testing applications which are primarily computational."

I've tried something from VisualAge at that time and it was a pure
catastrophe. My conclusion was that it was bought only by the enterprises who
decided to force their developers to "use IBM" no matter what. Maybe VAJava
was different?

~~~
hboon
I only have experience with VA Smalltalk and VA Java. I used their WebSphere
suite of products years later.

> I've tried something from VisualAge at that time and it was a pure
> catastrophe. My conclusion was that it was bought only by the enterprises
> who decided to force their developers to "use IBM" no matter what.

On the contrary, VAS and VAJ was one of the most non-IBM-like products,
compared to say Rational Rose or Eclipse (ironically, Eclipse was supposed to
be a descendent of VAJ) or WSAD which is built on it.

> Maybe VAJava was different?

VAJ is basically the Java language bolted on the Smalltalk paradigm - code
browsers, workspace, method-level versioning, etc. Smalltalk is an acquired
taste, so I can see how VAJ can be a turn off for some.

> it was a pure catastrophe.

Do you remember why it felt that way?

~~~
acqq
> Do you remember why it felt that way?

Yes: I've really enjoyed using Turbo Pascal in eighties and earned for living
developing using Borland products in the early nineties. I've received VA for
C++ to evaluate its suitability. After I've installed it it crashed almost on
every click, before I was able to even try something usable. Before it would
crash, it would be also quite slow to do anything. In short, not comparable at
all with the Borland feel I was spoiled with (remember, the OP here is about
Delphi). I don't remember if I've tried it before or after the first (16-bit)
Delphi. But I know that I was absolutely amazed with Delphi, and quite puzzled
with VA C++ (not understanding how they approved the production of the CDs of
something in that state). I understood that IBM favored OS/2 and I've tried it
on the NT of that time, so, apart for the clumsiness of the interface (which
simply didn't fit much with what I've expected an IDE should let me do easily)
I've also assumed that they probably tested it only on OS/2 and have made the
NT version just to say it exists.

So I can't say it appeared better than Rational Rose which was also horrible,
as far as I remember, more stable (as in not crashing that much), but again in
my opinion unusable except for wasting time.

The system on which I've tested was otherwise stable, the applications I've
user regularly and the builds that lasted hours haven't crashed.

~~~
pjmlp
From your description I would assume you got to use the version where IBM
tried to create a Smalltalk/Lisp Machine experience for C++, similar to
Lucid's Energize C++, which was so resource demanding that IBM gave up on it.

Nowadays we have Apple and Microsoft returning to the idea of using databases
to model C++ on the IDEs.

~~~
acqq
Here's one guy writing about VA C++ of that time:

[http://www.tarma.com/articles/1996sep.htm](http://www.tarma.com/articles/1996sep.htm)

"Let’s not beat around the bush: _VisualAge for C++ for Windows is a disaster
as far as I am concerned. It is by far the most anti-productive environment I
ever came across, C++ compilers or otherwise._ "

"The wizard-like approach for project configuration takes you through a number
of tabbed dialog pages à la OS/2 (with spiral binders and all that), and they
simply look gross on the Windows platforms. What’s worse, elementary options
such as a Browse button to navigate to a project directory are missing."

"A static library is not among the options as I found during one of my tests,
but for the ones that are, _you sometimes wish you’d never started in the
first place_."

Etc. I also remember it looked visually weird. And that it didn't do what I
expected an IDE to do. He describes that and also some strange manual steps.

Another guy, later version:

[http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review](http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review)

"Installing VAC4 can range from a trouble free walk in the park to something
akin to being in the first wave landing on Omaha beach. I have installed the
OS/2 and NT versions on multiple machines with varying, mostly good, results.
However _there are some really nasty horror stories in the news groups about
installs going awry._ In my experience installation problems seem to revolve
around four issues:

VAC4 is very picky about hardware. It will complain or _not run on a machine
that is seemly running everything else just fine_. I've run into this more
with OS/2 than with Windows."

"Once you get VAC installed there is one fix pack for version 4 and two fix
packs for version 3.6 that you need to install which take care of a number of
bugs. The fix pack installation also uses Feature Install. Did I mention that
Feature Install really stinks?"

I'm sure I haven't had "fix packs."

~~~
pjmlp
Yes that was the one.

It was just too advanced for its time, and as I mentioned, Apple and Microsoft
are exploring this path for their C++ IDEs.

~~~
acqq
> It was just too advanced for its time

As in, too advanced to implement the basic functionality before being that
advanced. But I think there's enough evidence: only those who were physically
forced to use it could have used it then. Which was my initial opinion.

P.S. Have you personally used VisualAge C++ in the nineties? Can you tell a
bit about your use too? I see you're linking the other things that weren't and
aren't that VisualAge C++ thing. Thanks.

~~~
pjmlp
As in, required too much computer resources for what people were willing to
pay for, and was full of bugs.

Lucid Energize C++ was way better, but bad management has a tradition to kill
awesome products.

[https://www.dreamsongs.com/Cadillac.html](https://www.dreamsongs.com/Cadillac.html)

------
_pdp_
Back in 98/99 I wrote an app on Delphi for my dad to run his business. He is
still using it today (on a modern OS) although he reports bugs that I no
longer can fix.

------
stijnsanders
I do my web dev in Delphi: [http://yoy.be/xxm/](http://yoy.be/xxm/)

------
michalpt
I loved Delphi as well. I remember developing games with Delphix and then
GLScene :)

------
swearfu
I miss C++ Builder

~~~
pjmlp
I thought C++/CX + UWP could fill that gap, but it isn't quite the same, but
still way better than VC++ + MFC/ATL ever was.

~~~
zeroc8
Did you see C++/WinRT? [https://msdn.microsoft.com/en-
us/magazine/mt745094.aspx](https://msdn.microsoft.com/en-
us/magazine/mt745094.aspx) Now that looks promising.

~~~
pjmlp
Yes, it is still pretty much work in progress, lacking many C++/UWP features
to be usable for UWP applications, specially regarding VS XAML editor, Blend
integration and UWP controls.

Microsoft is promising feature parity with C++/CX when VS17 comes out, lets
see.

In any case, .NET tends to have the spotlight for app development on the MS
stack, with C++ getting the low level high performance work, so C++/CX is
nice, but as way to expose those low level APIs as UWP controls, just like
C++/CLI does for .NET.

------
eweise
I miss Powerbuilder

