Yeah but isn't there a risk of losing support?
I work in perl a lot and find it's getting harder and harder to work with modern databases as the dbi driver slowly get bit rot. Is there nothing similar going on in Delphi?
Delphi is a one trick pony. You should use it for writing desktop apps and this area is not that dynamic anymore. For most databases there are bindings or you can use ODBC drivers, for networking there is good enough third party library. Rest of the things you need to code by yourself. There is not vibrant conmmunity anymore, but you might be able to find some answers in old mailing lists and such.
Funny that you mentioned Clipper. It's a language that you don't hear about a lot anymore, but it was the first language I learned as a kid (my Dad built point of sale and inventory applications in it for local companies as side work), so it holds a special place in my heart.
Mine too. The fact that it had both dBASE-like functionality (was a superset, in fact) plus could generate EXEs was just a great combo. Like in other countries (I'm sure), plenty of small businesses in India relied (and some probably still do) on small custom Clipper apps (such as POS, inventory, etc.) created by small software consultancies or freelancers. You could tell it was written in Clipper by the typical color scheme and look of the form and by the status bar, when you were at such a shop to buy something. And the speed of data entry by the operators, in those apps (without any GUI clutter to slow things down), was phenomenal.
>What is the purpose of the parent comment? To score a point? To show us all the commenter is smarter than the vulgus?
To defend their technology/language of choice, who they felt was undeservingly dismissed as obsolete?
>The same point could have been made without the condescension.
I think the "less competition" is a valid point. People that dismiss languages as "old" or not fashionable enough, often miss opportunities in niche areas -- case in point all the COBOL jobs.
I wouldn't say things like "gratuitous negativity" to anyone's face IRL. That would come off as annoying at best when two adults are trying to have a conversation.
dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps.
I do ponder sometimes why we don't have something quite like that these days. Oh, people do try, but it's never that simple, and there are always a lot of moving bits with plenty of friction between them. The ease with which I could collect a bunch of data from a form and shove it into a record in a table somewhere in FoxPro is still unmatched (remember SCATTER/GATHER MEMVAR?).
I don't, but I'd like to. Most of the online documentation on Foxpro is old, and doesn't convey the magic that I've seen happen with it. I'd love to see some combination of Delphi with Foxpro, probably with LISP syntax and Qt bindings. And a little bit of sugar from haskell and kona languages.
What made Turbo Pascal great was the help system. For every single standard library function, it had a snippet of code that you could cut, paste, run, and tweak.
I'd love to hear more about your thoughts on this. I couldn't find an email address in your profile, but I have an address in mine, so please shoot me an email.
FoxPro also had a great help system, including context help with F1 for whatever was under the cursor. It wasn't quite as good as TP, because it didn't have true hyperlinked text - but it had a separate section in each article just for links ("See Also"), and it had very fast keyword search, so it was "good enough" in practice. And yes, also tons of examples!
I'm pondering about build a Fox-in-spirit. I still mantain that NO programming tool today is good for database-development, and we need a modern take on the dbase.
My idea is build a relational language with a lot of the ideas of fox but with a modern syntax.
If somebody wanna to talk about this, and maybe help, I'm open!
Why don't you make a small github organization and drop a link here? I've done some programming language work on the side, and I've been wondering a little about stuff like this.
Judging by the all comments and the upvotes in this thread, it looks like it's a more popular sentiment than I expected - so, sure? But this is probably best discussed in a setting more convenient than HN comments.
What would it take to make a good dBase style environment? Would PicoLisp be an example? (granted it's a LISP, but it seems to have a focus on simplicity and CRUD style things)
>dBase-derived languages in general were a lot of fun. And incredibly productive, basically taylor-made for cranking out CRUD apps.
Yes, true. I did a good amount of XBASE (which is the generic term for dBASE, Foxpro, Clipper, etc., and I worked on all 3 of those) in my early programming days (along with Turbo Pascal and Turbo C) - including a very interesting line-of-business app for a switchgear manufacturer's factory - that one was in Visual Foxpro and using a Novell Netware LAN and Windows. Was on site there for around 10 months for the project. Turned out to be ~180 KLOC in size and had a lot of features, from CRUD to parameterized SQL reports of all sorts to somewhat advanced (for the time at least) decision-support sort of stuff, plus production planning.
>I do ponder sometimes why we don't have something quite like that these days.
There actually are a few options (maybe you are aware of them). Harbour project, Flagship (both names are probably plays on Clipper), and a few others. There are also both paid and free libraries that can read and write XBASE formats. My own xtopdf toolkit includes DBFReader, a class that can read dBASE files, both the metadata and data.
I know that Harbour is a re-implementation of Clipper with some added features, but not much else.
I think it's less about the DBF file format and xBase syntax, and more about the high-level conceptual approach, with the language built around concepts like database cursors and mapping data (rather than relegating it all to a library). If this stuff is to be redesigned from scratch in a modern environment, it would have to deal with contemporary data sources - meaning SQL RDBMS - and the syntax could definitely be more consistent and less crufty.
I think you're right on that. Having the database-related features built-in to the language makes a difference. A bit like how REBOL has many data types built-in (~45, IIRC [1]). And if not now, I guess over time, Red will have them too.
I have the same sensation, I moved to systems and mobile development but I would feel a bit lost if I went back. I catch myself reimplementing xBase-style utility functions like date and string manipulation in other languages, since they felt so sane in comparison. But I wonder that part of this nostalgic sensation was the result of an era that was simpler - no Internet, Web sites were a luxury, security was a distant concern, etc.
I had a pretty good chuckle at this comment. I couldn't agree more. While I loved Delphi, VB, TurboPascal, ASIC and DJCPP back when they were in vogue, I feel like starting new projects in a decaying ecosystem is a bad idea. Soon enough you'll find stuff there aren't any libraries for, outdated database drivers, or hit a wall when trying to do something most modern runtimes make incredibly easy (something as simple as making an HTTPS request.) At that point you hit a diminishing ROI from using the language you love and it becomes a matter of productivity.
Does Delphi justify its cost? As far as I can tell, there are no free compilers - seems like a pretty high hurdle when most languages can be used for free.
I was hired as a C# dev out of college. 6 months in, a legacy Delphi app was dropped in my lap for maintenance. It took me about a month to get up to speed, but after that it was just another platform/language.
I wouldn't expect them to want to though. Not because it's a terrible language to program in, just because it's not going to look as good on a resume for later jobs.
And that’s the sad part of HR departments hiring by checklist, we develop a monoculture which makes it harder to actually see different ways of solving problems or creates a reinventing the wheel syndrome. There are professions that value people with a range of experience. It is really too bad that software development often isn’t one of them.
Wow. Is this actually a major concern with some people?
Around D.C., there's this tendency for employers to be very open with what languages you've used before.
Have you only used Ada? Welcome on-board, though we have no uniforms here.
Only used Erlang? Are you guys still saying you can see the whitehouse from your building?
And for some reason C#/Java are considered almost the same language, depending on whom you talk to.
Honestly, good people are good, and we don't have enough of them to become picky about demanding 5+ years experience in exactly what you are already doing. It'll take a month to onboard someone regardless of if they've used the language or not before.
> Does Delphi justify its cost? As far as I can tell, there are no free compilers - seems like a pretty high hurdle when most languages can be used for free.
The bigger problem is that you are stuck with whatever features Embarcadero thinks are important.
For example, Delphi didn't have a 64-bit version for an excruciatingly long time. How many companies using Delphi got run over by a competitor during that window?
At this point, if a language isn't open source, I simply won't use it. I have been burned too many times on the proprietary front to ever give in on that anymore.
Not to take anything away from the general gist of your argument, but why would a company get run over by a competitor simply for not offering a 64-bit build? This seems extremely far-fetched to me.
Yes, I remember one of my competitors suffered for a long time because they couldn't support 64 bit. This was a component in the print spooler so they couldn't just run the 32-bit version, they really did lose customers over it.
For macOS there still isn't a 64 bit compiler from Embarcadero. They promised it will come in a future release and then you can port your firemonkey (FMX) apps. But of course that will set you back a couple of thousand in upgrades and put you on an subscription model.
For several years I hoped that FMX would get mature, even ended up building a product with it. You must sit on their subscription model if you want updates/fixes and yes you need those as the (macOS) product has plenty of issues.
Meanwhile freepascal/Lazarus already has a 64 bit compiler and their LCL (like VCL) does have a cocoa (not mature) and carbon (mature) port. I'm sure it has its own issues, but at least it uses native controls, can compile to Linux desktop right now and doesn't cost an arm and a leg if you want a fix.
So yes, pascal is still awesome, not too sure on the commercial version where you don't get fixes unless you pay regularly (anecdote: I bought XE8, couldn't debug on latest macOS about 4 weeks later, that was never fixed in XE8, ended up debugging via an earlier OS X)
Unless one was creating a library or had an application that used an enormous amount of memory, 32-bit or 64-bit really didn't matter. IOW, for most desktop applications, it was a non-issue.
Sadly, Embarcadero's chokehold on Delphi is what turned me off of it back then, and still does nowadays. You could argue FreePascal/Lazarus is an alternative, but it's really not the same.
Agreed, I feel like the only real problem with Delphi was/is Embarcadero, at least for many years after Borland exited the picture.
While one can argue about the pricing structure, the problem for me was that how they act and communicate never felt in any way professional, at least up until I left Delphi completely, it might have changed.
Even today, more than a decade later, their website retains the same feeling of being built by the lowest bidder, seemingly without even hiring a translator/copy writer that has command of English.
All of which feels super strange when you peddle a product for thousands of dollars.
I have never seen anything better than Delphi and the VCL for building simple and easily deployed Windows apps,
most everything fails on that second part. While it's a pity events took the turns they did, it's quite astonishing that MS and all their competitors never managed to find a way to easily and robustly deploy simple applications without the need for running an installer or using complicated runtimes.
I'm very sad that Delphi is so inaccessible for hobbyists. In some spare hours I'm building a native app in Qt, but I'd have definitely built it with Delphi if I wouldn't have had to cough up 3000 dollars just to get started.
In all frankness I don't get why Embarcadero doesn't copy Qt's licensing. If they make a free GPL version, Delphi-based open source could thrive while just about everybody who buys a license now would still be required to buy a license.
If you're looking for something more Deplhi-like, why don't you just use .NET? Mostly open source now, tons of 3rd party libraries and component packages available for it, just like Delphi in its glory days.
Definitely a good reason to use Qt, but you wouldn't get that with Delphi either. Qt is probably the best looking build-once, run with an acceptable UI package anywhere in that market.
EDIT: Just saw your second addition... not so sure I'd agree though, the performance on startup of .NET applications these days is quite excellent and I haven't been able to tell for years, but I've been on SSDs with lots of RAM on recent chips I suppose.
Delphi footprint is actually less than Qt in many cases (at least of older versions, don't know about the new ones). Don't forget that VCL wraps native widgets, so there's a lot less code in there.
I'm programming desktop applications in Racket, but unfortunately for many purposes it is, as of now, too slow. Especially application startup time is painful, and text% and other essential components of the GUI are way too sluggish for professional end-consumer applications. Maybe the Chez-based rewrite will help, but I'm not betting on it. Parts of the GUI library are just too complicated, and sometimes for no good reason (for example, style lists or the way it deals with snips internally).
I'm probably ending up with prototyping in Racket and writing the final application in Qt or Lazarus.
I believe there's a few things under .NET that try to wrap multiple UI libraries to varying levels of success too however none of them are as mature as Qt for a nice multiplatform UI in my opinion.
Let me offer my apologies on behalf of the Danish nation for what we have foisted upon the world: Hejlberg's C#, Stroustrup's C++, Lerdorf's PHP, and Heinemeier Hansson's RoR.
Nothing's wrong with C#. When it came, it was a "better Java" in many respects, and that was a niche that was desperately begging to be filled. Over the years, it became even better at it.
I'm sure there's nothing wrong with it. It's just me being old school and curmudgeonly - not really hot on runtimes and complex dependencies. Although of course, if I really need it, Nim will compile my wonderfull code to js. Otherwise just singe, compact, standalone executables for any platform I care to imagine.
And yes, the language itself is a joy to code in. Which is opinion, not fact, I realize that.
Would you compare Nim to DLang (honest question)? If yes, how?
I've been watching both and just waiting for an opportunity/excuse to build something using one of them
Yes. Both fast and AOT compiled languages with great compilers and probably not the best IDE support unless you count a bunch of plugins. Both have small and tight knit communities and have evolved fast. Neither are the best from a library perspective, but Nim can use C or C++ libraries easily. Doc isn't terrible. Nim has jokingly been called "New Improved Modula-3", so it has some things in common with Pascal, although it's syntax looks like Python with types, while D looks like a mix of C++ and Java.
Np...I'll add that Nim has an awesome book out "Nim in Action" and D has a free book on their site. Nim has several different backends (C, C++, Objective C, JavaScript) that it can transpile to that leverage the insane optimizations that things like GCC and Clang can offer. Nim has multiple garbage collectors depending on the level of performance you desire.
C#, for all the platform limitations, is probably the best designed and evolved mainstream language out there.
And C++ powers Google, Facebook, 100% of AAA games, 90% of mainstream OSes, and 90% of all top-of-the-line commercial programs (from browsers and office apps, to Photoshop and AutoCAD).
Admittedly, I haven't. I've Read On The Internet(tm) that it isn't as good as plain Delphi, but in all honesty I really should give it a chance indeed. Thanks!
There is an online package manager and a docking IDE package (if you are into single window IDEs) in the latest Lazarus 1.8rc3, so they are slowly getting there.
There's Delphi Starter Edition, which is free for freeware / personal use projects, and 'free' for commercial apps until you've earned $1000 in total revenue. (At which point, they want you to buy a ~$2000 license. Hmm.)
When I tried it, it didn't allow me to use third party components in design time. And only 32bit demo compiler is distributed. (Can't be used from command line)
That's the annoying thing. Why don't these companies say you can use it for free or for cheap until you've earned 10000 in total, and then you have to buy a license that costs less. That way you could put the money aside in your calculations and it would be no problem. The DAW Reaper has this kind of licence, you only have to buy the commercial version if you make more than 20,000 USD gross revenue per year.
It's the same with commercial CommonLisps, I'd love to use one, but the pricing is ridiculous for small companies / hobby programmers. That doesn't add up, you'd have to be 100% sure that you'll earn more than X dollars with your application and you can never be sure of that.
I think Delphi Started has same limitation as C++ Builder Starter - removed most of debugging functionality (e.g. local variables window). It may be not critical with small applications, but I would rather have "no commercial", no 3rd party components or code size limitation than crippled IDE.
I've tried to switch from Turbo C++ Explorer 2006 (this was also free version) to C++ Builder 10.1 Starter and I prefer old one.
Since Delphi derives from Pascal, it seems appropriate to mention Project Oberon, an awesome OS project that Niklaus Wirth (creator of Pascal) worked on:
FWIW modern Free/Object Pascal is miles away from the principles of simplicity found in Oberon. For example in Oberon a string is basically a series of characters whereas in Free Pascal there is a refcounted copy-on-write string type that keeps the string encoding and does automatic conversion (e.g. UTF8 to UTF16 or UTF32 or native codepage where available) where needed.
Delphi 10.2 was advertised to support making Linux web services, so I decided to put it to test. I created a Windows Apache module, added a Linux 64bit target, added a data provider and a database connection. The idea is to provide the database as a soap service on Linux to get a quick and cheap(!) Data layer.
The provider plays nicely with the client dataset and let's you interact with UI elements, sending automatic updates to the database through the soap service.
So when I switched to the Linux build, I noticed that data provider component in the components toolbar was disabled. That means it isn't supported on Linux.
Tricking the IDE with a Windows project, placing the provider in a data module and switching it to Linux target, I tried to get it to work on Apache. No response from soap.
After a couple of hours of eyeballing and recompiling the provided Delphi sources, I realized that the support is actually there, but there were some programming errors such as not implementing the entire interface, and somehow the memory manager behaved weirdly on Linux, causing another interface to go nil while refcount still didn't reach zero.
All in all, Delphi makes it easy to build Windows applications, complete with data layers and Model-view style. I just wish they would hurry up with the Linux server support.
I'm really surprised Apple hasn't come up with something in this space, not everyone is a programmer but most people have things they could do with automating a little.
Delphi 2005 was my introduction to computers and programming, first in a course given by the local technical university, later in regular school. Wasn't embarcadero back then, but Borland I think. Neckhold either way. I liked how the development worked, and think it wasn't a bad environment to first learn programming.
Anyway, that were years of fun, but I, as most, moved on..
Same here, I think it's a very nice system to learn programming with (certainly nicer, more forgiving than c++)
As time went by I moved on to PHP and other things.
Is there anything that actually requires deep, low level OS hooks or anything like that, that would justify a desktop client app, as opposed to a browser based app, running locally (with web sockets and such?)
> Is there anything that actually requires deep, low level OS hooks or anything like that, that would justify a desktop client app, as opposed to a browser based app, running locally (with web sockets and such?)
Mh.. A great user experience? In line with other made-with-love apps, which fit in nicely into the OS?
It's amazing if you're into Pascal. You don't really need anything else. But other languages advanced further these days.
That aside, one thing that I like about FP is their text-mode IDE. They basically copied Borland's original Turbo Pascal (circa 7.0) IDE for DOS. Except this one runs on Linux etc. And, of course, has a lot more features. There's something about that TUI goodness that is hard to capture in modern GUI IDEs - and then it's also blazing fast (you think Sublime is fast? ha).
It compiles to just about any platform you can come up with.
You can build a GUI app for any platform and backend without having to change a lot of code.
Builds to Linux, ARM/x86/x64, macOS, iOS, android, Windows, freeBSD and I'm sure I'm missing a few.
It actualy surpassed Delphi in some ways. You can develop native programs on non x86 platforms. The IDE and compiler installs and runs fine on the Raspberry/Nano/Orange PI boards, and others, so if you want to write a GUI to view sensors and actuators status, or maybe a display for a homemade KSP controller, the tools are there already. Free both as in beer and speech.
I currently consider using it instead of C++/Qt for a major desktop application, but I'm still undecided. Lack of good Emacs support is a major downside but the same is probably true for Qt (haven't checked yet).
Still I feel that going with Qt is more future proof.
Yesss! Being able to drop a few buttons, code a few lines, and compile, and get a statically compiled binary / exe file with native GUI, on all the three desktop platform (without any code change between them!) is just mind blowing if you tried any other GUI builder. This is how GUIs should be made. Period. :)
I've not used Delphi/Pascal seriously for over a decade... and then a month ago, after being fed up with sublime/VScode/atom as my daily drivers for developing python I decided to write my own editor.
So I installed Lazarus and within 12 hours I had a working editor which is so much FASTER than [put your JS based editor here]
This is the component-based nature of Delphi/Lazarus. You can find/buy components that implement entire chunks of your application in one shot, including code editors (SynEdit).
> Finally, I really enjoy programming in Delphi. Sure it has it quirks, is a bit verbose, shows its age, etc. but there is something fundamentally elegant about this technology, it is always a pleasure to code in. I feel happy when I’m using Delphi. If a tool makes me happy, does the job, that’s win-win.
People talk about the technology as if it can be objectively good or bad instead of a medium that you find a connection with. He likes it, that's the only reason for choosing it that really matters.
Does anyone else have the impression the most of the advantages OP lauds Delphy/ObjectPascal for are also present in Go?
...is there any nice cross platform desktop UI system for golang? (with an actual user base... because these things have bugs that can only be find through extensive real world usage unfortunately...).
I worked with both OP (ObjectPascal) and Go, and Go really catches much of the spirit of OP.
BUT Delphi is an IDE that was designed specially for making out most of ObjectPacasl (and ObjectPascal has extensions to interface back with the IDE) nothing in Go Ecosystem comes close to that
But if someone saw the opportunity and decided to fill in that niche, I'd be the first to spend my money on it. Make it cost $1000, it doesn't matter - a modern language plus and excellent IDE it's something really worth spending my money on.
You're not going to be able to do it, at least not in the same way as Delphi. Go lacks the complete OO and component functionality that allows Delphi to provide its level of integration between the IDE and the code/components. It's not just a language that was popped into an IDE, rather the IDE and the language were created to work together as one, and it all revolves around proper class support/RTTI.
Chuck Jazdzewski, one of the original developers that helped create Delphi, did a series of blog posts that details some of the thought processes behind Delphi:
We sell a Delphi-like IDE for web applications (Elevate Web Builder) that uses Object Pascal, and the only other language we would even attempt to implement with the IDE/compiler is C#. It's the closest in terms of features/behaviors to Object Pascal, with the main difference being multi-cast event handlers (delegates) in C#, which is really just a compiler-syntactic-sugar detail.
reminded me of the point that Delphi 1 was itself written in Delphi:
"It seemed that after every feature Anders showed people cheered and when Anders showed that Delphi itself was a Delphi app we received a standing ovation. I knew we had done something remarkable; something I will always be proud of."
Looks like the other posts will be interesting too.
OO in Go is quite peculiar, but not impossible. I'd even say you could quite naturally code methods and properties of components, while events would have to be a part of this particular implementation.
In any case, I completely agree: whoever decides to do it, they'll have to take Go's peculiarities into account and instead of making an exact copy of Delphi in Go, create a new project leveraging the specific features of Go and reflecting them in the GUI construction in an elegant way.
Yeah, my comment came off a little harsh. I'm not discouraging someone from creating a Go IDE like Delphi, I'm just saying that one should be prepared to make allowances for what the language can/cannot do, given that one cannot change the language. The original Delphi team had the enviable position of being able to modify the language to suit the IDE, and vice-versa.
I still compile a old project in Delphi 7 once every 3 months just to add 5 lines of code, and they pay me monthly for it. It's cheaper than porting the whole system to any other language.
It is a project that I've built 8 years ago. Delphi was already a "strange think" on that time, it was declining fast. I think Java killed Delphi - "One codebase for all platforms, even your freezer will have Java!" - this was the cool sentence on that time.
Since I started with Delphi when I was 14 (I am now 33), a lot of thinks changed to me. Now I mainly work in back-end field, building APIs, Bots, Crawlers and Queues to do massive things (like receive million SMS per hour in a voting system for a TV Reality Show program)
When I am programming, 70% of my time is Nodejs, 10% Python and 20% Vuejs.
But I still miss the old days of drag-N-drop GUI of Delphi, really easy.
there needs to be a delphi for react. I remember starting to learn components in delphi, never got round to it but I think you could composed them like with react and also style them.
I wish I could upvote this several times. That's my exact experience as well.
I would like more people to experience what was the way of creating software with Delphi, seamless and easy, really closing the loop between creating and the resulting application and then look back at what unnecessary complexity we are dealing with every day when working with software. (nb I think there was a blog somewhere by one of Delphi's creators where they explicitly mentioned that the language and IDE were designed to be simple to use).
If I will be teaching programming to my children I will dig up old installation of Delphi 7 and just let them play.
Absolutely. I did GUI programming with Delphi in high school, then haven't touched it till now, and I am somewhat shocked how the ability to create desktop (or web) GUIs today seems to lag so much behind how I remember Delphi.
Might be nostalgia speaking, but even if it doesn't lag behind, I'm pretty sure it hasn't gotten better. I guess QT Creator actually comes close.
.NET has Windows Forms and XAML Visual Studio designer, and Blend for XAML.
Java has Netbeans Matisse for Swing, Eclipse WindowsBuilder for Swing and SWT, Scene Builder for JavaFX, Android Studio designer. Not sure what InteliJ offers.
Objective-C and Swift have the XCode GUI design tools, based on the NeXTStep development environment.
C++ has UI designers for Qt/QML, C++ Builder, UWP/XAML.
Object Pascal has Delphi and Lazarus.
Xojo as Visual Basic dialect also has its own designer.
Commercial Common Lisp environments like Alegro CL and LispWorks also have their designers in the tradition of Lisp Machines.
Smalltalk environments also have GUI designers.
These are just some examples that come to my mind.
Yeah, I used Turbo Pascal, starting with TP 1.0 on 8 MHz, 8 bit Z80 with 64kB RAM (entire compiler and TUI in 64kB! compiled even large programs in a few seconds).
Much kudos must go to Anders Hejlsberg, who wrote the compiler in assembly language, starting on it at age 20[1]. Hejlsberg went on to create Delphi, J++, C#, and TypeScript.
I still regard TP 1.0 as one of the best software products I've used, and feel it is a testament to brilliant, performant, compact software development - and to its developer.
> Since I started with Delphi when I was 14 (I am now 33)
Almost the exact same experience: started at 14 and now close to 30.
Back in the day, we used to exchange game CDs in my small town, and by a mistake I got one with Delphi 5. I knew nothing about programming, just installed it, clicked around, somehow managed to run the default app, and got an empty window. We didn't have internet, so I had to ask around what this thing was about, someone said all other programs were done with it. There were no books about Delphi in local bookshops, the closest I found was an introductory book about Visual Basic. Armed with a book on VB and Delphi 3, by trial and error I had managed to produce my first ever working apps.
Few months later I was a well-known "programmer" in my town and wrote my first production ready app: a management system for a taxi company that managed exactly 20 cars. Why twenty? Because I haven't figured out loops and all my loops over those 20 cars were "unrolled" - 20 consecutive lines of if/else statements! But it worked! I don't know for how long, but it was still in use when I moved from the town few years later.
A GUI web site generator is trivial and many already exist. The difference between the web and traditional desktop based programs is that you have a lot more freedom in constructing the experience on the web. Whereas a typical WinForms app is made up of a bunch of drag and drop common controls like the button or text edit, simple text editing and buttons can take many different creative forms to best suit the intended experience.
So I guess another way of saying it is that older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences. The aesthetic and the experience as a whole is important.
>A GUI web site generator is trivial and many already exist.
>older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences.
Not talking about web sites here, but web apps, which in the modern sense are much more aligned with desktop apps than websites of old.
I meant web apps. Modern web apps offer a lot of freedom in constructing the precise experience we want the user to get. This is unlike traditional desktop applications with the cookie cutter controls that behave the same way from app to app.
That's not been my observation when it comes to SPAs, responsive apps, etc. They tend to use fairly straightforward components, layout schemes, etc. For instance, if you look at the components/layout capabilities that come baked into the latest version of Bootstrap, you'll find a lot of bases covered.
Regardless, there's nothing that precludes you from wrapping any control you desire into an interface that makes it droppable and configurable through a GUI editor, then have it generate code. Likewise, for the creation of different layout managers, though in practice I don't think you'd find a ton of variability there. Most "experiences" boil down to grid-based and responsive.
So, I'm not sure which precise experiences you imagine couldn't be created. It's all just code. But, if there are some, then they'd be the exception, not the rule.
You can already create simple websites with tools like above. But non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
It's not that the web hasn't caught up to GUI editor paradigm that has been around for decades. In fact WYSWYG web editors were common when the web was in its infancy.
>non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
Yeah, you've kind of repeated variations of that vague statement, to which I've replied with specific capabilities/features that SPAs and modern webapps tend to use. I've suggested that they represent very common features/layouts that can readily be constructed with the aid of a GUI tool.
But, here, you've now responded with a few website builders that are not intended to be used for the kinds of SPAs/modern webapps we're discussing. That doesn't make a point, except to say that "other things exist".
Do you have specific examples of SPA/webapp functionality that cannot be readily built with the aid of a GUI tool?
>This is unlike traditional desktop applications with the cookie cutter controls that behave the same way from app to app.
Controls in desktop apps are not just "cookie-cutter" (if I understand correctly what you mean by that). They can be subclassed in C / C++ / Delphi etc. code, to add to, or override, the functionality as well as the appearance of the superclass control. (And individual desktop app developers can, did, and still do this. It is not necessary to buy or downloads such custom controls, anyone can write them - like you say for the web.) This was being done way back in Windows (from as early as Windows 3.x [1]) and probably in Unix too (X-Windows). In fact, X-Windows may be the source, or one of the early examples, of the famous saying "provide mechanism, not policy" [2], which is related to this topic. (What that saying implies is that policy - which often involved look-and-feel - could be, and was, provided by higher layers, than the lowest layer, Xlib, which provided the mechanism (for X's style of client-server GUI programming.) I've not checked their implementation details, but probably both GNOME and KDE (which both look and behave rather differently from each other, though both are fundamentally Unix desktop environments), are built on top of X-Windows (in its newer avatar of XFree86 or whatever it is called these days).
[1] I just did this Google search for the term "paul dilascia windows programming book", and the first search result is:
which is a book by him called "Windows ++: Writing Reusable Windows Code in C++ (The Andrew Schulman Programming Series)" - which was considered an influential book at the time (see Wikipedia page link below). I had read it, years ago, out of interest, even though I was not doing much GUI programming at the time. It showed (with code) how to use C++ to wrap the procedural (WndProc), event-driven Win 32 GUI API in C++ classes, not only for more reusable code (as the book title says), but also how to subclass existing Windows controls and add more functionality to them, or change their appearance, etc. In fact, IIRC, his Windows++ framework completely hid (from the developer) the traditional, error-prone, manually coded WndProc window procedure style of programming, that was the staple of raw Win32 GUI programming. I was quite junior as a programmer at the time when I read the book, but remember thinking even then, that it was something significant that he was writing about, and the book helped me to understand some of those deeper topics to some extent. To describe it another way, the book basically contained the full C++ code for something like a smaller version of MS's MFC or Borland's Delphi or other OO Windows GUI frameworks that wrapped the lower-level raw Win32 GUI API, which involved writing a lot of low-level procedural boilerplate code (with a hand-coded event loop for each app you wrote). That was some general background and history, but more relevant to your point, it shows that customizing controls is very much possible and done in desktop apps too (not just in web apps). And you do not need to write your own GUI framework in order to customize controls, either. You can just take classes from an existing GUI framework that you use, and subclass those classes, and add or override functionality, including both look-and-feel and behavior. The second search result is Paul Dilascia's Wikipedia page - https://en.wikipedia.org/wiki/Paul_Dilascia .
HTML has more features about layout. Also styling is more flexible in HTML.
XAML has better rendering (esp. in WPF), better alpha blending (esp. in UWP), much better animations, better vector graphics, and better editor (you can create acceptable layouts using WYSIWYG, not touching raw markup). Also it has templating, data binding, and other features not found in HTML.
In order to do a Delphi-like product for the web, you need to solve these problems:
1) JS isn't discoverable from the perspective of the IDE. There's no static typing and no way for the IDE to hook up code to UI elements, and vice-versa. You need a statically-typed language that can transpile to JS without too much "impedance mismatch".
2) HTML layout functionality isn't really geared for the type of layouts that are present in desktop applications. Document-oriented layouts have a completely different set of requirements.
3) You have to solve the design-time/run-time issue, and this is not an easy issue to solve due to 1). You can't just use a browser engine at design-time for the WYSIWYG portion, so you need to create a whole "browser emulation" layer in the IDE, along with an execution environment for your statically-typed language.
Our product, Elevate Web Builder, solves these issues and implements a Delphi-like IDE for developing single-page web applications:
We've got a new version coming out soon that will also offer server-side coding in Object Pascal, giving developers a single-source-language approach to developing complex web applications.
Your IDE looks cool especially for Object Pascal die-hards but your way wrong with JS. One doesn't need static typing to discover patterned functions. You need a convention and a parser that can recognize that convention.
Re: patterned functions: you can't rely on patterned functions in a full-featured IDE that allows any class method to be an event handler/delegate for another class instance. What you end up may look like what Delphi is doing, but it is just an approximation of the real thing that won't work very well for general-purpose usage. There's going to be all sorts of edge cases that don't work correctly because you can't get a reliable signature for a given method.
I'm not familiar enough with Smalltalk to comment, but I'm guessing that it had a formal, discoverable system of hooking events to event handlers. Was that the case ?
There is no "formal" system for events, but there are patterns and most Smalltalk systems follow. For example, Pharo makes use of an object called `Announcer`, which you then subclass to make your own announcements. It works similarly to a pub/sub pattern, but using pure live objects and by sending specific messages to subscribers.
Previously, systems like Squeak used a pattern where objects had a collection of "dependents" that would be updated when sent the `changed` message. I think this is still how input events -- keys, mouse, etc -- work in Morphic.
In either case, the "handler" is whatever you want it to be, so long as the target object implements the appropriate message.
As for discoverable, I'd say most things in a Smalltalk are easily discoverable, though some of the patterns can get convoluted if you're inheriting an ancient object structure.
Thanks, very interesting. I think a lot of the confusion here is over my terminology and a general lack of understanding about what the Delphi IDE is actually doing.
By "discoverable", I mean can the IDE:
1) Compile/analyze the code in the component library/run-time,
2) Figure out which type of method can be used for a certain type of event property for a given class, and
3) Display all matching methods in the current unit/module for the user to select.
This is what Delphi does (and Visual Studio with WinForms), and all of it is done at design-time, meaning that your application is not getting compiled in order to determine any of this.
From what you're describing, I don't think Smalltalk is doing the same thing. However, it could be doing something similar if it enforces (at design-time) this part:
"so long as the target object implements the appropriate message"
You should play around with Pharo if you have some free time. It's a completely different way of doing things (and a lot of fun). Indeed, what you've described of Delphi is not happening in a Smalltalk: there's no difference between the thing you are programming inside of and the end product (at least not right away).
It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk itself) for some end-user or goal. Because a Smalltalk image is simply a snapshot of the state of the whole system, you can use a development image to generate a more bare-bones, customer image/application if you so choose. In other words, you can configure a Smalltalk image however you want for a client. This would be the equivalent of the kind of "compiling" that creates a usable end product. You are manipulating a live system and configuring it for some purpose rather than describing a system in text files, compiling it, and then giving it to people to use.
On a technical level, you are compiling all of the time when working in a Smalltalk. Every time you save, the changes recompile and execute, live, as instantly as these things can.
Of course this means that Smalltalk is highly self-aware, and therefore there can be / are some of the IDE features you've listed. One of my favorites is the ability to provide example inputs and example outputs and see recommended objects/messages and implement the method for doing it. It probably exists in other Java IDEs or something, but I've never seen it elsewhere myself.
I will definitely try Pharo and see how it all works. I've read a bit here and there about Smalltalk over the years, and the whole environment seems really cool. I'm especially interested in the whole "not requiring static types", because that may give some ideas on how to do a JS IDE without losing the functionality that we wish to maintain. The "liveness" of the Smalltalk environment is also very much in line with how JS/HTML are used, so there may be a natural fit there.
I just read scroot's comment (the grandparent comment to mine, and parent to yours). I found it somewhat uncannily similar to a sub-thread involving HN user mikelevins (a long-time Lisp developer) in another HN thread a while ago (about Lisp). He commented on something (it was a thread about a Show HN about Full Stack Lisp, a book), I asked a question, he replied in more depth. His description of some advanced features of Lisp was fairly similar to what scroot wrote above (but with more points added). So you might be interested to check it out:
That is the top comment by him in that sub-thread. My question to him is 2nd reply below, then he replied at even greater length. Some pretty deep stuff..
(In another of his comments - this one, in a different thread: https://news.ycombinator.com/item?id=14677396 - he also mentioned that Lisp and Smalltalk are two of only a few languages that share some of the features he talks about.)
I also should mention that I only started getting into the Smalltalk stuff a year ago, and am by no means an expert. But reading about it and using it (Pharo mostly) really changed the way I think not only about programming, but computing more generally. If you ever watch a Kay lecture you won't really get what he's saying until you've used one of these live environments, whether it's Smalltalk or an interactive Lisp.
I recommend getting the Adele Goldberg "Smalltalk: The Language and its Implementation" (colloquially known as the "Blue Book"). I find it to be the second best programming book ever, aside from The Little Schemer.
Also started Delphi at 14, now 37. Always had a soft spot for it, but Borland managed it into the ground, and the later owners never figured out a way to make it successful again, even though to this day it has a lot of unrealized market potential.
I often think nostalgically back to my NT4 system. A full office suite, photoshop, and delphi IDE running side by side in 128 MB of RAM, with room to spare, and very zippy. I see some functional improvements in modern day software, but nothing that warrants the incredible bloat.
I notice that the software industry as a whole still lives in the assumption that hardware can fix slow software. However, that doesn't seem to be the case. If you look at single-threaded performance the improvements are much less than they used to be. We may reach a point where CPUs stop getting faster at all. At what point should we go back to micro-optimizing our code?
Delphi and VB4-6 used to be the RAD tools. (RAD = rapid application developed) One could drag and drop controls and create an GUI application in WYSIWYG-style. Then in 1999 when Microsoft abdomen VB for their new dotNet vision, MSFT was about to be split up, etc Web took over and Dreamweaver (and Frontpage) offered a similar IDE experience for HTML4 with a tables and PHP (or ASP, etc). To this day VB6 has the easiest to use RAD IDE, no other newer IDE allows one to create GUIs that fast. Nowadays XCode has a good GUI tool. Traditional Windows applications are out of fashion for many years. Only Win32/64 games are made, everything else is crosspatform electron JS apps or legacy apps that get a yearly minor update. Android and iOS apps thrive, and SaaS web apps too. And on Windows UWP hasn't got traction, it's like a failed experiment - I use zero UWP apps, 1% dotNetFramework4 apps and 99% WinAPI C++ based apps.
You don't use the Start Menu in Windows 10 or the Settings application or the calculator or the WiFi menu or the Action Center or ...? UWP apps are more ubiquitous than you think they are in Windows 10. Zero times visited the Windows Store to directly install apps? Sure, that's possible. Actually using Zero UWP apps? Increasingly unlikely.
UWP isn't a failed experiment by most measures, and you may not directly notice the API transition in many major Windows components from Win32 to UWP, but it's happening.
For what it is worth, the RAD experience for UWP is pretty good and if you want to make a not-very-well-architected "VB6-ish code behind" app with Visual Studio RAD tools, you can knock it out in about the time it would have taken you in VB6.
I have tried Win10, but all these new UWP based parts tacked on Win7 shell are so laggy. I mean click on start button, it takes several noticeable milliseconds to show up, the same for the windows clock pop up (calendar), etc. even the calc has now a loading screen and animation. And even though these UWP parts like the start menu are coded in C++ for the UWP API, they are like 100 times slower than the old C++ WinAPI based applications. I know, I had a discussion with the MSFT startmenu devs over here on HN in a thread several months ago - it's a lot less responsive than what could be done with a WebView control and HTML and CSS yet it's even solver than both a webview and a native C++ WinAPI implementation - sucks. I stay with Win7, which is superb and doesn't suck.
For all you folk talking about pascal and so on, Delphi really isn't about the language imho, it's about the components.
The VCL is Delphi's component model, and it just isn't available anywhere else, if you've never used it, download the free starter edition and have a look. You can make applications in minutes, you can make your own components in Delphi as well and include them in the IDE, they look just the same as the ones that come with Delphi. You can also buy commercial components. You can make component editors that are included in the IDE to make things easier for developers, it is really unique.
It was unique when it first showed up. But on e.g. .NET, you already had all the same stuff with WinForms back in 2002.
Indeed, WinForms is so similar to VCL, even when it comes to the overall hierarchy (Object <- Component <- Control sound familiar?), you might look at it and wonder if Microsoft hired someone from Borland to work on .NET back in the day. Of course, it was only their chief architect. ~
Delphi is #1 for GUI. Period. Nothing alike, No QT, No Wx, No Winforms or XALM or anything else.
Just what is available in the lowest tier is far more complete that any other tool in the market, and you have sourcecode for the VCL and related components.
That is hard to believe. I test QT a few months ago (osx) and the toolset is the same joke as any other C++ toolset. Powerfull in the inside if you pray to the proper gods.
Great in theory, but in practice one ofter another component supplier is just going away. And the still available components are often barely maintained and often not very well documented. For some components the documentation is still pre unicode for example.
The IDE is just so far behind the competition. Crashing all the time an slow. Theming support ist very limited (to date). Delphi Code Insight ("Intellisense") is slow and sometimes just refuses to work and is generally not on par with other offerings. Error Insight (the wiggly red lines thing) is even worse.
Delphi still uses a single pass compiler which makes for great compilation speed but seriously limits the language constructs.
The pricing is just out of this wolrd. You get the impression that they try to squeeze every last penny out of their existing user base.
People always say one of the main advantages of Delphi is programming of database centric (CRUD) applications but compared to the SAP system it's still inferior. I think the principle of RAD itself may be flawed/dangerous. Sure, for small CRUD Apps with a single window operating directly with the db components (Grid, and those "mapped" Fields) you will quickly have results and it will work. But for larger Applications that all falls apart.
The trouble I see for Delphi is that the whole eco system is rotten. In my perception there are only a hand full suppliers of components and libraries left. Some of those components are barely maintained and even worse documented. There is lots more knowledge and up-to-date examples available for C#.
I learned to program using Borland Turbo C for DOS, but my first GUI applications were built with Delphi 2.0, which was the first 32-bit version. I earned my first money ever selling a shareware application I built with Delphi, before reaching puberty yet!
The Windows platform was awful so I ran away to Unix, and trying to find something even close to Delphi was just impossible. The best thing we had was Tcl/Tk, which I used a fair bit.
I tried Java at the time and remember saying to myself: You got to be kidding me.
Eventually I gave up on GUI development for Unix and embraced the web browser is the UI philosophy and develop the back-end in Python (then a fairly new language). Best career move I ever made.
I came to Unix at that time with Delphi fresh in my mind (Delphi 1/2 IIRC ) and the only thing that showed anywhere near similar promise was Qt, though it took a long time for it to get similar features in both the object model (properties etc) and the UI builder.
One of the many things I loved about Delphi compared to other RAD tools of the time was that it was the only one that supported and encouraged modular separation of logic and UI. In most others (VB!), the IDE did nothing to help you, and most people ended up with all their logic mixed into the UI code, simply because the UI code was the focus of the whole IDE.
> The IDE is just so far behind the competition. Crashing all the time an slow. Theming support ist very limited (to date). Delphi Code Insight ("Intellisense") is slow and sometimes just refuses to work and is generally not on par with other offerings
I'm 100% with you. That's why I switched from Delphi IDE to Visual Studio Code with OmniPascal (www.omnipascal.com). It's much nicer to work in a state-of-the-art editor.
Yeah true. I copied part of my comment from another comment I did regarding Delphi. So this mention of SAP lacks context. None the less Delphi is lauded for the speed and convenience with which you can create database applications but but compared with a language that was designed especially for it is not that great and Delphi's abstractions you have to use to "do it the Delphi way" and get the outlined advandtages just fall apart in more complex scenarios and begin standin in your way or are straight anti patterns.
And even with $10 million, SAP has a plain ugly UI - ASCII based controls from the 1980s coded with a COBOL inspired script language also from the 1980s.
> The pricing is just out of this wolrd. You get the impression that they try to squeeze every last penny out of their existing user base.
I used to think that about Delphi, various commercial Lisp implementations, etc. But after some time I've changed my view a little.
My change is because I realized that Delphi had its chance, and kept on trying as the chance slipped away. No amount of competitive pricing today is going to make a resurgence of Delphi happen. That door is closed, for all practical purposes.
The alternative is to offer products and support in a sustainable way and given the small number of people using Delphi professionally today, that means charging somewhat hefty amounts. IOW, their target market is business that has Delphi products that are worthwhile to maintain. In order to stay in business and provide service they have shed casual users.
(As much as we can debate about Tiobe and other indexs, is important to note that is still way higher that many will expect, and the flow of information we see in the community is very good, much more than many other hispers options)
The thing is that price is in fact the main problem. This kill the open source ecosystem options around it.
I will totally, like many others (I know, I'm moderator in on of the most important forum in Latin-America) work more for it but without a way to reach a large audience it kill many ideas we have.
Delphi was the most sucesfully opensource but commercial (as, you have the source) with many thirdy-party options. Think like the current React-Components market but maybe larger and years ago.
I think any company that would buy Delphi will agree more with me than with you.
If you're right and companies just can't see that or make it work, can the community do more with Lazarus? I have not played with that so I don't know how good it is.
In the height of the enterprise transformation, I asked Del Yocam, one of many interim CEOs after Kahn, "Are you saying you want to trade a million loyal $100 customers for a hundred $1 million customers?" Yocam replied without hesitation "Absolutely."
This is it. Management trade a large and healthy ecosystem chasing the rainbows.
This will fail for sure.
---
Lazarus is ok, except that suffer from the same disease of most open source projects: Lack of focus and good funding.
Look at every other Delphi competitor from the time period. Microsoft is giving Visual Studio away to casual users and Visual Basic is now VB.Net. Eclipse and IntelliJ come in free versions. There is no longer a market for a million loyal $100 customers for a programming language and ecosystem. There are too many high-quality free languages, compilers and IDEs to make that business model work anymore.
There's a sort of a hobbyist/professional split. There's a lot of grey area inbetween, but it's easier to reason about it if you think of two markets. One will pay, one won't if there are acceptable free alternatives. But it turns out that there are rather big synergies to be had from both camps using versions of the same tooling. So you have enterprises that are willing to buy pro versions of tools at prices that subsidize the existence of users at the free tier. That's nothing like the old Borland model that the post I was responding to wants Delphi to go back to.
I did an awful of Delphi in the nineties, but the closed nature and the lack of portability failed to keep me interested in the long run. Lazarus/Free Pascal, for some reason, has never really managed to ignite any passion, and it's not because I haven't tried.
Except for the lack of IDE/RAD, a worthy present successor is Nim. There really is no end to the potential of this clear, cool, concise, modern, fast, and elegant language.
I still make heavy use of Delphi - a superb tool for fat client apps, but I have to agree on Nim. The potential is enormous and I'll be using it increasingly in the future.
I love(d) Delphi, but commercial considerations - most significantly being the availability of alternative developers if I (as the sole developer for my customers) - mean I no longer start any new applications in Delphi and for two clients converted their applications to C# / .NET. The .NET ecosystem these days is an amazing thing in terms of development by MS / Xamarin, blogs, tutorials, SO replies, libraries; the Delphi ecosystem is tiny by comparison.
As someone who maintains an unknown but very large(several MLOC) free Pascal code base, I must say that I can't see much reason in the Pascal hate.
Sure, I would love to rewrite the whole thing in Lisp (which is the language that lets me keep my soul), but we are all in all still very happy with the current code base.
A complete recompile is less than 20 minutes, and then about half that time is spent in guile for macro expansion (we have a macro DSL). We have considered porting it to chez scheme, but we rarely do full recompiles.
Pascal lends itself well to big codebase, but will probably never again be a new cool thing. I do however believe that being able to test a big change on a Dev machine in less than 10s gives us a pretty big advantage over similar solutions in other languages.
Yep. We had a 250k line codebase ten years ago that took 20secs for a full rebuild in Delphi. You could code like a demon. Even 17 years ago it had awesome reflection that let you do some really efficient (lines of code) stuff with generating classes on components.
I would love to try, but I am only seeing oportunities atm. When I think reasonably about it I know that it is a bad idea.
OTOH: We are now at a position where I am pretty sure we are a perfect fit for Greenspun's tenth rule.
The amount of time we spent to make a large part of our code stateless is mind-boggling. We now have the luxury of being able to copy the state of almost 100% of the user-facing stuff and send it back home for us to test. That would have been so much easier with something like Allegro CL.
I have actually implemented a pretty neat macro system in guile scheme that I am in the process of cleaning up for an open source release. We write parethesised, prefix pascal for our macros that gets expanded to regular pascal (easy for most algol-like languages). Having a proper macro system made it possible to remove _a lot_ of boilerplate, even though we primarily use it to generate code that the compiler can optimize easier.
306 comments
[ 3.2 ms ] story [ 256 ms ] threadhttps://news.ycombinator.com/newsguidelines.html
And what's uncivil about them?
It passes the "gratuitous negativity" test to me. The same point could have been made without the condescension.
To defend their technology/language of choice, who they felt was undeservingly dismissed as obsolete?
>The same point could have been made without the condescension.
I think the "less competition" is a valid point. People that dismiss languages as "old" or not fashionable enough, often miss opportunities in niche areas -- case in point all the COBOL jobs.
Oh wait, we already have it - this comment will be censored by the YC central committee.
I do ponder sometimes why we don't have something quite like that these days. Oh, people do try, but it's never that simple, and there are always a lot of moving bits with plenty of friction between them. The ease with which I could collect a bunch of data from a form and shove it into a record in a table somewhere in FoxPro is still unmatched (remember SCATTER/GATHER MEMVAR?).
What made Turbo Pascal great was the help system. For every single standard library function, it had a snippet of code that you could cut, paste, run, and tweak.
I wanna get a relational / kdb+ / ml hybrid.
----
One of the gems of FoxPro was the always-on terminal. It have his own terminal/repl. In the IDE. Always ON. You can do
CREATE FORM name
and open the form as a table
then do
BROWSE
and see how was made. And you could activa the terminal on a shipped app, so you can fix things on the fly.
And the debugger (specially the var windows) was good. To date, no single debugger/var window have bees as good as was with Visual FoxPro.
I'm pondering about build a Fox-in-spirit. I still mantain that NO programming tool today is good for database-development, and we need a modern take on the dbase.
My idea is build a relational language with a lot of the ideas of fox but with a modern syntax.
If somebody wanna to talk about this, and maybe help, I'm open!
We could continue talking from here, in http://elmalabarista.com I have my contact info
Yes, true. I did a good amount of XBASE (which is the generic term for dBASE, Foxpro, Clipper, etc., and I worked on all 3 of those) in my early programming days (along with Turbo Pascal and Turbo C) - including a very interesting line-of-business app for a switchgear manufacturer's factory - that one was in Visual Foxpro and using a Novell Netware LAN and Windows. Was on site there for around 10 months for the project. Turned out to be ~180 KLOC in size and had a lot of features, from CRUD to parameterized SQL reports of all sorts to somewhat advanced (for the time at least) decision-support sort of stuff, plus production planning.
>I do ponder sometimes why we don't have something quite like that these days.
There actually are a few options (maybe you are aware of them). Harbour project, Flagship (both names are probably plays on Clipper), and a few others. There are also both paid and free libraries that can read and write XBASE formats. My own xtopdf toolkit includes DBFReader, a class that can read dBASE files, both the metadata and data.
http://slides.com/vasudevram/xtopdf
https://bitbucket.org/vasudevram/xtopdf
I think it's less about the DBF file format and xBase syntax, and more about the high-level conceptual approach, with the language built around concepts like database cursors and mapping data (rather than relegating it all to a library). If this stuff is to be redesigned from scratch in a modern environment, it would have to deal with contemporary data sources - meaning SQL RDBMS - and the syntax could definitely be more consistent and less crufty.
[1] https://en.wikibooks.org/wiki/REBOL_Programming/Language_Fea...
You'd be surprised. Technology might have moved beyond Clipper, but Delphi is even more modern than things in fashion today...
My main concern would be whether you can continue to activate it if Embarcadero drops support or goes out of business.
Around D.C., there's this tendency for employers to be very open with what languages you've used before.
Have you only used Ada? Welcome on-board, though we have no uniforms here.
Only used Erlang? Are you guys still saying you can see the whitehouse from your building?
And for some reason C#/Java are considered almost the same language, depending on whom you talk to.
Honestly, good people are good, and we don't have enough of them to become picky about demanding 5+ years experience in exactly what you are already doing. It'll take a month to onboard someone regardless of if they've used the language or not before.
https://aeon.co/essays/how-work-changed-to-make-us-all-passi...
The bigger problem is that you are stuck with whatever features Embarcadero thinks are important.
For example, Delphi didn't have a 64-bit version for an excruciatingly long time. How many companies using Delphi got run over by a competitor during that window?
At this point, if a language isn't open source, I simply won't use it. I have been burned too many times on the proprietary front to ever give in on that anymore.
How many customers did Altium lose because a design was bigger than they could handle?
Meanwhile freepascal/Lazarus already has a 64 bit compiler and their LCL (like VCL) does have a cocoa (not mature) and carbon (mature) port. I'm sure it has its own issues, but at least it uses native controls, can compile to Linux desktop right now and doesn't cost an arm and a leg if you want a fix.
So yes, pascal is still awesome, not too sure on the commercial version where you don't get fixes unless you pay regularly (anecdote: I bought XE8, couldn't debug on latest macOS about 4 weeks later, that was never fixed in XE8, ended up debugging via an earlier OS X)
That may or may not be close enough to commercial Delphi, depending on who you ask.
[1] https://www.freepascal.org/
While one can argue about the pricing structure, the problem for me was that how they act and communicate never felt in any way professional, at least up until I left Delphi completely, it might have changed.
Even today, more than a decade later, their website retains the same feeling of being built by the lowest bidder, seemingly without even hiring a translator/copy writer that has command of English.
All of which feels super strange when you peddle a product for thousands of dollars.
I have never seen anything better than Delphi and the VCL for building simple and easily deployed Windows apps, most everything fails on that second part. While it's a pity events took the turns they did, it's quite astonishing that MS and all their competitors never managed to find a way to easily and robustly deploy simple applications without the need for running an installer or using complicated runtimes.
In all frankness I don't get why Embarcadero doesn't copy Qt's licensing. If they make a free GPL version, Delphi-based open source could thrive while just about everybody who buys a license now would still be required to buy a license.
Plus I want it to have a tiny memory/CPU footprint and while .NET/WPF is better than the average Electron app I still notice a difference.
EDIT: Just saw your second addition... not so sure I'd agree though, the performance on startup of .NET applications these days is quite excellent and I haven't been able to tell for years, but I've been on SSDs with lots of RAM on recent chips I suppose.
I'm probably ending up with prototyping in Racket and writing the final application in Qt or Lazarus.
https://news.ycombinator.com/item?id=14928177
TP and Delphi, obviously, require no apologies.
And yes, the language itself is a joy to code in. Which is opinion, not fact, I realize that.
And C++ powers Google, Facebook, 100% of AAA games, 90% of mainstream OSes, and 90% of all top-of-the-line commercial programs (from browsers and office apps, to Photoshop and AutoCAD).
Nothing to apologize about RoR either.
No need to apology for them.
https://www.embarcadero.com/products/delphi/starter
It's the same with commercial CommonLisps, I'd love to use one, but the pricing is ridiculous for small companies / hobby programmers. That doesn't add up, you'd have to be 100% sure that you'll earn more than X dollars with your application and you can never be sure of that.
http://www.projectoberon.com
If you want to borrow the book, I have a copy in my office in SoMa (2nd and Bryant).
The provider plays nicely with the client dataset and let's you interact with UI elements, sending automatic updates to the database through the soap service.
So when I switched to the Linux build, I noticed that data provider component in the components toolbar was disabled. That means it isn't supported on Linux.
Tricking the IDE with a Windows project, placing the provider in a data module and switching it to Linux target, I tried to get it to work on Apache. No response from soap.
After a couple of hours of eyeballing and recompiling the provided Delphi sources, I realized that the support is actually there, but there were some programming errors such as not implementing the entire interface, and somehow the memory manager behaved weirdly on Linux, causing another interface to go nil while refcount still didn't reach zero.
All in all, Delphi makes it easy to build Windows applications, complete with data layers and Model-view style. I just wish they would hurry up with the Linux server support.
https://en.wikipedia.org/wiki/Lazarus_(IDE)
It has Object Pascal and a RAD setup.
https://news.ycombinator.com/item?id=14900486
Delphi 2005 was my introduction to computers and programming, first in a course given by the local technical university, later in regular school. Wasn't embarcadero back then, but Borland I think. Neckhold either way. I liked how the development worked, and think it wasn't a bad environment to first learn programming.
Anyway, that were years of fun, but I, as most, moved on..
Actually I think it's great, AFAIK, Pascal is meant to be a teaching tool for students.
As time went by I moved on to PHP and other things. Is there anything that actually requires deep, low level OS hooks or anything like that, that would justify a desktop client app, as opposed to a browser based app, running locally (with web sockets and such?)
Mh.. A great user experience? In line with other made-with-love apps, which fit in nicely into the OS?
If you haven't tried Lazarus/FreePascal, you're missing out. It's really amazing, and it's truly free.
That aside, one thing that I like about FP is their text-mode IDE. They basically copied Borland's original Turbo Pascal (circa 7.0) IDE for DOS. Except this one runs on Linux etc. And, of course, has a lot more features. There's something about that TUI goodness that is hard to capture in modern GUI IDEs - and then it's also blazing fast (you think Sublime is fast? ha).
Builds to Linux, ARM/x86/x64, macOS, iOS, android, Windows, freeBSD and I'm sure I'm missing a few.
It actualy surpassed Delphi in some ways. You can develop native programs on non x86 platforms. The IDE and compiler installs and runs fine on the Raspberry/Nano/Orange PI boards, and others, so if you want to write a GUI to view sensors and actuators status, or maybe a display for a homemade KSP controller, the tools are there already. Free both as in beer and speech.
Still I feel that going with Qt is more future proof.
People talk about the technology as if it can be objectively good or bad instead of a medium that you find a connection with. He likes it, that's the only reason for choosing it that really matters.
...is there any nice cross platform desktop UI system for golang? (with an actual user base... because these things have bugs that can only be find through extensive real world usage unfortunately...).
Chuck Jazdzewski, one of the original developers that helped create Delphi, did a series of blog posts that details some of the thought processes behind Delphi:
http://removingalldoubt.com/
We sell a Delphi-like IDE for web applications (Elevate Web Builder) that uses Object Pascal, and the only other language we would even attempt to implement with the IDE/compiler is C#. It's the closest in terms of features/behaviors to Object Pascal, with the main difference being multi-cast event handlers (delegates) in C#, which is really just a compiler-syntactic-sugar detail.
The Biggest Bang:
http://removingalldoubt.com/programming/2015/07/17/the-bigge...
reminded me of the point that Delphi 1 was itself written in Delphi:
"It seemed that after every feature Anders showed people cheered and when Anders showed that Delphi itself was a Delphi app we received a standing ovation. I knew we had done something remarkable; something I will always be proud of."
Looks like the other posts will be interesting too.
Just kind of, because sadly Go still has a lot to catch up with Object Pascal features and compiler toolchain.
It is a project that I've built 8 years ago. Delphi was already a "strange think" on that time, it was declining fast. I think Java killed Delphi - "One codebase for all platforms, even your freezer will have Java!" - this was the cool sentence on that time.
Since I started with Delphi when I was 14 (I am now 33), a lot of thinks changed to me. Now I mainly work in back-end field, building APIs, Bots, Crawlers and Queues to do massive things (like receive million SMS per hour in a voting system for a TV Reality Show program)
When I am programming, 70% of my time is Nodejs, 10% Python and 20% Vuejs.
But I still miss the old days of drag-N-drop GUI of Delphi, really easy.
There are already people playing with prototyping language runtimes into it.
I would like more people to experience what was the way of creating software with Delphi, seamless and easy, really closing the loop between creating and the resulting application and then look back at what unnecessary complexity we are dealing with every day when working with software. (nb I think there was a blog somewhere by one of Delphi's creators where they explicitly mentioned that the language and IDE were designed to be simple to use).
If I will be teaching programming to my children I will dig up old installation of Delphi 7 and just let them play.
Might be nostalgia speaking, but even if it doesn't lag behind, I'm pretty sure it hasn't gotten better. I guess QT Creator actually comes close.
(Plus: Compile times were never ever an issue...)
Now for the web, nevermind.
Java has Netbeans Matisse for Swing, Eclipse WindowsBuilder for Swing and SWT, Scene Builder for JavaFX, Android Studio designer. Not sure what InteliJ offers.
Objective-C and Swift have the XCode GUI design tools, based on the NeXTStep development environment.
C++ has UI designers for Qt/QML, C++ Builder, UWP/XAML.
Object Pascal has Delphi and Lazarus.
Xojo as Visual Basic dialect also has its own designer.
Commercial Common Lisp environments like Alegro CL and LispWorks also have their designers in the tradition of Lisp Machines.
Smalltalk environments also have GUI designers.
These are just some examples that come to my mind.
I also start with Pascal (Turbo 3, 4, 5, 5.5 (greatest!), 6 and little bit 7). Then jump to Delphi (all 1-7) and then abandon it.
Much kudos must go to Anders Hejlsberg, who wrote the compiler in assembly language, starting on it at age 20[1]. Hejlsberg went on to create Delphi, J++, C#, and TypeScript.
I still regard TP 1.0 as one of the best software products I've used, and feel it is a testament to brilliant, performant, compact software development - and to its developer.
[1]: https://en.m.wikipedia.org/wiki/Anders_Hejlsberg
Almost the exact same experience: started at 14 and now close to 30.
Back in the day, we used to exchange game CDs in my small town, and by a mistake I got one with Delphi 5. I knew nothing about programming, just installed it, clicked around, somehow managed to run the default app, and got an empty window. We didn't have internet, so I had to ask around what this thing was about, someone said all other programs were done with it. There were no books about Delphi in local bookshops, the closest I found was an introductory book about Visual Basic. Armed with a book on VB and Delphi 3, by trial and error I had managed to produce my first ever working apps.
Few months later I was a well-known "programmer" in my town and wrote my first production ready app: a management system for a taxi company that managed exactly 20 cars. Why twenty? Because I haven't figured out loops and all my loops over those 20 cars were "unrolled" - 20 consecutive lines of if/else statements! But it worked! I don't know for how long, but it was still in use when I moved from the town few years later.
LOL!!!!
> 20 consecutive lines
Haha that's nice think about trial and error.
Cool history!
How many years later and the web still does not catch up.
So I guess another way of saying it is that older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences. The aesthetic and the experience as a whole is important.
>older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences.
Not talking about web sites here, but web apps, which in the modern sense are much more aligned with desktop apps than websites of old.
Regardless, there's nothing that precludes you from wrapping any control you desire into an interface that makes it droppable and configurable through a GUI editor, then have it generate code. Likewise, for the creation of different layout managers, though in practice I don't think you'd find a ton of variability there. Most "experiences" boil down to grid-based and responsive.
So, I'm not sure which precise experiences you imagine couldn't be created. It's all just code. But, if there are some, then they'd be the exception, not the rule.
You can already create simple websites with tools like above. But non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
It's not that the web hasn't caught up to GUI editor paradigm that has been around for decades. In fact WYSWYG web editors were common when the web was in its infancy.
Yeah, you've kind of repeated variations of that vague statement, to which I've replied with specific capabilities/features that SPAs and modern webapps tend to use. I've suggested that they represent very common features/layouts that can readily be constructed with the aid of a GUI tool.
But, here, you've now responded with a few website builders that are not intended to be used for the kinds of SPAs/modern webapps we're discussing. That doesn't make a point, except to say that "other things exist".
Do you have specific examples of SPA/webapp functionality that cannot be readily built with the aid of a GUI tool?
Controls in desktop apps are not just "cookie-cutter" (if I understand correctly what you mean by that). They can be subclassed in C / C++ / Delphi etc. code, to add to, or override, the functionality as well as the appearance of the superclass control. (And individual desktop app developers can, did, and still do this. It is not necessary to buy or downloads such custom controls, anyone can write them - like you say for the web.) This was being done way back in Windows (from as early as Windows 3.x [1]) and probably in Unix too (X-Windows). In fact, X-Windows may be the source, or one of the early examples, of the famous saying "provide mechanism, not policy" [2], which is related to this topic. (What that saying implies is that policy - which often involved look-and-feel - could be, and was, provided by higher layers, than the lowest layer, Xlib, which provided the mechanism (for X's style of client-server GUI programming.) I've not checked their implementation details, but probably both GNOME and KDE (which both look and behave rather differently from each other, though both are fundamentally Unix desktop environments), are built on top of X-Windows (in its newer avatar of XFree86 or whatever it is called these days).
[1] I just did this Google search for the term "paul dilascia windows programming book", and the first search result is:
http://www.amazon.in/Windows-Writing-Reusable-Schulman-Progr...
which is a book by him called "Windows ++: Writing Reusable Windows Code in C++ (The Andrew Schulman Programming Series)" - which was considered an influential book at the time (see Wikipedia page link below). I had read it, years ago, out of interest, even though I was not doing much GUI programming at the time. It showed (with code) how to use C++ to wrap the procedural (WndProc), event-driven Win 32 GUI API in C++ classes, not only for more reusable code (as the book title says), but also how to subclass existing Windows controls and add more functionality to them, or change their appearance, etc. In fact, IIRC, his Windows++ framework completely hid (from the developer) the traditional, error-prone, manually coded WndProc window procedure style of programming, that was the staple of raw Win32 GUI programming. I was quite junior as a programmer at the time when I read the book, but remember thinking even then, that it was something significant that he was writing about, and the book helped me to understand some of those deeper topics to some extent. To describe it another way, the book basically contained the full C++ code for something like a smaller version of MS's MFC or Borland's Delphi or other OO Windows GUI frameworks that wrapped the lower-level raw Win32 GUI API, which involved writing a lot of low-level procedural boilerplate code (with a hand-coded event loop for each app you wrote). That was some general background and history, but more relevant to your point, it shows that customizing controls is very much possible and done in desktop apps too (not just in web apps). And you do not need to write your own GUI framework in order to customize controls, either. You can just take classes from an existing GUI framework that you use, and subclass those classes, and add or override functionality, including both look-and-feel and behavior. The second search result is Paul Dilascia's Wikipedia page - https://en.wikipedia.org/wiki/Paul_Dilascia .
[2]:
http://wiki.c2.com/?PolicyAndMechanism
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
(above page's subtitle: "Creating Owner-Drawn Controls")
Using Visual Styles with Custom and Owner-Drawn Controls:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...
But I've never seen any layout render engine with the same feature set as modern HTML/CSS engines.
Other technologies cited are very limited, not even close to what current web technologies offer.
Because until recently even basic stuff like centering text or grid layouts were an exercise in frustration.
Not to mention the magical incantation dance with CSS transforms to try to force a browser to use hardware acceleration.
Or nonsense like Shadom DOM to be able to define some sort of components, which are only properly supported on Chrome.
HTML has more features about layout. Also styling is more flexible in HTML.
XAML has better rendering (esp. in WPF), better alpha blending (esp. in UWP), much better animations, better vector graphics, and better editor (you can create acceptable layouts using WYSIWYG, not touching raw markup). Also it has templating, data binding, and other features not found in HTML.
1) JS isn't discoverable from the perspective of the IDE. There's no static typing and no way for the IDE to hook up code to UI elements, and vice-versa. You need a statically-typed language that can transpile to JS without too much "impedance mismatch".
2) HTML layout functionality isn't really geared for the type of layouts that are present in desktop applications. Document-oriented layouts have a completely different set of requirements.
3) You have to solve the design-time/run-time issue, and this is not an easy issue to solve due to 1). You can't just use a browser engine at design-time for the WYSIWYG portion, so you need to create a whole "browser emulation" layer in the IDE, along with an execution environment for your statically-typed language.
Our product, Elevate Web Builder, solves these issues and implements a Delphi-like IDE for developing single-page web applications:
https://www.elevatesoft.com/products?category=ewb&type=web
We've got a new version coming out soon that will also offer server-side coding in Object Pascal, giving developers a single-source-language approach to developing complex web applications.
Re: patterned functions: you can't rely on patterned functions in a full-featured IDE that allows any class method to be an event handler/delegate for another class instance. What you end up may look like what Delphi is doing, but it is just an approximation of the real thing that won't work very well for general-purpose usage. There's going to be all sorts of edge cases that don't work correctly because you can't get a reliable signature for a given method.
Previously, systems like Squeak used a pattern where objects had a collection of "dependents" that would be updated when sent the `changed` message. I think this is still how input events -- keys, mouse, etc -- work in Morphic.
In either case, the "handler" is whatever you want it to be, so long as the target object implements the appropriate message.
As for discoverable, I'd say most things in a Smalltalk are easily discoverable, though some of the patterns can get convoluted if you're inheriting an ancient object structure.
By "discoverable", I mean can the IDE:
1) Compile/analyze the code in the component library/run-time,
2) Figure out which type of method can be used for a certain type of event property for a given class, and
3) Display all matching methods in the current unit/module for the user to select.
This is what Delphi does (and Visual Studio with WinForms), and all of it is done at design-time, meaning that your application is not getting compiled in order to determine any of this.
From what you're describing, I don't think Smalltalk is doing the same thing. However, it could be doing something similar if it enforces (at design-time) this part:
"so long as the target object implements the appropriate message"
It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk itself) for some end-user or goal. Because a Smalltalk image is simply a snapshot of the state of the whole system, you can use a development image to generate a more bare-bones, customer image/application if you so choose. In other words, you can configure a Smalltalk image however you want for a client. This would be the equivalent of the kind of "compiling" that creates a usable end product. You are manipulating a live system and configuring it for some purpose rather than describing a system in text files, compiling it, and then giving it to people to use.
On a technical level, you are compiling all of the time when working in a Smalltalk. Every time you save, the changes recompile and execute, live, as instantly as these things can.
Of course this means that Smalltalk is highly self-aware, and therefore there can be / are some of the IDE features you've listed. One of my favorites is the ability to provide example inputs and example outputs and see recommended objects/messages and implement the method for doing it. It probably exists in other Java IDEs or something, but I've never seen it elsewhere myself.
I will definitely try Pharo and see how it all works. I've read a bit here and there about Smalltalk over the years, and the whole environment seems really cool. I'm especially interested in the whole "not requiring static types", because that may give some ideas on how to do a JS IDE without losing the functionality that we wish to maintain. The "liveness" of the Smalltalk environment is also very much in line with how JS/HTML are used, so there may be a natural fit there.
https://news.ycombinator.com/item?id=11834887
That is the top comment by him in that sub-thread. My question to him is 2nd reply below, then he replied at even greater length. Some pretty deep stuff..
(In another of his comments - this one, in a different thread: https://news.ycombinator.com/item?id=14677396 - he also mentioned that Lisp and Smalltalk are two of only a few languages that share some of the features he talks about.)
I recommend getting the Adele Goldberg "Smalltalk: The Language and its Implementation" (colloquially known as the "Blue Book"). I find it to be the second best programming book ever, aside from The Little Schemer.
I often think nostalgically back to my NT4 system. A full office suite, photoshop, and delphi IDE running side by side in 128 MB of RAM, with room to spare, and very zippy. I see some functional improvements in modern day software, but nothing that warrants the incredible bloat.
I notice that the software industry as a whole still lives in the assumption that hardware can fix slow software. However, that doesn't seem to be the case. If you look at single-threaded performance the improvements are much less than they used to be. We may reach a point where CPUs stop getting faster at all. At what point should we go back to micro-optimizing our code?
UWP isn't a failed experiment by most measures, and you may not directly notice the API transition in many major Windows components from Win32 to UWP, but it's happening.
For what it is worth, the RAD experience for UWP is pretty good and if you want to make a not-very-well-architected "VB6-ish code behind" app with Visual Studio RAD tools, you can knock it out in about the time it would have taken you in VB6.
The VCL is Delphi's component model, and it just isn't available anywhere else, if you've never used it, download the free starter edition and have a look. You can make applications in minutes, you can make your own components in Delphi as well and include them in the IDE, they look just the same as the ones that come with Delphi. You can also buy commercial components. You can make component editors that are included in the IDE to make things easier for developers, it is really unique.
Indeed, WinForms is so similar to VCL, even when it comes to the overall hierarchy (Object <- Component <- Control sound familiar?), you might look at it and wonder if Microsoft hired someone from Borland to work on .NET back in the day. Of course, it was only their chief architect. ~
You can also AOT compile to a pure binary .exe with Mono or the ongoing CoreRT being developed.
UWP apps are compiled to a static executable via .NET Native compiler (uses VC++ backend).
But very inferior. And is slow in contrast.
Delphi is #1 for GUI. Period. Nothing alike, No QT, No Wx, No Winforms or XALM or anything else.
Just what is available in the lowest tier is far more complete that any other tool in the market, and you have sourcecode for the VCL and related components.
Have you use Delphi?
yes, though I have to admit the last version I did use was Delphi 7. What did you find lacking from Qt ?
The pricing is just out of this wolrd. You get the impression that they try to squeeze every last penny out of their existing user base.
People always say one of the main advantages of Delphi is programming of database centric (CRUD) applications but compared to the SAP system it's still inferior. I think the principle of RAD itself may be flawed/dangerous. Sure, for small CRUD Apps with a single window operating directly with the db components (Grid, and those "mapped" Fields) you will quickly have results and it will work. But for larger Applications that all falls apart.
The trouble I see for Delphi is that the whole eco system is rotten. In my perception there are only a hand full suppliers of components and libraries left. Some of those components are barely maintained and even worse documented. There is lots more knowledge and up-to-date examples available for C#.
The only options available were a few 4GLs that cost more than even Delphi licenses are worth nowadays.
The Windows platform was awful so I ran away to Unix, and trying to find something even close to Delphi was just impossible. The best thing we had was Tcl/Tk, which I used a fair bit.
I tried Java at the time and remember saying to myself: You got to be kidding me.
Eventually I gave up on GUI development for Unix and embraced the web browser is the UI philosophy and develop the back-end in Python (then a fairly new language). Best career move I ever made.
I'm still fond of Delphi, it was a great product.
One of the many things I loved about Delphi compared to other RAD tools of the time was that it was the only one that supported and encouraged modular separation of logic and UI. In most others (VB!), the IDE did nothing to help you, and most people ended up with all their logic mixed into the UI code, simply because the UI code was the focus of the whole IDE.
I'm 100% with you. That's why I switched from Delphi IDE to Visual Studio Code with OmniPascal (www.omnipascal.com). It's much nicer to work in a state-of-the-art editor.
IIRC the average SAP deployment is in the region of $10 million.
Sure, for enterprise-level things that's justifiable, but most businesses don't have that sort of money to throw around.
I used to think that about Delphi, various commercial Lisp implementations, etc. But after some time I've changed my view a little.
My change is because I realized that Delphi had its chance, and kept on trying as the chance slipped away. No amount of competitive pricing today is going to make a resurgence of Delphi happen. That door is closed, for all practical purposes.
The alternative is to offer products and support in a sustainable way and given the small number of people using Delphi professionally today, that means charging somewhat hefty amounts. IOW, their target market is business that has Delphi products that are worthwhile to maintain. In order to stay in business and provide service they have shed casual users.
I disagree. Delphi is still great, and with a less tone-deaf it could get very well.
Note that Delphi still have a healthy position today:
https://www.tiobe.com/tiobe-index/
(Position 9, above Ruby! and others!)
(As much as we can debate about Tiobe and other indexs, is important to note that is still way higher that many will expect, and the flow of information we see in the community is very good, much more than many other hispers options)
The thing is that price is in fact the main problem. This kill the open source ecosystem options around it.
I will totally, like many others (I know, I'm moderator in on of the most important forum in Latin-America) work more for it but without a way to reach a large audience it kill many ideas we have.
Delphi was the most sucesfully opensource but commercial (as, you have the source) with many thirdy-party options. Think like the current React-Components market but maybe larger and years ago.
If you're right and companies just can't see that or make it work, can the community do more with Lazarus? I have not played with that so I don't know how good it is.
We (the community) have tell Borland and sub-sequent owners exactly what to do, and have been never been heared.
To see why it failed, read :
https://www.quora.com/Why-did-Borland-fail
In the height of the enterprise transformation, I asked Del Yocam, one of many interim CEOs after Kahn, "Are you saying you want to trade a million loyal $100 customers for a hundred $1 million customers?" Yocam replied without hesitation "Absolutely."
This is it. Management trade a large and healthy ecosystem chasing the rainbows.
This will fail for sure.
---
Lazarus is ok, except that suffer from the same disease of most open source projects: Lack of focus and good funding.
Look at every other Delphi competitor from the time period. Microsoft is giving Visual Studio away to casual users and Visual Basic is now VB.Net. Eclipse and IntelliJ come in free versions. There is no longer a market for a million loyal $100 customers for a programming language and ecosystem. There are too many high-quality free languages, compilers and IDEs to make that business model work anymore.
Until JetBrains came on to the scene.
---
We know the old model will not apply here. That is clear. That is not what we have tell them.
What we have tell them is that the tool must have a opensource compiler, and free tier and a reasonable pro tier. Xamarin was a good sample.
Also, take in account that the millon loyal customer is not that unreasonable to find:
https://stackoverflow.com/questions/2418435/how-many-delphi-...
Except for the lack of IDE/RAD, a worthy present successor is Nim. There really is no end to the potential of this clear, cool, concise, modern, fast, and elegant language.
I have also settled on Java/.NET as my TP/Delphi replacements.
Sure, I would love to rewrite the whole thing in Lisp (which is the language that lets me keep my soul), but we are all in all still very happy with the current code base.
A complete recompile is less than 20 minutes, and then about half that time is spent in guile for macro expansion (we have a macro DSL). We have considered porting it to chez scheme, but we rarely do full recompiles.
Pascal lends itself well to big codebase, but will probably never again be a new cool thing. I do however believe that being able to test a big change on a Dev machine in less than 10s gives us a pretty big advantage over similar solutions in other languages.
A kind salute to you, fellow Lisper!!
However i've used Delphi in the past and found it a remarkably good language, i wouldn't think to port something from Delphi to Lisp.
OTOH: We are now at a position where I am pretty sure we are a perfect fit for Greenspun's tenth rule.
The amount of time we spent to make a large part of our code stateless is mind-boggling. We now have the luxury of being able to copy the state of almost 100% of the user-facing stuff and send it back home for us to test. That would have been so much easier with something like Allegro CL.
I have actually implemented a pretty neat macro system in guile scheme that I am in the process of cleaning up for an open source release. We write parethesised, prefix pascal for our macros that gets expanded to regular pascal (easy for most algol-like languages). Having a proper macro system made it possible to remove _a lot_ of boilerplate, even though we primarily use it to generate code that the compiler can optimize easier.