4 ms·

Which in the end is actually a nice thing because that means the guiding principles were right. Tooling is just driven by one of the primary attributes an engi

Which in the end is actually a nice thing because that means the guiding principles were right. Tooling is just driven by one of the primary attributes an engineer should have: an abundance of lazyness that strives to find solutions for the long run.

effie 9y ago
Just the mainstream programming not changing that much does not mean that the guiding principles were right, it just means that the original ideas of computers and programming worked well enough to sustain themselves and win and maintain the place of mainstream way of automating things with computers. Once conventions are set and basic computer systems (platforms) get built, building anything new will most probably be done in the same paradigm, even if there is a better way of doing things. Consider the C language, which was very successful and today is a mainstream language via which we develop and control vast majority of computer systems. Programming in C today is, I think, very similar to programming in C when it was introduced. Would you say, considering the experience of those decades, that we use C because the principles of C were right? Or did we just get stuck with it because it was good enough in 70's and now it's too hard to detach ourselves from it?
- marenkay 9y ago
  I think you are mixing up things here. I am talking about principles on how to solve tasks in programming, you are talking about differences in programming languages. But the thing is: what is right in programming was the same in C 40 years ago and is exactly still the same if you use Erlang. And it is also the reason why many old programs still work because previous generations applied the basic principles much more diligent than we do (because there is the next NodeJS around the corer, etc. smirking)
maxxxxx 9y ago
We are still writing instructions into text files and executing them sequentially. Threading is still difficult to get right. There are still no good tools for understanding a codebase. Honestly I thought by now we would be interacting on a much higher and richer level with the machine.
- dasmoth 9y ago
  Honestly I thought by now we would be interacting on a much higher and richer level with the machine Smalltalk took some steps in this direction, and saw a degree of commercial use in the 90s. For the matter, fire up a REPL from your favourite LISP and you'll have a more interactive experience than most mainstream languages offer. There are still attempts to move in this direction. "Notebook" interfaces which are kind-of popular with data scientists in some fields. Swift playgrounds. I think what's prevented interactive environments gaining more traction is pretty much the same thing that's driving a lot of the trends in the linked article: what is being optimised is fine-grained collaboration and discipline within teams at the expense of flair and individuality. The modernist developer is getting unit tests to pass, not playing in an interactive interface.

effie 9y ago

Just the mainstream programming not changing that much does not mean that the guiding principles were right, it just means that the original ideas of computers and programming worked well enough to sustain themselves and win and maintain the place of mainstream way of automating things with computers. Once conventions are set and basic computer systems (platforms) get built, building anything new will most probably be done in the same paradigm, even if there is a better way of doing things. Consider the C language, which was very successful and today is a mainstream language via which we develop and control vast majority of computer systems. Programming in C today is, I think, very similar to programming in C when it was introduced. Would you say, considering the experience of those decades, that we use C because the principles of C were right? Or did we just get stuck with it because it was good enough in 70's and now it's too hard to detach ourselves from it?

marenkay 9y ago
I think you are mixing up things here. I am talking about principles on how to solve tasks in programming, you are talking about differences in programming languages. But the thing is: what is right in programming was the same in C 40 years ago and is exactly still the same if you use Erlang. And it is also the reason why many old programs still work because previous generations applied the basic principles much more diligent than we do (because there is the next NodeJS around the corer, etc. smirking)

maxxxxx 9y ago

We are still writing instructions into text files and executing them sequentially. Threading is still difficult to get right. There are still no good tools for understanding a codebase. Honestly I thought by now we would be interacting on a much higher and richer level with the machine.

dasmoth 9y ago
Honestly I thought by now we would be interacting on a much higher and richer level with the machine Smalltalk took some steps in this direction, and saw a degree of commercial use in the 90s. For the matter, fire up a REPL from your favourite LISP and you'll have a more interactive experience than most mainstream languages offer. There are still attempts to move in this direction. "Notebook" interfaces which are kind-of popular with data scientists in some fields. Swift playgrounds. I think what's prevented interactive environments gaining more traction is pretty much the same thing that's driving a lot of the trends in the linked article: what is being optimised is fine-grained collaboration and discipline within teams at the expense of flair and individuality. The modernist developer is getting unit tests to pass, not playing in an interactive interface.