Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Too many languages

Name: Anonymous 2014-03-09 9:44

There are thousands of programming languages.

The purpose of a programming language is to express programs. The
purpose of learning programming languages is to build up a toolbox for
reasoning about and synthesizing programs in any one given language.

There are diminishing returns on learning programming languages, and
time is scarce.

Therefore one must select between programming languages to study.

A good selection of languages has both
+ breadth
  + satisfies a number of real world economic needs.
+ focus
  + exploits similarity between languages and incremental learning.
  + some unifying basis

A good member of a particular selection meets a number of the
following criteria:
+ Satisfies one particular school of thought on programming languages.
+ Significant difference from predecessors
+ Significant influence on successors
+ Economically significant
+ Advanced i.e. no direct, established and proven heir.
+ A good language.
  + Easy to express programs with
  + Easy to read programs expressed with
  + Easy to reason about programms expressed with

No one of these criteria are sufficient or even necessary conditions.

A bad member satisfies the opposite criteria.

Name: Chris Done 2014-03-10 11:45

In C# I was always dealing with null errors in maintenance and confused by the limits of the type system and the arcane lambdas (C#: "Lam.. lam.. lamdoh!") it had at the time. I also wasted time trying to decide when to use an object class versus functions that work on a value. Until recently in C# you had to declare all types up front in a really duplicating way. Now only some are required. That gets old quickly and you can feel your hands wearing down every time you have to type that boilerplate. This is undoubtedly the bad experience that leads people to hate anything with the word "static" in it. C# fools you into thinking it's safe with its type system, and then shangais you at runtime. So you end up doing "defensive" programming at composition time, trying to make sure it won't blow up, which slows you down.

In JavaScript I'm always nervous about every line of code I wrote in case it'll explode, so I end up re-reading what I wrote. It doesn't matter much because I get runtime exceptions later anyway. Standard JS has no functional libs, so most code I write can't involve using them, and most code I read online doesn't either. So it's always verbose. You also pay for abstractions in performance in JS. No partial application is also a bother. JavaScript (vanilla) lacks lexical let which kills me.

In Elisp I always forget argument order of functions. There's zero convention. There are some functions that I use all the time and lookup the argument order every single time. Haskell's argument order always favours partial application. Elisp has no pattern matching and a single namespace is icky. It has LET and LET* which is an unfortunate distinction. Lisp has macros that would enable pattern matching, but who cares if only I know and use it? That's like making a boat I can only ride in my bathtub.

I like that Haskell has a "readFile" and "appendFile" function, simple "obvious" things like that. In Common Lisp it's like a three line expression. Also, for a "list processing" language, Lisp sucks at lists compared to Haskell. While I'm bashing Lisp, the LOOP macro sucks because it's heterogenous (shocker: this is why all macros suck). The syntax is unintuitive and special-cased. Whereas Haskell's looping facilities are all just normal functions that you compose. You only have to learn foldr/foldl/zip/map etc. once. They all have their use standalone or in concert. Elisp also lacks lexical scope which kills me.

The poor equality that Lisp has (and JS, and most everything else) trips me up a lot. (Did you mean EQ, EQV, EQUAL, string= or =)? Oh, you want to compare to arrays for equality? Ho, ho, ho. Lack of pattern mathing also kills me. It's laborious and boring to deconstruct objects manually. Haskell's type inspection is fantastic. Most of the time I don't have to read docs. I have to do that a lot in the above languages (though, C# a little less so). You have to sit there and read pros written by someone who resents having to write it in the first place while the other programmers are playing frisby outside. Again, composition and partial application are wonderous. I groan every time I have to write function(){ return ... } in JS or (lambda () ...) in Lisp or whatever weird stuff you have to do in C# these days.

I didn't use Java much. I spent a few days with it to do some PDF manipulation, which would've been a couple days if I wasn't swearing so much. If you think Haskell's type-laden APIs are confusing, look at the iText Java API. HP Lovecraft would have trouble coming up with an apt description. Although I think Iron Maiden could have a good go at it.

People say that they spend more time thinking in Haskell than writing it. I don't have that experience. I just start writing and then worry about the right design later. Thanks to the static checker, the cost of refactoring is very low. Probably the lowest of any language I've used to make pennies. In other languages you really have to think "is this the right design?" ahead of time otherwise you will hate life afterwards when you realise it wasn't. I've had competent Lisper colleagues just give up on changing a complex piece of code because "it works" even though it's a horrific mess. So in that way Haskell lets me just start going. Sure, it won't let me compare a number with a string but that's not something I want to do anyway.

Also, the type system is faster because you don't need to run a program to find out it's fundamentally broken. You find out at the tap-tap-tap-oops phase rather than the run-and-wait-for-it-to-run-oh-bugger phase.

In Bash I forget the syntax all the time because it's just stupid. Whenever I want to do something more than piping I start to wish I was using Haskell. This is why I'm working on a Haskell shell. I'm near to it being my full-time shell, once I've implemented one last thing.

Also doing threaded stuff in Haskell is trivial. And I'm now at the stage where I pretty much know every library I'm going to reach for to accomplish any task I tend to work on. But that comes with time and isn't peculiar to Haskell.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List