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

41–50 of 78 posts

Re: The truth about C and Unix history

#41

Post by 0942v8653 »

anatoly wrote: post #24
cbd1984 wrote: post #15

Earlier quoted context omitted.

The source code to the original Bourne shell did that and a lot worse. It became one of the inspirations for the IOCCC (International Obfuscated C Code Competition). http://www.ioccc.org/faq.html (What that FAQ doesn't mention is the real reason the Bourne shell deserved to be in the IOCCC: The way it allocated memory. It trapped SIGSEGV (the signal the kernel sends you when you've provoked a segmentation violation o…

That's an amazing story, thanks! This is the place where it catches the fault: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/...

Here's the IF/FI #defines: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/...

Re: The truth about C and Unix history

#42

Post by Ayaz »

jacquesm wrote: post #37
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…

You forgot that (object) Pascal found it's niche in Borlands excellent 'Delphi' product and that to this day it has its adherents. http://en.wikipedia.org/wiki/Delphi_%28programming_language%... There is also: http://en.wikipedia.org/wiki/Free_Pascal I've never used it but I've seen people using it and they were insanely productive and happy about the tools.

Ah, Free Pascal. It made me remember the first semester at my University where everywhere I looked I found Microsoft. I refused to do assignments and projects on Windows, preferring instead Linux (Slackware, then). In the first semester we studied programming in Pascal and I used the Free Pascal compiler on my Linux to learn and play with the language, while everyone else used Turbo Pascal on DOS/Windows.

Re: The truth about C and Unix history

#43

Post by jschwartzi »

coldcode wrote: post #32
spacecowboy_lon wrote: post #5

Now if we could all get back to using real Languages like Fortran and PL1/G :-)

APL will solve all the world's programming problems in just one line. Then it will take the world to figure out what the hell it does.

But it's concise, and therefore elegant, so who cares?

Re: The truth about C and Unix history

#44

Post by alyandon »

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.

I always thought Oracle's PL/SQL looked more similar to ALGOL than Pascal. They even mention ALGOL in their documentation. :)

Re: The truth about C and Unix history

#45

Post by leoc »

coldcode wrote: post #32
spacecowboy_lon wrote: post #5

Now if we could all get back to using real Languages like Fortran and PL1/G :-)

APL will solve all the world's programming problems in just one line. Then it will take the world to figure out what the hell it does.

Not even Deep Thought will be sufficient.

Re: The truth about C and Unix history

#46

Post by mathgladiator »

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.

What is a hard thing that requires better syntax?

I would argue that hard things require clarity, and syntax can often reduce clarity.

Re: The truth about C and Unix history

#47

Post by vinceguidry »

copsarebastards wrote: post #26
mojuba wrote: post #10

Earlier quoted context omitted.

You could have called me a "Pascal devotee" back then, but I had eventually come to realize verbosity kills creativity and dumped Pascal for good. This { int a[10]; ... } wins over this begin var A: array[0..9] of Integer; ... end; quite simply because the latter takes longer to both read and write. The proof being that none of the more or less serious languages created in the past few decades dared to adopt e.g. beg…

> 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…

Very few people actually have hard problems to solve.

Re: The truth about C and Unix history

#48

Post by lmm »

mathgladiator wrote: post #46
lmm wrote: post #36

Earlier quoted context omitted.

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.

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

> What is a hard thing that requires better syntax?

Any thing where, for the implementation you can come up with, those extra lines are the difference between fitting a function on a single screen or not. There's a huge difference in readability between a function or class that can fit on a single screen and one that can't.

Re: The truth about C and Unix history

#49

Post by arethuza »

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.

"Being able to fit 10% more code on screen is a lot like being 10% smarter"

Makes me wonder how I ever wrote anything on a 80x24 serial terminal in the 1980s....

Re: The truth about C and Unix history

#50

Post by jacquesm »

mathgladiator wrote: post #46
lmm wrote: post #36

Earlier quoted context omitted.

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.

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 individually.

Divide and conquer is the most powerful tool in a programmers arsenal because it allows you to use the worst languages to solve some of the most complicated problems.

But there may be a subset of problems where that strategy no longer works and for those problems the more compact languages may have a very strong advantage.

Post reply on HN