Live data from Hacker News

Computer Science from the Bottom Up (2013)

bottomupcs.com

91–100 of 161 posts

Re: Computer Science from the Bottom Up (2013)

#91
Thanks, I wrote this!

It was a bit of a different time, when docbook was the way to publish, when Itanium was the 64-bit architecture, things like go and rust didn't exist and we used bitkeeper. But most of it is still relevant, and despite acquiring 2 kids since I started still have some ideas.

Yes yes, it's not Alan Turing-esque computer science. I have taught algorithms and data structures courses as well as operating systems courses to "computer science" students and this is more the second obviously. You gotta know both!

All I can say is that being a professional now for some time, anyone who knows this stuff is welcome in my team, no matter if we're bit banging hardware or writing JavaScript. When you have some concept of what's happing underneath, you write better code and, more importantly, are a better debugger.

I'm mostly cloud-y devops-y these days ... But when your CI triggers a kernel panic or a crash in some low level libray, it's nice to be able to go digging and send a patch upstream to fix it :)

Re: Computer Science from the Bottom Up (2013)

#92
post #74
post #5

I've been rattling this idea around in my head and, although it may sound crazy, I think C is a little high level to start an adult out on. I know many people won't agree with this but all of the people I admire in the world of CS and everyone who is a true scottsman for all intents and purposes loves dipping down to a lower level once and a while. I think the best way to learn about computer science it to program fo…

That may be the ideal way to learn CS, but the problem IMO is that lots of people are going to lose interest immediately. When you start with a web app or a game they can immediately feel like they are developing a practical skill.

Writing an assembler teaches you nothing. The skills gained while building an assembler teach you everything.

Re: Computer Science from the Bottom Up (2013)

#93

Earlier quoted context omitted.

It is, but if you're, say, writing a small-scale webapp or some other app that's disk-bound (99% of all applications), it's probably not something you'll have to worry about.

Right but what's the reason not to pick a data structure with better performance? This should be a really trivial choice with virtually 0 impact on code since a list and array will have nearly if not entirely the same interface. I would also challenge that 99% of all applications are disk bound but I think it's really besides the point. Really, the argument is that performance doesn't matter in all situations, which…

Of course. But OTOH, we shouldn't immidiately discount LLs when writing code, just because the perf isn't optimal.

>but hardly means that we should be against writing fast software.

On the contrary.

Lisp is slow. Python is slow. Ruby is slow. Smalltalk is slow. What do these languages have in common? Dynamism. They trade speed for other that were, in the language designer's opinion, equally or more important than being fast.

The point is, that when you make a decision about performance, the decision has consequences in either direction. LLs are slow, but they have a lot of advantages. With skip lists you can get decent access tumes on ordered LLs, and in some contexts even O(n) is acceptable. But what LLs do better than other list structures like arrays is insertion. With an array, you get best-case O(1) appends, but all other types of insertion are O(n), and even appends can be O(n) if you run out of space and have to reallocate.

By contrast, provided you have a pointer to the location in the LL that you want to insert at (which is why most LL uses in applications like to insert at the head of the list), LL insertion is guaranteed O(1). That's sometimes useful.

Re: Computer Science from the Bottom Up (2013)

#95

Earlier quoted context omitted.

Right but what's the reason not to pick a data structure with better performance? This should be a really trivial choice with virtually 0 impact on code since a list and array will have nearly if not entirely the same interface. I would also challenge that 99% of all applications are disk bound but I think it's really besides the point. Really, the argument is that performance doesn't matter in all situations, which…

Of course. But OTOH, we shouldn't immidiately discount LLs when writing code, just because the perf isn't optimal. >but hardly means that we should be against writing fast software. On the contrary. Lisp is slow. Python is slow. Ruby is slow. Smalltalk is slow. What do these languages have in common? Dynamism. They trade speed for other that were, in the language designer's opinion, equally or more important than bei…

> Of course. But OTOH, we shouldn't immidiately discount LLs when writing code, just because the perf isn't optimal.

Most of the time you should, I'd say. Regardless, the decision should be very natural/ trivial for any developer - understanding the performance attributes of the most common data structures is not asking too much of developers.

> They trade speed for other that were, in the language designer's opinion, equally or more important than being fast.

Yes, of course. I am not advocating for highly tuned software - I've stated as much in the last post. There are often tradeoffs.

No one is arguing that a linked list is not more algorithmically efficient at certain things. What I will say is that Vectors still end up faster for most operations, and it shouldn't be hard for a developer to determine when those situations arise.

I am not arguing against LL. I am just saying that it isn't 'lunacy' to understand basic performance characteristics of your software. Your post essentially came off, at least to me, as "people are crazy for wanting ot use a more efficient data structure".

Re: Computer Science from the Bottom Up (2013)

#96
post #5

I've been rattling this idea around in my head and, although it may sound crazy, I think C is a little high level to start an adult out on. I know many people won't agree with this but all of the people I admire in the world of CS and everyone who is a true scottsman for all intents and purposes loves dipping down to a lower level once and a while. I think the best way to learn about computer science it to program fo…

Except at some point you have to deal with x86 and ARM and wait a minute - this looks a lot like computer engineering.

It's a very distinct segment of the whole hardware/software spectrum that's very, very far off from the realm of, say, dev ops.

Re: Computer Science from the Bottom Up (2013)

#97

Earlier quoted context omitted.

Computer science is not about computers; where does stuff like algorithms fit into this? What is a "true scottsman" of CS? Low level programmers? What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? I doubt these people know the inner workings of computers, but they have revolutioni…

> What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? > I doubt these people know the inner workings of computers ...wha...? This is so ridiculous of a claim that I can't even think of how to respond...

>> I doubt these people know the inner workings of computers

> ...wha...? This is so ridiculous of a claim that I can't even think of how to respond...

GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction.

Take everything with a grain of salt.

Re: Computer Science from the Bottom Up (2013)

#98

Earlier quoted context omitted.

> What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? > I doubt these people know the inner workings of computers ...wha...? This is so ridiculous of a claim that I can't even think of how to respond...

>> I doubt these people know the inner workings of computers > ...wha...? This is so ridiculous of a claim that I can't even think of how to respond... GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it'…

> GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction.

I think you missed my point. What I'm saying is there's a world of difference between "X knows B better than A" and "X doesn't know A [very well]". When you're talking about world-class experts who are at the forefront of research in their fields, if you work in the same discipline, there's a pretty damn good chance they're more of an expert at your work area than you are. (I'm obviously assuming "you" here are not the world-class expert in your area. "You" are just a generic but respectable engineer in your area of work.)

I think what you (& the OP) need to realize is that there's a HUGE and crucial difference between being, say, "rusty" on something (e.g. because you're not doing it on a day-to-day basis, or because it's someone else's system and obviously you can't magically know how it was designed a priori), and not having enough prior expertise such that your ramp-up time would be low enough to be negligible, should you ever need to touch that thing at some point. You need to realize, these folks have done so much work that they even get rusty on their own research topics after a few years. That doesn't mean they stop being experts on their topics. On top of that, they still keep up with their colleagues' research in other related areas... which, mind you, are likely to be more advanced than what you're doing. Chances are if they spent a day or two reviewing other stuff, they'd be as good (or even better) experts on them than they were originally, quite likely better than you (again, generic "you" here, as above).

Re: Computer Science from the Bottom Up (2013)

#99

Earlier quoted context omitted.

>> I doubt these people know the inner workings of computers > ...wha...? This is so ridiculous of a claim that I can't even think of how to respond... GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it'…

> GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, w…

It sounds like you hold researchers in the highest regard and believe everyone should too.

Re: Computer Science from the Bottom Up (2013)

#100

Earlier quoted context omitted.

> GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, w…

It sounds like you hold researchers in the highest regard and believe everyone should too.

> It sounds like you hold researchers in the highest regard and believe everyone should too.

Nice strawman. Where did I ever generically talk about "researchers"? Are these people mentioned (Karp, Valiant, etc.) just merely "researchers" to you? You really think I have the same regard for (say) a random grad student as I do for someone like Karp? And you really think I don't have the same respect for the best people working on corporate/commercial technology (Musk, Page, etc. just as a couple of examples off the top of my head)? It seems like you really have low opinions of all researchers no matter how accomplished they are, in which case that would explain everything, but I certainly don't. Otherwise it's like you're actively trying to waste my time and miss my point...

Post reply on HN