rohern

> "it just seemed strange that seeing a doctor (not even emergency room) cost roughly half as much as an iPad."

That's the banner headline. What a nightmare.

The supposition is that a more expressive language lets you do more with a single line of code on average than a less expressive language. The second supposition is that commits tend to be done to gather code expressing a single chunk of functionality in a program, so that on the average commits have the same utility in terms of what they contribute to the source project.

It's clear from this, I would think, why therefore length-of-commit is supposed to be a good proxy for measuring expressiveness.

To be clear -- the reason that it is obvious that I and the author disagree with you on the first case is because your objection was a) an elementary one and a consideration important to all such investigations, therefore it would be considered by anyone doing such an investigation or analyzing one and b) we were disagreeing with you anyway.

Yeah, sure. That's what an average is. It is taking the performance of a large case and reducing it to a single unit in order to make comparisons.

Obviously I and the writer of the article disagree with you that it fails the first case.

Well, then your point is to say that comparing two animals on the strength of their legs is ridiculous because both animals have legs. This is just a non sequitur. No one was confused about the fact that you can make a function call in C that does more than a variable assignment in Python.

We know a single line of code can do a lot of things in both languages. The question is what does the average line do. And this is important, because the occurrence of bugs is directly correlated with lines written rather than the complexity of those lines, and the same seems to be true for programmer productivity. So if 100 lines of Python does more than 100 lines of C, this is an important fact, as in first case more will have been accomplished for the same amount of work and the same debugging effort.

This is exactly the point I am making.

Yes, thank you for that 9th-grade science lesson.

The commenters in this thread are writing off the data because...? They decided the measure is bad? When the measure conforms to experience, it's probably worthwhile to look into it. This doesn't mean that correlation implies causation and yada yada 9th-grade science lesson.

I agree. I was also surprised by Ruby's position. I suspect the problem is related to that with JavaScript. That is to say, people including code in their commits that they didn't write.

These are valid lines of code (plus or minus a ;) in both languages.

Fair enough. That is an entirely valid critique. However, I do not think this makes the article worthless. Given the apparent correlation between known expressiveness and the data derived here, it may be that they had a good notion using length-of-commit as a measure for expressiveness.

:D

The data in the article based on LOC seems to match very closely conclusions based on other data. I do not know that we get to throw out this measure just 'cuz. This is proof of nothing, but no one is offering proof that we should ditch this measurement.

That's not what we're doing here. What this article really is an examination based on a set of assumptions about how we can measure expressiveness. This is a difficult thing to measure. You could (I assume) do just as well by polling thousands of programmers and asking them in their experience, which languages are expressive. In the case of this article, the measure of expressiveness used seems to match up very well with a) common programmer experience and b) the intentions of language designers. And we're not talking about programmer experience in 2013. This split between Lisp, C, and Fortran is older than I am.

I do not see anyone offering better measures of expressiveness or suggesting counterexamples to invalidate the results. The criticism here is just "Meh, not impressed".

There is a lot of weak-ass criticism going on in this thread when the data -- whatever about its methodology is troubling -- seems to almost perfectly back up what is the common experience among programmers. Yes, copy-and-paste doubtlessly affected the numbers for JavaScript, but I am not at all surprised to see JavaScript where it is.

Does anyone here really doubt that you can get more done with a single line of Python than a line of C/Java/C++? Same for Clojure/Common Lisp/Racket versus Python.

We might not take individual ranking too seriously, and none of this affects language choice when performance is a critical concern (though the spacing between Scala, OCaml, and Go is interesting and relevant to this), but do you guys honestly doubt the trend here? Does anyone have a strong counter-example? It seems like the authors may have had a decent notion with using LOC as a measure. There is no proof of this here, but I am intrigued by it.

The final conclusions in favor of CoffeeScript, Clojure, and Python are again pretty obvious. Is anyone going to suggest JavaScript or C++ is more expressive than any of these?

This is a terrific idea if it means that people become more open to expanding the size of Congress, an idea which is currently met with objections like 'Oh, but then we would need to build a bigger building'.

The Congress of the United States is absurdly small in relation to our population and absurdly unrepresentative as a result. The British House of Commons, which represents a country of 63 million persons, has 650 seats. The Canadian House of commons has 308 members (rising to 338 next election) representing 33 million persons. The entire US Congress, including the Senate, is only 538 seats, representing over 315 million persons. The House of Representatives has not been expanded since 1911 and the population of the United States has increased by 200 million since then.

Anything that makes this more achievable is worth having. The bonus of giving Congressmen the ability to work from their district in direct communication with the electorate is also worth having.

Just below this post is "Tips for Gamifying Your Mobile App".

Agreed. This a great article and great presentation.

I appreciate the interesting reading. Thanks for the useful comment!

I think the most interesting question raised by this article is, "Why are the smart people graduating from college willing to get shafted by startups?"

Why are schools failing to teach engineers about caring for their own careers? I do not think most business majors would put up with kind of crap. They are all taught to negotiate for salary and to get high earnings early as a basis for later demands. They also understand how stock options work and that 0.5% over a four-year vesting cycle with no protection in the event of acquisition is an atrociously bad deal.

The additional advantage of this age group being that they generally have no experience with salary negotiations or normal work-life balance. In fact, if they're coming out of a top CS program, they are probably used to bonkers work-life balance, which is exactly what a startup will demand of them.

> Startups aren't for financial security. They are for the frontiermen who are hoping to strike it rich in the gold rush. Most don't but some do.

I think you mean "Founding a startup is for the frontiermen..." Being an employee is not. Being an employee is a losing proposition far more often than the 95% you cited.

Talk about an ad-hoc nutritional doctrine.

Zing!

This is a great list. I highly recommend "Have You Ever Tried to Sell a Diamond?" to everyone on this board, both those who love and those who hate capitalism.

Here is a very good lecture on the state of cyber crime law. I recommend it to everyone in this community. Things are crazier than you are probably aware.

https://www.youtube.com/watch?v=q0Z_z4EHq6M

>But how does one determine what the prevalence of cardiovascular disease was in the ancient past? Time and the decomposition it brings are brutal on the flimsy meat of which we are made, and it is uncommon to have access to anything other than bones, much less bodies intact enough to be examined for signs of atherosclerotic disease. Even so, however, there have been indications that the idea that ancient humans didn’t suffer from atherosclerosis is a comforting myth, the most recent of which is a study published a week ago online in The Lancet by Prof. Randall C. Thompson of Saint Luke’s Mid America Heart Institute and an international team of investigators entitled Atherosclerosis across 4000 years of human history: the Horus study of four ancient populations. Basically, it was a study of 137 different mummies from four different geographic locations spanning 4,000 years.

The whole time I was reading this I could only think, "science is great!" Thanks for posting this.

You are probably a wonderful person to work with and any team is really lucky to have you. Having someone who is deeply passionate about these problems is very important and these are important problems!

Look. Becoming a programmer is NOT going to give you a satisfying life. Being a programmer is fucking boring. Companies do not give a shit what cool stuff you've built once they hire you. They want you to spend your time figuring out why their automated build system is broken and optimizing their databases. Sitting in front of a screen for 8-12 hours a day is a terrible approach to achieving satisfaction in your life.

Starting a company is different, and if you are massively interesting in solving a problem, that can be a great way to go. But starting a company is completely unpleasant a lot of time and if you want to pick a job that is going to fill your plate with bullshit, that is a good choice.

The best advice I ever received in regards to this topic is still pretty worthless, because almost all advice is worthless. You cannot learn wisdom that way. You learn it through experience. But here it is: Pick a problem that is meaningful to you and work on it. Optimize this by working with people you like and who share your passions.

That advice was given to me by one of the most famous computer scientists alive who also happens to be worth tens if not hundreds of millions of dollars. Note that his advice did not involve becoming a good engineer, getting papers cited, or starting a company.

I keep an index card in my pocket that says: "Never again have reason to regret." This is not "live without regrets". I think that attitude is mostly contemptible. Rather, spend your time -- all of your time -- on things you will not regret having done when you climb into bed at night. If nothing else, every day that I have obeyed this rule unfailingly I have slept well and awoken excited and optimistic in the morning. That's all the wisdom I have. The rest is just get damn lucky.

Considering the incredible amount you have already achieved, I am optimistic.

This is a terrific blog post. Excellent project and excellent sharing. I feel like we have a lot of games set in real world cities to look forward to. Also: autonomous vehicle pathing?

Again, this is just begging the question. You are positing that we need free time because we are humans to explain the assumption that we need free time because we are humans.

I understand that people work lousy jobs. This is not the interesting case. The interesting case is for those people who are working jobs doing things they quite like, for example musicians.