3 ms·

He still can't write a compiler, or do anything new with regards to Operating Systems. Think about the things we read on HN and say "Impressive" to. None of the

by wbl 14y ago

He still can't write a compiler, or do anything new with regards to Operating Systems. Think about the things we read on HN and say "Impressive" to. None of them are on the list.

klibertp 14y ago
Writing a compiler is easy. Optimizing one, not so much, but setting "writing a compiler" as some kind of difficult thing that requires arcane magic irritates me.
- rubinelli 14y ago
  Maybe most people's last contact with compilers was that lex/yacc undergraduate course. That was much harder than it had to be.
  - klibertp 14y ago
    My first contact with compiler writing was through a book, I forgot the title, where the guy explained how to write a compiler for pascal-like language for some specific, non-x86 processor (I forgot which; I only remember that it wasn't anything I'd heard of). The book was very amusing and made me realize how simple the idea of compilers is - I was somewhat proficient with assembly then and after a few illustrative examples it all "clicked". Needless to say, the parser was handwritten and expanded when another construct was added to the language, so it was the simplest and lowest-overhead possible. Anyway, compilers and interpreters ideas are very simple and powerful and beautiful because of that. There is no magic, however magical their workings may seem from the higher level :)
    - dmpk2k 14y ago
      Mayhap you refer to Crenshaw's tutorials.
- Silhouette 14y ago
  setting "writing a compiler" as some kind of difficult thing that requires arcane magic irritates me Isn't this a problem with much of software development, though? Most topics in the field are logical and easy to work with once you've spent a little time investigating them, but until you do, they can easily seem like black magic. When the Web was young and all the modern "server languages" were still obscure infants, I used to think that working with CGI was some sort of impressive, specialist skill. One day, I discovered to my amazement that it was just a simple, text-based protocol that I could work with perfectly well using nothing but standard C and a bit of trivial printf/scanf code. After literally years of assuming I'd never be smart enough to work on web sites, my perspective changed completely in a single afternoon. I must have had a dozen such epiphanies over a few years -- writing a simple compiler as we're discussing here, programming a game with graphics, dynamically linking libraries at run time, many more -- before I finally realized that usually the idea itself was quite simple but a poor choice of tools or just the lack of one good tutorial can make it seem impossibly complicated.
calinet6 14y ago
Add them on and some people still fit the definition. You're right, I think; compilers, machine code, operating systems, every single part of the computer down to the silicon (really, understanding the germanium doping that allow the transistors to work) including the electrical engineering, then the physics, and even chemistry that allows it to happen—that's really all part of the "full stack." I think the true 21st century Renaissance Man (or Woman!) will have a broad generalist understanding of the entire technological craft, beyond even that which he needs to know to do his work. Will he ever need to understand the properties of silicon to make a web site beautiful? No. But he does anyway. That's the point: the breadth of knowledge for the sake of it. Having the knowledge and respect of every part of the stack allows you to know what you're doing in a way very few people can. It allows you to say Yes to so many more opportunities, to find the correct answer to thousands of possible questions if only by knowing the right person to talk to. It's the musician's flexibility of being able to play jazz and classical—it opens new doors and makes you better at both, in some unquantifiable way that no one quite understands. So, put them on the list, and we'll talk Abstract Syntax Trees and A/B UI testing in the same sentence. Do they ever touch? Only at such a distance as to be nearly inconsequential to each other. But somehow, it makes you better at both to understand exactly how you get there from here.
- gngeal 14y ago
  You're right, I think; compilers, machine code, operating systems, every single part of the computer down to the silicon (really, understanding the germanium doping that allow the transistors to work) including the electrical engineering, then the physics, and even chemistry that allows it to happen—that's really all part of the "full stack. I think the problem is that people avoid these things because they think that they are complex. I'd argue that they are not: it's just that the SW ecosystem commonly used in practice is all too bloated which may create this impression. (HW as well, compare x86 with something nice, for example MIPS :-)) Many people would probably be surprised how small and simple can many useful things actually be. (Also, I have a growing suspicion that the complexity of the current HW/SW ecosystem is partly driven by their independent development, and partly by having to implement legacy stuff - case in point, you need a complex GPR allocator to generate efficient x86 code, and you need complex register-renaming HW in the CPU to actually process x86 code quickly. Simply raising the GPR count and redesigning the ISA would alleviate both sources of complexity. I'm growing increasingly fond of all those 1970's/1980's actual "full-stack" projects.) Oh, and what computers use germanium doping? I'm not conversant with current technological processes, but the last time I checked, most microelectronic components used mono-crystalline silicon for bulk stuff, SiO2 for insulation, aluminum or copper for wiring, and P, In, As, Ga etc. for channel dopants. Is there some new heterogeneous SiGe technology in use that I'm not aware of?

by wbl 14y ago

He still can't write a compiler, or do anything new with regards to Operating Systems. Think about the things we read on HN and say "Impressive" to. None of them are on the list.

klibertp 14y ago

Writing a compiler is easy. Optimizing one, not so much, but setting "writing a compiler" as some kind of difficult thing that requires arcane magic irritates me.

rubinelli 14y ago
Maybe most people's last contact with compilers was that lex/yacc undergraduate course. That was much harder than it had to be.
- klibertp 14y ago
  My first contact with compiler writing was through a book, I forgot the title, where the guy explained how to write a compiler for pascal-like language for some specific, non-x86 processor (I forgot which; I only remember that it wasn't anything I'd heard of). The book was very amusing and made me realize how simple the idea of compilers is - I was somewhat proficient with assembly then and after a few illustrative examples it all "clicked". Needless to say, the parser was handwritten and expanded when another construct was added to the language, so it was the simplest and lowest-overhead possible. Anyway, compilers and interpreters ideas are very simple and powerful and beautiful because of that. There is no magic, however magical their workings may seem from the higher level :)
  - dmpk2k 14y ago
    Mayhap you refer to Crenshaw's tutorials.
Silhouette 14y ago
setting "writing a compiler" as some kind of difficult thing that requires arcane magic irritates me Isn't this a problem with much of software development, though? Most topics in the field are logical and easy to work with once you've spent a little time investigating them, but until you do, they can easily seem like black magic. When the Web was young and all the modern "server languages" were still obscure infants, I used to think that working with CGI was some sort of impressive, specialist skill. One day, I discovered to my amazement that it was just a simple, text-based protocol that I could work with perfectly well using nothing but standard C and a bit of trivial printf/scanf code. After literally years of assuming I'd never be smart enough to work on web sites, my perspective changed completely in a single afternoon. I must have had a dozen such epiphanies over a few years -- writing a simple compiler as we're discussing here, programming a game with graphics, dynamically linking libraries at run time, many more -- before I finally realized that usually the idea itself was quite simple but a poor choice of tools or just the lack of one good tutorial can make it seem impossibly complicated.

calinet6 14y ago

Add them on and some people still fit the definition. You're right, I think; compilers, machine code, operating systems, every single part of the computer down to the silicon (really, understanding the germanium doping that allow the transistors to work) including the electrical engineering, then the physics, and even chemistry that allows it to happen—that's really all part of the "full stack." I think the true 21st century Renaissance Man (or Woman!) will have a broad generalist understanding of the entire technological craft, beyond even that which he needs to know to do his work. Will he ever need to understand the properties of silicon to make a web site beautiful? No. But he does anyway. That's the point: the breadth of knowledge for the sake of it. Having the knowledge and respect of every part of the stack allows you to know what you're doing in a way very few people can. It allows you to say Yes to so many more opportunities, to find the correct answer to thousands of possible questions if only by knowing the right person to talk to. It's the musician's flexibility of being able to play jazz and classical—it opens new doors and makes you better at both, in some unquantifiable way that no one quite understands. So, put them on the list, and we'll talk Abstract Syntax Trees and A/B UI testing in the same sentence. Do they ever touch? Only at such a distance as to be nearly inconsequential to each other. But somehow, it makes you better at both to understand exactly how you get there from here.

gngeal 14y ago
You're right, I think; compilers, machine code, operating systems, every single part of the computer down to the silicon (really, understanding the germanium doping that allow the transistors to work) including the electrical engineering, then the physics, and even chemistry that allows it to happen—that's really all part of the "full stack. I think the problem is that people avoid these things because they think that they are complex. I'd argue that they are not: it's just that the SW ecosystem commonly used in practice is all too bloated which may create this impression. (HW as well, compare x86 with something nice, for example MIPS :-)) Many people would probably be surprised how small and simple can many useful things actually be. (Also, I have a growing suspicion that the complexity of the current HW/SW ecosystem is partly driven by their independent development, and partly by having to implement legacy stuff - case in point, you need a complex GPR allocator to generate efficient x86 code, and you need complex register-renaming HW in the CPU to actually process x86 code quickly. Simply raising the GPR count and redesigning the ISA would alleviate both sources of complexity. I'm growing increasingly fond of all those 1970's/1980's actual "full-stack" projects.) Oh, and what computers use germanium doping? I'm not conversant with current technological processes, but the last time I checked, most microelectronic components used mono-crystalline silicon for bulk stuff, SiO2 for insulation, aluminum or copper for wiring, and P, In, As, Ga etc. for channel dopants. Is there some new heterogeneous SiGe technology in use that I'm not aware of?