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.

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.

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.

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.

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.

I have several coworkers with 30 years of seniority, and some with 40.

It's a job you leave largely of boredom.

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/

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.

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

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

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.

This combined with the years of subpar evolution due to poor management certainly did not help Delphi.

https://www.lazarus-ide.org/

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.

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.

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?

ORM of course, not sure what my brain was doing at that moment.

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.

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.

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.

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.

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.

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

Besides our product, all of our in-house order entry and shipping systems were created with Delphi.

Last year I decided to come out of retirement and start a retail business, currently in stealth mode, but still using Delphi 6 for our tech infrastructure. I wrote a multiple-station data entry system for capturing/maintaining our inventory using a SQLite centralized server. I wrote an ISAPI DLL to drive our Javascript-free package-free web site which is very fast and has quite nice search capabilities. (Yes, a 32-bit DLL can generate HTML/CSS quite adequate for a modern-looking website.)

After using it for over 20 years, it is so quick and easy for me to create just about anything I need with Delphi, that the few times I've considered using other tools it quickly became apparent it would just take too long to get a handle on things and the ROI simply wasn't there.

An example of that was when last year I stumbled upon a Python program that did some sophisticated processing I could use, but dealing with that environment turned out to be a time-sucking nightmare. Too much of modern "programming" has turned into trying to mix and match and glue together packages instead of actually creating code. So, I'm sticking to an old-school system that lets me be creative and productive.

Learned Delphi in 2003...it never clicked for me and went to C/C++, python, fortran, web (HTML, CSS, JS, frameworks) you name it, instead. And after many years, in 2022 I've rediscovered Lazarus/FPC and is like a revelation to me. Instant click, instant match to my development style and made me a 10X developer overnight in it. I feel the joy of programming again.

https://www.embarcadero.com/case-study/image-line-software-c...

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.

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 :)

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.

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.

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.

- <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 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.

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

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.

I guess the feature set is too... extensive for a beginner.

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.

> 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.

I learnt Pascal in my first year of University. After a brief stint of BASIC, I fixed up a failing project using Delphi. This was the start of a long (long..) stint of Delphi programming.

I've now opted for a lower paying role to learn new skills. I'm loving it. I should have done this a long time ago, but life is what happens while you make plans.

I think one of the biggest problem older Delphi apps have is that they lock themselves in to working well in a Windows GUI environment. Early Delphi based project successes, because of quick initial deliveries (due to RAD/ROI), of mostly working applications mask the problem of a lack of architectural forethought.

I suspect a very difficult problem for most Delphi apps these days is disentangling working, legacy business logic from many sometimes very old forms and code into a more web consumable format. I've thought of starting a business to do this very thing, but others are doing this quite well I think.

The well thought out apps, that did have some reasonable architectural forethought, have probably been ported to C# by now. The apps that can't do this can be quite tricky to work with.

Working in a dynamic lang, Python, Scheme, etc. also I think allows easier shape-changing for new requirements. Whereas I think Delphi apps can get bit locked down into a way of thinking/doing tasks (GUI talking to a DB).

YMMV,. but that's my experience :-)

Glossary: RAD: Rapid Application Development ROI: Return On Investment

I got hired for my second job, because of my previous experience with Delphi. It was a cool job with amazing colleagues, but I have opted to go for a degree in Computer science and I am not going back to Delphi.

There were many small frustrations with the language. I have recently worked a lot with GoLang and Python and have come to appreciate the extensive (standard)libraries these language provide. I know how to manage memory or reverse/traverse some iterable by hand - but do I have to? I feel like my time is spent much better by thinking about architecture, maintainability, testing, actually solving problems than wrestling with tasks, that computers can do much better by now.

Delphi is a neat product, but fuck Embarcadero - their business model is to extract revenue from the long tail of old Borland customers who are locked in for one reason or another, not grow the product.

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.

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.

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.

If you ask “How do I do XXX in language YYY”, it may just dump you into some library.

If you ask for it in Pascal, it will more than likely take a stab at an actual algorithm. Pascal is pretty straightforward to translate into something else.

https://jonlennartaasenden.wordpress.com/2020/01/20/turkey-s...

Author of original opensource FREE!ship switched to develop its proprietary variant, DELFTship - it still actively maintained.[4]

[0] https://sourceforge.net/projects/freeship/

[1] http://web.archive.org/web/20160831005653/http://www.hydrons...

[2] https://sourceforge.net/projects/freeship-plus-in-lazarus/

[3] https://github.com/markmal/freeship-plus-in-lazarus

[4] https://www.boatdesign.net/threads/free-ship-continues-as-de...

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.

£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.

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.

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

It nearly happened in this universe in the 1980s. The original Apple Lisa and Macintosh software was largely written in Pascal[1] and all the original developer APIs were in Pascal.

Pascal was a first-class language on Vax/VMS, and it's easy to imagine a world where Ada (which is a Pascal-family language) became popular instead of C++.

My first job was in Delphi, and I still am fond of the language. But it really is mostly dead for new applications now.

It's interesting to see the influence that Object Pascal in Delphi had on C# and now on Typescript - Anders Hejlsberg is responsible for all three.

[1] https://macgui.com/news/article.php?t=519

https://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.

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.

Pascal was popularized by Borland, who sold a complete develpment environment that was tiny, fast, well-documented, and dirt cheap. They got rich doing that. Delphi cost more, but it did a lot more... and then they started jacking the price of Delphi into Twilight Zone territory; over a thousand dollars if you wanted the necessary "add-on" bits that you really needed to make it work. That, and other bad business decisions, killed Borland, and put Pascal itself in the shadows, as they'd pretty much dominated that market. Anders Hejlsberg, who had written both Turbo and Delphi, eloped to Microsoft to work on Visual BASIC.

Besides the price, there was Borland's "upgrade" policy. At first, existing Borland product owners could upgrade for a nominal price. The price kept going up, and upgrades started coming faster. New versions were just incompatible enough to be a hassle. Finally, for the piece de resistance, they started running full-page ads begging Microsoft compiler owners to "upgrade" to Borland for less than what they were shafting their own customers for. That's when I, and apparently a whole lot of other programmers, decided to part ways with Borland.

If your dependencies can be downloaded and built in a Docker container, for example, it can certainly run in the cloud.

[1] https://www.embarcadero.com/products/rad-studio/features/del...

On the other hand, I have pet peeves with the language that prevent me from using it for more ambitious projects:

FPC has no "inline" var declarations, and the community is even against it. My code is math heavy with many "transient" variables so the dedicated var section at the top of the function gets crowded quickly. Recent Delphi now has this, but costs have to be taken into account if you want to commercialize or deploy cross-platform. It seems that the real reason for this is to help the compiler be fast instead of helping the programmer.

Case insensitivity might be a minor thing, but it is there and you have to deal with it.

Then optionally dropping the parentheses for functions with no arguments hides the fact that you're calling a function which possibly does something else besides just reading a value.

While I'm American, I did a weird U.S. DoD/State Department language program (NSLI-Y) in high school, where they sent us off to Moscow to study Russian. I thought it was such a fun and strange experience that I decided to stay afterward and do my bachelor's there.

Initially, I wanted to go to Novosibirsk. But between passport renewal delays and everything else, I took the first and only thing I could in February, the preparatory program at Tomsk State University. And yeah, at least in 2018, all of the introductory programming classes were taught with Pascal and Lazarus.

I think the professors in the prep program must've been from the more traditional "Institute of Applied Mathematics and Computer Science" faculty, though, rather than their newer spin-off, the "Higher IT School", which probably explains the Pascal choice in my case.

Because when I enrolled in the proper degree-granting 'Software Engineering' program, it was surprisingly modern and practical.

They had built their own little LeetCode clone that they used for the introduction class to teach the general basics of programming, algorithms, data structures, etc., with some ~600 tasks or so that you had to complete a certain percentage of in each module (one thing I liked is that they had a mandatory regex section as well in that class -- I feel like too many people end up having to StackOverflow those types of things). You could use a variety of languages (Java, C#, C, C++, Python, Ruby, PHP, Pascal, and Perl, I believe -- looks like Ruby, PHP, and Perl are gone now, though) that ran in containers against a bunch of test cases.

The second semester, that class focused more on practical projects and teamwork. So we had to build a little Instagram-like mobile app with whatever tech, and then any game with any tech (my group just did Android + Java, and then we made a Source Engine-style surfing clone with UE4).

We also had a weird but fun "cross-cultural communications" course where all the students in the Russian and English programs intermingled, and it ended with us having to organize, find sponsors for, build teams, and play in a CS:GO/Dota 2 tournament (Russia moment).

Initially, the third semester felt like we were going back in time because we were forced to use some ancient version of Oracle for our database class. And, of course, because of licensing limitations, we had to physically go trek to university in -40 for that. But the professor was an interesting character; funny guy who wrote all of his own textbooks in English and Russian for us (for free), and I don't even know how long ago he must've gotten his doctorate, but I know he's been teaching since the 80s.

After Oracle hell, he forced us to pick any NoSQL database and build something with it. The nice part, though, was that he really, truly did seem to know everything there was to know and stayed up to date.

That same semester, we also had a mandatory "OOP" class taught with C# and .NET Core and a mobile development course, which taught modern Android development in Kotlin.

The fourth semester was machine learning and data science, mostly taught with Python. And a vaguely titled "Programming Languages" course, which was kind of brutally intensive and went through functional programming, concurrency and parallel computing (I did not have fun writing lots of OpenCL), and then forced us to design a language and write an interpreter and compiler for it.

We also had a front-end course, systems administration and networking, and then "Entrepreneurship," where they taught some basics of business and econ, made us come up with an idea for a software startup, do market research, build a tiny MVP, and then present (it was OK for the presentation to be a 'why we failed' -- which was the case for my team, lmao).

Fifth semester, you had a "Software Engineering" course, which was more so about project management, learning how to write issues correctly, UML, etc., a course on back-end web development taught with ASP.NET Core, and then essentially a more hard-core continuation of the entrepreneurship class, except this time you're meant to present to actual VCs, and if your idea doesn't suck, they offer to give you funding and let you work on it for the remainder of the program if you desire.

In the sixth semester, you are meant to prepare for the fourth year, in which you choose between an internship, research, or your own business. And you write a ~40-page practice thesis based on your work or research.

And then, the final year is a continuation of whatever track you chose + the real-deal thesis, and some various minor classes here and there -- like we had some group-work-based Scrum course where we had to build a learning management system.

I'm sure I've forgotten a bunch; we had so many damn classes all the time. Plus, the other mandatory non-programming-related ones, like calc, stats, linear algebra, Russian, history, philosophy, and FOUR YEARS OF PE, OH MY GOD (and four years of English, but the professor is the coolest woman in the world, and it was fun since it mixed the international and Russian students, so I didn't mind that, at least).

(Also, worth noting for anyone not super familiar with education in a lot of the post-Soviet states, you're generally assigned a 'group' where you'll be with the same dozen or so students during each and every class for the entirety of your degree.

So, that also tends to mean there isn't really the concept of picking and choosing different classes, etc. -- every class is mandatory, and you all share them together; you're either going to have an amazing bond by the end of it or be very lonely).

EDIT: Forgot about cybersecurity. That was cool too. We were given access to various servers and web applications, each with different vulnerabilities that we had to find, exploit, and then patch. It was fun seeing things like blind SQL-injection, etc.

I already knew enough programming from building Flash apps and poking around with J2ME during high school and I got really bored, really fast, with all the kindergarten-level exercises and all the relentless bureaucracy. C programming professor insisted that assignments had to follow a strict template and be turned in as printed pages, for example. We had C, C++, and a bit of C#. The cryptography professor had us write crypto algorithms IN MATLAB OF ALL THINGS. There were also several course projects where you could choose your own stack, but again, they were uninteresting for me at my level. The databases (SQL only) and networking classes were the only ones where I actually learned something substantially new. Operating systems and Linux administration classes were also kinda useful because they helped me tie my understanding of these things together into a bigger picture.

We did surprisingly little real programming. Philosophy almost got me expelled because that professor was a young girl that didn't allow anyone to even try to cheat and wanted you to retell books. That's it. No thinking required, read a book and store it in your head. I had to lie to multiple people to take the long-overdue exam with another professor that didn't care about students cheating.

That was a recurring theme. There wasn't much interesting stuff, most was this "memory training". Memorize, regurgitate, get your passing grade, forget. This gave me unending trouble. There was even a system (ЦДО) where you would pass tests like these. I have a collection of most asinine questions somewhere. The same system was where our grades were stored. It also had internal mail. You could put HTML into messages. They tried to filter it, but I did manage to find a way to sneak an XSS in there, whoops. A stored XSS that you can send to anyone else who has access to this system! It involved some base64 trickery with <object> iirc. Never reported it.

You could really tell this was a very Soviet curriculum they sprinkled with some occasional modern stuff.

I got my real job at VKontakte as an Android developer at the beginning of my 2nd year. This is where I got most of my real programming experience. But either way, I'm officially an "information systems engineer".

There is GNU pascal. https://www.gnu-pascal.de/gpc/h-index.html - they page says that they do support some of the Delphi language features/extensions.

GNU pascal is a gcc frontend - so it must support a lot of platforms https://gcc.gnu.org/frontends.html

So there are probably some people who are still using Pascal, not just as part of the Delphi IDE.

It should be possible to make a web framework for GNU pascal, the executable could then run on any server.

Also there seem to be several options for web frameworks for pascal and/or delphi, interesting if people are using it for production (never used any of this personally)

https://wiki.freepascal.org/Brook_Framework

https://blogs.embarcadero.com/learn-about-a-solid-and-robust...

https://fanoframework.github.io/

https://github.com/EtheaDev/kitto

it's not the mainstream, however there seems to be some action going on here.

If you are looking for actively developed open source Pascal compiler, your only choice is FPC.

Now possibly there are non-public markets where you can hire devs at crazy salaries but us not being able to find them also indicates the relative scarcity.

So overall no I don't think finding work in old-school tech will pay better or even have much better work-life balance.

Edit: I said 20+ years initially.. but that's 2003 now :( So 20+ years from 20 years ago.

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.

https://www.embarcadero.com/products/delphi/features/mobile

https://au.linkedin.com/jobs/view/application-engineer-at-ca...

https://github.com/KinesisCorporation/SmartSetApps

As far as I can tell, that device is still a component that can be purchased new: https://www.se.com/my/en/product/5500PACA/cbus-pascal-contro....

Also very strict and convenient type system, you could define an integer type weight_in_grams and the compiler would not allow you to mix it with height_in_inches, or range types, I think modern languages have nothing like that ... miss it.

The language is very similar to Pascal in syntax but actually is very modern and very powerful and productive programming environment.

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 are, because the DB engine is enforcing the right privilege level on you. It also means you don't have to think about REST, JSON, GraphQL and all the plumbing that web apps require because the app can just issue queries directly and bind the results straight into UI controls. This is one reason why Delphi programmers tend to feel their environment is highly productive.

It had quite a lot of downsides compared to modern development. After the designer went to MS the platform entered a period of decline. The language was good for its time but fell behind due to lack of investment, the product was fundamentally Windows only and an attempt to bring it to Linux (Kylix) was a resource-sucking disaster. Borland renamed themselves to Inprise which everyone hated, and spent lots of time and money on esoteric enterprise features like CORBA. Meanwhile, like Windows, they largely ignored the question of internet distribution meaning that they started to be left behind as the web took off (which elegantly solved the distribution problem, at the cost of regressing in virtually every other department). Borland tried to bring Delphi to web development but without the VCL and GUI stack it lost a lot of the justification for its existence, especially as Delphi's natural domain of business apps really benefited from garbage collection which Delphi didn't have.

They originally licensed their compiler to Embarcadero back in the day.

They’ve modernised the language a lot.

RO also still make and support various components and tooling for Delphi.

I ‘grew up’ on Delphi but somehow ended up in .NET land eventually and now mostly do that and/or React but I do miss it from time to time.

The real problem of delphi/powerbuilder is not the tools, but not easy to find new developer for program maintenance and development. beside delphi, I am also curious "Are people still using Powerbuilder?".

https://delphi.fandom.com/wiki/Good_Quality_Applications_Bui...

https://lazarusccr.github.io/apps/

Jörg's AoC 2022 solutions in Pascal for CP/M running on a Spectrum Next with nice ASCII animations:

https://www.youtube.com/watch?v=eg7r_6IrWmo&list=PLcjDDXgGeS...

Source code: https://github.com/pleumann/aoc22

https://lemonspawn.com/turbo-rascal-syntax-error-expected-bu...

https://github.com/leuat/TRSE

https://entwickler-konferenz.de/de/

This Belgian company uses it for robot automation in life science.

https://www.lab-services.nl/en/home

Delphi/Object Pascal never went away, but rather it was targeted by various competitors in arguably their misinformation campaigns against it, in attempts to sweep it out of the way. Pascal/Object Pascal was going up against languages like C, C++, C#, etc... Languages that were promoted by powerful American companies like AT&T and Microsoft (to name a few). Even calling Pascal a "dead language", is indicative of how relatively successful the negative media propaganda was and is.

Pascal transformed into Object Pascal, but unlike say C's relationship to C++, Pascal and Object Pascal is much more closely aligned. This is reflected in how Object Pascal can be written, and with its most popular compilers (Free Pascal and Delphi). Outside of the USA, Borland and then Embarcadero has continually maintained a significant presence in many school systems. So while various Americans might have been tricked into thinking the language died off (especially with odd websites continually claiming its dead), others around the world have been introduced to Delphi, Turbo Pascal, Free Pascal/Lazarus, or PascalABC as their first programming language. The ton of Pascal/Object Pascal books that were written, and some new ones still coming out, also makes it much easier to teach.

So, what is happening, is that various people are rediscovering Object Pascal and are surprised it's still a significantly used language. Sometimes, people only just realizing that Delphi (the compiler/IDE), is using a dialect of Object Pascal. The TIOBE Index has been showing Object Pascal hovering around the #15 rank for years. Meaning Object Pascal, is just as alive or successful as notables like Go, Swift, Ruby, Rust, Lua, etc... Another element about this, is thinking that if a language is not in the top 5, then it doesn't really exist or has failed. That's also not how things work nor realistic thinking. There are thousands of languages, so making it even to the top 50, is both a struggle and an accomplishment by itself. Object Pascal, has stayed near the top for a long while, thus demonstrating its an all time success and great.

Borland produced excellent development tooling in its time. Turbo Pascal was a classic.

[0] https://minesweepergame.com/download/game.php?id=147

(Not mine at all, I'm just a loving player)

*[0] https://store.steampowered.com/app/824600/HROT/

I wrote a 3d engine.

I believe free Pascal has network and API libraries available.

Interestin.

Amazingly Embarcadero still sells and markets it!

Last updated last week

[0] https://www.rosseaux.net/