I'm sure this has been covered to death on HN already, but if anyone has a link bookmarked and feels like sharing?
I'm sure this has been covered to death on HN already, but if anyone has a link bookmarked and feels like sharing?
LISP was the medium, not the content
"I'd like to welcome you to this course on Computer Science. Actually that's a terrible way to start. Computer science is a terrible name for this business. First of all, it's not a science. It might be engineering or it might be art. We'll actually see that computer so-called science actually has a lot in common with magic. We will see that in this course. So it's not a science. It's also not really very much about computers. And it's not about computers in the same sense that physics is not really about particle accelerators. And biology is not really about microscopes and petri dishes. And it's not about computers in the same sense that geometry is not really about using a surveying instruments."
[0]: https://www.youtube.com/watch?v=2Op3QLzMgSY [1]: https://ocw.mit.edu/courses/electrical-engineering-and-compu...
I never released any of them and none are useful for anything any longer. None probably reached more than 75% completeness. But by trying to build games on them I saw with such clarity things that worked and didn't, and I got deep practicing in thinking about more 'general' forms/concepts/structures. I wrote a framework for writing 3D model loaders after, and the lessons carried over. I was utterly lost when starting the first game engine; with the model loading framework I had to think deeply, but I new where I was going.
Here's something to consider. If you try to just start writing 'a game engine,' (or whatever engine/framework) that could mean about anything (from 1 day of work, to 20 years of work). But, if you consider some concrete ideas for particular games you'd like to make, think about what they have in common, and then try writing a piece of software that takes care of the common parts, you'll have constrained the problem to something workable with definite goals, and a way of testing your success after.
This is at the heart of any sort of 'abstraction' you develop: you want to code several things which have a bunch of overlapping aspects, so you write something that captures the common parts, and then arrive at the several things you actually need by instantiating your abstraction with different parameters (I mean that in a very general sense, not with specific reference to OOP, though it provides means of instantiating abstractions with various parameters too, of course).
I'd say being able to do the above effectively is the cornerstone of being able to do architecture well. A bunch of other stuff comes after, like knowing when to not create abstractions, and all sorts of knowledge about doing things well for systems in particular domains (e.g. architecture for an interactive 3d simulation vs. web apps have very different patterns that have surfaced as effective).
I didn’t do CS in university. Following the above got me up to speed. I’ve seen it several times on HN. This time it’s me promoting it.
Appreciate the rec!
Some classes are better than others, but it’s extremely valuable to have a program that you’re following with deadlines and measures. If you have a desire to learn the stuff, you’ll get a lot out of it.
When I get busy personally or at work, I kinda phone it in and just do enough to make grades, but when I have the latitude to dive deep I’m learning a ton.
It’s also very affordable, fitting within most workplace education allowances, if you have one.