I miss Delphi
Why can't web development be as simple as delphi?
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.
Driving around randomly uses gas and contributes to maintenance costs, but gives you an irreplaceable spatial idea of your environment that you can't get from scrabbling through a directory, and which you definitely can't absorb from Google Maps or a GPS.
I only grasped these ideas quite recently, and have been rather motivating to get me to learn more about the academic aspects of CompSci.
> 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
(It was actually our bug - we were doing a Winsock layered service provider, and the error code indicated that we'd failed to return SUCCESS and hadn't set any additional error info. At the time, though, Microsoft's documentation gave only the one sentence above as a description.)
I don't blame this on Borland. Nonetheless.. I ran.
One day someone will make something like it for the web and make a few billion.
MM_preloadImages()Should have used madExcept or another tool like it. madExcept gives you runtime error logs which report the source code line of origin of any exception in your application. It's incredibly useful, particularly in the scenario you describe:
You experience is more a reflex on the nose-dive that management than what the tool/language is; including the Interbase engine, that was open-sourced then become closed fast.
Bad code is normal across enterprise applications, but even taking into account the RAD biased approach of the Delphi IDE is easy to do good coding. What is not easy is to have badly-trained developers doing massive amounts of code.
I know, because as moderator in Club Delphi, we answer A LOT of question about VERY BASIC stuff. Is amazing the amount of people that use Delphi (or JS, or .NET or PHP... we have sections for that too!) without read even a basic book or some decent basic entry-level tutorials/documentation.
I have thousands of answers that are mostly, "Please read http://www.delphibasics.co.uk/ (or similar)".
And about databases? Dammit, I don't know who is the bastard to blame in turn one of the easiest thing to learn and convince everyone "Nah! how wanna spend 20 minute of basic SQL/Relational fundamentals? Just write sql dammit!".
The other bulk of questions I help is about 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.
Are you using a framework for that or is it your own implementation? I've found mORMot to be useful:
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.
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).
There are some great sets of component libraries around though - tmssoftware and devexpress are very good, and of course you can always use c.
Turbo Pascal fealt great then (everything was coherent, relatively well-designed, speedy, etc), but after recently looking back at the code from then.. ehh.. we have better things now.
(Except perhaps in ease of getting started - for beginners.)
It was a constant infuriating disappointment. Delphi should have been so much more.
Hell, I miss it. Very much.
BTW, Synapse is better (IMHO) than Indy. One of the biggest damages of MS (yes I blame MS first) is that turn anything in a monster of complexity, I don't know if trying to mimic Java or as side-effect that a big company like MS can't understand how do lean app development.
Then the management idiots at borland follow MS (like everyone else) and the rest follow both. That is how you get something like Indy and other libraries.
Was WAY LATER with the arrival of python/ruby that that become more popular the idea of simple/good design on libraries.
Some of it is returning back to Delphi, however, because management price Delphi out of the equation of many of his own customers not exist a good ecosystem to rely on.
--- P.D: Still do good web development in languages with static types is a bit harder (even F# struggle with it); and I'm unsure what language of this family show a great experience here.
Whereas someone working with, say, C# or Java, can just go and find a library that's native to their language, ready to use out of the box (even if internally it wraps that very same C library).
It's the usual curse of a small ecosystem. Things were different back when Delphi was popular.
Easy, fast Delphi based web server. No affiliation, just a happy customer.
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.
I'm out of the loop of the cutting edge of UI stacks, so I genuinely do not know whether you are sarcastic or sincere...
So, you should be safe with v. 11...
That's so 2016, you really should get with the times.
The biggest thing desktop apps are missing was the delivery mechanism. With web apps:
* a new user is just a hyperlink away * pushing app updates is a page reload * server-side state eliminates all of the migration headaches for client-based state
People are fickle and they will decide not to use a service if it takes a couple of seconds to load. When you require them to download an app and install it, you've already eliminated two major categories of users: impatient users, and users who don't know how to (or aren't allowed to) install applications.
The problem is canvas wasn't designed to be that all-or-nothing alternative to the DOM. It was designed as an alternative to the flash player for html5 games. As a result, it lacks several features that are needed to display generic content, the most prominent of these features being proper (and easy!) font rendering.
I suppose you could build your own advanced font rendering engine (I think Flipboard did exactly that), but that's more work and risk than most companies or even individuals are prepared to take these days. And you are right; creating your own would cause you to re-create a lot of stuff that's already handled by the browser, like font highlighting, copy/paste, etc.
You just wait - there will be a terminal emulator written with webassembly+Canvas eventually. Perhaps powered by the already existing Emscripten port of Linux.
If you told me your stack is as you described, I'd say there's either some serious overengineering going on where you work, or you're solving a very different problem that would have been very complicated even in the Delphi world.
I think you're also vastly underestimating the operational work involved in deploying, maintaining, and syncing thousands of desktop apps in this type of environment. I'm personally happy I only have to get my software running on a couple nodes both with the exact same configuration.
You'd then be able to drag and drop columns from the list onto a form, and it would create the correct components depending on type, with appropriate labels, etc. Similarly, drop a grid on a form and get type-aware in-cell editing. Automatic updating of a details view when navigating through a parent data set. Etc.
One of the nicest things about Delphi was that you could compile into a single executable that you could deploy without further dependencies. One of selling points of Go, 20 years ago.
- 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 itBack 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.
You just gave me a humongous rush of nostalgia from when I was 12 and always had Resource Hacker open to make my apps look "professional" on every compilation. Thank you.
2) Agreed, the pricing needs some changes, it's still way too expensive for what they're including in the Professional version:
https://www.embarcadero.com/app-development-tools-store/delp...
For hobbyists and those on a budget, there's always Lazarus/Free Pascal.
3) Not true, unless you're talking about the IDE. However, there are all sorts of Object Pascal IDEs such as Lazarus (cross-platform IDE) and Oxygene (uses Visual Studio) that can use the same/similar Object Pascal code.
4) I'm not even sure what you're talking about here. Privileges under Windows, etc. has nothing to do with Delphi specifically.
5) Also not sure what you're describing here. You can add an icon to your application pretty easily via the Project Options dialog. One of our best-selling products is developed in XE6, and we don't have any issues with the application icon.
6) This is a build system issue. Most build systems handle version info/manifest generation without issue.
7) Zero ? I think that's pretty easy to disprove.
8) Definitely not true. If what you say is true, then we wouldn't be in business. There are still a lot of companies making a lot of money using Delphi, primarily because they didn't spend a better part of the 00's trying to rewrite their flagship application(s) in C#, just for kicks.
Having said all that, yes Delphi is definitely not in the same position it was in the early 00's, but it didn't all of a sudden get a crappier compiler or component library. If you invested in Delphi then for your business, then your applications could still be compiled today on Windows 10 without major issues or re-writes. It's hard to quantify that kind of value, but it's still important. It's the same reason why so many businesses stick with Windows - there's a lot of value in being able to run applications that are a decade old on newer versions of the OS.
The fact of the matter is that there are only two major options for writing LOB Windows applications fast today: Delphi and C#. Anything else isn't going to be anywhere near as productive. And, if you're writing applications that need to be distributed to a lot of seats and work on every version of Windows from the past decade, then using .NET is going to be somewhat problematic.
There is a lot of legacy Delphi code out there. I make a good living by supporting some companies. And they have no intention at all to replace / rebuild any of it because that will be much more expensive. As is often with legacy code.
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.
I would love full QT with a modern, high-level static language that is not hobbled on Windows. .Net may be the first to get there with a quality cross platform UI (Mono's WinForms are a bit hobbled too).
I haven't played enough with Lazarus to see how they compare though, it looked promising too.
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.
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
(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.
Our upcoming 2.06 release includes a new menu bar control (horizontal), which was also a sorely-missed control.
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.)
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...
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
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.
> 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://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.
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)
> 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).
>> 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.
> 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)
It's doing pretty well, and we're slowly but surely building up a decent customer base. Plus, we're a very small company, so we don't need much revenue.
> 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.
Yeah, try to ignore the web site issues for now. It's a little dated, and is about a decade old now. We're going to be "dog-fooding" the whole thing with Elevate Web Builder, once the web server is updated to include the Object Pascal run-time and the GZip/SSL support is added. It will make a good example that customers can use to build their own sites, etc. It will be a mix of back-end-generated pages with mini Elevate Web Builder apps for various sections that now use plain HTML forms. Having said that, we're going to move the logins on to HTTPS sooner than that.
> (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)
Yes, it's performing some machinations on the time to generate the code. Essentially the code/PNG is stored and then deleted after it has been used. Again, not our finest work, but we don't have too many people trying that hard to sign up on the web site with robots. :-)
> 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.
I've also wondered the same. Besides what you point out, my concern with React is that it might stress the GC too much, but that's based upon my limited understanding of how its diffing algorithm generates what it needs to update the DOM. In contrast, Elevate Web Builder only needs to track a simple change set per UI element and enforce one simple rule: no UI element will actually apply its DOM updates until all parent elements are no longer being updated. The initial application load results in only one pass of DOM updates because there is a BeginUpdate..EndUpdate block around the application "surface" (body element) during the application load. And, more importantly, elements are created once and stay created.
Elevate Web Builder 2.06 actually adds some more optimizations in this regard, including the concept of "local change blocks" whereby layout and measurement are delayed until the EndUpdate call (where UpdateCount=0) on a per-element basis without taking into account the parent update status. This provides a much-needed reduction in how many calls are necessary to compute the width/height of UI elements that are auto-sized. The measurement functionality touches the DOM (off-screen, but still part of the DOM), hence it's very slow. So, the general design is that local updates control when layout/measurement occurs (there's also a method to force this), and global updates (including parent update status) control when DOM updates are applied.
> 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's actually quite a nice language, although the Elevate Web Builder variant is a little more restricted than Delphi, due to some of the limitations of JS. We've written database engines, ODBC drivers, PHP extensions, web servers, general applications and libraries, and an IDE/compiler using it, so it's pretty versatile. More importantly, it has GUI options on the desktop, which is where a lot of languages fall down. It is often the case that "just use an embedded browser" is not a viable solution for a professional application, and then you're stuck using some tacked-on GUI toolkit that may or may not work particularly well with your language.
> Ah, the world of HTML4.999999999999
:-)
> 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.
It's probably just the binding to port 80, which is a bit naive, but can be changed pretty easily:
http://www.elevatesoft.com/supportfaq?action=view&category=e...
(if you want to follow up on this via email, you can contact us at support@elevatesoft.com)
> Also, shift+scroll doesn't scroll horizontally in the designer. Something I've gotten used to from Chrome, thought I'd mention it.
Thanks, I'll check that out and make sure that it's added.
> 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.
We also target mobile, fully support touch, and there are a lot of responsive flow options in the layout functionality, but yes, it's normally best to create separate mobile/desktop versions simply so that one can take advantage of the unique functionality on each platform. This isn't as bad as it sounds, however, because one can easily share units between projects, including database units that include database model functionality. There are also simple method calls for aggregate animation operations such as sliding:
http://www.elevatesoft.com/manual?action=viewmethod&id=ewb2&...
Ah, the 10k character limit. Heheh. Thanks again for replying!
In HN's case, it's because Arc sorts all comments with the same score chronologically... so I upvoted your first post. :)
Incidentally, Reddit's PM system happens to produce the same results too. Unfortunately due to post weight fuzzing the only way to keep things in consistent order is to make a tree of replies, or clearly mark "i of n" etc. Anyway.
> It's doing pretty well, and we're slowly but surely building up a decent customer base. Plus, we're a very small company, so we don't need much revenue.
(Very) small companies FTW.
> Yeah, try to ignore the web site issues for now. It's a little dated, and is about a decade old now. We're going to be "dog-fooding" the whole thing with Elevate Web Builder, once the web server is updated to include the Object Pascal run-time and the GZip/SSL support is added. It will make a good example that customers can use to build their own sites, etc. It will be a mix of back-end-generated pages with mini Elevate Web Builder apps for various sections that now use plain HTML forms. Having said that, we're going to move the logins on to HTTPS sooner than that.
Nice! I see.
>> (Regarding the captcha system, (...))
> Yes, it's performing some machinations on the time to generate the code. Essentially the code/PNG is stored and then deleted after it has been used. Again, not our finest work, but we don't have too many people trying that hard to sign up on the web site with robots. :-)
Oooh, I see. That's a nice and simple approach! I must admit my own thinking with captchas was something along the lines of "probably needs to be a Rube Goldberg machine, preferably one built out of kitchen sinks - that should make it secure enough"... I must admit I didn't quite think through simpler approaches like this (probably due to all the captcha fails I've come across, although I can't relocate the one I was thinking of right now).
>> I wouldn't be surprised at all if yours won out (...)
> I've also wondered the same. Besides what you point out, my concern with React is that it might stress the GC too much, but that's based upon my limited understanding of how its diffing algorithm generates what it needs to update the DOM.
FWIW, imgur is nigh unusable on my old ThinkPad T43 (if not for the Imagus image preview extension I {c,w}ouldn't use it). So yeah.
> In contrast, Elevate Web Builder only needs to track a simple change set per UI element and enforce one simple rule: no UI element will actually apply its DOM updates until all parent elements are no longer being updated.
Oh that's what you mean by reference counted... yup, that's a far simpler approach.
> The initial application load results in only one pass of DOM updates because there is a BeginUpdate..EndUpdate block around the application "surface" (body element) during the application load.
Nice :D
> And, more importantly, elements are created once and stay created.
I've noticed that modifying large chunks of HTML can cause rather large glitches, whereas isolating changes to the elements in question is ridiculously fast, yeah.
> Elevate Web Builder 2.06 actually adds some more optimizations in this regard (...)
That is really cool. I wish more application frameworks focused this much on efficiency :(
>> Also, Pascal doesn't actually look that bad. (...)
> It's actually quite a nice language, although the Elevate Web Builder variant is a little more restricted than Delphi, due to some of the limitations of JS. We've written database engines, ODBC drivers, PHP extensions, web servers, general applications and libraries, and an IDE/compiler using it, so it's pretty versatile.
I see (wow). So it _is_ a transpiler. Now I'm wondering if it'll ever have options to optimize for ES2015, or obsessing over JS generation (ref https://news.ycombinator.com/item?id=13762787), or even compiling directly to WebAssembly...
(FWIW, wasm's interpreter architecture and bytecode set are already locked in and both Firefox and Chrome already have (disabled by default) support - everyone's just tossing up how (hopefully not "if"!) to talk to the DOM.)
> More importantly, it has GUI options on the desktop, which is where a lot of languages fall down. It is often the case that "just use an embedded browser" is not a viable solution for a professional application, and then you're stuck using some tacked-on GUI toolkit that may or may not work particularly well with your language.
Yep, and this gets you Pascal->HTML. Makes a lot of sense.
>> Ah, the world of HTML4.999999999999
> :-)
The day HTML interpreters reach parity will likely be the day we're all using something else :(
>> (...) the web server failed to bind.
> It's probably just the binding to port 80 (...)
OH, of course, you can't bind to ports <1024. Yup, that fixed it. One question though: I was playing with the stop/start server buttons and couldn't restart the server "because it was already listening". I suspect it might be a missing SO_REUSEADDR: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
It's okay though, I just picked a different port.
And now I have a new problem: I'm seeing "Emitted C:\users\i336\My Documents\Elevate Web Builder 2\Projects\D:\project1.js (total size is 965998 bytes - not compressed)", which presumably isn't working. (Previous "is this what you wanted?"s included "C:\users\i336\My Documents\Elevate Web Builder 2\Projects\..\..\..\..\..\project1.js"!). I've emailed you in case you're interested :) (full disclosure: I'm just playing around with this, and I don't know any Delphi people, although EWB is of course filed away)
>> Also, shift+scroll doesn't scroll horizontally (...)
> Thanks, I'll check that out and make sure that it's added.
* 1024x768 sort-of-masterrace *
>> I was also curious: have you ever considered pitching this for mobile UI development? (...)
(PS. By "snapping options" I was trying to describe dynamic flow/resize, yep)
> We also target mobile, fully support touch, and there are a lot of responsive flow options in the layout functionality, but yes, it's normally best to create separate mobile/desktop versions simply so that one can take advantage of the unique functionality on each platform. (...)
Oh okay! Nice. (Although not targeting mobile is kind of crazy, so it makes sense...)
After Borland, other companies continued working with Delphi, namely, Embarcadero: https://www.embarcadero.com/products/delphi
Now, the prices can be a bit prohibitive. I would try one of the open source ones.
From what I see, it comes with a profiler, which is an excellent addition and the UI seems to be very similar to XCode.
You mean after Borland destroyed themselves with a over-the-top business strategy Embarcadero could swoop in and buy several Borland assets and trademarks (Delphi, C++ Builder, Interbase) rather cheaply.
Most of the people I knew who worked with Delphi moved on to .NET and Visual Studio. Main reason being that working with Windows Forms or WPF and the .NET BCL in combination with C# is pretty similar to working with the VCL and Object Pascal. Common factor being Anders Hejlsberg [0]; one of the biggest drivers behind both the Delphi and .NET ecosystem.
I wonder if there is work out there for objects pascal. Because I would like to apply.
But for now... twoottwoot* hybrid train, here we come :'(
Delphi is still kind of popular in Europe, we even have conferences.
Or more exactly, web development was turned (badly) into app development.
It was a freaking miracle, and I wonder how we have managed to lose SO much ground.
- 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 (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.
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.
It definitely feels bloated -- slow loading, tons of JS, overly engineered. Perhaps the demo should do something more substantial.
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.)
Thanks for the reply!
("Twitter clone with attachments" is one we use in workshops, actually - it fits neatly into a single session. Guess I should write that up.)
[1]: + TypeScript + Polymer
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.
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).
Still I am hopeful that they will overcome them, as Julia is an interesting language for those of us that know Dylan.
Interesting. I had tried out Dylan briefly (in one of my occasional spells of trying out multiple new / different languages), but long ago - and at that time I did not understand it much, maybe due to knowing less about some of the advanced programming language features and their benefits than I do now. Can you elaborate a bit on Dylan's features and the connection with Julia?
http://stackoverflow.com/questions/3649969/what-do-you-think...
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).
Edit: maybe it was per seat licensing? - client didn't want that
we need sometime like, for polymer one day?
At every Google IO they presented it, and yet the overall native support of all required features without any kind of polyfills is still missing across all browsers.
Delphi and other drag & drop RAD tools are easy, not simple.
All other surviving Ada compilers are commercial, following the same price practices as usual.
So many of us in the Pascal golden days were only able to buy Pascal compilers.
Just to put this in perspective, Turbo Pascal for Windows 1.5, the last TP version before Delphi was created, would be around 100 € on today's money. An Ada compiler would be at very least 5K €.
Also despite the famous "Why Pascal Is Not My Favorite Programming Language" assay from Brian Kernighan, the majority of Pascal compilers supported the UCSD, Apple and Borland extensions, so the actual Pascal dialect used by most of us was quite close to Ada83 in terms of features (minus generics).
In 2017, given the existance of GNAT, SPARK and updated Ada standards, Ada would be probably a better option.
Tons of variations : Why wasn't UNIX used ? Why did dBase beat all the minicomputer and mainframe solutions ? Why weren't the free C compilers used by hobbyist programmers ? Why did nobody run X11 ?
The answer is this : because doing that cost unreasonable amounts of money.
Either they did so directly, or because necessary hardware cost boatloads. And that happened because of 2 effects : either because it only ran on one kind of architecture that was really, really expensive, or because it required ridiculous amounts of resources.
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.
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.
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.
Assuming you have good enough primitives to work with (i.e. you write your render function in terms of HTML elements and other React components - or something similar, not raw lines and rectangles), then I just don't see any.
http://gamedev.stackexchange.com/questions/24103/immediate-g...
>The GUI library consists of one-shot "RenderButton", "RenderLabel", "RenderTextBox"... functions
>all RenderXXX functions that have user interaction like a buttons or checkbox have return values that indicate whether e.g. the user clicked into the button.
But React is nothing like that.
Writing JSX very much resembles writing HTML, which makes the tree structure easy to read/write, you bind event handlers to elements (`onClick={this.helloClicked}`) just like you could with HTML, passing data (props) to child components is trivially simple etc.
That's why I wrote "assuming you have good enough primitives to work with" in my previous comment. With game UI libraries, you often don't, and often there are limitations in the language itself that prevent the libraries from being good enough.
When you have a nice environment to work with, all that retained mode does is duplicate the state - so you have your application data, plus the internal state of the UI component, or even the larger structure of the components - and it places the additional burden of keeping them in sync on your shoulders.
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).
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++.
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.
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).
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.
To each his own :)
Why?
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.
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.
text editors and command line scripts seem like a backwards step.
However, the developer inspectors alone inside of Chrome and Safari are 100x more powerful than any of those old UI tools of the past.
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...
[2] http://www.samadhiweb.com/blog/2015.12.31.dolphin.nbsqlite3....
"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?
> 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?
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.
I used Delphi too, it was great. The VCL and the community/market around it was wonderful. I looked into BCB for a bit, but unfortunately never got to using it in anger..
Borland had a great run.
Nowadays we have Apple and Microsoft returning to the idea of using databases to model C++ on the IDEs.
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
"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."
It was just too advanced for its time, and as I mentioned, Apple and Microsoft are exploring this path for their C++ IDEs.
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.
Lucid Energize C++ was way better, but bad management has a tradition to kill awesome products.
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.