quatrevingts

As the article notes, that's because CPUs are designed to run existing C code fast. You could create an instruction set that provided this control, but it might be a tough sell in a world full of C code.

I think the contradictions are pretty clear: it raises prices, but holdouts sell cheap; it's a shit neighborhood that no one wants to live in because it's too crowded...

And the hypothetical boxed-in holdout scenario is simply not representative of what's happening in high demand areas in the US. We're preserving laundromats and parking lots in San Francisco and Manhattan. No one is trying to build towers in the middle of suburbia.

YIMBYism simultaneously raises prices (presumably for the greedy developers and sellouts) and lowers them (for the noble neighborhood defenders who are forced to sell). Got it.

As a layout and rendering toolkit, the modern web browser is just head and shoulders above everything else in terms of features and ease of use.

As problematic as CSS is, getting things in the right place is still dramatically easier than with Swing LayoutManagers, and when you do have problems, you have great tools in the browser to explain what's going on.

Browsers particularly shine in text rendering, naturally; text styling, font selection, word wrapping, etc. are all easily configurable. You want bold text next to regular text in Swing? You either need two JLabels, or you wrap your text in <html> tags and let the embedded HTML 3.2 renderer do it.

The built-in version has the big advantage that it integrates well with tools: you can statically determine the target of the reference and jump to it.

Incomplete, not inconsistent; i.e., not everything that is true is provable.

No, fmap is still an explicit operation.

The unspoilt countryside can certainly be pleasant, at least for the few that are well-off retired, or don't need access to an urban center to make a decent living, and don't mind driving an hour to do anything.

Start putting McMansions and Applebees in the countryside, and it becomes spoiled rather quickly.

He states that H-M is not used because of the lack of reified generics, which is completely irrelevant. (Hint: type systems perform analysis at compile time; "reified generics" means having type arguments available at run-time.) H-M is not used because it is not compatible with subtyping or method overloading, which are both critical for Java interop. There is no particular reason that Scala needs to use exactly the H-M system.

That is exactly what it means.

Do you have any experience with the inverse statement? That is, have you had a good experience with optional types in an enterprise context?

I'm curious how many runtime errors persist due to the optionality of the type system. Perhaps code standards requiring all "library" code to be typed would be a good balance.

I love doing blind wine tasting, and I do it every time I can get enough people together who are down for it. That said, I think it's easy to draw a hasty conclusion from a very small sample of wines.

The thing with wine is that, regardless of price, there is a huge variation between wines at any price point, and a huge variation between individuals' palates. Until you know what you like, then you should expect that, with a set of randomly chosen wines, there will only be a mild correlation between price and enjoyment.

On the other hand, once you know that, for example, you like aged traditional Barolos and don't care much for Napa cabs, then it won't surprise you if you like the $40 Barolo more than the $150 cab.

To be fair, this is a list of everything inherited, not just one level up, but the full transitive closure. All of the Gen* classes arrived with 2.9 when parallel collections were added.

Also, the implicits shown are any implicits which can be invoked on Iterable, which includes all implicits which can be invoked on Any.

This hardly even saves any LOC over the original two versions, and requires the reader to understand these new annotations. This is what happens when programmers get obsessed with some arbitrary notion of "elegance": they fiddle with the fundamental semantics of a language to save a couple lines of code and end up with an unreadable mess of cute tricks piled on cute tricks.

If only Python supported multi-line lambdas...

I'm curious what the cost would be of implementing generics by having an (implicit) parameter for the element size. It would certainly be a bit slower than the fully specialized version, but it avoids boxing and doesn't duplicate code.

These criticisms of exception handling are primarily based on their implementation in C++; they are not issues inherent in exceptions. Exceptions are clearly more problematic when they are bolted-on after the fact to a language with manual memory management and a large existing body of code that is unaware of them.

But writing exception-safe code IS trivial, in basically any language except C++. Garbage collection is all you need in most cases, and try-with-resources/RAII/etc takes care of closing I/O.

Note that Go still needs defer() to reliably take care of the latter, so it's not clear to me what is gained by the omission (or rather, strong deprecation) of exceptions.

I am highly skeptical that they are actively investigating ways to support generics, or that they are willing to change anything else about the language to support them better.

This statement, part of the standard Go talking points, seems to be designed to persuade the unsure to give the language a chance, "and generics will be around later once we figure it out." Not likely.

I think the designers know that no perfect shining implementation of generics--compatible with all of Go's existing design decisions--is going to arise deus ex machina after eluding researchers for all these years.

Yes. Not sure how much I feel like talking about generics and error handling again, but those are the first two reasons. I can respect them wanting error conditions to be explicit, but then they give you no acceptable way of dealing with them -- perhaps because proven techniques from the functional world would require parametric polymorphism, or yet more built-ins from the language designers.

Except that you lose type safety (or write an implementation for every permutation of types..)

And since it's at runtime, strike out the "much of it redundant, requiring a good linker.." bits. Which leaves it sounding pretty good.

You'd really be OK with gcc being 2-3x slower?

As much as I love high-level programming, many of the most interesting and important problems are ones where a "small" constant factor is the difference between great and mediocre.

I'm not sure what you're getting at with CPS. How do Java's lambda's inhibit CPS? And what do you hope to accomplish with CPS, anyway? I could see you wanting tail-call optimization in order to make CPS useful, but that's a VM limitation, not a language limitation, and you could always trampoline anyway..

Everyone gets confused by this it seems. You can mutate fields in the enclosing class. You can read locals. If you really want to, you can box a local, and then mutate it inside the box. You can't mutate locals directly, because that would make lambdas significantly slower for very little benefit.

(You would not be able to do stack allocation of locals in frames that contain lambdas (unless you could prove that the lambda does not escape).)

Incomplete how exactly?

Really? new double[] { 1.0, 2.0 }? Arrays.asList("foo", "bar")? Guava's Map builders?

Lambdas are what make operations on data structures convenient in Scala and Clojure, not saving a few characters on the handful of literals in your code.

But I can only make A implement B in the file that defines A, at least according to the comments here:

https://news.ycombinator.com/item?id=5443344

This means that your objects are aware of every "container" that might hold them. This does not scale, and it certainly doesn't work for reusing data structures.

So they pick the option that slows down the programmer? How forward-looking. And yet, Java, .NET, Haskell, O'Caml, etc. are all faster than Go anyway.

Not to mention the fact that this makes it harder to reuse data structures and algorithms, which can have a much bigger impact on performance.

Don't be. He's basically thinking out loud about two languages he knows very little about. It's an entirely content-free post, but because he's famous there's evidently a danger that people might take it seriously.

The fact that he clearly knows so little of Haskell is what's most telling - you shouldn't be taken seriously as a language critic if you don't realize that Haskell also has all of those scary things he lists from the Scala table of contents, with the exception of variance annotations (since it's not OO).

It's pretty obvious what it means: + means call the + function. Well what does that mean? Probably something additive. Just like if it were called "add". You don't really know in either case unless you read the function.

The risk is that programmers might start using symbols in a way that is not obvious, but what is obvious is highly contextual. I'd prefer it not be the language designer who decides which operators are obvious enough to be allowed in my context.