Dewie3

> (1) where does Rust fit in this?

It doesn't. Not any more than other languages anyway.

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.

When pron posts on a thread about lang X, it tends to be 30% about lang X and 70% raving about the JVM platform.

Ah yes, embracing your inner elitist.

Ditto.

That doesn't look like much of a trade-off in the context of the article, though. Namely living in civilization.

> 2. Women are less prone to overconfidence

> 3. Women are more ambitious

Well okay.

People here seem to like talking about trade-offs, specifically technical ones. Maybe intelligence is just another trade-off.

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.

Non-standard character set aside; is the terseness (one-letter commands and such) partly because of the slow input devices at the time?

> It's circling the wagons around people who had the privilege and opportunity to learn these things before everybody else.

The underprivileged Bloomberg readership.

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.

[2] Or whatever the equivalent is in D.

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).

[1] http://en.wikipedia.org/wiki/Rule_of_least_power

I thought JS was intended to be a Scheme in disguise?

Static FP languages just feel so natural for compilers - the AST can often be perfectly naturally expressed with algebraic data types. Then you want to traverse the tree and do certain things when subtrees or nodes are of a certain shape... which turns out that pattern matching can express very nicely.

I doubt that there are nicer general purpose languages than languages like Ocaml for compiler stuff, and symbolic execution somewhat by extension. Maybe languages that have more powerful matching and maybe even term rewriting, but I don't know if they would be considered general purpose (at least fairly fringe).

Kind of like how calling programs for proofs seems to make most programmers uneasy. (Not that most programs that you'll run into are proofs in any interesting sense.)

Does this brilliant webpage not know the concept of skimming and related approaches?

And I need to scroll horizontally to read the whole page. Though I guess it's easy to copy/paste into a text editor and read it there since the text is so plain.

> In that case it comes down to economics,

It doesn't come down to it: it was about economics all along. All these philosophies -- polyglot, more monoglot, etc. -- have costs. You can choose to ignore it sometimes by staunchly recommending one approach over another in generic settings. But the underlying costs are still there.

Is an English-speaking conference in a non-English speaking country in this day and age really that weird? I don't get why. I guess conferences tend to have an explanation? Except when the explanation is "obvious" (warm subtropical/"Mediterranean" setting...).

Alternative, glib answer: because computing shouldn't be confined to the US, or I guess places like London in this case.

> e.g., for me it's German, English, Chinese

I don't think we needed an example in order to understand "speaks more than his native language".

I'm interested in programming languages. But I don't know if I'm really a polyglot programmer. Ideally I want to be able to rely on a handful of languages for the vast majority of things that I want to do. If I'm being idealistic, maybe it would be possible to rely on two, or even just one.

But this "one" language would probably have the power to express its own EDSLs for different domains and problems (like Lisps). So in effect, maybe you could say it's many different languages in one. So why not just use many different programming languages instead of one extensible one...?

Because general purpose programming languages seem to end up feeling too monolithic when considering that they might only be used by you for that one thing. Consider two approaches: have one language that solves problems in domain A really well. Then you want to solve problems in domain B really well. But the first language is not suited for that. So you use a totally different language for that. Maybe it has its own interpreter/compiler/library and specification. Maybe you need to interoperate between these languages. What do you do? Inter-language communication seems to be in a sorry state, if the Unix philosophy of "strings anywhere" is the prevailing philosophy. I guess we're supposed to use Json now, perhaps? Corba is dead. I saw a thick old book about it where I work and didn't feel inspired.

Compare that to having a language where you can express domain B more clearly in the first language. It turns out that there was some friction and ceremony with expressing domain B in the first language, but being able to express this as as EDSL -- maybe by using something like macros -- gets you 90-100% of the benefits of using a totally new language. Additionally, there is less underlying complexity -- you have one language derived from the other using constructs from the original language. And ideally you can inspect and unfold this implementation; go through a few layers of macros, perhaps. Contrast this with having two wholly separate languages with their own runtimes, libraries and what have you.

This might be a philosophy of building layers of languages -- actually, probably more like a tree. Or maybe a DAG if you have several implementations that express the same DSL. Contrast this with several distinct implementations of monolithic languages, which probably have no knowledge of each other (languages tend to end up shallowly similar, but subtle in many many small ways; probably Turing Complete which makes analysis tricky or at least not straightforward, certainly not reliable...). But when looked at in isolation they look simple; hey this language is really good at expressing X. It doesn't have that many user-visible constructs. Simplicity! Only when you look at the bigger picture, you see how much effort and code that goes into implementing software that is subtly different, only to give the feeling of simplicity when looked at more in isolation from the whole overarching system.

Some people will look at you in horror if you suggest using a powerful and expressive language. A language that can effectively express a lot of 'languages'. They find things like operator overloading disgusting, because code should look uniform and it should be "obvious" what it is doing. Then they choose to involve 12 different programming languages on a project, because that is obviously good engineering practice. The right tool for the job! The fact that they have to learn and deal with so many languages is apparently trivial to them. The difference between the semantics and ecosystems of a dozen different programming languages is simpler then learning about and judiciously using operator overloading, I guess.

I am not trying to diminish the need for programming languages -- they seem incredibly hard to design, and the more I read about them the more I get convinced of that. There are ever more considerations that they can choose to care about, potentially at the expense of something else immediately next to it or maybe something far away. It doesn't seem like the ones who are designing them are close to converging on designs that express many of the problems that programming languages can/should care about. I look forward to seeing more language (designs) -- hopefully ambitious ones. :-)

tl:dr; I should learn a Lisp. Code truly is data, or it should be. But not even Lisp is able to do everything with sufficiently many macros, it seems.

In other words, not an anti pattern.

> I totally agree with the author that the tickets we're assigned are all puzzles that I could lose myself in and inevitably get some feeling of satisfaction when I figure it out. But in the grand scheme of things, most of us aren't working on problems of real significance (eg. curing cancer, creating a more efficient battery).

So what? Most people aren't curing cancer, or doing anything more of value than their paycheck reflects. And maybe the value of our paycheck is really inflated, even. In the end we are just floating on a giant ~ball through space and maybe someday we'll have a cataclysmic event that undoes all of our social and scientific progress. Stop thinking that you have to be some special snowflake, relax, and maybe you'll find that you can find pleasure in the little, mundane stuff. In the end, they're all we really have.

aka, "Try not to worry your pretty little head with it if you can avoid it". This post has a high condescension density.

You say that you stay with Ruby because of metaprogramming. Yet I suspect that it is in statically typed languages where we'll see metaprogramming that is both powerful and principled (legible, understandable, won't eat your laundry). C++'s templates are powerful, though ugly; the C preprocessor seems to be regarded as an inferior form of metaprogramming, to be avoided in newer language designs. On the other hand, there are statically dependently typed languages that collapse the type and value level, letting you make things like type functions. There is also multi-stage programming -- why choose between evaluating code at runtime or compile time when you can choose to evaluate it at compile time, runtime, or any arbitrary stage in between? (Yeah, this one is pretty wonky and I don't know if I've fully gotten the utility yet. But it might actually make for a new kind of dimension of abstraction -- letting you build up multiple layers of interpretation, and inspecting the different layers when you want to investigate what they do. I guess. In any case the motivation is to be able to write high-level code that ultimately gets "compiled" down to efficient, specialized code.)

Or maybe dynamic Lisp languages will stay the kings of metaprogramming. But it's still in the same spirit -- macros, which are static metaprogramming constructs.

Why is his profile picture the attractions road sign as seen in Scandinavia? :-)

Everyone quits because they have the opportunity to do it. If he didn't have enough cash to be unemployed on an indefinite basis, or the willingness to start his own tech gig, maybe he would have become a farm hand in Wyoming just to get away from it all. Then someone would have yelled Hipster!!! in the comments section. Or You don't know how easy you had it! You'll be back soon once you can't take the blisters and sore knees!.