> You're projecting that the person's literary references are "name dropping things in largely irrelevant contexts".
I wasn't talking about literary references.
> and goes out of their way to seem elitist.
The goal of someone who is elitist isn't really to come across as elitist, dude...
> Are you sensitive that you didn't get into a school like MIT?
I got into the school that I applied for. No, you haven't heard of it; no, it isn't prestigious.
See, this is the thing with elitism. It is easy to dismiss people that are put off by it as jealousy. If I am put off by someone who thinks he is hot shit for listening to Mozart, it's not because I have anything against classical music or people who listen to classical music. It is because I don't like people who thinks they are special for listening to <thing>.
It's weird to see so many of these "Go is a cleaned up/incremental step up from C" when
1) There have been plenty of natively compiled, garbage collected languages without much more fuzz than that before.
2) It seems more popular with people with a Python, Ruby etc. background rather than a C++ background (which was originally suspected would be a decent audience) or a C background.
Maybe these programming in the large languages don't necessarily have to be fantastic for programming in the large, and in the long term. But they have to be great for this at least in the short term. So imagine that such a language shows itself to be good for making medium-scale applications in the first year (assuming that large-scale applications take longer to become "large-scale"). The code is uniform, people can easily get up to speed with whatever section they are working on, there are no big surprises - great. This language gets adopted in more projects because of the initial rite of passage, and some luck and marketing (hype and random factors seems to be given for new technology, in the short term). So more projects spring up following the same model. These also work great, and by now we have a handful of new, discovered concepts associated with learning and using the language. The language, ecosystem and implementations are still lean and easy to comprehend. And so some years pass.
Now this language is actually used for large applications. It's still all gravy, the code bases are still uniform and easy to understand. People can easily be trained. More projects adopt this language, or even use it to build things from scratch. It gets applied to more domains. Years pass, and things that were unobservable in the beginning start to rear its head. They weren't non-existing, but they were so minuscule in this large landscape (remember - big adoption of this language) that it was unobservable from the bigger picture. Now what was a problem for a few developers seems to be a problem for many people. For a while, they solve this pain point by educating about certain patterns to look out for and solve. This works for a while, but after a while more pain points become apparent. And like for the initial pain point, it is just not a pain point for a small group of ignorable developers, but indeed a systemic one. There seems to be something wrong. We can't simply solve this pain point with education and applying patterns - we need abstractions. There is some murmur about this - the principal point about this language was to avoid over-abstracting things. We need to practice constraint. This works for a while, but after some time the concerned voices of the people advocating this kind of restraint gets drowned out. These limitations are just too much for people to deal with. So people start suggesting and inventing so-called abstractions. And pain points are relieved. After a while you have a whole cottage industry of these abstractions. And people's day to day life with this language and its associated code bases are happier and more productive. On the other hand, there is more to learn now, and things aren't straightforward any more. You can't simply look up a library and have flat, easy to read code. You also need to learn the associated abstractions. You also notice that the technologies associated with these abstractions are getting kind of big. They are starting to take on a life of their own. And it seems like they don't really fit. Some of them feel kind of shoe-horned in, as if there was no general slot for them already installed, it just had to be jammed in there.
Now, is this language good for large-scale development? The language is still easy to learn. Somehow. There was a bunch of additions up through the years to ease some pain points. Not all of jive as well with each other, or with the original language. But with some elbow grease, it is perfectly serviceable. Not to mention all the associated technology that cropped up to assist the language in its ascent - that is the hard part. So the language is not really easy to learn any more, with the associated things. But people know it, there are code bases to maintain and it has proven that it isn't useless.
Is the language good for large-scale development? Doesn't matter. It already won and is here to stay.
> And you demonstrate (usefully, I think) the mistake of confusing complex and/or erudite speech/vocab with arrogance.
There is nothing complex, hard to understand or erudite about "I went to MIT", "my wife is well-read" or "as a nerd being among other nerds is nice". Though I guess having studied at MIT implies that you have great knowledge, so is erudite in that kind of indirect way.
As to the rest of your post, I do not (mis)attribute speech which shows that the person is intelligent or knows things that I don't understand at all. I am comfortable with that. The person has to also come off as trying to show off, as opposed to just talking about what they're interested in. But I appreciate your stab at an analysis of my insecurities.
And yes I had to look up what erudite means.
> Speaking intelligently can be (often is) like serving a plate of delicate, complex food in front of someone who isn't interested in this "pansy bullshit" and just wants a hot dog. And it hurts the same way, because what you prepared for them really is amazing, and not only is the effort not appreciated, but the recipient interprets the offer as an insult. This is a very painful experience, and you learn to take great care to learn who is expecting a gourmet conversation and who is not.
This thinking often leads to elitist attitudes. Some things are more complex or harder to get into than other things. That doesn't mean that they are superior to entertain. It might show that the person who appreciates them has a certain intellect, or whatever, but not ttat the thing itself is inherently good. I used to think this way about a certain medium - why can't people appreciate this thing that I showed them? Can't they see that it is better crafted, more thought out, more beautiful than that other thing that they are currently interested in? Then I stopped looking at it as a matter of appreciating ever-more complex, hard and well-crafted things and just as appreciating the thing for itself. If two people enjoy two different things equally, does it matter which one is superior by some objective standard? No. It's just a bullshit distraction.
For a second I thought someone had submitted this article with their phone and by mistake left one of those "sent from my <Samsung?>" in as a trailing message.
Funny that the original intent for the Go creators was to not have to write C++[1] -- which of course is in the C/C++/Rust/D space -- and that Rob Pike seemed surprised that more C++ programmers didn't make the switch.
The two languages seem to diverge when it comes to the fact that Walter Bright seems to like to write both expressive and high-performance code (meaning, at the same time). That kind of philosophy tends to lead to iterators, generators[2] etc. which Go seems to look at as superfluous -- just write a for loop, more or less.
[1] Write C++ for the particular software that they make, anyway.
You have some points which are to a point, and in general, true. But you present them in such a ridiculously hyperbolic way that it seems divorced from reality.
Applicative is a pretty standard type class which are often used in introductory resources. It is not likely to be replaced by anything any time soon. If you think that it is a fashion then you should have an idea about what it can/is likely to be replaceable by. So, please do tell.
If anything, Applicative might be less controversial than Monad. I haven't really seen much complaints about the downsides of the usages of Applicative.
"Barbarian" - of course any fairly level-headed explanation of Haskell concepts gets regarded as elitist. It's practically a cliché at this point.
Lazy evaluation - this was pretty much the whole point of the language. A fashion? It permeates the language, being the default evaluation strategy after all. But it is controversial whether it is better than strict (eager?) evaluation. If opinions change about this it might be because someone unearths some way to get more of the benefits of lazy evaluation, and less of the space leaks. And potential discoveries are kind of the point of research languages like this.
I think this is a bad comparison. If you're, say, reading music in order to play it, why would you need things like functions and renamings in order to read it? Just read it straight off - one bar at the time. There isn't any need to have some kind of "pattern" or "abstraction" that compresses 20 bars into "this one thing, more or less". And you would have to read all of it to play the piece faithfully anyway. Maybe there is some utility to be able to say "I don't care about the nuances; just show me the general structure right now". I don't know, I'm not a composer.
On the other hand, it is of course tremendously useful in programming to look at some lines of code and be able to say "Oh, so this code this and that", then moving on. If you want more details, dive into that section more. You soar over the code to get an overview and dive down for more specifics when you need to. A music piece can be read (and played) from beginning to end, but that is less useful in programming. Maybe for a late evening with a bottle of wine when you want to appreciate the beauty of a code base that you really like, I guess.
That refactor is of a common pattern (I've seen it before; I've probably written it myself) into a bog-standard use of Applicative code. This use is pretty much the introductory example for Applicative. Do you use Haskell? Because Applicative is fairly well-known, and the operators etc. aren't considered esoteric and they are not something you are likely to have to learn when you encounter them. If you don't use Haskell, on the other hand, I don't see how you are in a position to critique the readability of a refactor.
The philosophy at play here is probably not code golf as much as it is about the principle of least power[1]. Applicative is strictly less powerful than Monad. So when reading Applicative code, there is less stuff to look out for -- it is great to be able to know what an expression can't do, when reading it.
Maybe the do-notation makes it look prettier, but I don't know if it makes it more readable. Maybe more superficially look like imperative code which makes one think Oh, I get this. But it might be a false sense of safety. In any case, I guess Applicative do notation can be used (at some point).