[Gllug] Dealing with "Word-Only" organisations

[Nix]

On 10 Nov 2010, general uttered the following:

> On 10/11/10 00:32, Nix wrote:
>>
>> It's not: but that's not what universities are for. It does what it's
>> meant to (assuming you learn something more conventional as well), which
>> is to teach you a wide spread of the total domain of computer languages.
>> If you can learn ML and something conventional, nothing much is going to
>> give you trouble.
>
> I'd simplify it further: If you can learn something conventional, 
> nothing much is going to give you trouble.

One lanugage is not enough. When you only know one language, you don't
know enough to know which features in languages are common and which are
unique to that language: and without that knowledge I'd suggest that you
necessarily don't know how to construct algorithms which best use those
features. (I had this problem in spades when I learnt Pascal, then again
when I learnt C++: after four or five languages it fades and you can
generally make fairly good use of whatever facilities you're given.)

(Some of this may be due to single-language inexperience: if you're not
familiar with a language feature, you won't know how to use it. But I
don't think all of it is. Certainly once you've learnt a few languages,
new ones come very fast because you've seen most of the pieces before
in other contexts.)

> Non-conventional is just that, not often encountered, so given very 
> finite resources it doesn't make that much sense to teach it at the 
> expense of the conventional which, presumably, you're going to encounter 
> all the bloody time.

I'd say what matters more is which language gives you more of a
foundation for learning other languages. There's a tradeoff here: the
really influential languages are often old and nasty (which is why Algol
is rarely taught), but the new and hyped languages are both likelier to
die out (new languages are always more likely to die out than older
ones, simply because the older languages are already known survivors)
and likely to be changing fast and full of unfixed design errors.
(A classic example is the obsession with teaching Java. In a lot of
universities this started pre-Java 1.2, and in most it started pre-Java
1.5, and then 1.2 or 1.5 came out and turned the way programs in those
languages were written upside down. All that was left from the Java
teaching after that was the general stuff, really.)

>                      Interesting though such subjects are it doesn't 
> make sense to spend as much time on them as my Uni seemed determined to, 
> especially with education getting more expensive every year. Those who 

Ah, you see, you consider universities as a place to teach people to get
jobs. This is not their function, and never has been. Universities are a
place to learn *how to learn*, and then to exploit that to extend the
boundaries of human knowledge. That current UK governments of all
stripes seem determined to turn them into further education colleges is
a terrible pity.

(This is a philosophical point and you may legitimately disagree but if
you do your whole family, indeed no your whole nation deserves to be
eaten by giant tube worms then filled with snake venom and thrown into
the sun.  Anything more would be extreme.)

> I reckon the useful concepts one might extract from learning ML 
> (something my uni dedicated a whole 10 week module to) could be taught 
> quite simply in an afternoon seminar using less pure but practically 

Not remotely true. ML is already one of the least pure and most
practical languages out there using a type system as powerful as MLs
(ocaml is more so, but, guess what? it's an ML first: also it seems to
be relatively unknown by the people setting up uni courses, who I think
would *really* rather be teaching Haskell only don't want to break the
brains of the poor students so soon).

> useful languages. FP may be a paradigm who's time hasn't yet come but 
> I'll wager that's coz it's not much use to the majority of developers 
> right now.

My text editor disagrees with you.

>> Nah. Each language teaches you something new about how to think about
>> programming: if you don't learn them for fun, you're constraining your
>> abilities unnecessarily.
>
> Well call me impatient but I'd rather someone summarised those nuggets 
> for me in a short blog post, or maybe in a google tech talk, that would 

Do you really think that the effect of large amounts of learning and
practice can effectively be summarized in a 'short blog post'? That's
not a royal road to learning you're asking for, it's a Mr Men book to
learning. Expertise is not that easy to obtain, ever.

> have been a lot more efficient than forcing me to code huge tranches of 
> Modula2.

A language useful mostly in that it is better than Pascal. It teaches
you a lot about how annoying Algol-style strict typing is (as opposed to
ML-style type inference) and teaches you a lot about how not to design
languages. I wouldn't teach it to students, though: its value is mostly
as a cautionary tale.

>          The only knowledge I took away from that was that my lecturer 
> was a crusty old strict-typing stalwart who was a) totally out of touch 
> with modern thought and practices and

Agreed! Modula-2 was effectively obsolete and unused by anyone in the
profession or in CS even when I was doing my GCSEs, twenty years ago.
It dates from an earlier era of language design, and shows it.

>                                        b) wanted someone to use _his_ 
> rubbishy Modula2 framework. Hardly worth spending weeks of my life on.

I have a horrible feeling this may be right too :)

>>   I note a very strong correlation between people
>> who don't like learning languages and people who don't like keeping
>> their code neat and maintainable and whose code I thus have to clean up
>> or rewrite all the bloody time: call it *pride in craft*.
>
> Correlation is not causation. I'm sad you work with people who don't 
> take any pride in what they do however despite being an amateur 
> (programming has only ever occasionally been a day job for me) I try 
> very hard to adhere to good practices and my code is as neat as I know 

That's not surprising to me at all. I'd expect amateurs to take a *lot*
more pride in their work than 'professionals' do: too many of the latter
are only interested in 'bash the code out, make it work and bugger off,
who cares about maintainability or elegance? it takes too long'. I
cannot imagine writing code like that, but the pressure to do so is
incessant.

> how to make it. I think I have a better chance of becoming a good coder 
> someday by concentrating on a couple of languages and learning them in 
> depth rather than flitting between them and never picking up their 
> subtleties or idioms.

I'd recommend doing both at once. Concentrate on a few in depth, but
learn the surfaces of a *lot* of languages. That way you pick up any
really major insights the languages may have lying around without
spending so much time on them you can't become an expert in a few.

>> them. I learnt enough Lua to be getting on with in two days, for
>> instance, with the main constraint being the speed I could read the
>> manual. And I don't consider that unusual.
>
> Two days you could have spent coding ;P

I find that I come back from those two days with lots of new ideas!
(Also it gave me an opportunity to optimize the heck out of the ekeyd
software :) and, hey, world of warcraft.)

>> Weeks or months?! To get good enough to write production code in a
>> new language, perhaps, but surely not to learn it. (Maybe we're using
>> 'learn' to mean different things?)
>
> Well I do want to write production code. Given my stated position if I 

In every language you learn?! weird.

> was only writing toy code or throwaway utilities do you think I would be 
> bothering to learn yet another language? I'm writing things that I want 
> to use with real people's data, some of it very sensitive and some of it 
> very precious and, as you are aware, writing highly robust and secure 
> code in languages you already know can be non-trivial, plenty of 
> full-time coders get that stuff wrong all the time.

Agreed. That's why you don't throw in every language you know into every
project you work on: you throw in the languages that seem right for the
task. That's another advantage of learning lots of languages: you're not
forced to write string-mangling code in Java rather than Perl, or a
threaded state machine in C rather than Lua... :)

>>> Besides, most languages are awful. The vast majority of them are only
>>> created to gain an academic a doctorate (or if they're lucky a measure
>>>      
>> Hardly. Academic languages are so obscure that I hardly ever pay any
>> attention to them. Most academics seem in any case to be totally stuck
>
> I agree but surely the total set of languages ever created contains far 
> more incomplete/proof of concept/academic languages that nobody ever 
> uses than fully fledged useful languages with healthy communities and 
> good libraries?

Yes, of course. But it's worth learning some languages even if their
libraries are bloody awful, because they may have insights elsewhere
(or, like Lua, may be extensible enough that adding the libraries is
easy: in fact, having hardly any libraries is one of the *features* of
both Lua and Tcl: it helps make them good extension languages because
they don't carry around a ton of other stuff. Lua definitely kicks Tcl's
aged rear in this area, though: its FFI to C is the first I've ever seen
that I could call lovely.)

>>> languages with their ugly brackets everywhere syntaxes, barren libraries
>>>      
>> If that's all you think Lisp is about you're missing the core of it:
>> macros and what you can do with them (which are intimately tied to the
>> lack-of-syntax parenthetic notation). Now *that* is mind-expanding.
>
> Heh, I never mentioned lisp, why does that spring to mind eh? ;)

It's the only language to use parentheses as its only grouping construct,
and the only language to be considered 'brackets everywhere' by people who
see it for the first time :) btw, for the hell of it I tried a font hack
that edited out the brackets completely. Properly indented Lisp code
was still readable.

> I have to say I think brackets and semicolons are the worst thing to 
> happen to higher level languages since GOTO. I had accepted them as a 

()()
 <>
 []

;)

> grim fact of life until the epiphaneous day I came across python and now 

You want to look at Lua, you do. *No* required punctuation at all: the
parse tree is unambiguous even if all you use is spaces, or if you put a
linefeed between every word. It seems like it should be impossible, but
it isn't!

> it pains me every time I need to write in something else! I think 
> Ritchie got an awful lot right with C and after all back then every byte 
> cost real money but with modern broadband, terrabyte drives, compression 
> and minifying I can't help think we should have left the brackets and 
> semicolons behind by now!

You can't do without brackets in Lisp simply because they are the only
grouping constructs in the language (well, other than "string quotes"
which hardly count in my eyes). They serve the same purpose that both
indentation *and* brackets serve in Python, or {} and () in C.

>>> and nasty workflows can jump in the sea for all I care. If I'd known at
>>>      
>> You see, I think that probably makes you a worse programmer than you'd
>> otherwise be. What matters about those languages isn't whether they're
>> directly useful: it's how they affect how you think about programming
>
> Really I take your point but I'd rather read articles explaining that 
> wisdom than waste weeks of my life finding it out the hard way, I don't 
> think learning to code in COBOL would be an efficient use of my time 

Obviously some languages are more worth learning than others! But I
don't think any is completely devoid of utility (learning COBOL *did*
teach me some things about language constructs likely to be useful in
high-level data formatting -- the only thing it's really good at -- and
several years later I folded that painfully-won knowledge back into a C
library I was working on.)
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug