Ask HN: Are people still using Pascal? | Hacker News Reader

Ask HN: Are people still using Pascal?

238 pointsp5v251 comments

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?

View on HN

Our main product is in Delphi, a B2B CRUD-ish application, with a 60% market share in our niche. We're crucial to daily operations of many local branches of well-known global businesses.

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.

Ya, we're in a similar boat - lots of custom versions for customers, we're a large payer in our market too however.

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.

These stories about not being able to hire developers sound like the software industry's version of "No one wants to work [here] anymore." I have real difficulty believing that these positions are as hard to fill they are made to sound. Comments about how it takes "months before [new hires] can be productive" certainly don't help in that regard.

So, I've been active on HN for almost 12 years now - I see how developers especially young ones chase the new and shiny over the existing.

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 larger issue is, they dont see the technology work on as a good stair-step on their career progression

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

Some of my job is UI/UX design, some of it is old fashioned unix system administration and shell scripting, some of it is windows administration, I also have to understand telecommunications generally, and networking - at least well enough to design a redundant reliable network.

I get to work on the whole enchilada, not just some narrow part of it, its wonderful.

"I work in an industry with useful, important, specialized, but unsexy technology."

For some reason, I find this very appealing.

It is!

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 work for a utility. We use technologies spanning decades. We don't change our technology stacks to enhance people's EV's. For us new technology is technology that's 5 years old. We call it "leading edge" and actually have a strategy to avoid "bleeding edge." We like to use technologies that have been tested out, worked out, and shown to work and has mindshare and tooling.

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 do you do for the utility?

Me too. I’m in telco, which is an industry full of weird legacy stuff, but the notion of working in a similar silo that isn’t as full of hype appeals to me.

I couldn't say it better.

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.

Probably great job stability if you do your work well.

Basically, yes.

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

It's a job you leave largely of boredom.

Imagine two jobs that in all aspects equal except the technology used. Would you rather use one that would serve you in many other jobs and is well-regarded? Or one that's poorly regarded, limited to a few employers, or outright custom? You'd be a fool to choose the latter. So any employer that wants to make their employees do a custom blend of MUMPS, PHP, COBOL, and an in-house programming language is going to have to pay a lot more, offer really compelling benefits, or something else to compete, or it will have to lower its standards to mop up people who couldn't get more desirable jobs.

Your thought experiment is framed as if it delivers a relevant insight. It doesn't—the conclusion is neither insightful (it's pretty facile and obvious—no need to walk through anything), nor is it dispositive for the actual subject at hand.

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

Presumably they would have to offer so much more than competitors to make the job attractive that it's infeasible and reworking the application into something modern -- something even current employees are likely to be happy about anyway -- is preferable.

Of course we could probably find someone fairly easy if we would hire anyone who walked in the door and said "yay Delphi!".

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.

Just curious, do you understand why you had difficulty with remote work yourselves? Remote work seems like it should be a good fit for jobs with rare language requirements; a lot of companies had fine experiences with remote work during the lockdowns; would be worth seeing if you could root out what the problem was.

> Just curious, do you understand why you had difficulty with remote work yourselves?

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.

The loss of bandwidth with peers is the one thing I miss from being in the office.

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

Shouldn't this be the job of the product manager?

Not with custom systems. Often there will be add on feature development for a single customer.

Perhaps, and our team lead which also has the product manager hat catches many such scenarios, or we catch it during our team meetings.

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.

"after a couple of courses they were good enough to commit solid work."

This Delphi course wouldn't happen to be online would it (or in book format)?

I'm pretty sure they were, however they were not free[1] (I see the advanced one is now physical, perhaps it was online due to lockdown).

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/

How many people do you know who are fluent in Delphi?

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.

"How many people do you know who are fluent in Delphi?" reads like, "I know I'm a 4 at best, but I'm holding out for my perfect 10. Willing to compromise a bit, but definitely no lower than a 9."

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.

You already questioned 'my six months to be effective' blurb, like, its not a hiring issue, its that people see 'Delphi' and worry about their next job, the one after your company.

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.

> You already questioned 'my six months to be effective' blurb, like, its not a hiring issue, its that people see 'Delphi' and worry about their next job, the one after your company.

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

There are just not many developers who have any experience with Delphi, and often if they do, it's not recent (as in living) experience. It's a whole lot easier to find C# people, who have been writing C# every day for the last X years.

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 don't understand why this conceptually is so hard to understand

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!

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

> This much is true. However this is also not the reason why we find it difficult to hire.

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 think there are lots of laudable things to say about Delphi, but like.. developer availability is not one of those things ;-)

I thought the whole appeal of Delphi was how easy it was though. In terms of the base language, Pascal is pretty easy to pick up. Any dev worth hiring would come up to speed pretty quick.

Yeah if you've been exposed to C, C#, Java, Go or similar you should pick it up quite quickly. Unlike C++ the syntax is fairly strict so you get fairly sensible errors most of the time, or a least in a relevant location.

Of course nobody wants to work there, it's a Delphi shop. It doesn't matter how nice using Delphi might be, it's going to make getting your next job significantly more difficult.

It goes both ways. For someone who wants to work in the same place and retire, in say 10 years, could work out great. Unless the company goes bust using unsexy tech could also be a good thing

Isn't it incredible that now in 2023 web is still this bad? One of the biggest online outdoor retailer websites breaks catastrophically in fully updated Safari on Mac.. been going on for month. By catastrophically I mean you get a blank white screen with ui flashing in out. And this is normal, I find something like that regularly, stopped bothering sending bug reports years ago.

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.

I mean it can. Some Web sites are done well, some aren't. What else is new? People wrote terrible desktop applications too.

Clearly there are some good applications running on the web out there.

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.

Yeah we are, but alas this will be an answer, not a solution for you.

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.

You are not necessary wrong but this is also super depressing to me.

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.

Language is just language. It's syntax and libraries and data and algorithms.

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 have played around with at least 10 different languages.

I completely disagree.

I also don't enjoy creating systems which calculate car payment or a registration flow.

I think where people get into trouble is trying to get too custom. It's been quite a while since I did any frontend stuff, but I was able to do work I was very proud of just sticking to default Angular 1 and Bootstrap and it worked great with a team fluctuating between 1-3 people. I was even able to write some code that could use reflection to generate forms based on the view models used by REST controllers in .NET, which was neat. But overall I'd rather work with Web tools than most desktop options out there. Clearly a lot of others feel the same or stuff like Electron wouldn't exist.

> but web is so messed up we still can't have shit working reliably.

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

> But as I said, things are changing. So far we're moving the "backend" stuff to .Net/C#.

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

Later he went to develop TypeScript

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

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.

Same here. Younger developers often don't realize how unproductive they are with their JS based frameworks.

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.

To download Delphi "Community Edition" I need to provide: name, email address, country, phone number and a company name. I can also use it only if I agree with their terms (understandable-ish, every license is like this). So how can anyone expect people to use it when even if you just want to try it out you have to register somewhere.

Yeah that's another side, Delphi's never been good at entry-level stuff. Back in the days the only way to get a cheap copy was to be a student. Now there's the "Community Edition" but as you say, compared to other options it's pretty high-friction.

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

Check out FreePascal with the Lazarus IDE. It's all free and the same language essentially.

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

Community edition was 32-bit, was missing design-time and had strange constraints for compiling. It is essentially and unusable, stripped down version of Delphi that you can look at, but not use.

> B2B CRUD-ish application, with a 60% market share > we've got hundreds of [customers]

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.

While I moved away from Delphi over a decade ago, it is still reasonably popular in niche vertical market software and internal systems.

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.

This reads like a perfect description of the place I work - only difference is that we're using Smalltalk instead of Delphi. We are gradually trying to move to the web, but the reality is that the complexity of the web makes it a lot harder and slower to develop useful applications. I am not sure if this added complexity is inherent to the web, or if we just decided it should be that way.

I went from a pure Delphi shop to a web/python/c++ shop and felt the same frustration with frontend development.

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.

Thanks for the feedback. Yeah we're already using DevExpress for Delphi, so obviously their web solutions are looking very tempting.

Do you do the form layouts by hand then, or are there other tools to assist with that which work well?

We use bootstrap for layouts. I think you're going to need to write some special tooling if you want to migrate hundreds of forms to the web. Maybe load a form, generate a component tree, dump to json and then try to generate devextreme forms with that information?

That's indeed an interesting idea, will have to do some serious investigation to see if that is possible. If nothing else, it might give us a GUI editor to drive the new forms.

> CRM

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

Your company sounds like a company who just connects companies with code which does exactly what the company needs.

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.

> No product, no product strategy just pure company integration.

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.

Not a Delphi/Pascal person, but: Did you look at Lazarus and Free Pascal? Why not go with them over .NET? Since Delphi and FP are both variants of Pascal, it seems like it would be easier.

The issue isn't licensing cost, but developer productivity and being able to hire people.

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

Have you evaluated RemObjects Oxygene?

The blurb says it integrates with .NET well.

It had to adopt the .NET object model to do so. At which point you get a language that's mostly C# with Pascal-like syntax. So existing code is not necessarily portable, existing devs still have to relearn, and meanwhile you have reduced your hiring pool even further (as Oxygene is even more exotic than Delphi).

Right, this was our conclusion as well. C# is close enough to Delphi that relearning for us that are already here is fairly trivial, while really expanding the number of potential applicants.

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 got disappointed every time I tried Lazarus over Delphi. The biggest problem is: DevExpress support. Second is: I always, without exception, come across a compiler bug. My last compiler bug was about setting boolean flags at module initialization causing segfaults on armv7. It took me hours to debug.

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.

I commented in a parallel comment, but likely for the same reason we are - Developer pool for .NET is much larger.

Do you feel that the strict type-checking that Delphi/Pascal do, has helped you in any way? I have done some stuff in TypeScript but what happens in our group is that they just use ":any" which defeats the checks, if they can't get it working right away (stack is Java on one side, Angular on the JS side). Wondering if the strictness has helped you avoid errors or not.

Sounds like an organizational problem, if people are passing code reviews with any littered all over the place then your engineering culture is flawed. At least at my company, you need to have a discussion explaining why any use of the any type is justified or else it will be by default rejected.

There shouldn't be _any_ need for it except for a weird, very badly documented library.

I agree it's an organizational problem; however in Delphi/Pascal I don't think you can turn off the checks at all; so, in a sense, that's a level of type checking that is comforting...

Oh absolutely. While I every now and then feel a bit restricted by it, overall it's just such a mental relief not to have to think about those things because the compiler will catch me if I mess up.

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.

Make an eslint rule to warn when using any. They should prefer unknown over any

What should be the problem with Pascal? I have the impression that here on HN most post are about latest/hyped tools, but the "real" industry is done with boring/old fashionated tools. Your post just confirms my toughs since you are using terms like "cloud-native" which sounds like marketing boolshit to me, but such terms are common here on HN. (And I am not against HN in general, it is my favorite website, but I learned a long time ago that I should treat it with a bit of salt regarding hyped tools and technologies)

ISO Pascal from the 1980s was popular as a teaching language but it was missing many features needed for systems programming. In my high school they used Pascal for introductory programming classes on a Digital VAX-11/730. The limitations would leave many people taking a class like that who were aware of other programming languages thinking it was a toy language.

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'm somewhat bemused that your school ran the toy ISO Pascal on a VAX, because VMS came with its own version of Pascal! VAX/VMS Pascal had some cool language extensions that made it extremely suited and extremely popular for VAX/VMS Systems Programming! VAX Pascal supported native VMS strings intrinsically whereas in VAX C you had to use cumbersome string descriptors to pass strings from C to the VAX/VMS RTL or Starlet (System Libraries). Ah happy memories, I miss VAX/VMS...

It might have been the full DEC pascal but we were taught to write standard Pascal.

I was in college in the early 80s at UCSC, the VAXen were running BSD UNIX. Many of the professors hated C, and made us use UCSD Pascal, which had uh, limitations... Like fixed size arrays and oh, the free function didn't actually free anything.

> 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

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

Was "boolshit" deliberate, or just a typo? For marketing hype about computer programming languages, it seems like the perfect term. So, whether deliberate or accidental, well done!

I'd consider an accurate description of the precedence for the boolean operators. They're treated as equivalent to their arithmetic cognates (~ == not, * == and, + == or) forcing you to use excessive parentheses to separate terms. Notably, this is something that Wirthian styled Ada didn't copy.

wow, my brain autocorrected that typo when I read it. maybe because i agree with the sentiment. i thought you were the weird one until i went back to re-read it. but now that you pointed it out, i do like it and think i'm going to be adding it to my vocabulary

Reminds me of this old conversation: https://news.ycombinator.com/item?id=19877916

I mean are Google, MS, Amazon, etc. not "real" companies?

Well, if your argument was true then none would use pascal/Delphi, as they'd only use Java and PHP.

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

I think that more often than not the effort to avoid vendor lock-in isn't worth it, especially when it is very common for your "generic" wrapper around cloud services to over time bake in assumptions specific to the one platform you ever run it on and be, in effect, locked in anyway.

Is "real industry" hiring millions of Pascal programmers?

You don't have to like things, but lying to yourself about how useful they are doesn't help you.

Have you developed code cloud native?

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.

Total Commander was in Delphi, but is now compiled with FPC. This is best file manager for windows. https://www.ghisler.com/

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/

I prefer DoubleCommander: https://doublecmd.sourceforge.io/

It is a free, cross-platform alternative, also written in Pascal and (IMHO) has surpassed TotalCommander in many ways.

Indeed, it's built with Free Pascal and Lazarus.

https://github.com/doublecmd/doublecmd/wiki/Development

I recall Lazarus/FPC was tried but the project switched back to Delphi.

Total Commander is Lazarus/FPC

My programming background started with FORTRAN and WATFIV and PL/C in high school, then mostly ALGOL W in college, then back to FORTRAN and Pick BASIC business data processing in the real world. I finally went out on my own and had a small software company from 1982 until I retired in 2017. I converted our primary product from Mac Pascal to Delphi 1 for Windows in 1995, eventually upgrading to Delphi 6 in 2001, and never went beyond that version.

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.

Lazarus/FreePascal are AMAZING, so much better than all the subpar web/GUI development tools we have nowadays that require thousand of employees to have a chat app running (slack, twitter, etc) because humanity have a tendency to forget the past and reinvent the wheel every 60 years. Every young dev think they are smarter and can do better tan those who preceeded him and that's how you end up with thousand of unnecessary text editors and the mess of web dev tooling and frameworks. In fact is a business advantage I much rather keep it niche and not poisoned by hype machine. Keep thinking is a dead language.

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.

One of the most popular DAWs (digital audio workstations), FL Studio, is written in Delphi.

Oh wow I had no idea.

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

It is actually the most popular DAW at this moment.

> So, i generally considered Pascal a dead language.

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.

I learned how to first program in the early 1990s with Pascal. It never really clicked with me, despite reading multiple different beginner books, and I gave up, figured programming wasn’t for me.

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.

I taught myself C before doing Pascal at school, so it always felt like a toy educational language to me.

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.

I think saying "essentialy it's dead" is too harsh.

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

> I really regret that there is no good low-level language targeting learners as ubiquitous as Pascal was

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

I can't imagine how Rust may be the perfect low-level language for beginners given its unusual typesystem which comes with significant mental overhead. Really, I have no idea how to explain 7 year old kids how to deal with Rust. It works perfectly with Pascal though.

I don't think anyone has seriously tried to teach schoolkids to code in Rust just yet. But the way you'd do it would be to treat it as something close to a pure functional language. .clone() all the things and use Cell<> for the hopefully rare case where you really need shared mutability somewhere. (Even RefCell<> is arguably a step-up in complexity over Cell<>.)

Essentially your proposal sounds like you would have to invent some kind of convention-defined language on top of Rust.

The beauty of old Pascal was its compact feature set which is really easy to explain.

I really think rust is great, but after learning what memory management is.

Teaching rust first would just be a weird memorization of rules that you might not appreciate.

The borrow checking rules of Rust are anything but "weird". They boil down to not mixing up shared references and exclusive borrows; and, more subtly, preserving the distinction between temporary borrows and complete ownership. (I.e. only the owner can dispose an object; when borrowing, you can only give it back.) That's quite teachable, albeit using these rules in practice is not nearly as easy.

I agree, if C++ can be taught then so can Rust.

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’m sure it could be, and maybe I am wrong but I know people say rust has a rough learning curve.

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.

> Teaching rust first would just be a weird memorization of rules that you might not appreciate.

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.

There is no reason for programming pedagogy to begin with low-level languages. Python was also designed to be a teaching language, and has been unreasonably effective for that purpose. The majority of all practicing software developers won't need to get closer to the metal than Python does; that wasn't the case in the 1980s and 1990s, when hardware performance was so poor that languages like Python usually weren't viable, but it is now.

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.

> Python was also designed to be a teaching language, and has been unreasonably effective for that purpose.

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?

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

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.

It's not really about starting out close to the metal, it's about mastering a language in a comprehensive way. You can understand the overall semantics of C or PASCAL as a beginning programmer in a way that's just not true of Perl or Python. (It might be true of, say, Scheme, but the clunky paren-based syntax does not make that language intuitive to novice programmers.) Of course C and PASCAL come with the well-known pitfalls associated to memory unsafety, so that's a good reason to pick something like Rust. Rust might be described as complex, but the complexity is built upon a core of language constructs that should be comparatively easy to teach and learn.

Most practitioners do not have the mastery you're talking about over any language at all. I can't support normative advice to new entrants to the field based on a whim we might have about how current practitioners should behave; I have to look at how they're actually operating.

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.

Most practitioners can write FORTRAN in any language, i.e. they fully master FORTRAN-level language features. The interesting challenge is to push that a bit higher.

Not to detract from the real thrust of what you're trying to say, but here's a controversial opinion:

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 went looking for Hinsen posts that supported this argument and couldn't really find any. Can you be more specific?

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

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.

Note that cancelling Python is my thesis, and khinsen just provides the evidence to support it. He doesn't come out and say, "Don't use Python," but I am. From my notes, here are (some? of) the posts I had in mind:

- <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 think it's a stretch to call it "crazy", since starting with Python is one of the more common didactic strategies in programming, and the most common in scientific computing.

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.

GDScript is a bad idea as a teaching language because it's so niche, practically a DSL. You really want people's first language to have broad applicability. Yes, Python has deployment problems, but so does Godot.

JS was a DSL. (Everything you meant to communicate by this comment was already accounted for when I posted mine—hence the parenthetical disclaimer about the idea being laughable.)

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.

I love Rust, but its model and specifics would make it difficult to learn how to write code in other languages.

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

> Google's influence has managed to push Go to the forefront despite its many quirks

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.

> C++ may be a good candidate once up-to-date books have been written and compilers actually support the modern spec

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

I actually went with Pascal(FPC) for my own self-learning in college, in the 2000's, even though I had some classroom exposure to C.

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.

Modula-2 was Pascal perfected to the point where it could do everything that C could do better and safer. Unfortunately, by then it was too late.

> Essentially it's dead.

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.

Instead of looking at Tiobe ranking (which is flawed in many aspects, in my opinion), I would rather check how many new Pascal/Swift projects were created on Github last year.

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

Stackoverflow survey

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.

Ok. Under what circumstances you would start a new project in FreePascal/Delphi?

Personally I would rather use http://oberon-lang.ch than plain Pascal. But also Delphi is still used in a lot of commercial projects/products; here are some references: https://www.embarcadero.com/resources/case-studies or https://delphi.fandom.com/wiki/Good_Quality_Applications_Bui.... So there apparently are good reasons for starting new projects in Delphi; one I would consider is the ease of drawing user interfaces, which can be efficiently done even in a meeting with customers, and the blazingly fast compiler performance; so if you want quick results and a fast, native binary, then it is likely a good option.

I'd say these recent languages are C/Pascal hybrids: Go, Swift, Rust, Zig.

I'd been a Delphi dev for several years. One of the funny things I share with other devs is how Universities are sometimes maligned for teaching content that is interesting and in depth, but perhaps not applicable in the real world.

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 have a similar story to this: Learnt Delphi (Lazarus) in school, got put on a Delphi project on my first job because I was the only one to "know" the language. The application only had maybe 100k lines of code, but had been started around 1984 (in Pascal, I imagine) and had expanded ever since. I only took over because the previous (only) developer had just retired.

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.

Architecture is needed for relatively big software, but not all specialized software is this big. I once made an application that got away with being just an html document, no angular I swear, its function was to fill a medical form and print it with IE's builtin printing function.

After receiving an aggressive call from Embarcadro's license compliance team for installing Delphi "Community Edition" registered with a personal email address, on a personal laptop, to the effect that I could not use it because they somehow managed to connect me with [Employer] which also has Embarcadero commercial licenses killed that experiment really quick. This was in mid-2022.

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.

I use FreePascal/Lazarus and Delphi for my desktop products. Delphi is expensive but since I am very old client I get away with discount for my pro version upgrades.

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.

We almost exclusively use Lazarus/FPC at work. Most of our software is PC applications for controlling / communicating with industrial machinery (CIJ printers, cable cutters, ..), so we don't need the latest & greatest stuff.. I'll be glad for the day when I never have to fiddle around with RS232/485 again..

You can actually use WebUSB for it these days ...

I worked with Pascal for 10 years, through the majority of the 2010s. I think my biggest complaint about the language was the ecosystem. Units for modern protocols that would easily available in other languages, including C and C++, were hard to come by with Pascal/Object Pascal. And most of those that exists were often incomplete, thus requiring additional modification to make workable.

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.

One of my favorite tool ever, the first thing I install in my dev env is HeidiSQL (https://www.heidisql.com/) It is made using Delphi

I have tried all sorts of Electron, Java and Web Postgres clients but HeidiSQL, despite limited Postgres support, is just way too usable in comparison. Maybe it speaks for the datatable implementation of Delphi but I’m not sure.

It may just be the raw performance. Delphi VCL programs are very fast, because they’re running native non-interpreted right on top of the base windows api.

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.

HeidiSQL runs great under Wine, too, fwiw.

One new use case for Pascal is asking for algorithms from ChatGPT.

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.

Turkish Ministry of Education has chosen Embarcadero's Delphi few years ago for students in technical schools.

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

An extended fork of FREE!ship[0] (abandoned since 2007), FREE!ship Plus[1] was ported from Delphi to Lazarus/FPC & Qt since 2015 and actively maintained till October 2020.[2,3]

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

I write a wee bit of custom (GUI/desktop) software, both for personal use and for use at my employer, using FreePascal/Lazarus. Despite the somewhat clunky syntax - I have more of a UNIX/Shell/C and Python background - I feel very productive with it. I've come to consider knowing to use it (in the proper context and when it's the right tool/language) a hidden superpower ;)

Afaik, schoolchildren in Ukraine still use to learn programming in late school years with Pascal.

Tunisia as well, we learned basic algorithms using Turbo Pascal

Echoing the same from Russia circa 2006, had the first "informatics" (aka intro to CS) class in 6th grade taught in Turbo Pascal. Sadly, learned almost nothing in that class, as the teacher had about as much understanding and interest in the material as the students (aka near none).

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.

I was also very disappointed to learn that my teachers didn't care for or wanted to talk about Python, Java or anything that wasn't in the curriculum. They didn't have that "spark" that I found again in university.

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.

In Russia as well.

and Moldova

TransportForLondon are currently looking for Delphi developers...

That's interesting. Must be hard to hire for nowadays. Then again, my friend says at least one government is still using COBOL!

I have a coworker who, when he got out of school in the 90s, got hired to write COBOL. There's a ton of COBOL out there, and why not? As much as "waterfall" is a fiction, high-spec, super-detailed-spec projects actually do have some advantages as they are usually well thought out. That is where COBOL played, and why those apps have run since the 70s.

Sometimes the entire specification really does exist before you start. Certain kinds of software applications have not had substantive new functionality in decades, so everyone knows what a complete implementation of it looks like.

Alternately, they change slowly, and they have to be right.

It probably was hard to hire in the mid 2000s. I applied for a job as fraud/engineer/technical investigator and didn't get it. The rejection phone call was we noticed you have "Pascal" on your resume, can you please come and help us out to document and extend a Delphi application for the same pay, we have created a job for you? I did.

COBOL will outlive all of us.

Where is the link?

https://www.linkedin.com/jobs/view/senior-application-engine...

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

Kind of trapped in a large project. Started in Turbo Pascal in 1994, ported to Delphi, and we're still working on it. Maybe will finally have to port it to something else if WASM support is not added soon. I like the language because it's readable, yet as powerful and close to the metal as C++. Not so happy with the pricing model though.

... Use Lazarus and Free Pascal. The are compatible with Delphi and both free and open source.

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.

REMObjects has a very modern Pascal dialect named Oxygene. https://www.remobjects.com/elements/oxygene/

My understanding is Pascal had an large influence in Ada, which is still used and has some interesting features. I've never really done either, but i keep meaning to.

My school used Ada to teach programming before switching to Java which was the new thing. At that time, it was a nice alternative to C/C++ for learning. Overall, it's quite a simple language. Type safe, good module system, generics... Although I don't know if there's much to learn from Ada nowadays. Also, I have no idea what the tooling is like nowadays: IDE support, package management, linters and so on...

I wouldn't exactly call Ada simple, at least not if we're talking about the entire language including stuff like concurrency primitives and OOP. A Pascal-like subset could be derived, though.

I believe the Miniatur Wunderland in Hamburg uses Delphi to automate their 1000s of model trains and hundreds of thousands of lights.

I wanted to say this too: https://www.embarcadero.com/case-study/miniatur-wunderland-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

It's interesting. In an alternate universe Pascal becomes the system programming language of choice.

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

Popular ECAD tool Altium Designer was written in Delphi originally, but I think they moved to C# a few years ago.

The current version (Altium 23) is a mix of Delphi and .NET (I guess C# but couldn't quickly find evidence). I don't have time to try to exactly figure out what's used for what, but a quick test shows that the main executable and dozens of DLLs of the latest Altium version are compiled with Delphi 30.

I'm both amused and saddened. I still occasionally run into Fortran, Perl, Pascal you name it. I do more work in Golang, C++ or Scala these days, but I am always reminded that at once time, Pascal and C ruled. What is sad is that the language of the day group has declared the Queen dead but she's still quite alive -- older, but alive. This is programming folks -- we are programmers. We write in the language that is asked of us. We can't know every language, but flexibility matters -- both in languages and us. Sure Rust is hot right now, but I remember when that was Scala. Remember when D was going to replace C++? Learn what you can in as many places as you can.

Well, there's this posted by Embarcadero just today:

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 think/know Pascal is still being taught at a lot of schools in Europe. My guess is that in small villages/cities/suburbs - the only people who can teach programming concepts and principles go way back as the new generation has moved on.

The PortableApps.com Platform's menu is written in Delphi. I'm the only one actively working on it at present. I've been debating transitioning it to Lazarus but have not had the time to test that out in a while.

Pascal kinda lives on in Oracle's PLSQL and in Postgres.

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.

inno installer script too

I moved from Turbo Pascal and Delphi to FreePascal and Lazarus. I write business application software; mostly inventory and sales stuff.

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.

Reminds me of a few things: Kernighan and Plauger's Software Tools in Pascal, Lazarus Pascal, and Embarcadero's Delphi, which they say is "Modern Object Pascal."

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

I have written several GUI apps and a virtual machine interpreter using FPC/Lazarus. It is great for cross platform GUIs and it compiles to standalone native code unlike C# (for a long time, before native AOT, which is still in development for Winforms). In my experience library dependencies are also more manageable, likely out of necessity since there's less temptation to just depend on off-the-shelf popular libraries which happens more often with C/C++. The Lazarus IDE has a builtin package manager for additional libraries and if you find what you need there, it will work smoothly. Unlike C/C++ it is also nice to have "interface" and "implementation" on the same file, making the project less cluttered. There are differences to learn, but that it is to be expected from a non C-family language.

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.

I won't be surprised if Russian schools still teach Turbo Pascal on computer science classes.

Yeah, it seems to still be the case. This post ended up being longer than I intended, but I figure it might be interesting to anyone curious about curriculum in other countries.

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.

Interesting how your higher education experience is different from mine. I went to ITMO (in St Petersburg) after graduating from school in 2010. The bachelor's/master's thing was new then and not all universities adopted it yet, our year was the last when they still did "specialists". My tuition was paid by the government. I passed university's own challenge thing to bypass the standard requirement of a rather high "unified government exam" (ЕГЭ) result.

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

I think they've graduated to python now.

Still plenty of Pascal in schools, especially outside of Moscow and St Petersburg. And new implementations specifically for this purpose, most notably https://pascalabc.net/

TeX82 is written in Pascal. I study it a lot because Knuth wrote it but other than that I have not really touched it. It is a fairly nice language though. Albeit dated.

We create software for designers in Delphi. Building a project of an apartment or house in 3D, with its own excellent render. More than 15 years on the market. We have our own server cluster for cloud rendering. And many other services. We also create mobile applications for our clients. For example, an application for viewing panoramas and ready-made projects for large shopping centers (they give tablets to customers there).

>So, i generally considered Pascal a dead language.

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.

Sadly GNU Pascal has been stagnant for many years. Probably a decade?

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

https://hedgewars.org/ has a game engine is written in Pascal, and it rocks!

The people who still use Pascal make so much money using Pascal that this question is literally above all of our paygrades.

True of most older languages that have fallen out of favor.

This is a mostly inaccurate trope from every time I've gone looking. If you look at the median and spread of salaries for Cobol developers or mainframes or Fortran or whatnot, it is way below the medians and spread for salaries of frontend and backend developers.

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.

And it's not obscure systems powering typewriters in a dimly lit basement! We're talking banks, grocery stores, warehouses. Anything that was made 40+ years ago and was never re-engineered either because they couldn't or wouldn't. The price to upgrade is higher than the price to maintain so why bother? Not everyone cares about the latest trends.

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

Delphi is the best developer tool out there for delivery of functionality to end users.

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.

If you're ok with limiting to (mostly local) scopes, it's fairly easy to write a general purpose mark/release then sugar it up with macros in FPC/Lazarus.

Can you elaborate on this some more or point to a link with more info about this?

You can use Delphi to build mobile apps, which blows my mind. Must be a Codename One sort of enterprisy cross-platform solution.

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

I know of a manufacturer of industrial equipment (quality control and process optimization on the factory floor) whos software is written in Delphi. They don't need any web interfaces, and if you want a WYSIG editor for GUI applications (in a language that can easily talk to hardware) it's one of the best options.

SigmaNest is written in Delphi (TurboPascal? I'm just a welder) as far as I'm aware:

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

Kinesis keyboards config tools are written in Pascal using Lazarus IDE - I haven't tried compiling it myself but they run just fine on macOS and Wine on Linux

https://github.com/KinesisCorporation/SmartSetApps

One of the major vendors of a certain software my industry uses has their product in Delphi. I'd say they have 40% market share and a pretty cool product. It was one of the first in my industry to have advanced GUI functionality, but it's starting to look a bit dated unfortunately.

It is also important to remember, languages are tools, not religions. I did a lot of Fortran work for scientific work, Pascal for desktop apps of the day, and C becuase, like today, there's very little hardware C can't get access to. That's the point. We use each language for what it's really good at. We keep the old langauges around because, to be honest, can you swear changing those Fortran libraries will work without breaking something -- who can you check with? The author is probably retired, or dead. Often old languages exist because, like mainframes, the code works and no one dares to change it.

A short time ago I was brought into a project with the scope to implement custom building automation (blinds that would track solar zenith) via a C-Bus Pascal Controller. That particular device was not my area of expertise at all, but was a nice trip back to my childhood language familiarity.

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

As I remember, Pascal was nicer than C, because it allowed to edit, compile and run the application all in memory, while with C, you had to go through all those C0, C1, (C2?), lib and link stages, all requiring hard disk activity, very slow. Also very nice total recursivity, like functions within functions, which only recently came to C#.

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.

I haven't worked professionally with it for about 25 years, honestly. I worked at a shop making grading software for teachers. The Windows side was Delphi and the Mac side was Think Pascal. Their tooling for the Mac was barely usable at that time. I don't even know if Think Pascal was still being sold then. (This was circa 1996.) The company is still around, but I did not leave on good terms (nobody ever did), so I don't know what they're using today. Obviously not Think Pascal!

Not exactly Pascal but I write AL languaeg all day every day for Microsoft Dynamics 365 Business Central ERP system: https://learn.microsoft.com/en-us/dynamics365/business-centr...

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

I have very little understanding of how Pascal and Delphi are designed, or what they're good for. Any resources for learning about these languages, for someone who was born after their primetime?

I started learning Pascal (using Turbo Pascal 7) in ca 2003-2004, then learnt Delphi to write Windows desktop apps with MySQL. Probably pretty advanced for a high schoolers at that time.

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.

Not sure if there are many now, it was always a commercial platform. Here's the gist based on what I remember. I wrote a bunch of Delphi apps in the 90s and actually my first open source project was called the Pythian Project which despite the name was an effort to create a 3D MMORPG in Delphi.

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.

Inno Setup uses Pascal for scripted installations and is rather popular.

RemObjects is still making and releasing a pascal compiler (https://www.remobjects.com/elements/) that’s now part of a suite of language support.

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.

Actually for CURD desktop application, delphi and powerbuilder is much productive than other dev tool. We still using powerbuilder and delphi applications, stable and efficient, which not easy to be replaced shortly.

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

We in Wizory Enterprises make all control software for tablets written in old Borland Delphi5. It makes ultra small and fast portable applications working well in all versions of windows and easily connects to controlled hardware via LAN TCP sockets or USB communication...

https://wiki.freepascal.org/Projects_using_Free_Pascal

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

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

We still use Object Pascal (in the freeware Lazarus IDE) for dev utilities. Mostly they're native desktop apps, but some interface with cloud services.

Does Advent of Code count?

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

Turbo Rascal Syntax Error -TRSE is a pascal like which is meant for games and demos on 8 bit hardware ( generally ) .

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

https://github.com/leuat/TRSE

Yes, Delphi has some following in Germany, with presence on programming magazines and an yearly conference.

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

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

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

> So, i generally considered Pascal a dead language.

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.

Pascal and Delphi are languages that I have a lot of respect for.

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

I did Macintosh application programming [0] in Pascal in the late '80s. I was forever struggling with strings; every time I wanted a string I found I had an array of characters, or vice versa.

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

My brother has a couple of small apps he wrote in Deplhi for his company; is is not a software developer, but an infrastructure manager, but he still plays with Delphi after ~ 25 years since he learned Pascal and moved ~2002 to Delphi. His apps are small web apps with a few dozen users and a SQL database, nothing scalable or cloud native.

IEC Structured Text (ST) is very similar to Pascal (you might say it's strongly inspired by it) and is available on many PLCs as a more powerful alternative to the non-programmer-friendly graphical programming systems like Ladder Logic and Function Block Diagram. A fair bit of industrial automation is done using ST.

HROT[0] is a retro shooter using a custom engine written in Pascal.

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

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

Honestly I think the "interface" vs "implementation" part of a Pascal file is a genius idea.

The least terrible of the IEC Programmable Logic Controller languages is effectively a pascal.

I grew up in the 90s using Pascal, and I loved it.

I wrote a 3d engine.

I believe free Pascal has network and API libraries available.

Interestin.

I have seen Delphi in some very established industries where there was never a concern about it for a very long time (and now there is a lot of nervousness about what to do about it).

Amazingly Embarcadero still sells and markets it!

I recently found this game engine is pascal/delphi: https://github.com/Cooler2/ApusGameEngine

Last updated last week

I still pull out his games and play them sometime. Love Astral Tournament.

BeRo is a demoscener who's still writing a ton of stuff in Pascal, IIRC. [0]

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

I realized that I am old now....

For those of you who work with Delphi, does your application use VCL or FMX?

It's quite popular in countries of the former USSR.

Reminds me of my Turbo Pascal days in the 80s.

desktop simulation software...delphi anf directX

wow this whole thread -- so many dinosaurs.

Have you ever programmed in Pascal or Delphi? You'd not know if you never experienced its productivity boost. ;) I'm a T-Rex btw

Reply on news.ycombinator.com