Wow! I wish I could reply with something interesting, but your post has just given me so much food for thought. I sense there's going to be a few days of lost sleep ahead trying to fully grok many of the concepts you spoke ofabridgewater wrote:Having written macrocode and microcode level emulation for the TI Explorer Lisp Machine, I can say that the situation was a bit more complicated than that...
If you have the time, I have a couple of questions:
- * Do you have any opinions on the CONS vs the CADR processor? If I understand correctly they were completely different architectures, though (if the naming wasn't germane enough!) both designed to run lisp.
* Do you have any particular books to recommend for the layman trying to understand microcode? Or any books relating to this methodology of designing an architecture around the language? I was doing a lot of research into whether hardware can be designed around running functional languages specifically, but most of it was going over my head, sadly.
Wow! Awesome stuff. Those are the kind of projects I have grandiose visions of achieving and... always end up having to take a step back and go back to researchingRahsennor wrote:I continued working my way up, coding a simple Forth compiler and evolving it into a bare-metal OS (cooperative multitasking!)
I sort of get the impression that... it's easy to feel like you're reducing complexity, when in fact you're just trading one kind of complexity for another. With assembly, you have little-to-no abstraction, so you're having to talk on the level of the machine. On the plus side... well, that's also the plus side! Every instruction has a 1-to-1 correspondence with the hardware. Do you sacrifice the "reality" of the situation (what the machine is actually doing) for a sort if idealised language which can better express the concepts of your program directly, which requires a compiler/interpreter/complicated syntax and all that baggage?Rahsennor wrote:It also taught me that complexity is the root of all evil, and that managing it - by minimizing it, structuring it and documenting it - is the key to success as a programmer.
The more viewpoints, the better! Being a relatively new programmer (around 1 year or so I guess) I decided to focus on functional programming almost instantly. I found a great deal of posts talking about how out of the two paths:Rahsennor wrote:Probably not the kind of answer you were looking for, but that's the perspective I got going from low to high instead of high to low.
* Learn procedural/OOP -> learn functional
* Learn functional -> learn procedural/OOP
That the first path is supposedly significantly harder, because procedural/OOP are, for most people, quite a natural way of modelling processes. Functional, on the other hand (for someone without a mathematical background such as myself) can be much less intuitive. If you believe that to be true, it would make sense to tackle the more alien first, so you don't mould your brain into the more "obvious" mindset, thereby causing you to struggle to try and break out of that mindset at a later date. I'm not claiming these notions to be true, of course, but I must have agreed in some way or I'd be learning different languages entirely -- assembler being the exception. However, I think assembly is, in a way, as much of a head-change from OOP (and even high-level procedural to some extent) that you could make a similar argument. Better to understand what's really going on in the operation of a machine (or at least a relatively simple machine) and then build abstractions on top, than start with abstractions and struggle to break them down to get to the core or what's going on at a later date.