4 ms·
I think these two points are important. From the article: > Object-oriented programming is popular in big companies, because it suits the way they write softwa
by geofft 8y ago
I think these two points are important. From the article:
> Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers.
And from the linked analysis by Jonathan Rees:
> This is related to Lisp being oriented to the solitary hacker and discipline-imposing languages being oriented to social packs, another point you mention.
I would guess that most of the world-changing programming work that can be done is work that requires collaborating with other, unknown people. (But not all! HN itself is a good counterexample, being the work of very few developers and still having a significant influence on the world.) You'll write something at a company, get reorged away (or leave for another job), and someone else will launch it. You'll write some open-source library and years later someone will make something cool with it. You'll contribute to an existing large-scale project, because that gives you leverage you couldn't get from your own project - perhaps because of an inability to replicate the technical accomplishments of the project, but more likely an inability to replicate the network effects of it already having users. You'll build a prototype of something that proves something is doable, but gets significantly rewritten before it goes into production.
If you're interested in these problems, it's in your interest to work in a language that lends itself to other unknown people picking up your work and running with it. If you want to make single-hacker scale projects that will not grow much beyond you, there's nothing wrong with that - but I think you have to be either lucky or able to commit time for the next several years if you want your project to get traction.
- pdimitar 8y agoWhy is there never a spectrum? Why is it always a "single-hacker project" vs. "a huge project with tens or hundreds of contributors"? Why is it always in these discussions that the concept of the functional languages gets hijacked to "they are only used by hackers"? (And what does "hacker" even mean in this context? The word has like 50 meanings already.) This fabricated extreme dichotomy is killing the discussion. Every time. And it's sad. We the techies are supposed to be objective and act on a meritocratic basis. I get very disappointed every time I see us just bickering over imaginary strawmen.
- geofft 8y agoI think the dichotomy is from 'pg in this case. I myself like using languages with a balance between the two extremes - Python, being neither the stereotypically enterprisey Java nor the stereotypically write-only Perl, being a good example. They allow me to be productive with single-person projects without overhead, and they're also suited to being used for large-scale projects once you start imposing some structure. The only thing is you have to be willing to start imposing some structure at some point, and the language has to make that easy, too. It can't be solely suited for the single hacker; it can't have been designed under the assumption that a language for use by large teams of people dispersed over time and space is one designed for "mediocre programmers," and so the things such a language values must be categorically avoided.
- pdimitar 8y ago> it can't have been designed under the assumption that a language for use by large teams of people dispersed over time and space is one designed for "mediocre programmers," I don't know why people find this an offensive statement. EVERY craft on this planet has a pretty small (in terms of percentage) group of people who just grok it and "get it" fantastically well, and everybody else in the profession is pretty average. That's nothing to be offended at: the bell curve distribution is in full effect there. Perfectly normal, no? And I would argue with you that some languages -- Go being the most modern example -- are specifically designed to be an easy onboard for people with certain backgrouns (C/C++/Java). That Java has been designed to be an easy onboard for people with C/C++ experience is pretty much a documented historical fact at this point as well. Large companies optimize for quantity, not quality. There's nothing shameful in admitting: "we need a horde of not-amazing programmers who we can treat as interchangeable nuts and bolts"... yet everybody is denying it, when reality clearly shows that's their exact attitude... really makes me wonder why people keep insisting on keeping that circus alive and well (I also heard managers speak of people like that, in expensive saunas and restaurants -- and they were talking quite loudly). Most corporations don't need craftsmen and artisans; they need prentices who build houses with already-made plans. I am asking for the umpteenth time -- why is this such a bad thing to admit? We cannot all be amazing programmers in each and every way. We have to stop denying this reality. > I myself like using languages with a balance between the two extremes Same, that's why I code Elixir: it's FP alright but not "pure" -- has side effects but the edges are clearly documented. And we can't get anything done without side effects anyway. So it's like 95% FP and 5% everything else, in the right places. Perfect. > I think the dichotomy is from 'pg in this case. I don't know enough about @pg to claim anything but whatever he said, that's no excuse for everybody else to start gravitating into camps. When people ask me "do you hate Java or do you hate C#?", you know what I say? "I hate the people who hate programmers based on what they work with."