Hacker News new | ask | show | jobs
by smburdick 878 days ago
I am at times more of a book learner, but find that attitude is often more helpful for non-CS disciplines that change slower (eg, math/physics).

A recent negative book example for me is the Quantum Programming book from O'Reilly. I found that it did not discuss quantum circuits in a detail that helped me really understand what I was doing -- though I suppose that is a conceit of quantum computing. Perhaps I will return to it later (I am working through Nielsen/Chuang now, which is very theoretical, but explains things very clearly)

My policy is that a book is nothing more than a learning tool, which a hobby project can also be (perhaps more effectively due to the experience gained).

Then again, knowledge is power, and books are great at pointing you in the right direction -- assuming you found the right one for your needs, of course.

I know some people who won't open a book unless they know they can read the whole thing, which I think is a ludicrous attitude.

I did just order O'Reilly's Generative Deep Learning book, and am hoping to get something out of that, and if I only retain a handful of snippets to use in my career, that is profitable for me.

The least I can count on is that it will look nice on my shelf.

1 comments

Fundamentals don't change. Sure there's a new frontend framework every week but they're all just generating html.
It's often hard to tell what information is truly fundamental, and what will age badly. I look at many books of software engineering that were popular in the early 2000s, like The Pragmatic Programmer, Agile Software Development or the Design Patterns book by the gang of 4. Those books aren't taking about technologies that we expected to be superceded in 5 years. And yet, a lot of the text regarding object orientation and design patterns is outdated at best, and outright harmful at worst.

One can also look at, say, concurrency. A topic often seen as unimportant in the 90s, but ultimately taught at the lowest level, with mutexes, threads, semaphores and such. Those aren't going away, but how often is concurrent programming all about manually setting mutexes? We use higher order abstractions, but those change too. Many languages are encapsulating this in monads, whether people know their promise implementation is a monad or not. But that's not the only way, and the most popular way can change: Maybe languages in 10 years will be all about continuations and direct styles. Maybe it'll be something else. The fact that in the end, the same basic features from the 80s and 90s will exist at the bottom somewhere isn't that useful for most programmers.

And html generation... I was writing UIs before web apps were there. A lot of things that seemed fundamental went away when the browser was embraced. But will the browser live forever, or be superceded? I suspect that it will all get replaced, or be utter legacy, eventually. Will that eventually be 10 years? 30? It's very hard to say what will remain fundamental, and what will not.

Mutexes, semaphore, CAS, threads are fundamental and this doesn't change when you embrace monadic effect systems or continuations, even if some of the details change (e.g., obviously, if a computation can jump threads, then you need implementations of mutexes, semaphores, etc, that can jump threads).

Also, programming languages in 10 years from now will be pretty much the same languages we have today. There might be a newcomer or two, but it will be niche, as incumbents don't really change and only grow.

As a reminder, for people thinking that technologies change too fast, POSIX is still here and as relevant as ever.

I'm sure whatever you were using to write GUIs was still just rendering nested rectangles and styling them.
Just for the moment, consider the idea of implementing the requirements shown in the figure using a network of connected microcomputers, one microcomputer per bubble.

Structured Analysis and System Specification, Tom DeMarco, 1978.

Yeah, I'm comfortable buying a book on C/C++, or Swift even, but for React or Vue or whatever, I'm buying a digital copy.
+1. What are the fundamentals of CS? Algorithms?
No particular order but how they came to mind:

Data structures, algorithms, algorithm analysis, various discrete math topics (set theory and number theory, a bit of graph theory, are usually included in a typical CS undergrad curriculum), models of concurrency, models of computing (lambda calculus, Turing machines), complexity classes, Chomsky hierarchy, type theory (some might consider this more advanced, varies by school and its lean towards practical or theoretical CS), systems of logic.

If software engineering whiteboard interviews are anything to go by, strictly hash tables. Hash tables are the only thing that matter, unless of course the interview process is broken...
Bonus points if some kind of list requirement comes up and you deftly maneuver the conversation back to using your hash table with array indexes as keys.
and data structures. Theres a book called Algorithms + Datastructures = programs which i've heard good things about.

I've also heard good things about 7 programming languages in 7 weeks, as well as crafting interpreters.

The latter 2 I intend to pick up this year

Read SICP and do the Scheme (a LISP) exercises oline:

https://sarabander.github.io/sicp/

If you want to run these locally, I can set Chicken Scheme for you.

Dan Grossman's "Programming Languages" series on Coursera was important in helping me connect the dots. And that was after only completing the first of three parts of the course...