5 ms·

Have you ever actually tried to write code in Modula-2? Has there ever been an efficient, portable implementation of Cyclone or Popcorn? Does anyone seriously

by scythe 11y ago

Have you ever actually tried to write code in Modula-2? Has there ever been an efficient, portable implementation of Cyclone or Popcorn? Does anyone seriously consider either to be easy to implement? And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?

nickpsecurity 11y ago
"Have you ever actually tried to write code in Modula-2?" Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. Amateurs repeated did stuff like that with it and its successors like Oberon for another decade or two. How long did the first UNIX take to get written and reliable in C? "Has there ever been an efficient, portable implementation of Cyclone or Popcorn? " I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. "And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?" It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses. People using them will get hacked or loose work less. Like with all safe, systems languages that people turned down over C. Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. Why is that bad for their ability to produce robust programs? And what does that mean about C developers statistically?
- AnimalMuppet 11y ago
  Here's what's wrong with your whole line of reasoning. People wrote an OS in Modula-2? That's great. How many of them wrote an OS that people wanted to use? That's a considerably harder task, you know. It's not just that all OSes are equivalent, and the one with the most publicity or corporate support wins. In particular, I assert that Unix was considerably bigger and harder to write than those OSes written with Modula-2, in the same way that Linux quickly became much bigger than Minix. That "bigger" and "harder" isn't the result of bad technique or bad languages - it's the result of making something that actually does enough that people care to use it. Next assertion: C makes some parts easy that are hard in Modula-2. That makes it more likely that the harder parts actually get written, that is, that the OS becomes usable instead of just a toy. (True, C also makes it easier to wrote certain kinds of bugs. In practice, though, the real, usable stuff gets written in C, and not in Modula-2. Why? It's not just because everybody's too stupid to see through the existing trends and switch to a real language. It's because, after all the tradeoffs are weighed, C makes it easier to do real work, warts and all.)
  - Avshalom 11y ago
    I dunno, I sure as hell never asked for Unix. That was a decision made for me by AT&T and it's monopoly a decade before I was born. As for why "the real, usable stuff" gets written in C? Because C is the only first class programming language in the operating system. And of course 20 years ago "the real, usable stuff" was actually written in assembly because C was slow and inefficient. Or Fortran if you needed to do any math more complicated than middle school algebra.
    - AnimalMuppet 11y ago
      Well, the "decision" was actually the consent decree in the AT&T antitrust case, which said that AT&T couldn't go into the software business. (Note well that AT&T did not have any kind of a monopoly on computer operating systems - not then, and not ever.) The result, though, was that Unix became available for the cost of distribution plus porting, and it was portable. It was the easy path for a ready-for-real-work non-toy operating system on new hardware.
  - nickpsecurity 11y ago
    As with scythe, you're ignoring the greater point to focus on tactics that it makes irrelevant. C started with stuff that was literally just what would compile on an EDSAC. It wasn't good on about any metric. They couldn't even write UNIX in it. You know, software that people wanted to use. So, seeing good features of easy compilation and raw performance, they decided to invest in that language to improve its deficiencies until it could get the job done. Now, what would UNIX look like if they subsetted and streamlined a language like ALGOL68 or Modula-2 that was actually designed to get real shit done and robustly? It's programming, science, all of it. You identify the key goals. A good chunk of it was known as Burroughs stayed implementing it in their OS's. Their sales numbers indicated people wanted to use those enough they paid millions for them. ;) Once you have goals, you derive the language, tools, whatever to achieve those goals. Thompson failed to do this unless he only cared about easy compilation and raw speed at the expense of everything else. Meanwhile, Burroughs, Wirth, Hansen, the Ada people, Eiffel later... all sorts of people did come up with decent, balanced solutions. Some, like the Oberons or Component Pascal, were very efficient, easy to compile, easy to read, stopped many problems, and allowed low-level stuff where needed. Came straight from strengths of design they imitated. A form of that would be easy to pull off on a PDP as Hansen showed in an extreme way. C's problems, which contributed to UNIX Hater's Handbook and many data losses, came straight from the lack of design in its predecessors which soley existed to work on shit hardware. They tweaked that to work on other shit hardware. They wrote an OS in it. Hardware got better but language key problems remained. Whether we use it or not, we don't have to pretend those effects were necessary or good design decisions. Compare ALGOL68 or Oberon to BCPL to see which looks more thought out if you're still doubting.
- scythe 11y ago
  >Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. I take it you didn't link to the OS because it was only ever a toy, correct? If it had been useful for anything, it would be worth linking to -- otherwise, you're better off if I know less about it. https://en.wikipedia.org/wiki/Lilith_(computer) https://en.wikipedia.org/wiki/Lilith_(computer) Lilith wasn't popular because it didn't solve any problems that needed to be solved -- it was too slow to be useful as a microcomputer OS, and it wasn't designed for that anyway. Microcomputer OS's of the time were written in assembly, and assembly continued to be important until around the time of Windows 3.1. Not integrating well with assembly is an anti-feature; the fact that it would become unnecessary some 15 years later is irrelevant. C did the job that needed to be done; Modula-2 did the job that somebody thought was cool. Also, you have yet to give me a reason to believe that Lilith was somehow safer or better-designed than UNIX of the time, considering that security wasn't even really a thing in 1980. That's not to mention it's [Pascal family] just poorly designed from a usability standpoint, with the language creators doing silly things like removing "for" loops from Oberon (a decision which both Clojure and Rust eventually admitted was bad). Lilith itself was "succeeded" by an OS that was written in an entirely different language and made no attempt to be backwards compatible (but portability is a red herring amirite?). >I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. I guess it's not a big surprise then that C wasn't popular in its early years? The implementations of Cyclone and Popcorn were never even complete enough to write software on normal operating systems, much less to write UNIX. >It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses It means that, statistically, they will all have other huge, glaring weaknesses that you pretend don't exist... >Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. If you have better options, why didn't you name them? Because they're equally bad if you spend even a few minutes thinking about it? (Lemme guess: Limbo, SML, Ada)
  - nickpsecurity 11y ago
    " take it you didn't link".... "you have yet to give me"... "s a red herring amirite?" "you pretend don't exist...""why didn't you name them?" The answer to all that is that my response to you was less thorough and referenced on purpose. That's due to the trolling style of your first comment that this one matches albeit with more information. A comment more about dismissal and challenge with little informational content didn't deserve a high-information response. My observation and recommendation is here though: https://news.ycombinator.com/item?id=11448855 https://news.ycombinator.com/item?id=11448855 That is, there were specific languages in existence from PL family, Pascal tradition, ALGOL's of Burroughs, ALGOL68, and so on that balanced many attributes. A number, from safety-checks to stronger typing to interface protections, had already been proven to prevent problems or provide benefits. Thompson would've known that given MULTICS was one of systems that provided evidence of that even if it failed in other ways. He even re-introduced some problems that PL/0 prevented. Let's focus on fundamental failure, though. So, if I were him, I'd note that the consensus of builders of high-reliability systems and CompSci researchers is we need a language like ALGOL68 that balances various needs. I'd still need as much of that as possible on my crappy PDP. So, I'd subset a prior, safe language then make it compile with tight integration to the hardware due to resource constraints. Might even made similar tradeoffs they did although not in a permanent way. If safety checks wouldn't work yet, I'd turn off as many as I needed to get it to run. As hardware improved, I could turn more on. I'd keep well-written language definition and grammar as others showed to do. I might also borrow some syntax, macro's or easy parsing from LISP to make my job easier as Kay is doing and numerous Scheme teams did at the time. Keep language imperative and low-level, though. Thompson had a different idea. There was a language that had no good qualities except raw performance on crap hardware. Was opposite of its authors design intent to top it off. Thompson decided on it. Any gripes you have with Modula-2, Cyclone, Popcorn, etc apply at this point because the language, esp his B variant, wasn't so good enough for about any job. As I'm advising for safe languages, it would have to be modified to get stuff done. The first version of C was still crap to the point UNIX was mostly assembly. They added structs to get information hiding/organizing then were able to write UNIX in C. Both C and UNIX were simple enough to be portable as a side effect. Rest is history. Almost any gripe you've had against safer languages of the time I can apply to C's predecessors other than compilation difficulty. That you will dismiss them on grounds that they need modification for the job at hand, but don't do that for C, shows the bias and flaws of your arguments. I've called out everyone from McCarthy to Wirth to Thompson for stuff I thought were bad ideas. For loop removal is a good example. I didn't settle against C until years of watching people's software burn over stuff that was impossible or improbable in better designed, even lean, languages. Evidence came in even in empirical studies on real prorammers, C showed to be behind in every metric except raw performance, its history tells us why, and logically follows that they should've built on better, proven foundations. Those that did got more reliable, easy to understand, easy to maintain systems. Of course, don't just take my word for it: Thompson eventually tried to make a better UNIX with Plan 9, but more importantly a better language. He, Ritchie, and Pike all agreed every feature in their language. That language was Go: a clone of ALGOL68 and Oberon style with modern changes and updates. Took them a long time to learn the lessons of ALGOL that came years before them.
googamooga 11y ago
Kronos, the Soviet 32-bit workstation, was designed and built from hardware to all compilers, OS and miscellaneous applications by a small group of students in a couple of years. The only language they used was Modula-2. [1] https://en.wikipedia.org/wiki/Kronos_(computer) https://en.wikipedia.org/wiki/Kronos_(computer)
- nickpsecurity 11y ago
  Thanks for the link! Had no idea Russians built a Wirth-style system based on Lilith. There's almost a trend with them as they received the Oberons and especially Component Pascal better than most countries. My foray into Blackbox showed lots of Russian use. There have to be attributes of the language and tooling that appeal to Russian programmers more than others for whatever reason. I wonder what those are, both aspects of Russian style and language that appeals.
pjmlp 11y ago
IBM did. After Assembly, IBM used mostly Modula-2 and PL/M to write their mainframe OSes, e.g. OS/400, migrating the code slowly to C++ afterwards. Also OS research at DEC and Compaq was done in Modula-2+, which gave birth to Modula-3.
- nickpsecurity 11y ago
  Those mainframes and OS/400 were also very reliable and fast compared to the UNIXen. Hmm. Probably just a coincidence the C people will tell us. ;)
cmrdporcupine 11y ago
I did, as a teenager. The language was nice. The strong types did get in the way of interfacing with a lot of OS level stuff that wanted to deal in void pointers tho.
- nickpsecurity 11y ago
  My strategy for that sort of thing was wrapping all the stuff in unsafe modules that exported safe API's. Just do some basic checks as function is called then messy stuff is handled in its own little file of scary code. I was doing this in other languages way after you were dealing with Modula-2 on even older hardware. So, I'm curious as to how you and others then handled that problem? What were the tactics?
  - cmrdporcupine 11y ago
    I was too young and too distracted by the world of being young to focus on it enough back then to truly sit down and do that. By the time I got my Modula 2 compiler I was 13 or 14 years old and then high school happened and about 3 or 4 years later I had a PC running (pre 1.0) Linux, so. I never had to truly deal with it.
    - nickpsecurity 11y ago
      Oh OK. That's aight.

by scythe 11y ago

nickpsecurity 11y ago

"Have you ever actually tried to write code in Modula-2?" Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. Amateurs repeated did stuff like that with it and its successors like Oberon for another decade or two. How long did the first UNIX take to get written and reliable in C? "Has there ever been an efficient, portable implementation of Cyclone or Popcorn? " I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. "And, if you just randomly picked three examples, why are they all bad? What does that mean about the other examples, statistically?" It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses. People using them will get hacked or loose work less. Like with all safe, systems languages that people turned down over C. Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. Why is that bad for their ability to produce robust programs? And what does that mean about C developers statistically?

AnimalMuppet 11y ago
Here's what's wrong with your whole line of reasoning. People wrote an OS in Modula-2? That's great. How many of them wrote an OS that people wanted to use? That's a considerably harder task, you know. It's not just that all OSes are equivalent, and the one with the most publicity or corporate support wins. In particular, I assert that Unix was considerably bigger and harder to write than those OSes written with Modula-2, in the same way that Linux quickly became much bigger than Minix. That "bigger" and "harder" isn't the result of bad technique or bad languages - it's the result of making something that actually does enough that people care to use it. Next assertion: C makes some parts easy that are hard in Modula-2. That makes it more likely that the harder parts actually get written, that is, that the OS becomes usable instead of just a toy. (True, C also makes it easier to wrote certain kinds of bugs. In practice, though, the real, usable stuff gets written in C, and not in Modula-2. Why? It's not just because everybody's too stupid to see through the existing trends and switch to a real language. It's because, after all the tradeoffs are weighed, C makes it easier to do real work, warts and all.)
- Avshalom 11y ago
  I dunno, I sure as hell never asked for Unix. That was a decision made for me by AT&T and it's monopoly a decade before I was born. As for why "the real, usable stuff" gets written in C? Because C is the only first class programming language in the operating system. And of course 20 years ago "the real, usable stuff" was actually written in assembly because C was slow and inefficient. Or Fortran if you needed to do any math more complicated than middle school algebra.
  - AnimalMuppet 11y ago
    Well, the "decision" was actually the consent decree in the AT&T antitrust case, which said that AT&T couldn't go into the software business. (Note well that AT&T did not have any kind of a monopoly on computer operating systems - not then, and not ever.) The result, though, was that Unix became available for the cost of distribution plus porting, and it was portable. It was the easy path for a ready-for-real-work non-toy operating system on new hardware.
- nickpsecurity 11y ago
  As with scythe, you're ignoring the greater point to focus on tactics that it makes irrelevant. C started with stuff that was literally just what would compile on an EDSAC. It wasn't good on about any metric. They couldn't even write UNIX in it. You know, software that people wanted to use. So, seeing good features of easy compilation and raw performance, they decided to invest in that language to improve its deficiencies until it could get the job done. Now, what would UNIX look like if they subsetted and streamlined a language like ALGOL68 or Modula-2 that was actually designed to get real shit done and robustly? It's programming, science, all of it. You identify the key goals. A good chunk of it was known as Burroughs stayed implementing it in their OS's. Their sales numbers indicated people wanted to use those enough they paid millions for them. ;) Once you have goals, you derive the language, tools, whatever to achieve those goals. Thompson failed to do this unless he only cared about easy compilation and raw speed at the expense of everything else. Meanwhile, Burroughs, Wirth, Hansen, the Ada people, Eiffel later... all sorts of people did come up with decent, balanced solutions. Some, like the Oberons or Component Pascal, were very efficient, easy to compile, easy to read, stopped many problems, and allowed low-level stuff where needed. Came straight from strengths of design they imitated. A form of that would be easy to pull off on a PDP as Hansen showed in an extreme way. C's problems, which contributed to UNIX Hater's Handbook and many data losses, came straight from the lack of design in its predecessors which soley existed to work on shit hardware. They tweaked that to work on other shit hardware. They wrote an OS in it. Hardware got better but language key problems remained. Whether we use it or not, we don't have to pretend those effects were necessary or good design decisions. Compare ALGOL68 or Oberon to BCPL to see which looks more thought out if you're still doubting.
scythe 11y ago
>Three people wrote a consistent, safer platform in it from OS to compiler to apps in 2 years. I take it you didn't link to the OS because it was only ever a toy, correct? If it had been useful for anything, it would be worth linking to -- otherwise, you're better off if I know less about it. https://en.wikipedia.org/wiki/Lilith_(computer) https://en.wikipedia.org/wiki/Lilith_(computer) Lilith wasn't popular because it didn't solve any problems that needed to be solved -- it was too slow to be useful as a microcomputer OS, and it wasn't designed for that anyway. Microcomputer OS's of the time were written in assembly, and assembly continued to be important until around the time of Windows 3.1. Not integrating well with assembly is an anti-feature; the fact that it would become unnecessary some 15 years later is irrelevant. C did the job that needed to be done; Modula-2 did the job that somebody thought was cool. Also, you have yet to give me a reason to believe that Lilith was somehow safer or better-designed than UNIX of the time, considering that security wasn't even really a thing in 1980. That's not to mention it's [Pascal family] just poorly designed from a usability standpoint, with the language creators doing silly things like removing "for" loops from Oberon (a decision which both Clojure and Rust eventually admitted was bad). Lilith itself was "succeeded" by an OS that was written in an entirely different language and made no attempt to be backwards compatible (but portability is a red herring amirite?). >I could've said that about C in its early years given it wasn't intended to be portable. Turns out that stripping almost every good feature out of a language until it's a few primitives makes it portable by default. I guess it's not a big surprise then that C wasn't popular in its early years? The implementations of Cyclone and Popcorn were never even complete enough to write software on normal operating systems, much less to write UNIX. >It means that, statistically, the other examples will have most of C's efficiency with little to none of its weaknesses It means that, statistically, they will all have other huge, glaring weaknesses that you pretend don't exist... >Least important, it means I picked the examples closest to C in features and efficiency because C developers' culture rejects anything too different. That includes better options I often reference. If you have better options, why didn't you name them? Because they're equally bad if you spend even a few minutes thinking about it? (Lemme guess: Limbo, SML, Ada)
- nickpsecurity 11y ago
  " take it you didn't link".... "you have yet to give me"... "s a red herring amirite?" "you pretend don't exist...""why didn't you name them?" The answer to all that is that my response to you was less thorough and referenced on purpose. That's due to the trolling style of your first comment that this one matches albeit with more information. A comment more about dismissal and challenge with little informational content didn't deserve a high-information response. My observation and recommendation is here though: https://news.ycombinator.com/item?id=11448855 https://news.ycombinator.com/item?id=11448855 That is, there were specific languages in existence from PL family, Pascal tradition, ALGOL's of Burroughs, ALGOL68, and so on that balanced many attributes. A number, from safety-checks to stronger typing to interface protections, had already been proven to prevent problems or provide benefits. Thompson would've known that given MULTICS was one of systems that provided evidence of that even if it failed in other ways. He even re-introduced some problems that PL/0 prevented. Let's focus on fundamental failure, though. So, if I were him, I'd note that the consensus of builders of high-reliability systems and CompSci researchers is we need a language like ALGOL68 that balances various needs. I'd still need as much of that as possible on my crappy PDP. So, I'd subset a prior, safe language then make it compile with tight integration to the hardware due to resource constraints. Might even made similar tradeoffs they did although not in a permanent way. If safety checks wouldn't work yet, I'd turn off as many as I needed to get it to run. As hardware improved, I could turn more on. I'd keep well-written language definition and grammar as others showed to do. I might also borrow some syntax, macro's or easy parsing from LISP to make my job easier as Kay is doing and numerous Scheme teams did at the time. Keep language imperative and low-level, though. Thompson had a different idea. There was a language that had no good qualities except raw performance on crap hardware. Was opposite of its authors design intent to top it off. Thompson decided on it. Any gripes you have with Modula-2, Cyclone, Popcorn, etc apply at this point because the language, esp his B variant, wasn't so good enough for about any job. As I'm advising for safe languages, it would have to be modified to get stuff done. The first version of C was still crap to the point UNIX was mostly assembly. They added structs to get information hiding/organizing then were able to write UNIX in C. Both C and UNIX were simple enough to be portable as a side effect. Rest is history. Almost any gripe you've had against safer languages of the time I can apply to C's predecessors other than compilation difficulty. That you will dismiss them on grounds that they need modification for the job at hand, but don't do that for C, shows the bias and flaws of your arguments. I've called out everyone from McCarthy to Wirth to Thompson for stuff I thought were bad ideas. For loop removal is a good example. I didn't settle against C until years of watching people's software burn over stuff that was impossible or improbable in better designed, even lean, languages. Evidence came in even in empirical studies on real prorammers, C showed to be behind in every metric except raw performance, its history tells us why, and logically follows that they should've built on better, proven foundations. Those that did got more reliable, easy to understand, easy to maintain systems. Of course, don't just take my word for it: Thompson eventually tried to make a better UNIX with Plan 9, but more importantly a better language. He, Ritchie, and Pike all agreed every feature in their language. That language was Go: a clone of ALGOL68 and Oberon style with modern changes and updates. Took them a long time to learn the lessons of ALGOL that came years before them.

googamooga 11y ago

Kronos, the Soviet 32-bit workstation, was designed and built from hardware to all compilers, OS and miscellaneous applications by a small group of students in a couple of years. The only language they used was Modula-2. [1] https://en.wikipedia.org/wiki/Kronos_(computer) https://en.wikipedia.org/wiki/Kronos_(computer)

nickpsecurity 11y ago
Thanks for the link! Had no idea Russians built a Wirth-style system based on Lilith. There's almost a trend with them as they received the Oberons and especially Component Pascal better than most countries. My foray into Blackbox showed lots of Russian use. There have to be attributes of the language and tooling that appeal to Russian programmers more than others for whatever reason. I wonder what those are, both aspects of Russian style and language that appeals.

pjmlp 11y ago

IBM did. After Assembly, IBM used mostly Modula-2 and PL/M to write their mainframe OSes, e.g. OS/400, migrating the code slowly to C++ afterwards. Also OS research at DEC and Compaq was done in Modula-2+, which gave birth to Modula-3.

nickpsecurity 11y ago
Those mainframes and OS/400 were also very reliable and fast compared to the UNIXen. Hmm. Probably just a coincidence the C people will tell us. ;)

cmrdporcupine 11y ago

I did, as a teenager. The language was nice. The strong types did get in the way of interfacing with a lot of OS level stuff that wanted to deal in void pointers tho.

nickpsecurity 11y ago
My strategy for that sort of thing was wrapping all the stuff in unsafe modules that exported safe API's. Just do some basic checks as function is called then messy stuff is handled in its own little file of scary code. I was doing this in other languages way after you were dealing with Modula-2 on even older hardware. So, I'm curious as to how you and others then handled that problem? What were the tactics?
- cmrdporcupine 11y ago
  I was too young and too distracted by the world of being young to focus on it enough back then to truly sit down and do that. By the time I got my Modula 2 compiler I was 13 or 14 years old and then high school happened and about 3 or 4 years later I had a PC running (pre 1.0) Linux, so. I never had to truly deal with it.
  - nickpsecurity 11y ago
    Oh OK. That's aight.