Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The truth about C and Unix history

rutschle.net

Post reply on HN
Print view View original

71–78 of 78 posts

Re: The truth about C and Unix history

#71

Post by sacado2 »

jacquesm wrote: post #50
mathgladiator wrote: post #46

Earlier quoted context omitted.

What is a hard thing that requires better syntax? I would argue that hard things require clarity, and syntax can often reduce clarity.

I think this is all somewhat related to how much you can keep in your head at once. More code -> less expression -> less that you can keep in your head -> you can solve smaller problems. If a problem requires that you keep all of it in your head then being able to express that problem concisely will aid in solving it. The poor mans solution is to reduce the scope: chop the problem into sub-problems that you can solve…

It's a double-edged sword, though : your compact, clever solution is great when your write it but becomes unreadable when you (or worse, someone else) tries to maintain it. And then you have to understand both the hard problem and the way it was solved in the first time.

Re: The truth about C and Unix history

#72

Post by sacado2 »

thaumaturgy wrote: post #68
blt wrote: post #63

Earlier quoted context omitted.

I agree. I don't understand the programmers who debate syntax all the time. Good syntax is important, but appropriate semantics are more important. Only after you've selected the typing, execution environment, memory model, paradigm support, available platforms, and libraries you need, should you worry about syntax. At that point there are usually 0 or 1 satisfactory languages.

The other day I was surprised to learn that the equals sign was invented in 1557. I wondered what the hell everyone did in algebra before then, and it turned out that a lot of the earliest examples of algebra are essentially word problems. By the time the equals sign was invented, it was commonplace to use the abbreviation "aeq." for equality, for "all equivalent (or equal) to". But the equals sign turned out to be a…

Good point. Boole boosted logic the same way.

a ∧ (a → ¬b) → ¬b

is easier to reason with than

Socrates is a man, no man is immortal, therefore Socrate is not immortal.

Re: The truth about C and Unix history

#73

Post by PythonicAlpha »

caf wrote: post #70
PythonicAlpha wrote: post #56

Earlier quoted context omitted.

I liked Modula 2 much more than Pascal or C. (for those, that don't know it:) Modula 2 was the successor of Pascal from Niklaus Wirth. It had cleaner syntax and many other good features. Its successor, Oberon, was object oriented. [1] But the culprit (and that belongs to all Pascal descendants, as it seems (at least until Modula 2)) was, that the libraries where not very helpful. The standard libraries for Pascal (no…

I really like the insight that printf() was C's original killer feature. It makes a lot of sense.

I think, it was just one top feature of the first standard C library. It made printing a lot easier. In standard Pascal or Modula 2, you still had to print every single data type with its own special "WriteX" statement. Even there was a distinction between "WriteString" and "WriteLine", the second wrote a string and added a Newline after it (I am not sure in the moment, if it really took a string or just wrote the NL). In printing to screen, some languages of those days where really spartan.

Re: The truth about C and Unix history

#74

Post by kjs3 »

caf wrote: post #22
thaumaturgy wrote: post #6

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

Pascal sort of lives on in Oracle's PL/SQL, which if not a lineal descendent is definitely at least a cousin.

Pascal lives on as Ada.

Re: The truth about C and Unix history

#75

Post by kjs3 »

PythonicAlpha wrote: post #56
thaumaturgy wrote: post #6

This particular April Fool's joke goes back at least 30 years. I remember getting a chuckle out of it a long time ago. For context for younger readers, it might be worth pointing out that there was for a while a sort of rivalry between C and Pascal adherents. C was the more "modern" and "professional" language, while Pascal was a "teaching" language (or so some of the arguments went). Windows was coded in C, while Ma…

I liked Modula 2 much more than Pascal or C. (for those, that don't know it:) Modula 2 was the successor of Pascal from Niklaus Wirth. It had cleaner syntax and many other good features. Its successor, Oberon, was object oriented. [1] But the culprit (and that belongs to all Pascal descendants, as it seems (at least until Modula 2)) was, that the libraries where not very helpful. The standard libraries for Pascal (no…

That's a really interesting insight. Wirth, et al, spent a lot of time delivering on really deep libs that solved CompSciIsh problems (lot's of ADTs) and not so much doing stuff people really needed to do in the real world.

Re: The truth about C and Unix history

#76

Post by lmm »

sacado2 wrote: post #71
jacquesm wrote: post #50

Earlier quoted context omitted.

I think this is all somewhat related to how much you can keep in your head at once. More code -> less expression -> less that you can keep in your head -> you can solve smaller problems. If a problem requires that you keep all of it in your head then being able to express that problem concisely will aid in solving it. The poor mans solution is to reduce the scope: chop the problem into sub-problems that you can solve…

It's a double-edged sword, though : your compact, clever solution is great when your write it but becomes unreadable when you (or worse, someone else) tries to maintain it. And then you have to understand both the hard problem and the way it was solved in the first time.

The main way to make code genuinely shorter is to actually make it simpler; replacing logic with a higher-order function call (e.g. map rather than a loop) makes it more readable and maintainable, not less. Or if we're talking about meaningless syntactic clutter like the extra lines of begin/end, they don't make the code any clearer.

Re: The truth about C and Unix history

#77

Post by musername »

lmm wrote: post #36
copsarebastards wrote: post #26

Earlier quoted context omitted.

> The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. begin ... end again. facepalm Except Ruby, OCaml, Erlang, Lua, etc. Frankly, if verbosity is a significant limiting factor on your creativity, a) C is not the solution to your problem, and b) you weren't trying to solve any hard problems anyway. Seriously, if you're doing anything really hard, stuff l…

Syntax limits everything, it only becomes more important as you're doing hard things. Being able to fit 10% more code on screen is a lot like being 10% smarter, which is the kind of thing you need to make the hard problems even possible.

With regards to complexity theory, I'm inclined to assume that syntax is a constant factor in the equation. You only have to extend the language by writing a macroprocessor once, if you count that to the power of the language. That's why C is still very powerful, although other langs have half an STD-Lib toolbox hidden in syntactic sugar.

Re: The truth about C and Unix history

#78

Post by copsarebastards »

lmm wrote: post #36
copsarebastards wrote: post #26

Earlier quoted context omitted.

> The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. begin ... end again. facepalm Except Ruby, OCaml, Erlang, Lua, etc. Frankly, if verbosity is a significant limiting factor on your creativity, a) C is not the solution to your problem, and b) you weren't trying to solve any hard problems anyway. Seriously, if you're doing anything really hard, stuff l…

Syntax limits everything, it only becomes more important as you're doing hard things. Being able to fit 10% more code on screen is a lot like being 10% smarter, which is the kind of thing you need to make the hard problems even possible.

> Syntax limits everything, it only becomes more important as you're doing hard things. Being able to fit 10% more code on screen is a lot like being 10% smarter, which is the kind of thing you need to make the hard problems even possible.

Yes, syntax limits everything, and being able to fit 10% more on the screen is a lot like being 10% smarter. But libraries, available techniques, and built-in features limit everything a lot more. Being able to do 500% more with the same amount of code is a lot like being 500% smarter. If you're piddling around with 10% increases like a switch from Pascal to C, you're wasting everyone's time. Switch to a higher-level language that's more closely suited to the problem you're trying to solve and you'll trivially be writing a fifth of the code you'd be writing in C[1]. So like I said: C is not the solution to your problem.

And that's being generous to your assumption that Pascal -> C actually even does give you a 10% boost: I think given that you'll be writing the same bounds-checking incantation everywhere in C which you wouldn't be writing in Pascal, the semantics probably negate the syntax very easily.

[1] There's one exception: where C is the language most closely suited to your problem. However, this exception is much more rare than most people think.

Post reply on HN