Hacker News new | past | comments | ask | show | jobs | submit login

"It’s about understanding the common paradigms and implementation patterns so as to be confidently language agnostic."

Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there? My guess would be to include something like C and LISP, but is that enough?




Haskell for lazy FP, pattern matching, and monads; ocaml for strict FP and a crazy expressive module system; C# for industry OO; lua for dynamic language and prototype inheritance; ruby for runtime meta programming; lisp for macros; forth for stack language; erlang for actor module, byte pattern matching, and dynamic unification pattern matching; prolog for logic programming; c for low level; c++ for templates and destructors; rust for linear types; idris for dependent types; R for rank polymorphism. After that languages started to seem like variations of things I've seen before.


> rust for linear types

Apparently Philip Wadler came up with this notion, so your already-mentioned Haskell should suffice ;)

> idris for dependent types

Are we still on "Essentially, which are these few common paradigm languages that teach you more than 90% of what's out there?" or are we by now in the territory of "which languages to cover every single remotely-computation-related notion anyone ever conjured up and managed to somewhat implement"? ;D


Can you explain why you see R as an exemplar for rank polymorphism?


I don't see it as one. It just happens to be the one I encountered that had the feature. Please suggest better, I wasn't that fond of R.


Here are my recommendations, each category has a really different programming paradigm than the others:

* Procedural: c / pascal / basic / fortran

* OO: c++ / java / c#

* Dynamic: python / ruby / javascript

* Funcional: lisp / scheme / clojure / haskell

* Logic: prolog

* Query: SQL

* Assembly

Learning something of each category should prepare you for almost everything!


C++, Java and C# aren't really object oriented languages --- they're scalar languages with object systems bolted on. The giveaway is that they're full of types which aren't objects; ints, pointers, floats, booleans, etc. These are handled and implemented entirely differently to the object types. e.g.: compare a Java int (a scalar type) with a Java Integer (an object type).

In a proper object-oriented language, everything is an object, including these. That allows you to do some really interesting things which are at the heart of the OO mindset. e.g. Smalltalk avoids having to use conditionals almost completely via dynamic dispatch:

    b ifTrue: [ 'b is true!' print ]
b is a Boolean; ifTrue:block is an abstract method called on Boolean. But the values true and false are actually instances of subclasses of Boolean; True's implementation of ifTrue evaluates the block, and False's doesn't, and that's how you get different behaviour depending on whether b is true or false. The core language neither knows nor cares that booleans are special.

(Actually, the bytecode does care, and has special accelerated opcodes to make operations of booleans fast for performance reasons, but that's just an implementation detail.)


Luckily I first encountered "OO" after having already learned the concept of structs/records in Pascal, this way I did not have to seriously entertain the idea that simple scalars oughta be anything-but..


OO should be Smalltalk given it's real OO & implementations still exist. Functional should include an ML on it given all the languages influenced by SML and Ocaml. If they'd done functional, then I suggest Mercury for logic language as it's a better Prolog with functional and performance improvements. It's used commercially, too. Query, if logic programming is done, should be SQL followed by Datalog. Assembly should be x86 and one RISC (probably ARM).


> I suggest Mercury for logic language as it's a better Prolog with functional and performance improvements. It's used commercially, too.

Any idea what sort of applications the Mercury language is used commercially for? (Only) one I know of is Prince XML (from the Wikipedia article about either one of them). Not saying it's not used for more, just interested to know.


Regular business apps or processes at Mission Critical IT:

http://www.missioncriticalit.com/technology.html

You could also use it anywhere Prolog is used. So, you could look up applications or commercial users of Prolog. Here's one in finance that would probably benefit from Mercury:

https://dtai.cs.kuleuven.be/CHR/files/Elston_SecuritEase.pdf


Cool, thanks. Good point about Prolog.


Your OO examples all come from the same portion of the OOP family tree. People should also explore the style of OOP which comes from systems like CLOS & Dylan.


My favourite member of the Logic Programming family of languages would be http://picat-lang.org/ . As far as implementations of Prolog go, http://www.swi-prolog.org/ is a good implementation to go with (It's mature, has a good ecosystem, and good documentation).


C is a bit dated and Lisp too wishy-washy, I'd suggest either Rust or Go for the Turing machine paradigm, and for the Lambda Calculus paradigm Haskell (or any truly comparably powerful robust "strictly" pure-and-lazy functional language --- can't think of any).

This way by covering the extreme ends of the spectrum from (A) gratifyingly roll-up-your-sleeves-and-get-your-hands-dirty petal-to-the-medal (heh) systems programming to (Z)abstractions-all-the-way-up-and-down-and-sideways algebraic-typed purely-functional glory.

With current-day concurrency approaches, easy-networked-ness etc thrown in natively in any of the above.

Once proficient in these "spectrum extremes", anything in between should be relatively easier to get up to speed with


Norivg's advice seems better than the entire article. And it's probably best to be skeptical of anything that insists you should start with X - that tends to reflect the author's own experience rather than anything fundamental.


IMO steps one and two taken together explain their point pretty well




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: