6 ms·

Thinking Forth; Software Tools; SICP; Abstraction and Specification in Program Development; Essentials of Programming Languages; Paradigms of AI Programming; I'

Thinking Forth; Software Tools; SICP; Abstraction and Specification in Program Development; Essentials of Programming Languages; Paradigms of AI Programming; I'd like to list something about OO too, but no book I know really measures up to learning from other programmers. But there's Mark S. Miller's thesis Robust Composition. (in roughly chronological order. As you can see from the chronology, it took me a long time to start to like OOP.)

kod 9y ago
What I wouldn't give for 5 more books of equal quality to PAIP...
- aerique 9y ago
  Came here to mention PAIP as well. A lot of Peter Norvig's stuff is good. He makes it all look so beautiful and simple.
mikekchar 9y ago
Here I was thinking, "I was never really influenced by books. I just read and wrote a lot of code." But you've reminded me that it's just wrong. Thinking Forth. Nearly 35 years later it still probably dominates my approach. Edit: Just realised that it is available under a CC license: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/
- vram22 9y ago
  >Thinking Forth. Nearly 35 years later it still probably dominates my approach. That's interesting. Can you elaborate on why you think it dominates your approach? I'm interested because I had read a good amount of Starting Forth by Leo Brodie some years ago, and liked the language, and had played around with it a bit (only got access to a Forth system for a short time, so could not go deeply into it, on the practical side). But I remember liking the language. I don't think I have read Thinking Forth.
  - abecedarius 9y ago
    For me the biggest influences underemphasized in other sources are to be alert for relentless simplification, for 'mechanical sympathy', for ways changing your problem could make it much simpler to solve -- and that there's an agility in using a simpler programming system like a Forth which you grok and can change as you need to, which can sometimes outweigh the leverage of a big one that comes with lots of stuff already done for you. These are useful points of view even with Forth being almost never the most practical tool now. Its day was already passing when I learned it in the 80s. Also, though I don't think this was quite in the book, it helped lead me to the idea of refactoring and its synergy with automated testing almost a decade before the idea started spreading.
    - mikekchar 9y ago
      Yes, this is pretty much the same as me. The focus of Thinking Forth (as much as I remember it -- I should re-read it now that I can download it) is about creating small words that you can compose. The idea was that you could interactively tests the words as you were writing the code. FORTH is a bit like Smalltalk in that the environment is always loaded, so you're always jumping in and out of the editor to try things. Later when I learned about refactoring and TDD, it felt really natural. Until now I hadn't made the connection, but it was exactly the same thing I was doing when I was writing FORTH code. I also program everything bottom up, rather than top down. I'm pretty sure this is from the influence Thinking Forth had on me as a programmer. I'll make a mental sketch of how things will fit together overall, pick a spot, drill down and then start building the pieces I'm going to need. I refactor as I go. Finally I plug everything together. This also leads me to do subsystem decomposition very, very late in the process. Only after I've built the pieces do I start thinking about where they should ultimately end up. This makes refactoring a lot easier: first when you are building the pieces because you don't have to jump through hoops to get at things, and second when you are assembling because the pieces will naturally fall into places based on what data they interact with. If you have problems understanding where a piece should go, then it's a good indication that you have more refactoring to do. Some people hate the way I do evolutionary design :-) It works for me, though.

kod 9y ago

What I wouldn't give for 5 more books of equal quality to PAIP...

aerique 9y ago
Came here to mention PAIP as well. A lot of Peter Norvig's stuff is good. He makes it all look so beautiful and simple.

mikekchar 9y ago

Here I was thinking, "I was never really influenced by books. I just read and wrote a lot of code." But you've reminded me that it's just wrong. Thinking Forth. Nearly 35 years later it still probably dominates my approach. Edit: Just realised that it is available under a CC license: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/

vram22 9y ago
>Thinking Forth. Nearly 35 years later it still probably dominates my approach. That's interesting. Can you elaborate on why you think it dominates your approach? I'm interested because I had read a good amount of Starting Forth by Leo Brodie some years ago, and liked the language, and had played around with it a bit (only got access to a Forth system for a short time, so could not go deeply into it, on the practical side). But I remember liking the language. I don't think I have read Thinking Forth.
- abecedarius 9y ago
  For me the biggest influences underemphasized in other sources are to be alert for relentless simplification, for 'mechanical sympathy', for ways changing your problem could make it much simpler to solve -- and that there's an agility in using a simpler programming system like a Forth which you grok and can change as you need to, which can sometimes outweigh the leverage of a big one that comes with lots of stuff already done for you. These are useful points of view even with Forth being almost never the most practical tool now. Its day was already passing when I learned it in the 80s. Also, though I don't think this was quite in the book, it helped lead me to the idea of refactoring and its synergy with automated testing almost a decade before the idea started spreading.
  - mikekchar 9y ago
    Yes, this is pretty much the same as me. The focus of Thinking Forth (as much as I remember it -- I should re-read it now that I can download it) is about creating small words that you can compose. The idea was that you could interactively tests the words as you were writing the code. FORTH is a bit like Smalltalk in that the environment is always loaded, so you're always jumping in and out of the editor to try things. Later when I learned about refactoring and TDD, it felt really natural. Until now I hadn't made the connection, but it was exactly the same thing I was doing when I was writing FORTH code. I also program everything bottom up, rather than top down. I'm pretty sure this is from the influence Thinking Forth had on me as a programmer. I'll make a mental sketch of how things will fit together overall, pick a spot, drill down and then start building the pieces I'm going to need. I refactor as I go. Finally I plug everything together. This also leads me to do subsystem decomposition very, very late in the process. Only after I've built the pieces do I start thinking about where they should ultimately end up. This makes refactoring a lot easier: first when you are building the pieces because you don't have to jump through hoops to get at things, and second when you are assembling because the pieces will naturally fall into places based on what data they interact with. If you have problems understanding where a piece should go, then it's a good indication that you have more refactoring to do. Some people hate the way I do evolutionary design :-) It works for me, though.