Making a plea :)

[MarkMLl]

BASIC had quite a following until Turbo Pascal showed up.  C was a niche language (Bell labs) until late-ish 80s when it started to get out of the Bell closet.

Remember: I was there. BASIC (including MS QuickBASIC, later MS Visual Basic) outsold Pascal (almost entirely Turbo Pascal) /at/ /least/ 5:1. C was significant from the mid-80s onwards (remember that all the Windows and then OS/2 APIs were expressed in C) and C libraries were vastly more popular that Pascal... remember that TP didn't have a "uses" clause until v4 which didn't come out until late 1987 by which C had a flying start.

Promoting Pascal in the face of C and BASIC was difficult. The C brigade would come out with arguments like "UNIX is written in C, and C is the only language you can run on it" while the BASIC brigade would come out with "show me one thing you can do with Pascal that you can't do with BASIC" (while, admittedly, not having the depth to appreciate the usefulness of things like function pointers and recursion). And this was before the days of the Internet with Alta Vista as a search engine, which gave you some chance of mustering the references to strengthen an argument in less time than the value of the sale was worth.

And if this was difficult before ANSI C started tightening up the language and later dialects of BASIC started adding control structures other than goto, it became vastly more difficult after other languages belatedly absorbed enough of Wirth's ideas from Pascal (and later Modula-2) to become halfway decent.

Now I admit that I'm pulling age there, but I'd suggest that if you want to argue against my position you could usefully look at the gross sales of MS Language Division vs Borland for the period concerned.

MarkMLl

[marcov]

In the early nineties in secondary school and at university, Turbo Pascal was everywhere. Quickbasic only occasionally.

But the Dutch university license buying foundation (SURF)  had massive site licenses (including usage of students at home) for TP/BP.

added later:
I was aware that students doing their thesis and postdoc work used Fortran and C in their numerical projects usually on Irix systems, but C on not Unix was not known to me till 1993-94 or so. I abandoned Turbo Pascal in 1994 for Modula2, only to come back (to FPC) in 97/98.

[440bx]

Remember: I was there.

You're not the only one who was there.

MS introduced QuickPascal in 1988 because it was getting _trounced_ by Borland in compiler sales.

Visual Basic, introduced in 1991 did make a dent in sales of Borland Pascal compilers but, VB was initially, at most, barely adequate to develop simple programs. 

Back in 1985, C was a "boutique" language which eventually got out of Bell Labs closet but, it was a disgrace and no one other than misguided professional programmers wanted to use it.   It wasn't until the ANSI standard that C was a halfway decent language (which is where it plateau-ed.)  But, yes, it was and is used to write O/Ss but, that doesn't mean it's used by a lot of people though, a lot of people learn it so they can claim knowing it in their resume.

[gidesa]

It's relatively recent that the FPC team became more conservative, probably because of the growing code base of the compiler and the need for maintainance with the small team.

But the 3.3.1 (trunk?) version is just here, with large improvements in anonymous, generics, RTTI, and other. What is the reason it isn't released? Maybe because developers want to deeply test on the large different platforms where FPC is avalaible? Or what else?

[marcov]

It's relatively recent that the FPC team became more conservative, probably because of the growing code base of the compiler and the need for maintainance with the small team.

But the 3.3.1 (trunk?) version is just here, with large improvements in anonymous, generics, RTTI, and other. What is the reason it isn't released? Maybe because developers want to deeply test on the large different platforms where FPC is avalaible? Or what else?

Features not finished/debugged and target support.  Also major versions often have internal changes that might not be so visible, but also need to be tested/mature.

[Warfley]

But the 3.3.1 (trunk?) version is just here, with large improvements in anonymous, generics, RTTI, and other. What is the reason it isn't released? Maybe because developers want to deeply test on the large different platforms where FPC is avalaible? Or what else?

Well, those changes are quite big and there are still a lot of issues with them. Just looking at the gitlab issue tracker, issues marked with function references are still 7 open, anonymous function 15, generics 165 (granted only like 60-70 of those are since the last FPC release). So theres still more than enough work to do

[VisualLab]

...you could usefully look at the gross sales of MS Language Division vs Borland for the period concerned.

Perhaps. But that could result not only from the features (advantages vs. disadvantages) of the product but also from the fact that the supplier (manufacturer) is the same company that supplies the OS and other programs. That is, a kind of reasoning of a large part of customers: "it's a large manufacturer, has experienced engineers, can be trusted, so I'll buy the tool from them". This is a social and economic phenomenon that has little to do with an in-depth technical analysis of the product being purchased (which does not mean that the product is bad, it can be great). In any case, people do not necessarily use common sense when purchasing certain products (some do, some do not). Moreover, if after the purchase the product is not exactly what the buyer wanted, the buyer tries to rationalize his behavior after the purchase (an attempt to rationalize the wrong decision).

[MarkMLl]

Perhaps. But that could result not only from the features (advantages vs. disadvantages) of the product but also from the fact that the supplier (manufacturer) is the same company that supplies the OS and other programs. That is, a kind of reasoning of a large part of customers: "it's a large manufacturer, has experienced engineers, can be trusted, so I'll buy the tool from them". This is a social and economic phenomenon that has little to do with an in-depth technical analysis of the product being purchased (which does not mean that the product is bad, it can be great). In any case, people do not necessarily use common sense when purchasing certain products (some do, some do not). Moreover, if after the purchase the product is not exactly what the buyer wanted, the buyer tries to rationalize his behavior after the purchase (an attempt to rationalize the wrong decision).

Indeed. But we're not considering what people /should/ /have/ been doing, but what they /were/ doing: which was mostly buying BASIC and C on account of UNIX and MS's clout, and if they wanted Pascal going for Borland's product (MS Pascal was not highly regarded, and I don't remember a single copy of QuickPascal being sold).

If we were considering what people /should/ have been doing... well they should have been buying TopSpeed Modula-2 produced by JPI (a Borland spin-off), which was available at about the same time that Turbo Pascal introduced the uses clause and offered better thought out syntax and semantics with stronger type checking even across modules.

MarkMLl

[Ștefan-Iulian Alecu]

If we were considering what people /should/ have been doing... well they should have been buying TopSpeed Modula-2 produced by JPI (a Borland spin-off), which was available at about the same time that Turbo Pascal introduced the uses clause and offered better thought out syntax and semantics with stronger type checking even across modules.

Or even better, consider Oberon and BlackBox Component Builder, but what people should've done is irrelevant. "Should've"s and "could've"s don't matter anymore, what matters is what we, as a community, can do now to promote Pascal (ideally in a non-obsessive/non-zealous way... ahem) and Lazarus and Wirth's work as a whole. Because, as it turns out, marketing is still needed, and word of mouth is effective to some degree.

[MarkMLl]

Or even better, consider Oberon and BlackBox Component Builder, but what people should've done is irrelevant. "Should've"s and "could've"s don't matter anymore, what matters is what we, as a community, can do now to promote Pascal (ideally in a non-obsessive/non-zealous way... ahem) and Lazarus and Wirth's work as a whole. Because, as it turns out, marketing is still needed, and word of mouth is effective to some degree.

Although obviously, Oberon came along so much later than TP became a "competent" compiler with unit support that that specific comparison isn't really relevant.

Apart from that, I agree. But even if patient discourse in the face of suspected trolling or hostility (and as you say, /ahem/) doesn't win any converts we should still relish the fact that the majority of Wirth's ideas have been adopted my most modern languages.

MarkMLl

[dbannon]

....what matters is what we, as a community, can do now to promote Pascal (ideally in a non-obsessive/non-zealous way... ahem) and Lazarus and Wirth's work as a whole. Because, as it turns out, marketing is still needed, and word of mouth is effective to some degree.

Yes, I agree promoting in a non-zealous way is good. Here, on this forum, it is preaching to the converted.

What might help, IMHO, is proving Pascal/FPC/ObjectPascal/Lazarus actually works by getting user applications out there in user hands (discretely labelled "another fine product of ..."). I recently spent some time trawling over github looking at the project tagged 'Pascal', lots and lots of tools, libraries and units but not very many "finished products", ready for an end user. 

I don't really care about the history, but I enjoy using FPC/Lazarus and I want it to continue.  I don't want it to change just to make it more like, eg, C++, its not C++, its Pascal.  But I do want it to be able to evolve naturally and consistently. Its not Latin !

The inline variable declaration (There Thaddy, I said it again) in a for loop is a good example, its consistent with the way a Pascal programmer thinks, its useful and would make code clearer.

But I personally believe that the slow release cycle of FPC does far more harm to FPC's image than not having inline implied variable declarations. A recent statement that only PascalDragon (bless him) writes new language features is scary. I looked through the commit history and dispute that idea but it was made and not refuted.

Davo

[BrunoK]

What might help, IMHO, is proving Pascal/FPC/ObjectPascal/Lazarus actually works by getting user applications out there in user hands (discretely labelled "another fine product of ..."). I recently spent some time trawling over github looking at the project tagged 'Pascal', lots and lots of tools, libraries and units but not very many "finished products", ready for an end user. 

I do sometimes the same thing. Lately it was about Coco/R  EBNF parser (linked to Wirth and co. works at ETHZ, probably as important as his other works on computer languages).

The cause for the non popularity of these, (at least nearly working 4 and many branched but unworked versions from turbo pascal to some 2020 Delphi version) is that of the 4 versions :

1 - http://www.tetzel.com/cocor.shtml : dating ~2000 and necessary for the conversion and use of FlashFiler 2.13 has a tiny bug that prevents generating the SQL parser. That tiny bug I corrected but I cannot publish or branch since the soft is free but the copyright is reserved. I attempted to contact the author but he didn't respond. So this one is dead.

2++ - Many versions on SourceForge  / git. Nearly working but always breaking when something a bit unexpected is submitted (runtime errors).

4 - Finally a apparently recent (nearly one-one) conversion of a CSharp Coco/R compiler from the original team to a modern version of DELPHI with acceptable licensing. BUT HERE THE PROBLEMS WITH MODERN CONSTRUCTS START :
Apart first figuring out what the software does compared to the one in 1-. Most problems were relatively easy to solve (FPC 3.2.2).
a) Easy, put $MODE DELPHI at the start of units.
b) Easy, naming of units not matching.
c) Feasible but annoying, throwing out anonymous methods and replace them with call backs.
d) Very annoying, getting rid of collections that are undocumented and UNDEBUG ABLE. But here generics (fgl) come in handy, still work, but debugable.
e) Dubious modern Delphi file/stream IO features, solvable.
f) Much more difficult, UTF-16 to UTF-8 changes (where I'm partly stuck now).
g) UNSOLVABLE. Numerous libraries that the CSharp to Delphi converter did use but many of unknown origin, thus lots of apparently interesting features cannot be evaluated. Sad.

So you end with lot of probably very useful code that is nearly working but due to developer change of interest (perfectly OK for open/free software), and use of overly modern / difficult to understand code constructs, nobody is anymore able to maintain. Those will disappear.

[Thaddy]

There are several coco/r versions that do work with links on the forum.
- one by me that predates 2006
- at least one from a later date, probably two.
So search the forum.

[BrunoK]

There are several coco/r versions that do work with links on the forum.
- one by me that predates 2006
- at least one from a later date, probably two.
So search the forum.

Link please.

[vfclists]

<snip>
1 - http://www.tetzel.com/cocor.shtml : dating ~2000 and necessary for the conversion and use of FlashFiler 2.13 has a tiny bug that prevents generating the SQL parser. That tiny bug I corrected but I cannot publish or branch since the soft is free but the copyright is reserved. I attempted to contact the author but he didn't respond. So this one is dead.
<snip>

If the source code is available free for download, then just publish the patch so others that download it can apply it locally.

You should be entirely within the law.