3 ms·
Hmm, after looking at your rather nice list, six was probably too low; I think I'll revise my estimate to a more conservative eight. There'll always be some gap
by camccann 17y ago
Hmm, after looking at your rather nice list, six was probably too low; I think I'll revise my estimate to a more conservative eight. There'll always be some gap, of course, but eight ought to get closer to the point of diminishing returns I had in mind.
Incidentally, I'd probably include some form of assembly as well, for the whole "must understand the underlying hardware" aspect.
- dkersten 17y agoOhhh! That was certainly an oversight on my part - an assembly language should be included. Eight should be enough, after that, you probably wouldn't learn enough to make the effort worthwhile (except maybe to learn a language for a particular need, eg available libraries). I think my number seven then would be an assembly language and my eight would be Oz, ATS[1] and J[2] (not really in the same category, but more of a misc interesting languages category). I would then add Python/Ruby/Boo/Groovy in with C++, C# and Java. ATS and J are both unique in their own ways. I'm not sure what value there is in learning either of these (since I don't know them) but they seem different enough to teach you something new. J (or APL or K) do teach you about array processing languages and point-free programming, so maybe this is useful. ATS is interesting because of its emphasis on types in a way I haven't seen in other languages: [1] http://www.ats-lang.org/ http://www.ats-lang.org/ [2] http://www.jsoftware.com/ http://www.jsoftware.com/ PS: Turns out I spelled Lustre wrong :-D
- camccann 17y agoI'd actually be inclined to get C++/C#/Java off the list entirely due to not showcasing any one perspective particularly well, to be honest. Smalltalk or Ruby would better illustrate OOP, and between them the OOP language and the assembly should cover the basic procedural approach well enough, I think. Also, plain old C could possibly stand in for the assembly, especially if you were mostly using it "portable assembly" style instead of relying mostly on libraries. For what it's worth the list I had mind originally was something like: * C, for low-level procedural and machine-awareness * Ruby, for high-level procedural and OOP (plus scripty perl-isms) * Scheme, for distilled lisp-iness without distracting details * Haskell, for HM static typing and functional purity * Two empty slots to cover languages I'm less familiar with After seeing your list, I realized I'd carelessly underestimated the number of empty slots necessary...