Ask HN: Are people still using Pascal?
Pascal, and later on Delphi, was what introduced me to programming 20-something years ago. As with most folks in our generation, I quickly discovered other options, more suitable for that relatively fresh thing called the Web.
So, i generally considered Pascal a dead language.
I was surprised to find out the other day that Delphi is not only alive, but thriving in its own way. Its community is as strong and as fervent about using it as it was back then. Even on the open-source front, there is an alternative IDE called Lazarus that offers a similar developer experience at no cost.
This got me curious. Who is still using Pascal/Delphi in 2023 and what for? Has it matured beyond the desktop app? Has it transitioned into the cloud-native era?
259 comments
[ 3.2 ms ] story [ 254 ms ] threadhttps://www.youtube.com/watch?v=l3nn3isshVg - When Delphi reaches the Cloud!
Disclaimer: I'm not a Delphi programmer. This just popped up in my YouTube feed.
Delphi itself was also a very speedy IDE, at least back in the borland and codegear days. Can’t speak much to the embarcadero era as that is when I switched fully to web dev.
£60k seems a little low for a "senior" position in central London. Although you do get final salary pension, slightly above average holidays (30 plus bank holidays), and free TFL travel.
Luckily, many years later in a US high school, I rediscovered it all from scratch (programming, not Turbo Pascal lol), and things started making way more sense. Looking back, it was not the fault of Turbo Pascal at all for how my first experience with it went, and i find it a pretty fascinating language.
All they cared about was the material they were supposed to teach (Turbo Pascal, Dreamwaver and Microsoft Access) and it almost turned me off from programming.
I believe Zoom Player too is a pascal beast. Before VLC became ubiquitous and playing all formats, Zoom Player was one of the top windows contenders. Since then Zoom Player grown to be also Zoom Commander, which is a player for meant for restaurants and venues, with ability to split video across multiple screens, with multiple overlays. https://www.inmatrix.com/
It is a free, cross-platform alternative, also written in Pascal and (IMHO) has surpassed TotalCommander in many ways.
https://github.com/doublecmd/doublecmd/wiki/Development
https://www.embarcadero.com/case-study/image-line-software-c...
The software on-screen: https://youtu.be/kySAQvU51CY?t=137 . It controls lights, cars, and recently they had the idea of using "AI" to actually let 20 mini F1 cars race each other on a magnetic track, with each car using a CPU core of a 32-core machine: https://youtu.be/3ujaGUFfgC0?t=187
In my opinion there is nothing out there that matches simplicity, productivity and power of Delphi when it comes to desktop. My deployments are signed single exe that can be copied anywhere they just run. And are super snappy.
My main languages outside desktop are C++, JS and whole bunch of others when needed.
I was exposed to Pascal in high school and college in the late 80s/early 90s.
I've never used it professionally except for when I supported an Oracle DB backend in the 00s.
https://delphi.fandom.com/wiki/Good_Quality_Applications_Bui...
https://lazarusccr.github.io/apps/
Lazarus is a very powerful IDE that allows you to build your app for the console, GTK or QT you choose.
And Free Pascal is a blazingly fast compiler, that generates high performance native code for multiple cpus, including Intel and ARM cpus 32bit and 64 bit, and for multiple operating systems (Linux, Mac Os, windows, etc).
It's pretty amazing to see your code compiling and your binaries executing, in such different cpus and operating systems, almost effortlessly.
Apple came out with Object Pascal in the early 1980s which was the official programming language for the Lisa and original Mac. Borland came out with Turbo Pascal that went through numerous iterations and by the end of the 1980s I thought it was much better than C for the IBM PC but I switched to C in college because it was portable and would run on 32-bit Sun workstations.
By grad school I had jumped into Linux with both feet and had given up on DOS and Windows, around that point Borland came out with Delphi which was basically "Object Pascal for Windows" and was a direct competitor for Microsoft's Visual Basic intended for developing GUI applications quickly.
Today there are still people who remember Delphi fondly and there are quite a few Delphi clones out there.
I was first taught proper programming on Turbo Pascal in 1992 as a summer class (for nerdy kids obviously) I took when I was 11. It was taught by some undergrad student from what would eventually be my alma mater. I have very vague, but very fond, memories of that experience :-)
Fyi, cloud native means that your application is written to utilize cloud services such as S3, dynamodb, dynamic scaling etc. It often comes with vendor lock-in and is not necessarily the best choice, but calling it a pure marketing term sounds a little ignorant
You don't have to like things, but lying to yourself about how useful they are doesn't help you.
It's not magic but writing software cloud native and modern feels easier better and faster.
It's easier to write, faster to write, easier and faster and more stable to operate and to configure.
https://github.com/KinesisCorporation/SmartSetApps
Pascal is a general purpose programming language (like C/C++), which is not limited to teaching programming basics. The first Photoshop and classic MacOS were partly written in it.
All the cool kids nowadays most likely use Go or Rust. Pascal is still alive pretty well, even though you don't see it often enlisted on job vacancies these days. Now you can use Delphi to write MacOS, Android, and iOS apps as well. If you want to write desktop apps which easily buildable on Windows/Linux/Mac, then Lazarus is a good option. Of course there's an ongoing effort for Android: LAMW (https://github.com/jmpessoa/lazandroidmodulewizard)
A good reference is "Pascal in Three Days". Should be enough to help you learn the language basics.
Delphi was a combination of a lightning fast compiler which produced small and memory-efficient binaries, a fairly advanced OOP language called Object Pascal, a widget toolkit that wrapped the win32 API, a (for the time) pretty advanced IDE with visual GUI designer, and a giant pile of frameworks for Windows-specific stuff like COM and database access. The primary designer of Delphi was eventually hired by Microsoft to C#. It cost a few hundred dollars in its heydey and that let you build and redistribute as many apps as you wanted for free, these days it costs thousands of dollars.
Delphi was a child of its time. In the 90s and early 2000s the primary environment programmers targeted for app development was Windows. The web existed, and people were trying hard to make apps with it, but they were extremely crude and slow so any self-respecting app developer was making desktop apps. And because GUI toolkits were very expensive to develop, there was really only one or two games in town for that, the main one being Win32. Only one tiny problem: Win32 API sucked hard. It was designed in the 80s for C programmers and wasn't particularly good even then. As a consequence a whole pile of products and languages sprang up that tried to give developers access to the large amount of functionality Microsoft offered, without having to actually use their API. The Delphi VCL (Visual Component Library) was such a tool and was a pretty good fit, being as it was characterized by manual memory management, tasteful OOP design and good C interop.
Delphi programs are split into files called "units". Each unit has two sections labelled the interface and the implementation. Types go into the interface, code in the implementation. It's a bit like how C uses header files except more rigorous and tightly enforced. Unlike C/C++ you can't (couldn't?) have circular dependencies between units, which forced a very hierarchical structure on programs.
The Delphi compiler was extremely fast, partly because it was a single pass compiler and partly because it didn't do much/any optimization. For desktop apps that spent most of their time blocking on events that didn't matter, whereas fast iteration speed did, and in this way Delphi carved out a loyal following of developers who didn't want to deal with Microsoft's slow C++ toolchain and poorly designed APIs, nor the designed-for-beginners Visual Basic product.
A big part of Delphi's appeal was the visual window designer. A quasi-marketplace of components existed and when you installed a new component, it would appear in the components tray that was always visible at the top of the screen. Components could be dropped onto UIs, have their properties be adjusted, be connected together, event handlers could be filled out by double clicking etc and they could be visual or non-visual. Also, you have to understand that at this time components are primarily distributed as binaries and sold by companies. Open source was little known in the Windows ecosystem, so there was no notion of dependency or package managers. To use a component you bought it and installed it. Microsoft had a standard for components called OCX and I can't remember what the Delphi equivalent was.
Many Delphi apps connected directly to a SQL database engine and issued queries as the logged in user, via something called the Borland Database Engine. I never used it so can't say much about this, but it's worth noting that this two-tier approach had a lot of advantages and there may be good reasons to bring it back! I'll be giving a talk on this idea at KotlinConf in April. For example SQL injection is impossible by design when your database knows who you ar...
My only problem is that the compile edit develop cycle doesn't suit my "personal" needs and it doesn't have garbage collection for search needs. You can't be hunting down unfreed memory when you just want a quick and dirty utility.
Essentially it's dead. Though, looking at all the people trying to learn programming using dynamic languages with managed memory, I really regret that there is no good low-level language targeting learners as ubiquitous as Pascal was. I still advice those who can't grasp basic concepts and data structures (like reference, identity, passing by value, etc) to spend some time with Pascal and some old school-level Pascal books. For some reason that usually works better than K&R and C. I guess it's just about the language being lot simpler and not enforcing extensive pointer operations.
Years later I was encouraged to read “The C Programming Language”, and it was revelation. And so here I am many years later with a long and successful career in tech.
C was great in the sense that K&R said hey this is a string, and this is strcpy, and oh by the way, this is how you write strcpy.
Also I never managed to get a free copy of Delphi when it was all the rage, so I later moved to VB6, then C++ on Visual Studio and then C#, all of which were easily found in the enthusiast magazines a newbie like me would buy in the 90s.
It seems Borland and later Embarcadero had massive distribution and licensing problems, and they are the cause of their demise.
Some people are betting that Rust will be that language - and it probably can be a viable first programming language if all you're writing is toy programs with trivial use of dynamic memory, like you probably would when learning Pascal. It certainly has better chances than C++.
The beauty of old Pascal was its compact feature set which is really easy to explain.
Teaching rust first would just be a weird memorization of rules that you might not appreciate.
But pedagogically, it is difficult to motivate why we can’t read a reference and mutate it in the same scope, since Python, JavaScript, Ruby, Lua, Lisp, Java, OCaml, C, etc. all allow it. It is much easier to accept this hurdle after having seen and debugged memory bugs and data races in, e.g., C.
I learned C and Typescript before ever touching rust, and I feel like I experienced no rough introduction. Maybe it’s anecdotal, but I always assumed I learned memory and semi-functional programming first, which made rust a breeze.
That's pretty much exactly the situation with first-time programmers who are taught Java—none of the background to know why it makes the decisions it does.
For low-level code, I think Carbon may fill that niche in the future. If it doesn't, C++ may be a good candidate once up-to-date books have been written and compilers actually support the modern spec. Classrooms/guides would need to move away from the still-lingering "C++ is C with classes" approach and use the standard library before that can be a reality, but this book[0] by Bjarne Stroustrup himself demonstrates the future C++ _could_ have if all the modern language features become usable.
In business, C++ will still be the domain of ancient clusterfucks compiled by MSVC++ 6 in many areas, similar to how most Java code is still built around Java 8 because that was the most recent stable version for many projects' lifecycle (and Oracle's decision to only ship JRE 8 to consumers doesn't help) and how .NET 4 is still taught in schools because the new and scary dotnet tool doesn't map 1-to-1 with the old way of working. I can't imagine microcontroller toolkits supporting a modern version of _any_ language in the first place.
However, if more people would learn modern C++ (or a replacement, like Carbon), I think this class of programming languages can have the same growth and hype Rust has enjoyed for the past years.
I'm keeping my eye on Carbon and Zig. Google's influence has managed to push Go to the forefront despite its many quirks, and Zig seems to be focused on doing "C, but right" rather than "C++, but right" which so far is looking pretty promising.
It's also fun to see Jakt[1] being developed in real time; I don't think it's a language that will be useful for production software any time soon, but on the other hand it's a language that actually produces binaries reliably (unlike pre-alpha Carbon or pre-release Zig, the latter exposing many problems after switching to a self-hosted compiler).
[0]: https://www.stroustrup.com/tour3.html
[1]: https://github.com/SerenityOS/jakt
I guess the feature set is too... extensive for a beginner.
Nah, the good things about Go have made it popular. If Google's influence is all it took then Dart would be a much more popular language.
Rust seems like a distinctively bad teaching language. It's a fine language! But I'd probably teach assembly before I taught Rust --- and both after establishing Python fluency.
From what I've seen, those who learn programming using high-level dynamic languages with managed memory really struggle to understand many basic concepts (e.g. equality/identity, abstract machines, etc, etc) and data structures.
> The majority of all practicing software developers won't need to get closer to the metal than Python does
Like they'll never need to write a native extension?
That’s not my experience, and I’d be especially surprised if the first of those examples was true of people who learned with Python, since the identity vs. equality distinction is a basic, important, and in most pedagogy very early concept in Python.
> Like they’ll never need to write a native extension?
Use? Sure. Write? Probably not.
For what it's worth, I came up as a C programmer. I value the experience, but do not value any sense of mastery I might have ever felt I had over all the minutiae of the language.
Continuing to push first-time programmers towards Python is net long-term harmful. It was excusable in 2013, but shouldn't be happening in 2023.
Konrad Hinsen (who is by no means a Python hater) has several years of blog posts that together make up part of the case for why.
From an earlier, now-deleted comment in response to a comment in a previous thread comparing Python to Go in particular:
> Folks probably _should_ stop writing Python—or at least stop pushing it on non-technical people as the easy path to "learn to code". Python and the Python ecosystem have real problems that make it less suitable for that demographic than is popularly imagined. It's more or less an unfortunate accident of history that so many academics who don't first and foremost consider themselves to be programmers are shunted in that direction. If it weren't for the self-perpetuating science-gets-done-with-Python meme and if things were selected through a sober decisionmaking process that took into consideration the actual merits of the language, its tooling, and accessibility, then Go would be killing Python. Heck, even Pascal would fare well. A focused Pascal distribution that concentrated on things like direct runnability (i.e. no build step required, unless compiling for deployment to other machines) and a few choice language extensions for [...] [Python-like] cuteness would go a long way towards making that a reality.
In re <https://news.ycombinator.com/item?id=34850852>
Thinking it over, GDScript seems perfectly positioned to make a dent in the Python problem—at least as a starting point. (Expecting a toy language for a game engine to go anywhere else might seem laughable, but stranger things have happened.)
I don't like Python. But it is difficult for me to look past the empirical evidence that it is (a) remarkably easy for new programmers to pick up, and (b) an extraordinarily popoular, load-bearing tool for actual practitioners in the field.
It isn't the last word on software development (I don't use it), but it's the language I'd reach for first if I was teaching someone how to code. I think the class system is archaic and it goes a little out of its way to resist some functional programming idioms, but makes up for that in other ways.
- <https://blog.khinsen.net/posts/2015/11/06/a-rant-about-softw...>
- <https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stabili...>
- <https://blog.khinsen.net/posts/2017/01/13/sustainable-softwa...>
- <https://blog.khinsen.net/posts/2017/11/22/stability-in-the-s...>
- <https://blog.khinsen.net/posts/2019/02/11/the-computational-...>
- <https://blog.khinsen.net/posts/2019/05/09/the-computational-...>
---
> I don't like Python [...] but it's the language I'd reach for first if I was teaching someone how to code
Damn, that's crazy. Considering how many of those people would be coming from Windows and Python isn't actually[1] a batteries-included situation, I'd go with JS. I'd say, "Look: here's how you can get started right away making little programs that run in your browser right now even when you don't have WiFi," then at the point where other people might start introducing Node (or Deno), I'd say, "You should really learn Go." I'd preface the JS stuff by saying, "mostly ignore EVERYTHING that you come across telling you how tech influencers on the Internet think you should be writing JS. (For example, if at any point during this stage you find yourself pressing the key for the equals sign three times in a row, then you have already lost sight of the trail—and the plot.) Instead of listening to StackOverflow and GitHub, here's a copy of ECMA-262, 3rd edition (notice how it's still accurate, even though it's from 1887) and an offline copy of developer.mozilla.org for reference."
1. <https://news.ycombinator.com/item?id=34833619>
I wouldn't start with Javascript, though reasonable people could. It's too malleable a language, and a bit of a moving target. Python wears its opinions on its sleeve, which is a good thing for this purpose. Remember, the point of a teaching language isn't that it's the last language you learn; it's the first.
I pretty much agree with all of this. I don't love Python from a PL nerd perspective, because of its weird hostility to functional programming and proper lexical scoping. But when people ask me what language to learn as a beginner, I always say Python. Empirically it's in the sweet spot of both being easy to pick up and practical enough that people can start out making useful things.
I also agree that you shouldn't teach Rust as a first language. You shouldn't teach any typed language, honestly--types just complicate things before you learn what they're for, which only hands-on experience will teach you.
I was also fingering GDScript specifically as a _starting_ point for the sort of thing described in the quoted/deleted comment: a concentrated effort to produce a RAD-ish environment meant to dethrone Python from the seat it unreasonably occupies today.
Delphi and FPC/Lazarus are still under active development. Some hardcore Delphi-ers from the 2000s I know are still using it, either for maintaining in-house apps or doing side jobs.
If you are looking for jobs, I agree Go/Java/Kotlin/C#/PHP yield more search result, though :)
Pascal is just a little bit more polished in its syntax around data handling. The pass-by-reference syntax reduces reliance on pointers, and the Borland pointer syntax is sensible(reference vs dereference is indicated by ^ at left vs right) and helps to position pointers as an occasional tool rather than the essence of your program. Trying to teach C syntax involves a mandatory "OK kid, here is how we actually decipher what the * means here and why your program crashes when you try to dereference it" period. We know that it's bad - because everyone, at every level of skill, messes it up occasionally, and there's an inherent tendency in C to do a heap alloc wherever your algorithm needs it and then immediately manipulate it with pointers, instead of thinking through a way of designing it with bounded buffers. Likewise := is a better assignment operator than C =, because you might accidentally leave out the : and compare, but you'll never accidentally add a : and assign.
The downside of Pascal syntax relative to C is mostly in control flow, block structure, declarations being more verbose - it's something you can get used to, but it's that little bit harder to jump in and start hacking out something. With the extensions currently in FPC, I'd still prefer using it over C, though. It's a mature development environment, mostly hamstrung by an ecosystem that has fallen behind in favor of newer things.
Nonsense. Just have a look at current rankings (Stackoverflow survey, IEEE Spectrum, Tiobe, etc.) where Pascal/Delphi is around the same position as e.g. Swift or ABAP; in your logic all these languages are dead, which is obviously wrong. There are also other languages with a Pascal like syntax (e.g. Lua) which do well.
> syntax
Syntax is the least important part of a language. In my opiaion, Lua has almost nothing in common with Pascal (type system, memory model).
IEEE Spectrum
and some more (if you don't like TIOBE)
It's usually the syntax people complain about. The semantics is very very similar to most of the C syntax flawored languages.
The Lua syntax was designed with Modula-2 in mind (a Pascal descendant).
It's like saying Macintosh is dead just because its market share is much smaller than Windows.
These days it's obvious the years of lost momentum is taking a toll. The language hasn't evolved much and is showing its age in many areas. The IDE is far behind Visual Studio in terms of code completion and similar help. It's also been difficult hiring developers.
We've looked at moving to the web, but none of the front-end frameworks and tools we've seen so far get anywhere close to the ease of Delphi when it comes to making decent looking user interfaces with nontrivial functionality that doesn't silently break in random weird ways from one day to the next.
Also, if you want something in between a full CRM and "assembly level" database access, Delphi has some powerful libraries and components.
To give some perspective, we've got hundreds of businesses with many thousands of users, many large modules which constantly evolve, we have tons of custom integrations per customer, including custom data entry windows/screens. The largest customer has 25 integrations, 20 of them entirely custom including non-trivial new user interfaces, and got onboarded in less than a year from signing the contract. This with a team of 7 devs total and zero hired manpower. I'm not sure we could have gotten this far with such few developers with any other tool/platform.
But as I said, things are changing. So far we're moving the "backend" stuff to .Net/C#. Via RPC and message queues we can implement pieces in .Net while keeping the frontend in Delphi for now. We'll probably move the front end at some point once we find something suitable.
This combined with the years of subpar evolution due to poor management certainly did not help Delphi.
https://www.lazarus-ide.org/
We ship our application as a binary with some premade Delphi form files and a tool we wrote to build DFM files for the customer specific application that limits access to the functions and objects built into the application. I'm part of the group that consumes the application as built and develops customer implementations.
We're slowly transitioning from Delphi to C#, because the language is creaky, and mostly, its become impossible to hire dev's and when we do its months before they can be productive (but boy are they once they are).
I think the move away from Delphi is going to hurt a bunch in the short term, but will probably get us long term benefits.
For me the biggest issue I'm dealing with, is Windows is a treadmill of changes, and its hard-to-impossible to keep up with it.
Would they relocate to fill a job in a small company that mostly use Delphi?
We're talking about a programming language mostly targetting software for small businesses. A language that has basically no future.
Nothing's impossible, but I'm ready to believe that finding people for these types of job is probably not easy.
Not impossible, just not as easy as finding a Python developer.
If is-already-fluent-in-unsexy-niche is a hiring requirement, then your hiring is totally broken. (To be honest, it's broken even when you broaden it outside "unsexy niche"...)
> finding people for these types of job is probably not easy[...] not as easy as finding a Python developer
Damn, goalpost, you sure do get around.
I dont think python or C# are especially hard to hire for.
I feel like you came to this conversation with a preconceived notion here. Look - not everyone can match the SV pay scale, I'm not on one, there are no stock options floating around here.
I have no idea what this is trying to say here. Yes, I called out the months-to-productivity quip.
> I feel like you came to this conversation with a preconceived notion here.
Right—the one that I said I had: that people who say it's "impossible" to hire developers to work with <X> are the equivalent of other industries' folks who the same thing e.g. about not being able to hire retail workers. When you prod a bit, it turns out it has nothing to do with <X> or workers, but instead pathological hiring behavior and expectations on the part of the companies themselves (with a common one being the "4 who expects to date a 10" effect).
I don't understand why this conceptually is so hard to understand - I know some very obsolete, and arcane shit, some of it, I'm the only person I know who has even a modicum of familiarity with it, as these technologies were no longer in common use by the late 90's (and I suspect most of the other people who still know it, are either, about to retire, retired, or dead). If you put out a req with that experience as a requirement, you're not gonna find people for it, no matter the money offered, or the hiring process.
I've not seen anything that'd lead me to think anyone is expecting 10's here, I think even finding 4's with Delphi experience - just based on the responses to this post, is very very hard.
I understand it fully:
> If you put out a req with that experience as a requirement, you're not gonna find people for it
You're making _my_ point, dude. That's a stupid req.
You said it yourself that the N-months-to-productivity problem (which is par for the course anywhere) is not actually a consequence of language but rather of domain familiarity or business processes or whatever. Again: not a surprise. So whether/if it takes two to ten months to see productivity from your hires no matter which language you're working in, then it's silly to lament the difficulty of being able to hire developers who can write Delphi on day one. You don't even need that!
This much is true. However this is also not the reason why we find it difficult to hire. We don't require someone who can write Delphi from day one. We require someone who is willing to write Delphi from day one.
Obviously past Delphi experience will make that much more likely. But we've tried listing "C#/C++/Java or similar" in the suggested experience part, and most of the people with such backgrounds are not willing to learn Delphi it turns out.
Cool. Would have been nice then to not have brought it up ad nauseam as if it was relevant, rather than a massive distraction masquerading as a mic drop-worthy argument ender.
I work in an industry with useful, important, specialized, but unsexy technology.
PCM Audio, Multicast, lots of analog connectivity, arcane binary protocols (even widely adopted and interoperable ones), lots of manufacturer specific protocols too. Windows and RHEL. We've only just barely figured out what Web 2.0 is, Javascript based UI is new for us. We also do a bunch of embedded development, RTEMS, now Linux, other shops have some VxWorks too. Plus lots of development on just DSP code. This isnt just us I'll note, its my whole industry.
Technology in our world moves very very slowly. We provide decent wages, good benefits and a no requirement for overtime, but it's not sexy and it's not the way the rest of the technology industry is pivoting. We provide solutions that are reliable, and must work, but dont need to serve billions, just hundreds.
Also, as a deployment engineer it takes someone new into my role, about six months before they understand enough of the system to work unaided. It's not that we cant find developers - its that finding people who understand our industry is hard, and even if we hire someone who isnt in our industry, it does take six months or so before they can be productive. The larger issue is, they dont see the technology work on as a good stair-step on their career progression, so they dont wanna work here.
The web and mobile dev stuff is "comfortable" and "safe" because they (we?) see how ubiquitous it is. Maybe the companies themselves are not, but everyone needs web developers right now.
I recently took a job that is in web development, but is focused on front-end (and I've spent 13 years as a very versatile full-stack dev) and is a much more focused tool (data visualization tool versus an operations management system for everything government public works, including simple data visualization) and even that made me mildly hesitant.
I do dream of some day pivoting entirely into something more low-level and hardware focused. I've done a lot of hobbyist audio production and that's always seemed like a fun niche to build in. Maybe when I'm old :P
I get to work on the whole enchilada, not just some narrow part of it, its wonderful.
For some reason, I find this very appealing.
There are some advantages in working for a company none of your (non-industry) friends have heard of. You get to talk about your job and explain it without preconceived notions.
Also, I feel I'm making an honest to god difference at work, I help people solve difficult problems that are critical for the health of broader society (utilities, transportation, government) that would be hard to solve elsewhere.
I have several coworkers with 30 years of seniority, and some with 40.
It's a job you leave largely of boredom.
XKL sells network switches running TOPS-20 for their management software on an FPGA based PDP-10 (probably the last place one can see and use a 36-biter).
It's exotic legacy stuff, and at the same time a breath of fresh air.
Having been developing for nearly 40 years now the technologies don't really excite me - it's what I'm building and the impact that it's having on its users that motivates me. It sounds like you've found something that motivates you, too.
What is claimed, and what is in contention, is the inability to find developers.*
I could show you some people who don't like to (or can't) eat peanut butter. That's a completely different matter from demonstrating that nobody will eat peanut butter. Your ∃ is not an ∀.
Second: That an employer who wants to hire will have to either pay more (than what they are currently trying to get away with) or lower its standards is a pretty straightforward restatement of what I was already saying. That observation is, again, not some sort of insightful riposte—it's just, you know, arguing for my position...
* which is a claim that the person I first responded to has already walked back
Having such a small team means each person has a huge impact. Hiring a poor fit can be a net negative on the team and thus we'd be better without.
We've had poor experience with remote workers, including ourselves during corona lockdown, so we want someone who can be at the office at least 2-3 days a week. And they'll need to be competent in Norwegian, as most of the gov't documentation and customer interactions will be in Norwegian. So that narrows the pool quite a lot.
We've tried not specifying the language in the job ads, and have almost everyone turn away when they ask and we tell. Clearly many are worried about taking on an unknown, and how that will reflect on their CV.
As for taking months to be productive, that's certainly my experience. Obviously getting productive in Delphi doesn't take much time, our two latest hires had zero Delphi background, mainly Java or Python, but after a couple of courses they were good enough to commit solid work.
However what we need, due to our size, is that our devs can get a task, then go design and develop the solution on their own. Maybe ask some clarifying questions to team leader or customer along the way, but no hand-holding. This requires both acquiring domain knowledge and learning our existing code base.
Personally that took about a year or so, and I didn't get really good at it until after two years. This matches well with those who got hired after me.
I've been trying to think a bit about it. So far what I got is mainly two-fold. The big one is that people seem to find it far easier to ask the colleague in the next office over when they're stuck, compared to over Teams. And it's far easier to tell people about new features you've implemented over lunch or similar.
I also much harder to direct someone over Teams, or illustrate, compared to pointing at their screen and tell them what to do or quickly drawing some flow chart on a piece of paper while together, so teaching is more difficult. We a brand new hire just before the lockdowns hit, so we noticed this very well.
Also you miss out on listening in on the corridor chats. There's quite a lot of stuff I pick up on just by listening in on the other devs or support chatting in the corridor. Oh those customers want something very similar to the feature X I'm working on right now? Let's join the chat and see if we can't satisfy two customers for the price of one. That kinda stuff.
I'm pretty sure if we had been fully geared and prepared for remote work it could work much better, but I do think it requires a different mindset and different management style.
Shouldn't this be the job of the product manager?
But like I said we've got hundreds of customer-specific features and integrations, it's hard to catch everything, so no need to defer things when one of us devs can shortcut the process.
This Delphi course wouldn't happen to be online would it (or in book format)?
Anyway there seems to be a fair collection of free stuff over at Learn Delphi[2] though I haven't checked any of it out so don't know the quality.
[1]: https://alfasoft.science/en/events/category/embarcadero/
[2]: https://learndelphi.org/
ORM of course, not sure what my brain was doing at that moment.
Delphi and C# share a chief architect, Anders Hejlsberg, who left Borland for Microsoft in 1996[0].
[0]https://en.wikipedia.org/wiki/Anders_Hejlsberg
Like I said, we've struggled big-time to fill our open dev positions. Also, the .Net community is just that much bigger, and the tools get more attention.
For example, a customer recently required us to fetch messages from Azure Service Bus to get an ID for a file in Azure Blob Storage. Sure the REST calls for the Azure API's could have been written fairly easily, but they used that pre-shared key authorization scheme which required signing certain HTTP headers[1]. None of our libraries easily supported integrating that, as they all generated those headers on the fly while making the HTTP call.
In .Net there was already official libraries for this and it took me a couple of hours to write the integration, including testing. Even without the authorization blocker, it'd taken way more time than that to implement the necessary REST calls and properly test them in either Delphi or Free Pascal.
In another example, we've adding JSON support for our "public" API, in addition to our XML. We're quite used to customers feeding us with crap data, so validating against schema on the way in is a must to keep support requests down. In .Net there was already a nice JSON Schema library waiting for us[2], so only took me a couple of minutes to integrate that. The only Delphi/FPC library I could find was years old and didn't support the JSON Schema version we required.
[1]: https://learn.microsoft.com/en-us/rest/api/storageservices/a...
[2]: https://www.newtonsoft.com/jsonschema
The blurb says it integrates with .NET well.
Oxygene would maybe make it a bit easier to write C# for some of us[1], but it's incompatible with Delphi so we'd have to rewrite code anyway. Just doesn't make sense.
If you're starting from scratch with a small Delphi team and want to target iOS and such alongside Windows, then yeah I'd consider it.
[1]: not me, I wrote C# back in the 1.1 days and feel right at home
I love the project like an old friend. I just can't trust it in a professional setting like a customs depot or a logistics department. Delphi works fine.
That has been my experience as well. For stamping out these CRUD apps with custom forms, nothing I have come across has been able to match the productivity and simplicity of Delphi and Visual Basic from the mid 1990's.
The one thing that I found that makes knocking out a simple web app fast is Streamlit in the Python ecosystem. Setting up Python is a bit of a nightmare but once out of the way, using Stramlit is quite nice. Although no visual designer is a bit of a let down.
For example, when we upgrade a dependency and suddenly we get 30 compiler errors because the signature of a call-back function in the new version of the dependency differs. Without strong typing and strict checking that could be 30 support cases (or more) as we don't have full integration test suites for all the various customer integrations for various reasons.
Strong typing helps a lot with readability, as it can make the code a lot more self-documenting. Very often I don't need any separate documentation. Just by looking at a function signature I can see what types it expect, I can thus find code for those types to see what they look like and that way gain a good understanding of what I need to do to call that function and, just as importantly, what I get back.
Strict checking means I don't have to worry about silly bugs all over. Want to assign a string to an integer variable? Well then you better say so.
In fact the areas that annoy me the most is those where the strict checking fails. For example the TDateTime type, which holds a time and a date unsurprisingly, is defined as a type alias for a double-precision float. Thus "myDateTime := Pi;" compiles just fine.
This is mainly for historical reasons, as records (structs) were more limited and clunky back in the days, however the type is so ingrained in library code all over it's hard to avoid.
It blows my mind.. really it does, how did we not fix this shitshow? We have automated test on top of automated test on top of automated tests but web is so messed up we still can't have shit working reliably.
How many are
a) highly nontrivial with hundreds of windows/screens, many with with multiple searchable grids, custom lookups, per-screen user-definable tab-stop order etc etc
b) reliable enough that the users can enter all the data they need without looking at the application (ie no missed keypresses or focus changes etc)
c) being developed, maintained and operated by a team of <10 devs?
Honest question, if you know then do tell! I'd love to hear how they're doing it.
Like, this year changes to gov't systems means we'll have to implement about a dozen new complex windows/screens, along with all the backend logic. We get the specs about 6-9 months before go-live, so it's not like we have a full year either.
I'm also using a language from the 90s, but one even more niche than Delhi. We have desktop systems, and Web systems, and while they share a lot of source code, the UI procedures are different.
The Ide is still maintained an updated, but of course falls well behind visual studio now.
So for you to switch to this makes even less sense than staying on Delphi. We're under similar pressures to "rewrite in something more modern" but fortunately (for us) the business doesn't have the pockets that sort of project would consume.
Technically there's little reason to change, Functionally the language let's us program anything we want, so apart from the perceived "long term security" of rebuilding from scratch in c# there's not much upside.
For what it's worth we've built the system mostly with 1 developer, although on occasion as many as 3. The primary developer has changed once, and that was a smooth process so it can be done again if necessary.
I write all this to encourage you. If what you have is the best option, then stick with it, swapping bits out slowly as you need to. Make a transition organic, not one giant project. Code is just code. Customers don't care about the language, they don't care about the code, they only care about the solution to their pain.
I have my job because I love technology.
There is joy and fun in using modern systems.
Good tooling like ide, security tools, linting, Testing Frameworks etc requires modern supported languages.
Languages evolve.
I've been doing this a while, and I've been around the IDE bush, and the editor Bush and so on lots of times.
There are many disadvantages to using things that will never be popular, that are niche, but lack of joy is not one of them.
For me it's not in some shiny new language, or toolset, or whatever. The joy is in what you create, not the tooling. It's in creating solutions that make people's lives better. It's in putting good on the family table. It's in employing others and watch them do the same.
The things you talk about are language agnostic. What doesn't exist, we create.
I completely disagree.
I also don't enjoy creating systems which calculate car payment or a registration flow.
By "web" you mean "professional standards". There's no excuse for not being able to put out something that doesn't result in a blank page in Safari. The Web has not gotten more difficult to publish for. It's not an SDK that forces you to rev your codebase from time to time if you want things to keep working*; the stuff that worked last year and 10 years before that would still work today. The developers chose to make these changes, and the client chose to accept it.
* barring some pathological circumstances like previously having decided to depend on undefined/non-standard behavior, but that's (a) gonna be a problem anywhere and not unique to the Web, and (b) not remotely essential for publishing working stuff that you want to show up in a Web browser
It is probably still a practical choice for both of those. Certainly I've seen sprawling internal systems developed with web technology at a multiple of what it would cost to deliver the functionality with Delphi.
Recruiting top talent will be tough though - those with the most choice often (rationally) choose to work on growing-adoption technologies.
Lesson for anyone wanting to start their own business, go after small niches like this company where the entire customer base is < 1,000.
There’s lots of money to be made in these pockets. Then expand into adjacent segments.
DevExtreme (DevExpress for web) comes very close to the frontend development experience of Delphi, because it was created by the shop which created the best Delphi component suite.
Currently, we are using DevExtreme with React. All of the components are tied to DataSource which you can map your insert, update, delete calls in order to cause the updates to be rendered, just like it did in Delphi with Data Modules and Data Sources.
Of course you don't get the benefit of data sources working at design-time while working on the web. Delphi was and still is a few decades ahead of whatever we have on the web.
Do you do the form layouts by hand then, or are there other tools to assist with that which work well?
No product, no product strategy just pure company integration.
I bet the train is gone for years already.
And instead of creating a real product and forcing companies in a clean workflow and driving it you are being driven.
The message queue thing you mentione sounds exactly like other companies I have seen with the exact same issue were suddenly some random tech is used to add things to that pile 'easier' just digging the grave deeper.
But I can be wrong.
Oh we definitely have a product. Almost none of our customers have all the data they need in the other systems, but they almost always have much of it. They're just lacking the domain specific stuff, unsurprisingly.
So our product has a lot of domain-specific logic that greatly assists customers in enriching the data as required by law, before submitting it.
However part of what got us to dominate the niche is that we were willing to be driven, as you say, or solve our customers problems as we see it, when it comes to integrating with those other systems.
Now that we've grown we're trying to be more strict. Custom screen/windows is not something we do readily anymore for example.
However, oh so many new customers ask for our standard XSDs etc, and once we hand them our XSDs they turn around and go "hmmkay, but how about you just use the files we already got?" and hand us some other XML, CVS or whatever.
This made projects that required any sort of advancement in protocol - even just for a prototype - scale quickly, and most of them we abandoned before we got there, unless the old tech (in our case, mostly self-designed) was proving too problematic.
Too a lesser extend is the age of Pascal. But I would apply this critique to C and C++ as well. Hell, even Java and C# are showing their age these days. There are just some quirks in Pascal, one needs to remember, like 1-indexed strings (I know they added an option for 0-indexed strings later) and that you can - theoretically - make arrays any-indexed. But all languages - including far younger ones - have their own quirks.