Live data from Hacker News

1972 Unix V2 "Beta" Resurrected

tuhs.org

101–110 of 153 posts

Re: 1972 Unix V2 "Beta" Resurrected

#101
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

Ken is definitely a top-notch programmer. A top-notch programmer can do a LOT given 3 weeks of focus time. I remember his wife took the kids to England so he was free to do whatever he wanted. And he definitely had a lot of experience before writing what was first version UNIX. Every programmer that has a project in mind should try this: Put away 3 weeks of focus time in a cabin, away from work and family, gather eve…

> low level projects that rely on as few external libraries

I think this is key. If you already have the architecture worked out in your head, then it's just smashing away at they keyboard. Once you have a 3rd party library, you can spend most of your time fighting with and learning about that.

Re: 1972 Unix V2 "Beta" Resurrected

#102
post #99
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

I’ve heard that Torvalds build Git in 5 (or 10) days and that Brendan Eich created JavaScript in 10 days. Maybe the average programmer is less efficient, but the distribution is probably heavily skewed these days.

I'd argue that ordinary programmers can perform the same *type* of exercises if they:

- Put away a few weeks and go into Hermit mode;

- Plan ahead what projects they have in mind, which books/documents to bring with them. Do enough research and a bit of experimental coding beforehand;

- Reduce distraction to minimum. No Internet. Dumb phone only. Bring a Garmin GPS if needed. No calls from family members;

I wouldn't be surprised if they could up-level skills and complete a tough project in three weeks. Surely they won't write a UNIX or Git, but a demanding project is feasible with researches allocated before they went into Hermit mode.

Re: 1972 Unix V2 "Beta" Resurrected

#103
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

It is also the case that the first 80% of a projects functionality goes really quickly. Especially when you are interested and highly motivated about the project. That remaining 20% though. That is a long tail, it tends to be a huge slog that kills your motivation.

Re: 1972 Unix V2 "Beta" Resurrected

#104
post #99
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

I’ve heard that Torvalds build Git in 5 (or 10) days and that Brendan Eich created JavaScript in 10 days. Maybe the average programmer is less efficient, but the distribution is probably heavily skewed these days.

> I’ve heard that Torvalds build Git in 5 days

And it shows.

I am joking of course, git is pretty great, well half-joking, what is it about linux that it attracts such terrible interfaces. git vs hg, iptables vs pf. there is a lot of technical excellence present, marred by a substandard interface.

Re: 1972 Unix V2 "Beta" Resurrected

#105
post #68
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

I’m wondering what the process was for the early UNIX developers to attain this level of productivity. Did they treat this as a 9-5 effort, or did they go into a “goblin mode” just to get it done while neglecting other aspects of their lives?

A lot of the supposed "features" we have in Unix nowadays are the result of artifacts resulting from primitive limitations, like dotfiles.

If you're willing to let everything crash if you stray from the happy path you can be remarkably productive. Likewise if you make your code work on one machine, on a text interface, with no other requirements except to deliver the exact things you need.

Re: 1972 Unix V2 "Beta" Resurrected

#106
post #68
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

I’m wondering what the process was for the early UNIX developers to attain this level of productivity. Did they treat this as a 9-5 effort, or did they go into a “goblin mode” just to get it done while neglecting other aspects of their lives?

A big one is the lack of peer reviews and processes, including team meetings, that would slow them down. No PM, no UX, just yourself and the keyboard with some goals in mind. No OKRs or tickets to close.

It's a bit like any early industry, from cars to airplanes to trains. Earlier models were made by a select few people, and there was several versions until today where GM and Ford have thousands of people involved in designing a single car iteration.

Re: 1972 Unix V2 "Beta" Resurrected

#107

Earlier quoted context omitted.

compiler creates a binary in elf format or other format which can be run given a shared object exists. Intepreter either writes it in bytecode and then executes the bytecode line by line ? Atleast that is what I believe the difference is , care to elaborate , is there some hidden joke of compiler vs intepreter that I don't know about ?

I assume GP meant that a lot of compilers also interpret and interpreters also compile. For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3. Then, some language features require compilers to perform some interpretatio…

Then what is the difference, I always thought of Java as closer to python in the sense that it's running the byte code. And python also has bytecode.

I don't know what the difference is , I know there can be intepreters of compilers but generally speaking it's hard to find compilers of intepreters

Eg C++ has compilers , intepreters both (cpi) , gcc

Js doesn't have compilers IIRC , it can have transpilers Js2c is good one but i am not sure if they are failsafe (70% ready) ,

I also have to thank you , this is a great comment

Re: 1972 Unix V2 "Beta" Resurrected

#108

Earlier quoted context omitted.

Ken is definitely a top-notch programmer. A top-notch programmer can do a LOT given 3 weeks of focus time. I remember his wife took the kids to England so he was free to do whatever he wanted. And he definitely had a lot of experience before writing what was first version UNIX. Every programmer that has a project in mind should try this: Put away 3 weeks of focus time in a cabin, away from work and family, gather eve…

> low level projects that rely on as few external libraries I think this is key. If you already have the architecture worked out in your head, then it's just smashing away at they keyboard. Once you have a 3rd party library, you can spend most of your time fighting with and learning about that.

Exactly. Both projects mentioned in this thread (UNIX, Git) have clean cuts visions of what the authors wanted to achieve from the beginning. Nowadays it is almost impossible to FIND such a project. I'm not saying that you can't write another Git or UNIX but most likely you won't even bother using it yourself, so what's the point? That's why I think "research projects" don't fit here -- you learn something and then you throw them away.

What I have in mind are embedded projects -- you are probably going to use it even when you are the only user. So that fixes the motivation issue. You probably have a clean cut objective so that clicks the other checkbox. You need to bring a dev board, a bunch of breadboards and electronics components to the cabin, but that doesn't take a lot of spaces. You need the specifications of the dev board and of the components used in the project, but those are just pdf files anyway. You need some C best practices? There must be a pdf for that. You can do a bit of experimental coding before you leave for the cabin, to make sure the idea is solid, feasible and the toolchain works. The preparations give you a wired up breadboard and maybe a few hundred lines of C code. That's all you need to complete the project in 3 weeks.

Game programming, modding and mapping come into my mind, too. They are fun, clean cut and well defined. The thing is you might need the Internet to check documents or algorithms from time to time. But it is a lot better to cut off Internet completely. I think they fit if you are well into them already -- and then you boost them up working 3 weeks in a cabin.

There must be other lower level projects that fit the bill. I'm NOT even a good, ordinary programmer, so the choices are few.

Re: 1972 Unix V2 "Beta" Resurrected

#109
post #99

Earlier quoted context omitted.

I’ve heard that Torvalds build Git in 5 (or 10) days and that Brendan Eich created JavaScript in 10 days. Maybe the average programmer is less efficient, but the distribution is probably heavily skewed these days.

I'd argue that ordinary programmers can perform the same *type* of exercises if they: - Put away a few weeks and go into Hermit mode; - Plan ahead what projects they have in mind, which books/documents to bring with them. Do enough research and a bit of experimental coding beforehand; - Reduce distraction to minimum. No Internet. Dumb phone only. Bring a Garmin GPS if needed. No calls from family members; I wouldn't…

I also think people under estimate how much pondering one does before starting a project.

Re: 1972 Unix V2 "Beta" Resurrected

#110
post #66

Earlier quoted context omitted.

Now we know where SMTP got it, I guess.

That's possible but unlikely. MTP as defined by Suzanne Sluizer and Jon Postel in RFC 772 in September 01980 https://datatracker.ietf.org/doc/html/rfc772 seems to have been where SMTP got that convention for ending the message: > ...and considers all succeeding lines to be the message text. It is terminated by a line containing only a period, upon which a 250 completion reply is returned. But in 01980 Unix had only b…

The "." to terminate input was used in FTP mail on ARPANET, defined in RFC 385 which was well before anyone outside Bell had heard of Unix.
Post reply on HN