10 ms·

Extremist Programming

167 points by achille 14y ago

timbaldridge 14y ago
This is why I use Clojure. I can do Functional, OOP, logic, or any of the dozens of other programming styles in one language. And since it's a lisp I don't have to worry about having to need extra syntax from the language writers to get what I want. Pragmatic languages FTW!
- spicyj 14y ago
  I interpreted the OP suggesting that you not use a single multiparadigm language because then you won't be forced to follow the new principle everywhere. Of course, it's possible to do (for example) OOP in a lisp-like language, but you'll really be forced to work with it in a language like Java, which may give you a deeper understanding.
  - jfb 14y ago
    Well, avoid Java, which is just C++--, and think Smalltalk instead.
    - klez 14y ago
      Therefore Java == C?
      - jfb 14y ago
        Well, only shittier.
      - evincarofautumn 14y ago
        I don’t think programming languages have inverses, so in general λ + 1 − 1 ≠ λ.
- oskarkv 14y ago
  Your comment gives the impression that Clojure is a big multiparadigm mess. But it is not. Clojure's design is clean and simple. Clojure is mostly functional. Sure, since it's a Lisp one can kind of incorporate other paradigms with macros. But out of the box Clojure does not do Java-style OOP (except for interop) or Prolog-style logic.
  - timbaldridge 14y ago
    Perhaps it does place oriented OOP poorly, but it actually has an extremely nice logic engine (see core.logic).
    - oskarkv 14y ago
      Yeah, I know about it, but it's an additional dependency, right? [org.clojure/core.logic "0.7.5"] Whatever, Clojure is clean and simple is what I wanted to say. :)
jonsen 14y ago
Another extreme direction to try out is the direction toward the machine. The value of trying out assembler programming may not have similarly direct benefits. But I personally find it a great general advantage to have detailed knowledge of under which practical conditions your program must run. To know that whatever fancy high level constructs you are making use of, you are always building a giant state machine where space is traded for time.
- PieSquared 14y ago
  To expand on your suggestion a little, I would suggest going even further - learn how to design your own processors and figure out how the low-level details really work. With hardware description languages such as Verilog, programmers can apply a lot of their knowledge to hardware engineering. I've found that a lot of things carry over from conventional programming languages to HDLs, and that it's incredibly easy to get started. The computer engineering mindset is pretty similar to low-level programming, and really helps you understand how your code runs, even more so than assembly.
  - jonsen 14y ago
    Completely agree. I was about to write something like that. I've designed processorlike hardware, but not touched it since the 80'es, so I'm not really confident in state of the art of hardware programming.
  - jules 14y ago
    One surprise that you find out when you do this is that languages like C don't efficiently map to hardware at all. Hardware is inherently massively parallel, whereas C is completely serial. What modern hardware is doing to be fast is trying to recover as much fine grain parallelism from a sequential C program as possible using pipelines and out of order execution. We are now at a point where that has been mostly milked out, so explicit parallelism is necessary to gain performance, like SIMD and multiple threads. It's interesting to consider how you can exploit parallelism more easily, for example from going from a sequential instruction set and language to an inherently parallel instruction set and language. Nobody has found the ultimate answer to that yet. GPUs execute thousands of sequential threads in parallel, and while that works for problems with massive and regular parallelism, it does not work for irregular parallelism or parallelism that requires fine grain communication or short lived parallelism or not-so-massive parallelism. FPGAs do work well for those types of parallelism, but they have other problems for general purpose computing. With hardware trends, it's inevitable that we'll see more and more parallelism and eventually a paradigm shift to inherently parallel architectures. Interesting times ahead.
wissler 14y ago
He underrates the power of principle. "Mass is awesome. What if every object in the Universe had mass?" "Liberty is awesome. What if there should be no such thing as slavery and every human being should be free?" If you pick the wrong principle and take it to an extreme, then yes, it'll lead to undesirable results, but that means you should throw bad principles out, not all principles.
- lambda 14y ago
  Huh? He was advocating for finding a principle and taking it to the extreme. He wasn't discouraging it. Yes, he said that sometimes it won't work; but the whole point of the article is that you can discover and learn new things when you try taking one principle to its logical conclusion. Where did you get the idea that he was arguing against that?
  - wissler 14y ago
    Yes, he said to try new principles, he also said not to expect them to really work, which undercuts the motivation for finding really difficult to discern principles.
    - lutusp 14y ago
      > he also said not to expect them to really work, which undercuts the motivation for finding really difficult to discern principles. That would be an argument against science, which labors under the same constraint (i.e. with rare exception, things don't work), but as it turns out it really isn't an argument against science at all, because the rare "thing that works" tends to change the world.
      - wissler 14y ago
        "That would be an argument against science" No. Great science is done by people who are more like Newton and Tesla, not people like you and Edison.
tikhonj 14y ago
I agree with the blog's premise: "extremist" languages are great for language and for research. So this whole rant is not directly related to the post's central thesis. Instead, it's about the assumptions most people have whenever this topic comes up. What I'm a little annoyed with can be summed up with a single banal and overused phrase: "the right tool for the right job". For one, this phrase really doesn't say all that much--it's basically a tautology. Yes, using the right tool would be good, but with programming languages, it's rarely obvious what the right tool is! It's just a specialized version of the advice to "make the right choices", which is not much advice at all. Another problem is that people inevitably ignore how much programming languages overlap. Virtually any languages worth comparing are going to be general-purpose languages. Choosing between a functional language and an OO language is not like choosing between a hammer and a screwdriver to pound in a nail, it's more like choosing between different types of hammer. In a world where hammers can do anything. (I don't know enough about carpentry to extend the analogy properly.) There are very few applications where one language clearly fits and another is clearly unsuited--and if you're in a vertical like that, the question just won't come up in the first place! Another thing that comes up is people assuming that a multi-paradigm language has the benefits of all the paradigms it supports. I've found this is never the case. Even very multi-paradigm languages tend to favor one paradigm or the other more. And even if they didn't, there are benefits to being consistent. You can do much more by being functional everywhere than you can by merely supporting functional programming in some places. Any mix of paradigms is necessarily going to be a compromise, and the advantages of prioritizing one main paradigm can outweigh the flexibility of supporting more than one to any large extent. Doing one thing, and doing it well, is a powerful idea that doesn't stop applying in designing programming languages. Now, I'm not leaning one way or the other here in any comparison of languages (I'm sure my biases are pretty evident and show through, they're just not germane to this comment); I just think that summarily dismissing a language for being too focused or too "extremist" or not multi-paradigm is rather short-sighted. Also, often, unless you've tried doing something in a language yourself, don't assume it's more difficult than what you already know. There is much "common wisdom" about (like "functional programming is bad for GUIs") which is often more "common" than "wisdom".
- papsosouid 14y ago
liquidise 14y ago
Awesome article. I would argue this goes for practices as well. Automated Testing vs TDD and the like.
deleted 14y ago
[deleted]
10098 14y ago
That's the right idea for a hobby or research project, but please don't do this in production code. Think about people who have to maintain it after you. I've seen my colleagues wade through a swamp of completely unnecessary C++ metaprogramming madness left by someone who apparently learned about templates yesterday, and it wasn't very nice.
- shusso 14y ago
  I have to disagree with your first sentence, but the rest I do agree. I think maintenance of the SW should be categorized under "the right tool for the right job". If your company has dozens of skilled "extrimists" then why not use it in production. On the other hand if not..
nickbarone 14y ago
So, could we start a listing of things learned through the application of extremist programming? Or better yet, a listing that shows where a given principle hasn't been extremified, so we can go try it out and see what happens?
drbawb 14y ago
>what if we made an OS where everything was a file? Shameless Plan 9 plug. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_concepts http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_co...
- cms07 14y ago
  Or, you know, Unix. Edit: Which came from Multics, I know.
  - jacques_chester 14y ago
    Plan 9 is the spiritual successor of Unix, because in Unix: Everything Is A File (except for the many, many things which are not files after all).
- mahmud 14y ago
  I think the author knows of this and avoids to name names for stylistic reasons. I mean, everything he lists has an archetype well-known to anyone with a clue, why be blunt?
w0utert 14y ago
Nice article and interesting viewpoint, taking principles to the extreme for learning purposes seems very useful. The thing that impressed me most isn't the article though, but the amazingly beautiful clean look of that blog. Really a pleasure to look at and read on the iPad :-)
rizzom5000 14y ago
Sure, you could try to treat everything like an object and then find out if an integer was an object (the hard way) or you could just RTFM (the easy way). Don't get me wrong, experimentation is a great for learning about limitations and capabilities; but I personally wouldn't use it as my primary means for learning about the design of something (unless it was very poorly documented, in which case I would try to avoid using it at all).
jacques_chester 14y ago
Incidentally, this is a formula for coming up with PhD projects: take a common comp sci primitive and then remove it or shift it to someplace else in the life cycle or stack. http://chester.id.au/2009/10/21/upsetting-the-natural-order/ http://chester.id.au/2009/10/21/upsetting-the-natural-order/

167 points by achille 14y ago

This is why I use Clojure. I can do Functional, OOP, logic, or any of the dozens of other programming styles in one language. And since it's a lisp I don't have to worry about having to need extra syntax from the language writers to get what I want. Pragmatic languages FTW!

spicyj 14y ago
I interpreted the OP suggesting that you not use a single multiparadigm language because then you won't be forced to follow the new principle everywhere. Of course, it's possible to do (for example) OOP in a lisp-like language, but you'll really be forced to work with it in a language like Java, which may give you a deeper understanding.
- jfb 14y ago
  Well, avoid Java, which is just C++--, and think Smalltalk instead.
  - klez 14y ago
    Therefore Java == C?
    - jfb 14y ago
      Well, only shittier.
    - evincarofautumn 14y ago
      I don’t think programming languages have inverses, so in general λ + 1 − 1 ≠ λ.
oskarkv 14y ago
Your comment gives the impression that Clojure is a big multiparadigm mess. But it is not. Clojure's design is clean and simple. Clojure is mostly functional. Sure, since it's a Lisp one can kind of incorporate other paradigms with macros. But out of the box Clojure does not do Java-style OOP (except for interop) or Prolog-style logic.
- timbaldridge 14y ago
  Perhaps it does place oriented OOP poorly, but it actually has an extremely nice logic engine (see core.logic).
  - oskarkv 14y ago
    Yeah, I know about it, but it's an additional dependency, right? [org.clojure/core.logic "0.7.5"] Whatever, Clojure is clean and simple is what I wanted to say. :)

jonsen 14y ago

Another extreme direction to try out is the direction toward the machine. The value of trying out assembler programming may not have similarly direct benefits. But I personally find it a great general advantage to have detailed knowledge of under which practical conditions your program must run. To know that whatever fancy high level constructs you are making use of, you are always building a giant state machine where space is traded for time.

PieSquared 14y ago
To expand on your suggestion a little, I would suggest going even further - learn how to design your own processors and figure out how the low-level details really work. With hardware description languages such as Verilog, programmers can apply a lot of their knowledge to hardware engineering. I've found that a lot of things carry over from conventional programming languages to HDLs, and that it's incredibly easy to get started. The computer engineering mindset is pretty similar to low-level programming, and really helps you understand how your code runs, even more so than assembly.
- jonsen 14y ago
  Completely agree. I was about to write something like that. I've designed processorlike hardware, but not touched it since the 80'es, so I'm not really confident in state of the art of hardware programming.
- jules 14y ago
  One surprise that you find out when you do this is that languages like C don't efficiently map to hardware at all. Hardware is inherently massively parallel, whereas C is completely serial. What modern hardware is doing to be fast is trying to recover as much fine grain parallelism from a sequential C program as possible using pipelines and out of order execution. We are now at a point where that has been mostly milked out, so explicit parallelism is necessary to gain performance, like SIMD and multiple threads. It's interesting to consider how you can exploit parallelism more easily, for example from going from a sequential instruction set and language to an inherently parallel instruction set and language. Nobody has found the ultimate answer to that yet. GPUs execute thousands of sequential threads in parallel, and while that works for problems with massive and regular parallelism, it does not work for irregular parallelism or parallelism that requires fine grain communication or short lived parallelism or not-so-massive parallelism. FPGAs do work well for those types of parallelism, but they have other problems for general purpose computing. With hardware trends, it's inevitable that we'll see more and more parallelism and eventually a paradigm shift to inherently parallel architectures. Interesting times ahead.

wissler 14y ago

He underrates the power of principle. "Mass is awesome. What if every object in the Universe had mass?" "Liberty is awesome. What if there should be no such thing as slavery and every human being should be free?" If you pick the wrong principle and take it to an extreme, then yes, it'll lead to undesirable results, but that means you should throw bad principles out, not all principles.

lambda 14y ago
Huh? He was advocating for finding a principle and taking it to the extreme. He wasn't discouraging it. Yes, he said that sometimes it won't work; but the whole point of the article is that you can discover and learn new things when you try taking one principle to its logical conclusion. Where did you get the idea that he was arguing against that?
- wissler 14y ago
  Yes, he said to try new principles, he also said not to expect them to really work, which undercuts the motivation for finding really difficult to discern principles.
  - lutusp 14y ago
    > he also said not to expect them to really work, which undercuts the motivation for finding really difficult to discern principles. That would be an argument against science, which labors under the same constraint (i.e. with rare exception, things don't work), but as it turns out it really isn't an argument against science at all, because the rare "thing that works" tends to change the world.
    - wissler 14y ago
      "That would be an argument against science" No. Great science is done by people who are more like Newton and Tesla, not people like you and Edison.

tikhonj 14y ago

I agree with the blog's premise: "extremist" languages are great for language and for research. So this whole rant is not directly related to the post's central thesis. Instead, it's about the assumptions most people have whenever this topic comes up. What I'm a little annoyed with can be summed up with a single banal and overused phrase: "the right tool for the right job". For one, this phrase really doesn't say all that much--it's basically a tautology. Yes, using the right tool would be good, but with programming languages, it's rarely obvious what the right tool is! It's just a specialized version of the advice to "make the right choices", which is not much advice at all. Another problem is that people inevitably ignore how much programming languages overlap. Virtually any languages worth comparing are going to be general-purpose languages. Choosing between a functional language and an OO language is not like choosing between a hammer and a screwdriver to pound in a nail, it's more like choosing between different types of hammer. In a world where hammers can do anything. (I don't know enough about carpentry to extend the analogy properly.) There are very few applications where one language clearly fits and another is clearly unsuited--and if you're in a vertical like that, the question just won't come up in the first place! Another thing that comes up is people assuming that a multi-paradigm language has the benefits of all the paradigms it supports. I've found this is never the case. Even very multi-paradigm languages tend to favor one paradigm or the other more. And even if they didn't, there are benefits to being consistent. You can do much more by being functional everywhere than you can by merely supporting functional programming in some places. Any mix of paradigms is necessarily going to be a compromise, and the advantages of prioritizing one main paradigm can outweigh the flexibility of supporting more than one to any large extent. Doing one thing, and doing it well, is a powerful idea that doesn't stop applying in designing programming languages. Now, I'm not leaning one way or the other here in any comparison of languages (I'm sure my biases are pretty evident and show through, they're just not germane to this comment); I just think that summarily dismissing a language for being too focused or too "extremist" or not multi-paradigm is rather short-sighted. Also, often, unless you've tried doing something in a language yourself, don't assume it's more difficult than what you already know. There is much "common wisdom" about (like "functional programming is bad for GUIs") which is often more "common" than "wisdom".

papsosouid 14y ago

liquidise 14y ago

Awesome article. I would argue this goes for practices as well. Automated Testing vs TDD and the like.

deleted 14y ago

[deleted]

10098 14y ago

That's the right idea for a hobby or research project, but please don't do this in production code. Think about people who have to maintain it after you. I've seen my colleagues wade through a swamp of completely unnecessary C++ metaprogramming madness left by someone who apparently learned about templates yesterday, and it wasn't very nice.

shusso 14y ago
I have to disagree with your first sentence, but the rest I do agree. I think maintenance of the SW should be categorized under "the right tool for the right job". If your company has dozens of skilled "extrimists" then why not use it in production. On the other hand if not..

nickbarone 14y ago

So, could we start a listing of things learned through the application of extremist programming? Or better yet, a listing that shows where a given principle hasn't been extremified, so we can go try it out and see what happens?

drbawb 14y ago

>what if we made an OS where everything was a file? Shameless Plan 9 plug. http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_concepts http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Design_co...

cms07 14y ago
Or, you know, Unix. Edit: Which came from Multics, I know.
- jacques_chester 14y ago
  Plan 9 is the spiritual successor of Unix, because in Unix: Everything Is A File (except for the many, many things which are not files after all).
mahmud 14y ago
I think the author knows of this and avoids to name names for stylistic reasons. I mean, everything he lists has an archetype well-known to anyone with a clue, why be blunt?

w0utert 14y ago

Nice article and interesting viewpoint, taking principles to the extreme for learning purposes seems very useful. The thing that impressed me most isn't the article though, but the amazingly beautiful clean look of that blog. Really a pleasure to look at and read on the iPad :-)

rizzom5000 14y ago

Sure, you could try to treat everything like an object and then find out if an integer was an object (the hard way) or you could just RTFM (the easy way). Don't get me wrong, experimentation is a great for learning about limitations and capabilities; but I personally wouldn't use it as my primary means for learning about the design of something (unless it was very poorly documented, in which case I would try to avoid using it at all).

jacques_chester 14y ago

Incidentally, this is a formula for coming up with PhD projects: take a common comp sci primitive and then remove it or shift it to someplace else in the life cycle or stack. http://chester.id.au/2009/10/21/upsetting-the-natural-order/ http://chester.id.au/2009/10/21/upsetting-the-natural-order/