8 ms·

I think its a mistake to directly compare the experiences (and conclusions) of these two exceptional programmers. Rich Hickey explains at the start of his talk

by kenshi 9y ago

I think its a mistake to directly compare the experiences (and conclusions) of these two exceptional programmers. Rich Hickey explains at the start of his talk where he is coming from, what the context of his development work, and he calls it "Situated Software". His background and the context for his development is building information systems in organisations where the rules are messy and no doubt change often. One of the things he calls out explicitly in his talk is the messiness of dealing with the "Two for Tuesday" rule in one of the systems he worked on. He also spoke about how different working in that domain was, to doing compiler development. John Carmack's experience and domain expertise is building high performance game engines. I'd argue this is closer to compiler writing in the sense that it is a much more rigid problem than say having to serve the needs of an organisation whose requirements may change often and in seemingly arbitrary ways, and usually on a tight deadline. I am not trying to elevate one domain over the other. They are different kinds of problems, and have different kinds of limitations and constraints applied to them. As such I don't think its any surprise that the priorities for each of these developers is different. Choosing between more dynamic or more static approaches without considering the context in which you are working in, is a mistake.

mightybyte 9y ago
This is an outstanding point. When watching this talk, I got the distinct impression that Rich has simply worked on a very different class of problems than the ones I have worked on. As we all are wont to do, we extrapolate our experience to the whole universe. But that's not always the right thing to do. I would say that for the most part, a statically typed language can do the same things a dynamic language can do, but not the other way around. Another commenter mentions the Any type, but I don't think that's it. It's maps. Rich wants to be able to combine maps with a union operation, take subsets of keys, etc. And that is exactly what maps afford. I'd rather work in a language like Haskell where I can use strong types when I need them and drop down to untyped maps when I need them than a language like Clojure where all I ever have is the maps. Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you. I'd rather work in a language where my compiler can help me this way than in one where it can't.
- AriaMinaei 9y ago
  Sorry to go off-topic, but this was a very nice sentence: "We extrapolate our experience to the whole universe."
  - sova 9y ago
    Nicely sieved out! I too found this sentiment very essential.
- stuartaxelowen 9y ago
  Dynamism is certainly available to statically typed languages, but I believe the problem comes at how difficult it is to write dynamic code in static-typed languages, and to use the common building blocks that help you solve real problems. Writing dynamic code in static languages is like running through mud, just like writing static checking in dynamic languages is. I think both paradigms are important and valuable for different applications, but I have never seen a language that does both in any truly useful way.
  - erokar 9y ago
    I think the gradual typing TypeScript provides is pretty useful, with relaitvely low friction.
- weavejester 9y ago
  "a statically typed language can do the same things a dynamic language can do, but not the other way around" It's interesting you'd say that, as I'd consider the opposite to be true. There are functions that are trivial to write in a dynamically typed language, but are hard to statically type. For instance, the `assoc-in` function in Clojure. "Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you." You don't necessarily need static typing to give functions some form of type signature or specification.
  - 9y ago
munificent 9y ago
> I'd argue this is closer to compiler writing in the > sense that it is a much more rigid problem than say > having to serve the needs of an organisation whose > requirements may change often and in seemingly > arbitrary ways, and usually on a tight deadline. Ex-game developer. If only this were so. When making a new game, the requirements are constantly in flux and the driving force changing them is incredibly elusive: "fun". This depends a lot on the experience level of the designers and how original the game is trying to be, but it's very common for features and systems to completely change as designers try things out and discover what does and doesn't feel good. And, of course, game development is always under very heavy time pressure because the margins are narrow. Carmack's situation is a little different because he's been making similar games for much of his career and much of the stuff he's building (rendering and low level infrastructure) are relatively decoupled from the gameplay and game features that are more volatile. Game developers are under a really tight crunch. They need to write software that's nimble and flexible so they can iterate on the game design quickly and figure out what's fun. At the same time, the code needs to be very efficient, even during early phases of development (it's hard to tell if a gameplay idea is fun or not when the game is running at 3 FPS) and certainly by the time it ships.
- spiralganglion 9y ago
  Current game developer. This is why you tend to use a low level / static / concrete language to write the (relatively constant, well-defined) game engine — the graphics pipeline, model loading, animation playback, sound, etc — and you use a high level scripting language like LUA to write the (constantly changing, unique) game logic. To tie this back to the OP, this is one of the reasons I'm fond of Clojure (even though I don't get much of an opportunity to use it). It's written to be concise and expressive (as described in Rich's talk, when compared to C++) but also relatively high perf (by leveraging the native capabilities of the host on which it sits). It has the potential to be a great language for both the high-perf core of a game and the high-level logic. Sadly, it doesn't yet target a host without a GC (and probably never will), so you're going to have a devil of a time using it in a way that guarantees pause-free execution.
stcredzero 9y ago
Choosing between more dynamic or more static approaches without considering the context in which you are working in, is a mistake. It's amazing how well the parallels and metaphors work between the study of weapons and historical martial arts and programming. (Perhaps not so amazing, since both have a certain nerdy component.) As Matt Easton of scholagladiatoria says, "Context, context, context!" It's erroneous to say that sword X is the best/ultimate sword! It all depends on context. Are you up against armored opponents? What kind of armor? Is this on a battlefield? Is it a duel? Is it on horseback? Do you need to wear one at court? Design is all about context and response to the forces in that context.

by kenshi 9y ago

mightybyte 9y ago

This is an outstanding point. When watching this talk, I got the distinct impression that Rich has simply worked on a very different class of problems than the ones I have worked on. As we all are wont to do, we extrapolate our experience to the whole universe. But that's not always the right thing to do. I would say that for the most part, a statically typed language can do the same things a dynamic language can do, but not the other way around. Another commenter mentions the Any type, but I don't think that's it. It's maps. Rich wants to be able to combine maps with a union operation, take subsets of keys, etc. And that is exactly what maps afford. I'd rather work in a language like Haskell where I can use strong types when I need them and drop down to untyped maps when I need them than a language like Clojure where all I ever have is the maps. Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you. I'd rather work in a language where my compiler can help me this way than in one where it can't.

AriaMinaei 9y ago
Sorry to go off-topic, but this was a very nice sentence: "We extrapolate our experience to the whole universe."
- sova 9y ago
  Nicely sieved out! I too found this sentiment very essential.
stuartaxelowen 9y ago
Dynamism is certainly available to statically typed languages, but I believe the problem comes at how difficult it is to write dynamic code in static-typed languages, and to use the common building blocks that help you solve real problems. Writing dynamic code in static languages is like running through mud, just like writing static checking in dynamic languages is. I think both paradigms are important and valuable for different applications, but I have never seen a language that does both in any truly useful way.
- erokar 9y ago
  I think the gradual typing TypeScript provides is pretty useful, with relaitvely low friction.
weavejester 9y ago
"a statically typed language can do the same things a dynamic language can do, but not the other way around" It's interesting you'd say that, as I'd consider the opposite to be true. There are functions that are trivial to write in a dynamically typed language, but are hard to statically type. For instance, the `assoc-in` function in Clojure. "Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you." You don't necessarily need static typing to give functions some form of type signature or specification.
- 9y ago

munificent 9y ago

> I'd argue this is closer to compiler writing in the > sense that it is a much more rigid problem than say > having to serve the needs of an organisation whose > requirements may change often and in seemingly > arbitrary ways, and usually on a tight deadline. Ex-game developer. If only this were so. When making a new game, the requirements are constantly in flux and the driving force changing them is incredibly elusive: "fun". This depends a lot on the experience level of the designers and how original the game is trying to be, but it's very common for features and systems to completely change as designers try things out and discover what does and doesn't feel good. And, of course, game development is always under very heavy time pressure because the margins are narrow. Carmack's situation is a little different because he's been making similar games for much of his career and much of the stuff he's building (rendering and low level infrastructure) are relatively decoupled from the gameplay and game features that are more volatile. Game developers are under a really tight crunch. They need to write software that's nimble and flexible so they can iterate on the game design quickly and figure out what's fun. At the same time, the code needs to be very efficient, even during early phases of development (it's hard to tell if a gameplay idea is fun or not when the game is running at 3 FPS) and certainly by the time it ships.

spiralganglion 9y ago
Current game developer. This is why you tend to use a low level / static / concrete language to write the (relatively constant, well-defined) game engine — the graphics pipeline, model loading, animation playback, sound, etc — and you use a high level scripting language like LUA to write the (constantly changing, unique) game logic. To tie this back to the OP, this is one of the reasons I'm fond of Clojure (even though I don't get much of an opportunity to use it). It's written to be concise and expressive (as described in Rich's talk, when compared to C++) but also relatively high perf (by leveraging the native capabilities of the host on which it sits). It has the potential to be a great language for both the high-perf core of a game and the high-level logic. Sadly, it doesn't yet target a host without a GC (and probably never will), so you're going to have a devil of a time using it in a way that guarantees pause-free execution.

stcredzero 9y ago

Choosing between more dynamic or more static approaches without considering the context in which you are working in, is a mistake. It's amazing how well the parallels and metaphors work between the study of weapons and historical martial arts and programming. (Perhaps not so amazing, since both have a certain nerdy component.) As Matt Easton of scholagladiatoria says, "Context, context, context!" It's erroneous to say that sword X is the best/ultimate sword! It all depends on context. Are you up against armored opponents? What kind of armor? Is this on a battlefield? Is it a duel? Is it on horseback? Do you need to wear one at court? Design is all about context and response to the forces in that context.