technologyreview: Programming Languages: Toolkits for the Mind

Toolkits for the Mind: "When the Japanese computer scientist Yukihiro Matsumoto decided to create Ruby, a programming language that has helped build Twitter, Hulu, and much of the modern Web, he was chasing an idea from a 1966 science fiction novel called Babel-17 by Samuel R. Delany. At the book’s heart is an invented language of the same name that upgrades the minds of all those who speak it. “Babel-17 is such an exact analytical language, it almost assures you technical mastery of any situation you look at,” the protagonist says at one point.



With Ruby, Matsumoto wanted the same thing: to reprogram and improve the way programmers think.

It sounds grandiose, but Matsumoto’s isn’t a fringe view. Software developers as a species tend to be convinced that programming languages have a grip on the mind strong enough to change the way you approach problems—even to change which problems you think to solve. It’s how they size up companies, products, their peers: “What language do you use?”



 That can help outsiders understand the software companies that have become so powerful and valuable, and the products and services that infuse our lives. A decision that seems like the most inside kind of inside baseball—whether someone builds a new thing using, say, Ruby or PHP or C—can suddenly affect us all. If you want to know why Facebook looks and works the way it does and what kinds of things it can do for and to us next, you need to know something about PHP, the programming language Mark Zuckerberg built it with."



'via Blog this'

Why I Switch From [Language_1] to [Language_2]

Why I Switch From [Language_1] to [Language_2]: "I am a big fan of [Language_1] and one of its early adopters, having been disappointed with the utter failures of [Language_0]. I have been an avid contributor to many open source projects such as [Obscure_Project_1], [Obscure_Project_2], and [Obscure_Project_3]. However, after using [Language_1] for over 5 years, I have been dealing with [Minor_Technical_Flaws]. At first, I ignored and even tolerated these flaws, but I was forced to confront reality. I could not live with these flaws, and since [Language_1] is a mature language, it will be difficult, if not impossible, to actually fix [Minor_Technical_Flaws]."



'via Blog this'

xkcd: Functional Programming

xkcd: Sad: "

'via Blog this'

General Computer Science links

2 + 2 = 5

Interesting attempts to make this work on various popular programming languages.


Not light reading!

How to Design Programs

Structure and Interpretation of Computer Programs

Top 30 computer science and programming blogs http://t.co/RSZ1SaRyBe
— Computer Science (@CompSciFact) January 21, 2015

Demystification of #functionalprogramming (immutable, stateless, ..) - http://t.co/9M4ALIXlkU
— Charles Moulliard (@cmoulliard) October 7, 2014

Aruoba/Fernández-Villaverde: Comparison of Programming Languages in Economics

Comparison of Programming Languages in Economics: code examples

http://economics.sas.upenn.edu/~jesusfv/comparison_languages.pdf

We solve the stochastic neoclassical growth model, the workhorse of modern macroeconomics, using C++11,Fortran 2008, Java, Julia, Python, Matlab, Mathematica, and R. We implement the same algorithm, value function iteration with grid search, in each of the languages. We report the execution times of the codes in a Mac and in a Windows computer and comment on the strength and weakness of each language

Paris Review: http://www.theparisreview.org/blog/2014/09/05/the-beauty-of-code/

theparisreview.org

as software programs grow bigger and more complex, the code they comprise tends to become unreadable and incomprehensible to human beings. Programmers like to point out that if each line of code, or even each logical statement (which may spread to more than one physical line), is understood to be a component, software systems are the most complicated things that humans have ever built: the Lucent 5ESS switch, used in telephone exchanges, derives its functionality from a hundred million lines of code; the 2008 Fedora 9 distribution of Linux comprises over two hundred million lines of code. No temple, no cathedral has ever contained as many moving parts. So if you’ve ever written code, you understand in your bones the truth of Donald Knuth’s assertion, “Software is hard. It’s harder than anything else I’ve ever had to do.” If you’ve ever written code, the fact that so much software works so much of the time can seem profoundly miraculous.

Why Twitter picked Scala...

Engineer-to-Engineer Talk: How and Why Twitter Uses Scala

Intesting quote:

We knew we needed another language. How did we pick a language that was really fun for us? We considered Java, C/C++ of course. And we looked at Haskell and OCaml for functional programming, though neither has gotten much commercial use. Erlang developers are doing stuff with a lot of network I/O but not with a lot of disk I/O; the knowledge-base around the language wasn’t great though, and the community seemed inaccessible.Java is easy to use, but it’s not very fun, especially if you’ve been using Ruby for a while. Java’s productive, but it’s just not sexy anymore. C++ was barely considered as an option. Some guys said, if I have to work in C++ again, I’m going to stab my eyes out with a shrimp fork. Java-script on the server-side via Rhino had performance problems, and it wasn’t quite there yet when we were evaluating it.
So what were our criteria for choosing Scala? Well first we asked, was it fast, and fun, and good for long-running process? Does it have advanced features? Can you be productive quickly? Developers of the language itself had to be accessible to us as we’d been burned by Ruby in that respect. Ruby’s developers had been clear about focusing it on fun, even sometimes at the expense of performance. They understood our concerns about enterprise-class support and sometimes had other priorities.
We wanted to be able to talk to the guys building the language, not to steer the language, but at least to have a conversation with them.

Data-crunching is better done with Statically typed languages

http://unriskinsight.blogspot.se/2014/06/fast-functional-goats-lions-and-wolves.html?spref=tw

Software API Links

API Cheat Sheets


New Series: API Design Best Practices

The Computer Language Benchmarks Game

Interesting, but always a controversial topic.

http://benchmarksgame.alioth.debian.org/