4 ms·

As usual, the big issue is "do you actually understand the problem you need to solve?". Many problems are complex, either per se or due to constraints outside o

As usual, the big issue is "do you actually understand the problem you need to solve?". Many problems are complex, either per se or due to constraints outside of your control. Maybe you don't like to have to implement a lot of complex code to interact with a terribly programmed legacy app, but if your customer pays you to do that, that's the kind of constraint you cannot really do anything about. When you look at it closely, my feeling is that you'll find a lot of apparently-unnecessary complexity is there for a good reason, and it's our job to make this complexity manageable. It doesn't mean you shouldn't challenge existing paradigms. Innovate! Blow our minds! But just make sure you understand the problem you're solving first :)

seanmcdirmid 12y ago
As a researcher, I have freedom to constantly reinvent things. Complexity melts away the better you understand your problem: ya, it was there, it was needed, but now I know more and I can get rid of this. People in production don't usually have these benefits. I have only made this letter longer because I have not had the time to make it shorter. - Blaise Pascal.
- mercurial 12y ago
  I think that's often true for blue-sky projects. And I agree that a better understanding of the problem can lead to a reduction in complexity, but you cannot always afford it.
  - seanmcdirmid 12y ago
    As long as we are talking about reinventing programming, I think we can afford it. The problem is that once you are in production, you have to ship...this is what I always got from RPG's "worse is better!"
    - mercurial 12y ago
      Of course, it's a matter of tradeoffs. It's particularly interesting to observe how Rust is moving along: since I started watching it, it has undergone a huge quantity of non-trivial changes. Which would tend to show that "worse is better" doesn't work for programming languages. Indeed, languages which have grown organically, like PHP, are not well-regarded. Maybe it's a question of surface: the smaller unpolished surface you expose to the outside, the faster you can ship something which will not turn into PHP later. If your CLI is not well thought-out, it's not a big problem, but you won't be able to make drastic, incompatible changes in syntax and semantics for a programming language with millions of existing lines (ask the Python 3 people :) ).

seanmcdirmid 12y ago

As a researcher, I have freedom to constantly reinvent things. Complexity melts away the better you understand your problem: ya, it was there, it was needed, but now I know more and I can get rid of this. People in production don't usually have these benefits. I have only made this letter longer because I have not had the time to make it shorter. - Blaise Pascal.

mercurial 12y ago
I think that's often true for blue-sky projects. And I agree that a better understanding of the problem can lead to a reduction in complexity, but you cannot always afford it.
- seanmcdirmid 12y ago
  As long as we are talking about reinventing programming, I think we can afford it. The problem is that once you are in production, you have to ship...this is what I always got from RPG's "worse is better!"
  - mercurial 12y ago
    Of course, it's a matter of tradeoffs. It's particularly interesting to observe how Rust is moving along: since I started watching it, it has undergone a huge quantity of non-trivial changes. Which would tend to show that "worse is better" doesn't work for programming languages. Indeed, languages which have grown organically, like PHP, are not well-regarded. Maybe it's a question of surface: the smaller unpolished surface you expose to the outside, the faster you can ship something which will not turn into PHP later. If your CLI is not well thought-out, it's not a big problem, but you won't be able to make drastic, incompatible changes in syntax and semantics for a programming language with millions of existing lines (ask the Python 3 people :) ).