incepted

> 4. Who really cares about cross-platform code if all I do is on Linux?

Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal.

> 5. Why does this program require 4GB of ram?

Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?

> 6. Must I really download and install the JVM all the time, and what is it good for anyway?

Once or twice a year, if you really want to. You update your browser much more often.

> C# and D, for example, have had most of these features for a few years

Come on, now. D is 15 years old, C# 16.

Python is more than 25 years old.

> Everything we do at Facebook is focused on our mission to make the world more open and connected.

Call me cynical but to me, Facebook's mission is to get the whole planet to create a Facebook account and track them so they can be served ads.

Agree that software patents but to me, the issue is patent trolls.

Patents should only be applicable if the company can show it's actually working in a domain that will apply this patent.

With rules like this, patent trolls would cease to exist and software patents would go back to being extremely useful to software innovation, like they were designed to be.

> Derailer uses an automatic static analysis to produce a visual representation of the information flows within a Ruby on Rails web application.

Rails?

Such a tool might have been useful ten years ago but today?

Very often, writing a tutorial about monoids, functors, applicatives, or monads ends up improving the understanding of these concepts a lot more for the author of the post than its readers.

At the end of the day, not everyone responds the same way to metaphors, so the more tutorials and metaphors on these concepts, the better. One day, you'll stumble upon that one article that makes all things click for you.

> <groupId>software.amazon.ion</groupId>

Why not "com.amazon.ion", like thousands of other existing packages?

> before the turn of the century, it usually seemed like when you bought a game you owned it.

That was never true.

> Single small binaries are easy with go

With static linking? I don't think so.

Wow, $289?!?

I loved the previous generation priced under $100 but that's a huge jump and I'm not convinced the feature list justifies such a price. I predict this is not going to sell very well.

And I would have loved a slightly larger screen (7 inches).

Agreed.

I think the Facebook engineers have a tendency to fix symptoms rather than causes. A lot of their engineering creations are trying to shrink the binary while they might want to consider revisiting all the dependencies that their application depends on, because that graph (and the size of their apk) is really absurdly large for such an app.

Of course, there's also the fact that such a tool is already partially obsolete because of Jack and Jill.

You don't seem to realize it but your countLines() method is a getter.

At the end of the day, you need to get values from your class, otherwise, they are useless (and they do side effects).

FYI, Armstrong thinks that OO sucks [1] so it's weird to see him claim his language is a better OOP language than others.

[1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

Good points except saying that getters and setters are an anti-pattern of OOP. Actually, you contradict this a few lines blow:

> No, good OOP has class/object with both private state

If a class has state, you have to be able to read that state or it's useless.

It's a good practice overall to tell classes what to do but eventually, you need to get information from them. That's where getters come into play.

You're not, it's just a microscopic drama that is engulfing a tiny subset of the FP world. I'm following a lot of these people and their Twitter stream has been flooded by reactions to this, which makes me think they really don't have much else to talk about.

It's pathetic, really.

But we went through that with C++ already: all companies used to publish their own guidelines of what C++ features were allowed and not allowed to use. Of course, all these subsets were different. And of course, if you work on open source project, it's just impossible to be productive in such a language without knowing all of it.

I guess the point of the person you're responding to is that following the article's advice, Kotlin would probably be a better choice than Scala in most cases.

For example, Kotlin doesn't support higher kinded types so if your problem doesn't require highed kinded types, Kotlin would be a better fit than Scala since it's the "Least powerful language that will solve your problem".

Which will probably lead to the controversial claim that "All programs need higher kinds" followed by the realization that the perceived power of a technology is extremely subjective.

Using `Either` instead of `Option` would violate "Use the least complex approach that solves your problem".

If all you need is represent an optional value, why use `Either`, which needs a second type parameter representing the failure? If you don't care about what caused the failure (because there was no failure, an absence of value is a valid result), no need to represent it.

Besides, these two classes still represent fundamentally different concepts and they are not interchangeable at all.

It's refreshing to see some down-to-earth pragmatism in Scala land for a change. Thanks, Li-Haoyi.

I spent the first thirty years of my life in a European country.

Where did I say that more powerful languages don't give benefits?

Besides, assembly fails the "allows to execute quickly" test.

All good points.

Even though it's hard to find any flaw in "Use the right tool for the job", I still think that the success of a start up in Silicon Valley (and probably the rest of the world) has a lot less to do with the technical choices of the company than the people who work there. And luck. A lot of luck.

It's still baffling to me that pg doesn't realize how lucky he was. He was in the right place at the right time and he was probably surrounded by competent technical and non technical people. If you have such a team, the technical preferences of the engineers will probably have very little bearing on the success of the company as long as they use the tools they are proficient with and which allow them to execute quickly.

I mean, the fact that Rails and PHP were at the origin of Twitter and Facebook alone shows that the quality of programming languages is irrelevant for the early year(s) of a start up.

> the point we make in the book is that few employees expect or want lifetime employment at a single company

Any citation about this claim? Because in my experience, it's completely incorrect.

Outside of the US, lifetime employment is a heavily coveted goal, because economies outside of the US are in a terrible shape overall with unemployment rate routinely above 10%.

Inside the US, except for white collar workers in major cities, long time employment remains the holy grail of most of the workforce, even though the US economy is in a pretty good shape overall.

Interestingly, even though Dan Lyons technically belongs to the white collar community that is probably not interested in lifetime employment, it's pretty obvious to me that when he joined that semi-startup, his goal was a lot more to write a book about it than embracing the party line and planning a long career there.

I mean... you're hiring Fake Steve Jobs and when he's out of the company, your executives try to illegally get a copy of the book with the futile hope that it won't get published... Seriously? What did you expect?

Well, Erlang is a niche programming language, isn't that evidence enough that all these claims that Erlang will save us from the multithreaded hell are vastly overblown?

We're doing multithreaded programming just fine in a lot of very varied languages.

That would be a powerful argument if you could prove the code path enabling this uses Erlang.

According to Wikipedia, shortly after Armstrong was let go of Ericsson, the company quickly ripped out Erlang from all its products and replaced it with C and C++.

> And actor supervision is the best way to write reliable systems.

Need some citation there, because we've been writing extremely reliable systems (multiple nines) for decades in various languages (mostly C, C++ and Java).

All these languages (including Erlang) come with pros and cons to write such systems, but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

> It used to be that when you bought an appliance, you owned it, and you could take it apart, repair it, and plug in whatever accessories you wanted without the manufacturer's knowledge or permission.

That's some glorious equivocation the EFF is pulling here.

You can still do this today. Nothing stops you from taking apart, repairing and tweaking devices you buy.

What you can't get today and that you could never, ever get before either, is the guarantee that the company you bought that device from will keep its servers alive for any given period of time.

Anyone who thinks that open source is the way out of this dilemma needs a reality check.

The fact that the source is open gives you exactly zero guarantees that a company will keep paying for servers that runs this code. Zero. If you're lucky, someone will pick that source up and deploy servers to run it, but again, no guarantees.

> Customers likely didn't expect that, 18 months after the last Revolv Hubs were sold, instead of getting more upgrades, the device would be intentionally, permanently, and completely disabled.

Then they were naïve customers. If the terms of service don't include such a guarantee, then you don't have it, period. It doesn't matter if the source is open or closed or if the company that provides the device is worth billions or just an angel funded startup.

> In an ideal world, Hub owners would be free to point their devices at a different central server, run by a third-party competitor or a trusted friend,

They can do this today, the world doesn't need to be "ideal", there just needs to be a financial incentive for a company to run such software. That's what happens in a free trade economy, supply and demand rule. This economy gives us a lot of benefits but you need to be ready to face the reality that sometimes, it won't give you what you want.

> But there's another way to push back against untrustworthy devices, and that's refusing to buy electronics and software that prioritize the manufacturer's wishes above your own.

What a great idea. Now, can you give a few examples of alternate devices that give us the kind of guarantee you are advocating?

I would certainly love to hear about them.

Sometimes, I wonder if the EFF lives on the same planet I live on.

Branches and being able to revisit older code are very important, regardless of the number of people working on the code base.

> TIOBE is a poor measure of programming language popularity for a lot of reasons.

And yet, it is completely consistent with pretty much all other measurements of programming language popularity (github, job postings, StackOverflow answers, etc...).

So maybe it's not that poor a measure after all.

Yes, Wizardry was the first game to ship that was written in Pascal UCSD if I recall correctly.

The boot sequence was pretty unmistakable (clear screen, switch to 80 columns, cursor in the upper left corner) but quite novel at the time.

Here it is, if you want to experience it yourself:

http://www.virtualapple.org/wizardrydisk.html