Can FPC/Lazarus save the World?

[gidesa]

I agree with your point about Java, and Borland had their finger in that pie as well (although when one scratched the surface, a lot of Java's cross-platform stuff was an illusion unless one was in a position to write ones own JVM).

A note: I was thinking to the language that replaced the mainframe Cobol, PL/1, and similar, often migrating to Unix servers.
Maybe I am wrong, but Pascal, and Borland, never was largely present in mainframe world. That is, one of the richest IT development world.

[gidesa]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

[VisualLab]

Pascal occupies a higher position in the "sucks" TIOBE index  (11th place) than PYPL (29th place), or IEEE Spectrum (45th place).

But, besides bad opinions on Tiobe (I have that), Ob.Pas. has  only 1,52 percent. Compare to sum of first 5 languages: 49,7 percent.
That is, apart the first 5-6 languages, the rest is residual, because all other 45 languages (recent and legacy) in total reach only 50 percent!
So it's a pity, but also Tiobe index is not very good for Pascal.

This summary is thought-provoking. Therefore, this thought occurred to me:

If the popularity of programming languages ​​is measured by the number of various entries on the Internet about them, how does this compare to actual use in practice? Could it be that for language X from the top¹ of the list, the level of popularity is underestimated or, conversely, overestimated? If so, how much?

Because entries on the Internet can be different: praising, critical, indifferent. They may include: project descriptions, library documentation, tool documentation, examples, tutorials, questions and answers about code errors, blogs, etc. How closely does this reflect real language usage? Could it be that solutions that are more annoying² in everyday use are described more often? Someone recommended something ("after all, everyone uses it") and new users got stuck in it and "are waist-deep in the swamp", not knowing how to get out? And then they write on the forum: "help, it doesn't work for me"?

To sum up: could it be a self-reinforcing mechanism that the more someone writes about something, the more people use it and generate information noise on the Internet?

---
1) Some initial items.
2) I.e. not obvious, with traps, with oddities, overcomplicated, with a confusing record, with historical events.

[MarkMLl]

If you let the designtime only tools handle everything yes. But as said, most big applications don't, even if only they want to have more control over transactions.  IMHO it is unfair to compare  Delphi/Lazarus level 0 (all design time, without much errorhandling) to fully blown business apps without context.

See https://github.com/MarkMLl/testdb It's very easy to find a situation where the local controls respond, but you're screwed when you try a commit because the server has lost its state. The high-availability community appears to agree that this is a problem: connection interruption (including failover etc.) will rollback any transactions and there's no easy way for the client to find that's happened, at least if you limit yourself to row-at-a-time manipulation you've got some chance of recovery.

That is a dud too. Any one who took some economy classes knows that the classic market economy has certain border conditions (like many producers and many consumers which can't influence price on their own). Only in those conditions you really get "market" conditions. In privatisation scenarios those rarely hold true.

Basically it is just washing their hands so they can blame the "market" if it fails, while making sure their cronies get a updated salary "according to market standards" for as long as it lasts.

Tell the Tories, not me.

MarkMLl

[MarkMLl]

A note: I was thinking to the language that replaced the mainframe Cobol, PL/1, and similar, often migrating to Unix servers.
Maybe I am wrong, but Pascal, and Borland, never was largely present in mainframe world. That is, one of the richest IT development world.

I think that Borland- and for that matter MS- assumed that if they made the PC and PC-based-server environments attractive enough they could offload enough work from mainframes (which of course these days pretty much mean IBM) to make them irrelevant. And Java had the advantage that it would run on Sun systems (which could get pretty big) and IBM jumped on board fairly promptly.

I've got a great deal of doubt about "let's stick everything in The Cloud and assume that customer accounts will reconcile themselves eventually", which seems to have replaced the strict atomic integrity requirements of a few years ago. I've also got a vague recollection of MS attempting to challenge mainframe dominance during to 90s or 00s: if I've got it right they sold Barclays in the UK a distributed banking system based on Windows NT and it did not go well.

Over the years, I've intermittently been involved with various generations of "smart terminal", of which browsers as a "universal desktop" are but the most recent example. It's all very well having that sort of thing to dress up the UI, check consistency of queries/commands before they're sent upstream, and (these days) implement SSL/TLS etc., but at some point there's an unavoidable requirement for an integrated system to enforce atomic operations.

Which takes me to another thing: (IBM) mainframes got clustering working way before anybody else started thinking about it, which made failover etc. far easier. Linux (as the dominant unix) is still far behind, and PostgreSQL (as arguably the leading "free" enterprise-grade database server) has limited inherent replication etc. capabilities until you start strapping on extensions... I suspect IBM and Oracle are far ahead here.

MarkMLl

[marcov]

See https://github.com/MarkMLl/testdb It's very easy to find a situation where the local controls respond, but you're screwed when you try a commit because the server has lost its state. The high-availability community appears to agree that this is a problem: connection interruption (including failover etc.) will rollback any transactions and there's no easy way for the client to find that's happened, at least if you limit yourself to row-at-a-time manipulation you've got some chance of recovery.

This is nearly any scenario. A timeout can take a long time, and basically anything that you add on top of outstanding requests gets dodgy. You can do something about that (having a cache of operations and reroll them next connection, regardless of the connection method), but that comes at a complexity price. (and rerunning transactions at a later date might overwrite newer stuff)

I've worked in large companies, and their apps didn't even attempt to fix this. Restart or reconnect or redo.

At least my simple homemade CRM logs any SQL transaction (simple ZEOS monitor component), and that means in case the effort was great (e.g. a really long comment for a ticket), you can retrieve it.

[MarkMLl]

To sum up: could it be a self-reinforcing mechanism that the more someone writes about something, the more people use it and generate information noise on the Internet?

Yes, and that goes back a long way. Think about the extent to which OS/2 fell out of favour as far as journalists and "cottage industry" developers were concerned, even though is was far superior to Windows until NT came out.

However in the current case I'm not so much interested in the woeful perception of Pascal. My current question is "what do IBM, Oracle, Fujitsu et al. have which enables them to get work, that Object Pascal and Delphi/Lazarus lack if used with e.g. PostgreSQL? What other components would somebody putting together a consortium to bid for e.g. a Horizon replacement need?".

MarkMLl

[marcov]

I think that Borland- and for that matter MS- assumed that if they made the PC and PC-based-server environments attractive enough they could offload enough work from mainframes (which of course these days pretty much mean IBM) to make them irrelevant. And Java had the advantage that it would run on Sun systems (which could get pretty big) and IBM jumped on board fairly promptly.

I think the early PC centric vendors primarily wanted not to target the mainframe market, but everything else, smaller companies and drive cost down for when a mainframe is overkill.

[MarkMLl]

This is nearly any scenario. A timeout can take a long time, and basically anything that you add on top of outstanding requests gets dodgy. You can do something about that (having a cache of operations and reroll them next connection, regardless of the connection method), but that comes at a complexity price. (and rerunning transactions at a later date might overwrite newer stuff)

I've worked in large companies, and their apps didn't even attempt to fix this. Restart or reconnect or redo.

At least my simple homemade CRM logs any SQL transaction (simple ZEOS monitor component), and that means in case the effort was great (e.g. a really long comment for a ticket), you can retrieve it.

The problem is that as soon as you start piling complexity on top of a robust database you risk breaking that atomic integrity. I don't know to what extent this was Horizon's problem, or if they quite simply didn't have a robust database in the first place.

MarkMLl

[Edson]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

Don't forget my PIC Pascal (Modula-2) compiler  : https://github.com/t-edson/PicPas

[avra]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

Don't forget my PIC Pascal (Modula-2) compiler  : https://github.com/t-edson/PicPas

I've built so many projects with this one: https://www.e-lab.de/AVRco/index_en.html   

[marcov]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

For specific Microchip controllers. for the 16-bit range (that I use), you could go to

https://www.mikroe.com/mikropascal-dspicpic24

But it is geared at beginners

[VisualLab]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

Don't forget my PIC Pascal (Modula-2) compiler  : https://github.com/t-edson/PicPas

Yes, I recognize the name of the compiler from discussions on this forum (and descriptions and screenshots on your website). I have two microcontrollers: PIC16F887 and PIC18F4450, with which I have been experimenting so far on the EasyPIC board from Mikroelektronika. A few days ago I ordered a few more PIC microcontrollers in DIP packages so that they could be easily placed on the breadboard. The semester is just about to end and the holidays will begin. So I will have time to experiment with your compiler and PIC microcontrollers as well as MPLAB X IDE and the SNAP debugger. So far, I've personally found out that SNAP does not support the 2 above-mentioned integrated circuits (probably, according to Microchip, they are too old).

[VisualLab]

It wasn't quite oblivion. Anyway, I know about Turbo51 and microPascal. I don't know of any other Pascal implementations for microcontrollers.

There is also Pic Micro Pascal, http://www.pmpcomp.fr/. It's specific for Microchip microcontrollers.

For specific Microchip controllers. for the 16-bit range (that I use), you could go to

https://www.mikroe.com/mikropascal-dspicpic24

But it is geared at beginners

And also for 32-bit microcontrollers: PIC32 Microchip based on the MIPS core as well as from other manufacturers, based on ARM.

[SymbolicFrank]

The most used languages, JavaScript and C++ have a whole lot of gotchas that make it easy to shoot yourself in your foot. The popular new kid on the block, Go, seems easy at first, the gotchas are there when you want to make it more complex, or multi-platform. And while JavaScript seems ubiquitous, for a serious program Typescript is a must.

JavaScript classes are "meh" and hard to use, Go doesn't have them. And we see that in the programmers: they're streamlined to write very simple code, mostly database lookups that are translated into JSON, or the other way around. Most think classes are scary.

So, simple, dynamic procedural programs are produced. If they grow big and are in JavaScript, you're encouraged to move more of it to node.js on the server. And if you're using Go, you're basically stuck with it, because it's hard to rewrite in another programming environment and Go doesn't talk with other computer languages.

So, it boils down to:
1. Whatever is easiest to start using it (JavaScript)
2. Whatever the Big companies use
3. What we have used for at least the last decade

In contrast, Object Pascal does most things pretty well and bugs and gotchas are actually fixed. It does have some weak points, but nothing as bad as the popular ones. Which do all look like C, so that's to most programmers how a programming language should look like.

And, as said, everything else is marketing.