-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
Why did Wirth's languages never see widespread adoption besides Pascal?
Even Pascal is not used much nowadays outside of Delphi and Lazarus. I
tried Pascal myself and I found it to be a nice language structurally, but
I also found it to be missing basic features that relate to writing the
language itself (example: not being able to insert newlines into strings
like you would do in C via '\n').
I also don't like how much "modern" Pascal is centered around just 2
compilers: FreePascal and Delphi. If we take a look at C, there's a huge selection of C compilers out there, and if a C compiler is compliant with the C standard, then it can do (almost) everything any other C compiler...
Apr 25 · 2 weeks ago
cont... can. This isn't the case with Pascal, as FreePascal and Delphi have to
define QUITE a bit of extensions on their own, without regards to other
Pascal compilers. Speaking of which, there aren't even many Pascal
compilers that target modern machines (correct me if I'm wrong on this
one).
I later found that Wirth's later languages were made to improve upon
Pascal, namely modula-2 and -3. The thing about these languages is that
they're so much less popular than Pascal, despite apparently being better
than it.
I heard of Oberon, which is somewhat more popular than the Modulas
(correct me if I'm wrong) but even that is barely supported.
cont... So, the question is, why did Wirth's "better Pascals" never take off? I
honestly think Pascal as a language is sweet in its structure and has alot
of potential if a "modern" version of Pascal was to be made (I don't
consider Object Pascal to be one such "modern" version, as its base IS
Pascal).
This post is mainly intended as a way to spark discussion about the state
of "Wirthian" languages, of which Pascal is the most widely used one. To
end the post I have a few questions:
1. Do you think Pascal is structurally sound, or even GOOD? For what it
tries to do, I indeed think so. As with any language, you have little
flaws here and there. The biggest flaw with Pascal's structure that I can
think of off the top of my head is how variables that need to be defined
in the main program execution are declared GLOBALLY rather than INSIDE the
main program execution's block. (i.e. inside the "begin ... end." block,
with a period.)
2. Is Pascal actually missing any vital features? I think compared to
other languages, Pascal's standard library is underwhelming. This is not
to sound vague, but that's the best I could describe it right now.
3. Do you use Pascal? And, do you like it?
4. Do you use the later Wirthian languages (the Modulas, Oberon)? How is
the support for these languages? Do you think they're BETTER than Pascal?
Sorry for the long post, I'm not sure why bubble won't let me post anything over a really small limit of characters.
>Why did Wirth's languages never see widespread adoption besides Pascal?
because wirth was a scientist and teacher. he was not concerned with market things. and he cared about beautiful design.
for example he didn't care about backward compatibility. when he designed modula, the pascal to modula translator was also written. because he consdered pascal to be old and unnecessary language when there is much better modula-2.
same with oberon, he lost interest in modula, once oberon development started.
he even lost his own very beautifully written modula-2 compiler, and it was luckily later found on someon's lilith workstation. but we don't know if that was the latest version, maybe wirth had the latest additions.
>I also found it to be missing basic features that relate to writing the language itself (example: not being able to insert newlines into strings
no.
program ins; var str: string; begin str := 'abcdefg'; str[3] := #10; writeln(str); end.
compile this and run:
$ ./ins ab defg
>how much "modern" Pascal is centered around just 2
compilers: FreePascal and Delphi. If we take a look at C, there's a huge selection of C compilers out there, and if a C compiler is compliant with the C standard, then it can do (almost) everything any other C compiler...
no.
linus torvalds had a rant many times about how much he would lke to get rid of gcc, but he cannot because they use gcc extensions, and there's no other c compiler they can switch to.
then years later clang emerged by the money of apple.
but most of c code today uses gcc or other extensions and will not compile with iso or ansi or c99 or other c compiler without compiler extensions.
also, yes. pascal is not used as much as c.
so if you're a hardware maker, if you produce microcontrollers, you are motivated to also sell or suggest your c compiler for your hardware.
or you have insentives to support/improve gcc support of your hardware.
since everything around is c, you have no reason to spend money for pascal compiler. pascal is comparable, sometimes much better, sometimes much worse for some tasks, but comparable. but it doesn't matter.
so maybe the proper question isn't why pascal is not used, but why c is used?
well, it just happened. many things happen. c happened to be in the 'right' place in the 'right' time.
if some things were different, maybe pascal would be today's c.
macos classical and significant part of its software was written with apple pascal. if jobs wasn't kicked out of the company, and then didn't use open source c compilers to create objective c for graphical interfaces, and then if apple didn't buy jobs with nextstep back, then maybe macos would continue the other way. but it became unix, and unix is c.
also, the world was getting computers from usa.
and those computers were coming with own software.
so whatever was used by whatever reasons in usa would dominate the world.
and then there is power of inertia.
if you already invested in c code, then you continue.
that's the snowball effect. nobody is able to rewrite such amount of c code. mozilla tried to rewrite firefox engine in rust. they gave up.
while android was supposed only to run java code, nothing native. but that would mean no good browser. google cannot compile chrome for android then. so google decided to allow ndk and native code. because who can write so much code again? nobody, even google cannot.
more on fpc and delphi.
well, turbo pascal and later delphi were to some extent a successful commercial products.
because of that they gained popularity and lots of code was written with those dialects of pascal.
so it became de facto standard. these dialects are different from iso pascal, where bunch of language nerds were designing another pascal like language.
so most of the people 'speak' that dialect. that's why you want to support that dialect.
and there's not much market for something more than fpc. if there was demand, there would be supply.
maybe it's even good. maybe if oberon or modula-3 was popular, it would become something like modern pascal? i would not love it as much.
more on backward compatibility.
it's not good when you want to design a clean language.
so python3 is not compatible with python2.
but they still have to support python2.
and c++ aimed (but not accomplished completely that aim) to be compatible with c. and thus all the problems of c++. well most of them?
wirth cared about design, and he didn't care if existing pascal users will like or dislike the newer language. he wanted to create something better.
> is how variables that need to be defined in the main program execution are declared GLOBALLY rather than INSIDE the main program execution's block.
first of all, it's not pascal thing, it's a delphi thing.
i use pascal most of the time by writing in vim and debugging with gdb/ddd.
lazarus project decided to be compatible to some extent with delphi and use same approaches, again to some extent.
and i remember there was a long thread on fpc mailing list and eventually they decided that both global and local should work. and they do.
you don't have to declare some things globally, it's just how lazarus behaves by default. but freepascal is not equal to lazarus.
and nothing prevents you from writing even with lazarus in other way.
by the way, freepascal is not always compatible with delphi.
some things delphi borrowed from fpc. and sometimes fpc refused to adopt (after discussion) things that delphi adopted, let's say in delphi you can declare a variable everywhere outside of var section, like in c, but in freepascal that is intentionally unsupported.
do i use pascal?
yes, and i do use fpc. sometimes delphi.
i use delphi community edition to write once and build also for android or ios.
i use fpc for many things, to write commandline programs, to write small things, even instead of writing bash scripts often, because bash syntax is not that readable, and if the script becomes bigger, you don't want to use bash anymore.
a couple of days ago i felt the power of fpc again, when helping someone to write a gui program which sends this and that http(s) requests, parses json response, communicates with locally running server too.
that was a pleasure to write, just in one hour. and we got native efficient, small code.
i love fpc compiler because it is not gnu pascal. it has no dependency of gcc. its runtime (unless you use threads) is independent from libc.
fpc rtl uses kernel calls, it is faster that way, they avoid glibc bugs, and glibc differences. they have their own world.
fpc compiler produces very small statically linked binaries, today about 100kb, and those binaries contain very small efficient runtime, with cow strings, and efficient memory manager, and some safety features.
statically linked c code is about 800kb and no such functionality as in pascal rtl.
while delphi achieved its portability because they have this new crossplatform library called firemonkey, and they get the opengl window from the operating system and draw all the visual components themselves. then they have themes to style them.
so that way they are able to have same code compile for ios and android. because they basically just get an opengl window and render everything inside their way.
also i think that indeed, turbo pascal dialect is very good one. andreas heilsberd did very good job designing delphi and object pascal.
and no wonder nsa report included pascal, though it has no garbage collector. but it has arc for interfaces, which is very cool.
so i think modern pascal covers whatever devs usually want from c++, but it is much better.
i would critisize it for lots of features but fpc has options to limit the syntax by this or that dialect, and also today's c++ or rust or c# grew so fat that pascal is a fit athlete compared to them.
yes, i do use oberon. i write whatever i can in oberon. often there are no libraries, so the development is slow. and often i use pascal because in oberon i need to spend too much time for the same task.
in oberon i can link to existing c code, but i don't want to do that very often. i prefer pascal code, than c code.
but i like oberon, i think oberon is exceptionally well designed. i don't use oberon-2 vmt's, and i like oberon-1 style oop. well, you don't have to do oop, you can do composition too.
it may feel limiting to many, because it even lacks enums. but there are reasons for that, wirth wanted very consistent language.
so oberon is the best for me.
and last thing. in order to be commercially successful, it does matter if you have powerful forces behind.
java had sun. now google and oracle.
c#/.net has microsoft.
rust had mozilla, and now half of the world.
go has google.
oberon had only, mostly one university.
go is what oberon would become in commercial world if it had support from the powerful corporation. but i still like oberon more than go, exactly for those reasons, oberon did not become go because there was no commercial interest. and that is good.
aaand pascal has modules! pascal units aren't dynamically loaded like oberon's modules, but still the unit has its interface, implementation and initialization sections.
the compiler is able to make sure interfaces are used correctly, fpc generates not only .o files but alse .ppu files.
on the contrary c has headers, programmers write those by hand, so the header may not correspond to the actual interface. and then u're lucky if your program crashed. maybe the function returns wrong resulh but you won't find ouh about it.
headers are also very slow tomparne. pchmprecompiled headers didn't help much. now in 2020 c++ standard they eventually introduced modules. which were in rate 70ies in modula.
Thanks for the in-depth reply.
> no.
>
> ```
> program ins;
>
> var
> str: string;
> begin
> str := 'abcdefg';
> str[3] := #10;
> writeln(str);
> end.
> ```
>
> compile this and run:
I am aware of this, but this isn't like C's '\n' because it is dependant on ASCII. This code wouldn't work as intended on a machine that doesn't use ASCII (although I know there aren't many of those nowadays).
I do agree with what you said about C needing compiler extensions, but this is a quirk of C itself, and a bad one.
Wirth's languages shouldn't need compiler extensions because they shouldn't do the bad things that C does. I did say "almost" because I am aware of how prolific some extensions are in C projects.
>more on backward compatibility.
>it's not good when you want to design a clean language.
I agree. But I don't think that Modula not being backwards compatible with
Pascal is a reason for its unpopularity. In anycase it's good that it
doesn't try to be backwards compatible.
> first of all, it's not pascal thing, it's a delphi thing.
> you don't have to declare some things globally, it's just how lazarus behaves by default. but freepascal is not
equal to lazarus.
Yeah, my fault actually.
It looks like you can infact have locals.
> yes, i do use oberon. i write whatever i can in oberon.
So what's the go-to oberon compiler nowadays? Is there a freepascal equivalent to oberon?
> and often i use pascal because in oberon i need to spend too much time for the same task.
Is it because of the lack of libraries for oberon or something about the language itself? Oberon is supposed to be a better pascal, after all.
> it may feel limiting to many, because it even lacks enums. but there are reasons for that, wirth wanted very co
nsistent language.
Does not having enums really make the language more consistent? What's the
alternative, then?
I think lacking features is not exactly elegance or simplicity. Being really powerful aswell as being simple are not mutually exclusive things.
The thing about Pascal, too, is that its standard "library" is all built in to the language. Some functions can have variadic arguements but if you wanted to have variadics for your own functions, you'd need to use a compiler extension.
Pascal isn't perfect, and I think even wirth testifies to that. That's why Modula and oberon exist.
> and last thing. in order to be commercially successful, it does matter if you have powerful forces behind.
> oberon did not become go because there was no commercial interest. and that is good.
Yes, I think rust is suffering quite a bit from all the corporate influence it's getting. It's being pushed everywhere (even into Linux!) despite all its problems.
Arguably the reason why C was so successful was because it had AT&T backing it.
Yes, a language need not be commercially successful for it to be a good language.
Yeah, C's header system is a bit of a pain. Pascal's units are so much nicer to work with in comparison.
Your reply has sparked my interest in Modula and oberon, so to end off what are the modula and oberon compilers you use? I haven't really found any "good" ones yet. For Modula I've found a gcc backend for Modula-2, but it's sub-par to say the least.
i think when wirth talks about pascal, he refers to his version, which doesn't have modules.
and i think if you want more consistent pascal like solution, that would be modula-3. btw, it's not created by wirth, but still very talented team.
and you won't have much code or library for it, as you have for pascal.
comments here from a hobbyist.
I found Pascal, here, in this subspace. I'd heard of it but never considered it. I stuck to Python because the little time I have to code I didn't want to waste learning something new.
But, I gave it a shot while I had time on a business trip and I really like it, quite especially for my little projects here in gemini. I stayed away from lazarus for a while and just used Vim but eventually tried it out and I like it.
The good and bad, for me, about Pascal is that there aren't 1 million websites that have solved every problem for me. With python I just do a search for my problem and get an answer - with free pascal I'm digging through the official documentation because I can't find a forum that has solved what I need.
I find this to be a good thing since I learn more of the language, however, the freepascal wiki, while extensive, could be better, but I'll take it.
So, for me, I use it because it's fun and it suits my use cases here in gemini.
i never liked this '\n' and printf because we pay for it with preprocessors (c requires cpp preprocessor), defines, macros, and complex compilers.
i like so much the oberon way:
Out.String(str); Out.Ln;
and yes, i/o is not in the language like in pascal.
on the other hand, pascal strings are very convenient to work with.
first of all, i want to ask you all to excuse me, i was under pressure recent days, and was only able to enter bbs at night, exhausted, and i didn't have much time and strength to write and form responses in a way i like.
let's say i dislike my 'no', if i had more strength, i would express the same some other way.
>Your reply has sparked my interest in Modula and oberon, so to end off what are the modula and oberon compilers you use? I haven't really found any "good" ones yet. For Modula I've found a gcc backend for Modula-2, but it's sub-par to say the least.
i sincerely don't know what to suggest for m2.
for m3 i know - cm3.
for oberon, i am biased. i have my project i work on since long ago.
we also have a working, though rudimentary package manager. it is able to build some projects:
in order to build
with it one needs to type:
vipack -p irc_bot -P /tmp/irc_test
it will download dependencies and build irc_bot in /tmp/irc_test.
rudimentary, poor, but it is what it is.
some people try to write in oberon:
as you have noticed voc compiles to see, it is a fork of ofront, which was inherited from op2, classical compiler from eth system.
it means it produces very readable, but c code. libc is a dependency, c compiler too. but the generated c code is safe, and there is a good runtime.
it is portable this way. if it was part of gcc, recompiling gcc takes lots of time, recompiling our compiler - 5 seconds, if compiler only.
we can use gcc, clang, tcc, msvc underneath. i used cc65 with it
in 2007-8 i have been written a x86 asm backend for the newest (back then) wirth's oberon-07 compiler. then binutils' linker was used to link the resulting executable. i wanted to develop it further and turn it to what vishap became, but there were licensing issues.
it was inspired of fpc, generated very small statically linked binaries, 0.7 kb was the minimal size. only dependent on two kernel calls: mmap and exit.
but anyway, it's not in the shape to use as voc. voc is what is practically useful.
for some time i was fan of oo2c. it is still available for downloads on sourceforge, it also translates to c, but to asm like unreadable c. it has generics though. it has very nice adt library.
no oberon compiler has lots of libraries and code available like pascal.
so in order to write that irc bot, first i made a wrapper for unix sockets, then implemented some part of irc protocol, then only the bot logic.
for vipack i had to implement base64, http protocol's part (only GET, but for both cases, when content-length is known or not), then i made a wrapper for mbedtls, then i inherited from my http class, and changed methods read, write, connect, disconnect to use tls versions.
I've enjoyed using the vishap oberon compile on occasion. Thanks for making it available! I found out about the package manager by reading this thread, and I'm quite interested!
I really found Writh's Oberon very inspirational, both the programming language and the operating system. The book "Project Oberon: Design of an Operating System and Compiler" is very impressive. I also particularly liked Oberon-2. The fact that Wirth made his later developoments in Oberon the language and the operating system and the book available on the Internet is also very inspiring. I wish they were a little more accessable, though.
I also like Modula-3, and wish it was more accessible as well.
> The good and bad, for me, about Pascal is that there aren't 1 million websites that have solved every problem for me. With python I just do a search f or my problem and get an answer
I think that's a quality of python itself, due to how popular it is. I've found that most other languages don't have this either, so it might not be a thing with pascal.
> i never liked this '\n' and printf because we pay for it with preprocessor
s (c requires cpp preprocessor), defines, macros, and complex compilers.
I never thought of it this way. But I don't know if a simple \n needs a pre-processor, though.
> for m3 i know - cm3.
Thanks, I'll check it out.
> for oberon, i am biased. i have my project i work on since long ago.
Honestly, this is really impressive. VOC looks very mature. The package manager is very cool too.
> it means it produces very readable, but c code. libc is a dependency, c compiler too. but the generated c code is safe, and there is a good runtime.
Really? How do you ensure the safety of the C code? And how is the mapping from oberon to C?
> so in order to write that irc bot, first i made a wrapper for unix sockets, then implemented some part of irc protocol, then only the bot logic.
That doesn't sound so bad. I know you usually wouldn't need to do the first two steps but after you're done, you could use the protocol implementation for other projects. They're always there.
on safety of c code: it is a generated c code. likewise writing in assembly is not safe but assembly generated from oberon or ada is safe. (:
another addition is this example: oberon arrays always have size. even if you expect in the function
VAR str: ARRAY OF CHAR
when you get str, you know the size. we pass the size as an additional argument, it is visible in c code, but hidden in oberon.
oberon compiler which produces machine code would send an oberon string which is actually a struct with one field for size. well voc also keeps arrays as structs with one field for length.
TKurtBond, on package manager, my dream is to be able to
have lots of 'ports' that can download even this or that forgotten software from this or that university website, patch it, build it and make it available. it is possible, i need to work on it, but of course everybody is invited.
vipack is designed to work under oberon os. for example its internal interfaces don't know about directories. there is a linux backend which opens the file and returns the descriptor, but nothing in main modules that knows about directories. it tells a function to retrieve lets say this json from the storage, and the storage is abstracted. so i hope i will be able to integrate it with oberon os.
-- Response ended
-- Page fetched on Fri May 10 14:17:35 2024