Programming languages

Quick summary of programming languages.

Should I learn...

There's a lot of languages out there, and most of them have a lot of overlap over common problem domains. In principle, all languages being Turing complete, there's nothing stopping you from doing any task in any language. But in practice, there may be orders of magnitude difference (we're talking 100-1000x here) in how much time it takes to do a project in a suitable language vs. an unsuitable one. Among the joys you may experience by picking the wrong language are:

• Fighting passive aggressive syntax that pesters you with irrelevant low-level details
  • You shouldn't underestimate the importance of simple syntactical decisions and syntactic sugar. Learning a language and developing software both take a lot of commitment and hard work. If you don't enjoy your language, it will destroy your motivation, and it will become very hard to get anywhere.
• Having reinvent the wheel because nobody bothered porting critical library X
• Having to figure shit out on your own because all guides for topic X are written for other languages (translating example code you don't understand is so much fun!)
• Committing hundreds or thousands of man-hours into a project, only to realize that you can no longer improve on performance or a feature set because of the design decisions your language made, and if you want to progress your only hope is to rewrite everything in another language first
• Spending time and effort learning a language only to realize the job market for it is shit (if you have career goal as opposed to being a hobbyist)

To a novice, a summary of language features will not be much help. Even something as basic as functional vs. procedural is irrelevant if you have never programmed and don't understand well what these things mean. If you are just starting out, you have to be careful about who you listen to. There are many languages out there, and a lot of them are pretty good for solving certain sets of problems. But few are suitable for a newbie (as a newbie, you will be learning not just the language, but also general computation). The last thing you won't is to get trolled by some faggot engaging in language wars.

If you are experienced (rule of thumb: have you created useful software in and gotten paid for it in more than one language?) then the choice becomes much easier. Based on the languages you do know, you will probably already have a taste for certain features. Consider the languages you're already comfortable with - what do they do well? What would you change? The language you are considering learning will invariably be better in some ways and worse in others than those you already know. The question is do the pros give you enough to justify both the cons and the extra effort of learning a new language.

Ultimately, you should aspire to learn how to program, not to learn any given language. To wit, all programming revolves around making the computer do things: The computer know a small set of atomic, fundamental "things" which it can already do. It is your task, as the programmer, to define how these fundamental tasks should be combined with each other to perform new tasks. Depending on how the fundamental tasks of a language are chosen, and what rules govern their combination, some tasks will be rendered easy or difficult, intuitive or unintuitive.

Intrinsic vs. Extrinsic

When comparing the comparative merits of languages, we may divide them into two main groups: Extrinsic properties and intrinsic properties. Intrinsic properties are properties of the language itself, such as syntax. Extrinsic properties are everything that isn't part of the language itself: The community, the tutorials available, the libraries that have been written, how the language and its users are perceived, and so on. Basically, intrinsic properties are what you get if you were using the language in a vacuum, with nothing but a description of the syntax and a basic compiler.

Languages do not exist in a vacuum, but considering them in a vacuum may inform the bigger decision of which language is worth your time. We therefore make the distinction between intrinsic and extrinsic aspects for the following reasons:

• Intrinsic properties are constant in time (at least until a new version of the language is released). Extrinsic properties are very much inconstant (who knows what language will be popular in a five years?).
• Intrinsic properties influence extrinsic properties, but not vice versa (the exception is when language designers listen to what the community wants for the subsequent version of the language).

Generally, your decision should be rooted in the intrinsics, since as you can see, they are the key factor and they are the ones you will be stuck with so long as you use the language. But that's not to say extrinsic factors aren't important or should be ignored (this is in fact a very big mistake).

Intrinsic properties

For most languages that are designed without a specific purpose in mind, intrinsics will be fairly similar. They will not be glaring flaws or radical improvements. When languages are designed with a specific purpose in mind, they tend to have more drastic changes. Usually, if a specialized language is designed from a problem domain, that problem domain is very hard to deal with using more generalist languages.

Individual languages

Assembly

• Terse, but pedantic as fuck.
  • Small programs are simple to write, but larger ones become an unwieldy and complex mess in most cases.
• Based Motorola ASM, so many variants, so much serial port downloading.
• x86 ASM is pretty neat too, also known as PC ASM. Pain in the ass because AT&T ASM syntax is the UNIX standard, and Intel ASM syntax is the DOS standard and they are so close but its the little things that are different. Enough different to be a pain in the dick.
• Not portable. This is as close to the metal as you get without writing actual machine op codes. Each instruction IS a 1:1 mapping to a machine opcode. Each CPU architecture has a different set of instructions.
• Currently, Intel x86-64 ASM is the largest instruction set.

BASIC

• >It can do anything C can do, guise!!1
• Lots of proprietary implementations, only a few decent FOSS ones.
• Still slower than C
• >muh goto

C

• Designed to be a "portable assembly language"
• Small, simple language whose parts compose well
• Very small standard library
• Lingua franca for big libraries and APIs
  • If it has no C API, it's probably shit
• Very mature compilers that produce extremely fast, well-optimized code
• Implementations for pretty much every architecture or platform imaginable
  • If some hardware doesn't have a C compiler for it, chances are it doesn't matter in the first place
• Lots of things are left undefined so that implementations can make the best choice possible in terms of speed
• Potentially dangerous to write for the uninitiated
  • You manage your own resources yourself
  • You perform your own safety checks if you want them
  • Absolutely no hand-holding
  • Undefined behavior where anything can happen
• Will force you to learn a lot about memory and lower level issues
• Pretty much the only sane choice for systems and embedded programming
• Can also be used for applications programming

C++

• Very, very large and feature-filled language
• Considered verbose at times
• C, but with OOP on top, and massive set of massive libraries
• Considered dangerous to write in because, like C, there is no memory management
• Almost as fast as C
• Not very orthogonal and features frequently clash with each other
• Despite being called C/C++ frequently, good C++ is completely different from good C

C#

• What Java should have been
• Runs on .NET or the Mono framework (Mono framework allowing you to run it on GNU/Linux)
• Is very similar to Java, with some extra stuff borrowed from C++ and Haskell
• Dubious legal situation because parts of the language are encumbered with MS patent.

Erlang

• Makes concurrency/multithread shit a breeze.
• Uses a specialised VM that has a hard time crunching numbers, and an even harder time handling strings.

Golang

• Also known as Go
• Created by Rob Pike (one of the original UNIX guys) and some other engineers at Google
• Mascot looks suspiciously similar to the Plan9 mascot
• Is basically C with minimal extras, but with garbage collection, and some core language features to make it really good for concurrent programming (doing multiple things at once). Not really as fast as C, though.
• Directory structure must be laid out in a certain way to build projects
• Has an interactive tutorial at their website, and a go tool which allows you to pull from github, and package go, etc
• Uses Goroutines for concurrency, which are like lightweight threads which are then fit into threads for more efficiency. The compiler handles the threads for you.

Haskell

• Extremely expressive, offers abstraction capabilities near Lisp
• Focuses on pure functional programming and type systems
• Very rigid language, if you do something wrong, it probably won't even compile
• Takes a lot of time to learn completely
• Can be unwieldy for inherently stateful problems

Java

• Very portable; compiling down to bytecode, which is then executed by the JVM
• Object oriented language
• Very large and enterprise
• Huge libraries and a lot of software is written in it
• Very verbose APIs
• Receives a lot of undue criticism
• Can be convoluted to write in sometimes
• Is made fun of for the design patterns people use with it, and for the verbose naming schemes often used

Lisp

Main article: Lisp.

• Family of programming languages which have the most notable features of using fully parenthesized prefix notation and being homoiconic.
• Intially appeared in 1958.
• Lisp is said to change the way one thinks about programming, because it exposes the abstraxt syntax tree to the programmer for modification and extension of the language itself to fit the domain-specific needs of a particular task.
• No (visible) limit to abstraction

Pascal

• Very strong, safe, and featured type system
• Simple syntax that prefers words over symbols, and is highly-structured
• Originally designed for teaching, and very easy to get started with
• Fast, single-pass compilers
• Covers both low-level and relatively high-level concepts well
• Not very popular anymore, you won't find a job using it, and newer learning resources for it are lacking
• The syntax is considered too verbose by some
• Bias carried over from problems with earlier versions of the language
• Large number of varied modern dialects and compilers may confuse newcomers

Perl

• Very tacit and unreadable syntax
• Called a "swiss army chainsaw" for its versatility
• Slow for non-procedural tasks
• Dynamic grammar makes it fun to write impossible code
• Hated by Python fanboys worldwide
• Can be OO, imperative, and even has functional elements.
• Avoids the use of reserved keywords, prefers keyboard squiggles (&, $, @, ->, etc.)

PHP

Go is a sane alternative to PHP and webapps and seems almost the only sane one. Heck, even Python is far more sane than PHP. Don't use Node.js, it's considered harmful.

Python

• Very easy to read and simple (and fun) to write
• Kinda slow
• Uses whitespace indentation to separate logical blocks
• Excellent for scripting
• Considered the antithesis of Perl
• Can be OO, imperative, and even has functional elements.
• Is nice to start out with and program in, but after a few years of it, you'll start to want to play with some of the stuff Python sacrifices, like pointers, and speed.

Ruby

• Focus on programmer happiness
• Fully object-oriented
• Elegant, readable code
• As slow as any dynamic language will be
• Excellent for general-purpose programming, scripting, text processing and web dev

Rust

• Developed by Mozilla
• Also known as rust-lang
• Like Golang, is also designed for concurrent programming
• First stable release by the end of 2014

Scheme

• Based on Lisp with a focus on minimalism and simplicity
• Popular in many universities and featured in SICP
• Great for programs with a basis in recursion and iteration
• Lacks portability and has little implementations

Vala

• The GNOME foundation's response to C++
• Compiles to C code, which can then be compiled with a normal C compiler
• Uses the GTK and GObject (GNOME) libraries
• Has elements of C++ and C#, but is more sane