Hacker News Reader

Comment by tangus | Hacker News Reader

I don't think so. Wirth languages are generally not appreciated because they are short sighted. They guy designs a language with only one goal: to build a compiler that runs in the machine he's currently working on.

* This system has a way to run programs where I need to specify the program name and the files it'll work on? Ok, that goes into the language: `program X (input, output)`

* I need a couple of variadic functions? Why bother creating a protocol for them? Let's put the ones I need into the language.

* I need to format numbers in these couple of functions? No need to write a library function for that; that would force me to create a variable string type, which I don't need. No, I'll add a special parameter syntax just for these functions into the language.

Etc., etc. Somebody needs to come and works hard in making a Wirth language usable for general programming before they can be appreciated.

View on HN

Ah, just like a couple of dudes made a language that targeted only PDP-11, and then suffered lots of extensions until it was standardized about 15 years later?

The "extending" was an order of magnitude less intrusive with C than it was with Pascal. With C, you wrote a new function that wasn't part of the AT&T distribution, which was a perfectly normal thing to do. With Pascal, you had to change the language definition, which probably meant changing the compiler.

Forgetting about everything else besides bare bones terminal output?

I have some 1980's books with lots of extending and dialects like RatC.

> Forgetting about everything else besides bare bones terminal output?

No. You could write things that were not "bare bones terminal output" as functions (or libraries) within C, and do anything you needed to do. You could "extend the language by adding library functions" without having to "extend the language by changing the compiler or the shipped-with-the-compiler libraries".

Some of those library extensions could be useful enough to sell as a package, and people did. That's not the same as what you had to do with Pascal.

> I have some 1980's books with lots of extending and dialects like RatC.

Yes, some people also altered the syntax in various ways. But that wasn't necessary with C the way it was with Pascal.

Nothing changes the fact that C's actual portability came decades later, and people did had to cater for those changes, doesn't matter if it were a few or a bunch of them.

So? If we were arguing about whether C was perfect, your point might be relevant. But we were arguing about whether C was more usable than Pascal. And your latest reply makes it look like can no longer argue that point, but still feel compelled to argue something.

C was more usable in unextended form than Pascal was. C extension more often took the form of libraries, which were more portable. This made C programs themselves more portable between compiler variants than Pascal programs were.

And that is a big part of why C won and Pascal lost. It wasn't just free compilers. (By the way, were any of the extensions and dialects free? To the degree that they caught on, that disproves your "free" argument; to the degree they didn't, that disproves your "but variants!" argument.)

Nah, we are arguing that when C dudes get pointed out that C also required extensions to be usable outside UNIX and PDP-11, the outcome is always this two weights, two measures kind of hand waving.

That latter line of thinking was quite apparent in Go, where a bunch of the global functions had signatures that weren't expressible in the type-system.

Reply on news.ycombinator.com