Only tangentially related, but the "rant" by Ryan Dahl (node creator) when he left Node day-to-day is worth a read:
I'm sorry, I just can't get over it. "Just solve the problem" - I hate that attitude. That's how shitty software is born. Incompetent schmucks give birth to unholy, unmaintainable, monolithic code because they think it's okay to not know your shit as long as you "solve" the problem.
Look, you can't just throw cheap shots, that's all deuche. What was the need for calling him an idiot or incompetent?
But, I would not want Ryan writing code that people completely trust to live on (hospital equipment, NASA, etc).
That does not make him an incompetent person. Just someone with opinions of wanting to keep things as minimalistic as possible which is just one of the many paths available for us to choose in life. In some cases, this is great, in others it is not.
Diversity is good anyways.
Just like I wouldn't expect a civil engineer to build a bridge in a suburb capable of holding 5 Tons because "NASA does it that way because their spaceships are heavy" I wouldn't expect the same guarantees from software engineers writing an image sharing application.
---
"The only interesting languages are C/C++, Go, Dart, JS (and possibly Rust). Everything else is legacy bullshit."
"Node.js has linear speedup over multiple cores for web servers.”
There is also the one about math not being useful for computer programmers and how programming is just like playing with duplo block and legos.
---
I don't know. Node scaling linearly over multiple cores. I can see how many would agree with you saying he created node.js but might think twice about the schmuck label.
Note also that Ryan is a mathematician. Mathematicians hate engineering because there's nothing to protect real-world systems from little accidents that compound over time. No proof, no piece of code, no matter how elegant, can reverse the thousands of bad design decisions that have resulted in the modern Linux ecosystem.
Hell no. Software comes from software development. And software development is a process. My editor, programming style, directory structures and other personal organizational behaviours do matter. This is work we do, and while the end user's experience may be identical regardless of very different personal development style options, the one which gives me the most comfort and work satisfaction is superior. So yes, I will configure my editor so that I don't have to keep repeating the same keystrokes dozens of times throughout the day. I will align things the way I see fit, and I will endeavour to study and improve my skill with the language. Not only so that I'm more efficient, but because it will bring increased contentment to the process of development.
Only nobody cares about you.
As in a restaurant, people care about the food, not the cook.
And even if you (and I) mattered, developers of a piece of software are N, where users are 1000N or 100000000N. They matter massively more.
Oh, and there will always be programmers as long as there are money to be made, so the "without me [in particular] there would be no software" argument doesn't hold much either.
The health inspectors care about both the food and the cook, and the latter's workflow is certainly scrutinized.
If we're going to beat this analogy to a bloody pulp, the health inspector in software land would be technical debt and colleagues.
Not taking care of the process will bury the project, and the users with it. Ryan Dahl's brilliant, but I don't think his entire statement should be adhered to verbatim. It's solid guiding principle, nothing more.
What a different industry it would be if all software required independent audits and the public could get access to the results.
I care about how code is written, because I'll have to work on it. My employers care about how code is written, because our reputation is on the line.
It's about solving problems, certainly, but workflows directly contribute to solving problems better, faster and more reliably.
Similarly companies too crazy about short term shareholder value find that it takes committed employees to get long term results.
Except me, I care about me.
And I don't want to use crappy and shitty tools. I want to use good tools. I am less productive when I use crappy tools, it can be done, but then a lot of time is spent fighting the tools not really solving problem.
> Oh, and there will always be programmers as long as there are money to be made
There are not that many good programmers. Or at least they are not the ones throwing resumes around. One has to find them, if they are good they are probably already in a good place and are not looking for job. So you just taking anyone from the street because they did some VBScript in High School you are going to replace one good programmers with even 100 incompetent ones. It is just not how it works.
Neither does Ryan. That's what the whole rant is about. He just wants to make software for users without having to hack through the forest of bad design decisions that is the modern Linux system.
Spoiler: Most software you create wont be around in 10 years: http://www.youtube.com/watch?v=zut2NLMVL_k&feature=youtu.be
What matters is the value it delivers in the meantime, which is ultimately the end-user result - not how you got there.
Yes, in the end, the software won't be around, in fact nor will those who derived value from it. All that will matter is how you got there.
>Spoiler: Most software you create wont be around in 10 years
I was working for a start up about about 5 years ago working on a the reporting system for measuring customer metrics, the data was granular enough that we allowed the customer to drill down to the per-hour activity level. As a result it was deemed important to represent the data in the customer's timezone. To "future proof" the system we had a table indicating when to shift an hour for daylight savings time. I populated the table to go out 25 years I think. My manager asked me "what happens in 2033?". But after a moment of thought he came to the same conclusion you did and 25 years was deemed sufficient.
That is true, but the experience of the people developing the software matters too, as it informs the care that will be put into creating a better user experience.
Let's say you're creating an application and you're the sole developer and designer of that application. When you have a predictable and reliable development environment that emphasizes good, well defined practices, you reach a state of flow with more ease when you're coding, and your project gets developed faster. Faster development allows you to iterate quickly and better test your assumptions about the user interface and the overall user experience. It gives you more time to design the application. All in all, with a better development experience, the developer gets more time to create a better experience for the user.
I bet Ryan's frustrations—all the abstractions and crappy interfaces—come from years of legacy technologies and the need for compatibility and integration with other systems, and sometimes as preemptive measures to avoid security issues. When they were made, there was a reason for their existence.
http://www.vpri.org/pdf/tr2010004_steps10.pdf
STEPS Toward Expressive Programming Systems, 2010 Progress Report Submitted to the National Science Foundation (NSF) October 2010 Alan Kay et al
"If computing is important—for daily life, learning, business, national defense, jobs, and more — then qualitatively advancing computing is extremely important. For example, many software systems today are made from millions to hundreds of millions of lines of program code that is too large, complex and fragile to be improved, fixed, or integrated. (One hundred million lines of code at 50 lines per page is 5000 books of 400 pages each! This is beyond human scale.) What if this could be made literally 1000 times smaller — or more? And made more powerful, clear, simple, and robust? This would bring one of the most important technologies of our time from a state that is almost out of human reach—and dangerously close to being out of control—back into human scale.
(...)
Previous STEPS Results
The first three years were devoted to making much smaller, simpler, and more readable versions of many of the prime parts of personal computing, including: graphics and sound, viewing/windowing, UIs, text, composition, cells, TCP/IP, etc. These have turned out well (they are chronicled in previous NSF reports and in our papers and memos). For example, essentially all of standard personal computing graphics can be created from scratch in the Nile language in a little more than 300 lines of code. Nile itself can be made in a little over 100 lines of code in the OMeta metalanguage, and optimized to run acceptably in real‐time (also in OMeta) in another 700 lines. OMeta can be made in itself and optimized in about 100 lines of code."
More:
http://www.vpri.org/pdf/tr2011004_steps11.pdf
"This year we are able to write this entire report in the Frank part of STEPS, including producing the PDF version for NSF’s web site. We can give comprehensive high‐quality, high‐resolution presentations using STEPS which include live code and in situ demos, and which show working versions of a number of the document types derived from the STEPS “universal document”."
So yes, they have something that is working. Unfortunately, as far as I can figure out - the "Frank part of STEPS" isn't really available as such.
There's a few thing to play with, like:
http://piumarta.com/software/cola/
http://lukego.livejournal.com/16036.html key quote: "Here's what a hello-world-esque operating system looks like"
There's also:
svn co http://piumarta.com/svn2/idst/trunk idst
head -2 idst/function/examples/tcp/00_README
This example demonstrates an alternate 'shell' for
Jolt and how to build a tiny TCP/IP stack using it.
Sure, down in the trenches it makes you want to pull your hear out. And the world would probably be more productive if software interfaces and programming languages were completely frictionless. But it would also make programming, to me, less fun, challenging, and enjoyable.
We are imperfect beings living in an imperfect world, and I don't think changing the status of either or the former or the latter would create the nirvana ry is alluding to.
The problem is that the wrong things are fucked and that's neither challenging nor fun.
E.g configuring some system so you can get your software built correctly is neither fun not challenging. It's merely tedious busy-work. Actually solving problems, that's the fun part.
One man's tedium is another man's pleasure, as much as I too enjoy solving the bigger-picture problems. There's a reason both Gentoo and Arch exist :)
And what you're saying is precisely what I'm disagreeing with. I'm sure there are people that like those things (mostly beginner's with Unix and such, tinkerers etc). It's a form of passtime.
That doesn't mean it's challenging in any creative way. It's a boring ass brain puzzle that tons of people are solving again and again.
The sense of "accomplishment" of getting the dependencies to build X right, might be valid if you just started building things and getting to know how compilers, libs etc work, but it's grows old very quickly for normal people and it's a false accomplishment after that initial stage.
Actually saying you enjoy that is like saying you like boilerplate code, because that's exactly what it amounts to.
>It might not be the kind of fun and challenging you're looking for, but please, try not to state state opinion as fact.
Sure, you can find people that like everything, even the most boring ass shit. I'm sure there are people that enjoy calculating logarithms manually too. But I wouldn't call such bizarro outlier fun as fun in the accepted sense.
But it's a fact (I've seldom seen anyone state the opposite, tons of texts from Stack Overflow to blog posts support this) that most programmers/hackers tear their hair out to get rid of those "fun" tedious configuration/setup/figuring dependencies etc work and move to the real part.
I've actually never read an interview with a hero programmer where he said that he likes those parts of programming -- but have read tons of those that say the exact opposite, from Alan Kay to Jamie Zawinsky.
Actually a large part of programming is exactly about removing (automating) those tedious parts.
By the way, your post comes off as unnecessarily rude.