Live data from Hacker News

My Kid Will Never Hack Linux

blog.jonasoberg.net

71–80 of 98 posts

Re: My Kid Will Never Hack Linux

#71
post #67
post #36

Earlier quoted context omitted.

That bubble's gonna pop eventually, I don't foresee it staying around for 10+ more years.

What do you think will stop artificial intelligence from becoming a closer and closer approximation of human intelligence?

Your question as asked has lots of reasonable answers, such as the fact humans aren't all that intelligent on average, and certainly not some asymptotic limit we're aiming for.

That said, AI is here to stay.

Re: My Kid Will Never Hack Linux

#72
So? Perhaps his kid will hkac MINIX. According to wiki page[1], there is only 6000 lines in its kernel. Not everybody has to start by cakhing a monolith. As long as there are smaller things.

[1] https://en.wikipedia.org/wiki/MINIX_3#Reduce_kernel_size

EDIT: Yes, Linux kernel slowly approaches point when gigabyte of source is a long gone story of a past. I doubt there anybody out there who can say they actually understand the whole of it. And this is probably bad for a lot of reasons, of which being not accessible to a beginner is one of the smallest concern.

EDIT2: Even more so for hardware which is harder to investigate under the hood and probably much less understood - when was the last time when you could claim to have inner mental model of your computer and software on it?

Re: My Kid Will Never Hack Linux

#73

Earlier quoted context omitted.

Thing is, for understanding why Rust is the way it is, you need to suffer through memory leaks and eg. buffer overflows, segfaults, lack of strict typing, etc. Same with most frameworks I know, regardless of where in the stack. That's why I believe Java is a bad educational language, and Donald Knuth uses MIX assembly in his books.

That's like saying, "to understand why the automobile is valuable, you need to suffer through a horse and carriage". You don't need to suffer through yesterday's problems to understand today's.

I don't think it's about suffering yesterday's problems to understand today's. Learning to program in C made me a better programmer because I had to watch out for memory, etc. I think a better analogy would be how even with modern animation software, great animators still recommend being able to draw well with pencil and paper ("lower level", slower) to develop a sense for the nuances of animation.

Re: My Kid Will Never Hack Linux

#74

Earlier quoted context omitted.

Thing is, for understanding why Rust is the way it is, you need to suffer through memory leaks and eg. buffer overflows, segfaults, lack of strict typing, etc. Same with most frameworks I know, regardless of where in the stack. That's why I believe Java is a bad educational language, and Donald Knuth uses MIX assembly in his books.

That's like saying, "to understand why the automobile is valuable, you need to suffer through a horse and carriage". You don't need to suffer through yesterday's problems to understand today's.

[deleted]

Re: My Kid Will Never Hack Linux

#75

Earlier quoted context omitted.

Counterexample: Rust compiler is written in Rust.

Doesn't Rust compilation rely on LLVM for all the actual compilation from IR to machine code?

For now it does, but there's an upcoming experimental alternative backend written in Rust. Furthermore, there's no reason that LLVM has to be written in C++, it was just the best choice available when LLVM got started 15 years ago. Suffice to say, there are higher priorities for the Rust project than porting LLVM. :P

Re: My Kid Will Never Hack Linux

#76
post #15

Earlier quoted context omitted.

Then we need a 'safe' language that has the performance characteristics of C or assembly. Not there yet?

Fortran, Ada, Rust, D, and more.

Fortran? I admittedly don't know much about it, especially the most recent developments, but my impression was it's perhaps safer than C but otherwise mostly not even as "safe" as idiomatic C++98.

Re: My Kid Will Never Hack Linux

#77
post #18
post #15

Earlier quoted context omitted.

Fortran, Ada, Rust, D, and more.

I feel that without the unreasonable hype behind rust nobody would even mention safety.

It was more the hype behind Java (to a lesser extent, earlier, Lisp) that made memory safety a particularly hot topic/dispute among language evangelists. Although Rust* has made it still more common.

*Also, though I now contradict myself because they preceded Java, the inspirations for Rust's more formal/statically-checked memory model: C++'s RAII and STL.

Re: My Kid Will Never Hack Linux

#78

Earlier quoted context omitted.

Thing is, for understanding why Rust is the way it is, you need to suffer through memory leaks and eg. buffer overflows, segfaults, lack of strict typing, etc. Same with most frameworks I know, regardless of where in the stack. That's why I believe Java is a bad educational language, and Donald Knuth uses MIX assembly in his books.

That's like saying, "to understand why the automobile is valuable, you need to suffer through a horse and carriage". You don't need to suffer through yesterday's problems to understand today's.

Fair point. But I know that for me knowledge of machine-level or at least C-level code is requisite know-how to comfortably build abstractions on. I'd have a problem starting in the middle of a stack at a boundary someone else has drawn for me, and which at times seems arbitrary to me (speaking in terms of general knowledge scope, not about work on a particular project). I frankly don't get how this' generations young developers can cope with this kind of ignorance and unknown territory in their stack (but I admire or pitty them for it rather than looking down to them).

Re: My Kid Will Never Hack Linux

#79

Earlier quoted context omitted.

Counterexample: Rust compiler is written in Rust.

Doesn't Rust compilation rely on LLVM for all the actual compilation from IR to machine code?

Yes, but there is a research project here that replaces LLVM for codegen: https://github.com/stoklund/cretonne

Re: My Kid Will Never Hack Linux

#80
post #31

Earlier quoted context omitted.

Not like it requires C to implement a new language.

This is a remarkably common belief and it bugs me to no end. I don't know why, but many people have developed this conviction that C is required for computers to work, that that's the baseline of computation. This comes from both novices and experts . I haven't figured it out.

The C Abstract Machine looks like a generic machine based on the Von Neumann architecture, so it "feels" like it should be fundamental. Add in some sunk-cost fallacy, and a lot of people end up with the belief that C is fundamental to computing, despite the existence of systems that do not use any C.
Post reply on HN