[Gllug] Dealing with "Word-Only" organisations

[general_email at technicalbloke.com]

On 11/11/10 20:50, Nix wrote:
> 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.

Then learn a few, I have, there's nothing wrong with that but don't 
force student to spend too much time on the whacky ones. I could see my 
lecturers loved the elegance and purity of ML but part of being a good 
teacher is inspiring your students to want to learn on their own time 
and that would have been better accomplished by giving them something 
they could eventually write something useful in. At the time although 
all of us had computers we had no way of running an ML interpreter at 
home and the language simply wasn't complete enough to do anything 
useful even if we had. I'm quite ready to admit the situation is 
different these days with linux and free useful functional languages 
like OCaml that you can run at home but back in the day I don't think it 
helped any of us, there was simply FAR too much emphasis on it.

>> 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:


And where there's a tradeoff there's a balance to be struck. Soft Eng at 
my Uni, certainly in the first two years before I f***** it off, didn't 
feature a single practical language, not one. No C, no C++, no Java, no 
Perl, no ASM, no Bash, no Delphi (yet one module of UI design with 
Visual bleedin basic!). Really they should have at least taught some C, 
probably the most influential language of all time but no.  I'm not 
saying you shoudn't teach lisp and smalltalk and ML at all but you 
certainly shouldn't teach them exclusively! Balance, there's nothing 
wrong with it.


>>                       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.

No, it's not an either or thing. Universities raison d'etre shouldn't be 
to turning out as much cubicle fodder as fast as possible, but neither 
should they be about churning out streams of completely hapless 
academics. Some real world skills are useful, insisting on some weird 
concept of academic purity is both elitist and unpragmatic, you remind 
me of the pure maths snobs who look down on the applied maths people 
becasue they choose to sully themselves by interacting with the real world.

>> 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.
>
>    

You may have a point there, the state of the art has clearly improved in 
the intervening decade and a half. Anyway my original point was less 
about functional programming being useful now as functional programming 
being useful back in the mid 90s which it wasn't, unless you were 
planning on becoming a full time academic.



>>> 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.
>    

Large amount of otherwise quite tedious learning yes, of course. 
Learning the hard way is rarely the right way, you want to know how I 
know? People write books. If hard won knowledge couldn't be meaningfully 
condensed then nobody would buy them right? If that couldn't be 
condensed further they wouldn't have indexes or conclusions and there 
wouldn't be abridged versions. No-one ever would have written a cheat 
sheet and nobody would have ever bothered to take notes. And yes, you 
can fit a lot in a short blog post: if any of it isn't clear, or piques 
your interest we have these things called hyperlinks and search engines 
you can use to research deeper. Why do you think everybody needs to know 
everything in bends inducing depth?



>    
>> 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.
>    


Well that's a perfect example then isn't it? We had to spend weeks 
dicking around with it when, to be honest, I'd seen enough within an our 
or two. I don't need to put my hand in the fire to know it's a bad idea, 
I can tell well enough from how other people react, if those people seem 
wise then I can take them even more seriously (i.e. I need to invest 
even less effort with first hand research). Learning from others is the 
most efficent way of learning, slogging away in the trenches is for when 
there's no alternative.


>>                                         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 :)
>
>    

It happens :(

> 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.
>
>    

Which is why I won't do it for money any more, it takes all the fun out 
of it.





>> 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.
>
>    

I take your point but it's hard enough finding time to do any coding at 
all when it's not your actual career - I want to get some stuff done. 
Anyway, there's plenty of room to improve code later, personally I love 
re-factoring and tidying up code. If your project is open source then 
even better, if it's something people want to use they may well pitch in 
and improve it too.

When it comes to programming if I spend any time on 'personal 
development' at all it's trying to learn higher level stuff that's 
applicable to many languages i.e. patterns, database theory etc. I 
consider that a better us of my time (and way of acquiring large tracts 
of insight) than learning how to write "hello world" a hundred different 
ways, that's just syntax. Computers are universal machines so to some 
extent it doesn't matter what you use to program them, although I'd draw 
the line at teletypes & punched cards.


>>> 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.)
>
>    

LOL! If you're ever short of ideas just ask, I have about a dozen a day, 
sadly there's not nearly enough time to code them.




>>> 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.
>    


You misunderstand... I have projects I want to complete, I have picked 
my languages for them, I therefore have no time to look at other 
languages until those projects are completed or abandoned - in 5 months 
time my first child will be born and I will have even less time to code. 
If I can finish one or two parts of the projects I am working it should 
save me quite a lot of time which I will need if I ever want to exercise 
leisurely activities again, such as learning new programming languages.


>    
>> 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... :)
>
>    


Well with limited time to split between learning and doing this almost 
becomes an analog of the CISC vs RISC wars! Of course right now my RISC 
thinking would suggest I'd get more important stuff things done faster 
if I dropped the GLLUG instruction ;)


>
>> 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.
>
>    

Nice hack :) Still, I think the majority of languages are too bracket 
heavy, I can see it makes things easier from a parsing perspective but 
that shouldn't really be a priority for language writers.



>> 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!
>
>    

That sounds lovely, maybe someday but right now it would require 
neglecting my coding or girlfriend even further. Believe me I've no 
aesthetic objection to learning a _nice_ new language as long as it's 
got a fairly comprehensive set of libraries or can converse easily with 
other languages libs.


>> 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.
>    

Yeah, you see I think switching brackets for whitespace is a fair trade. 
I'm interested to hear the author of Lua has managed to get rid of them 
entirely, I'd always thought that shouldn't be too difficult for the 
sort of people who are clever enough to design languages in the first place.


>> 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.)
>    

But I dare say you could probably explain those things to me a lot 
faster than I could learn them by programming a butt load of COBOL, why 
don't you write us an article? ;)


Roger.

PS: I really enjoy lengthy multidimensional arguments but, as explained 
earlier, I don't really have time for them right now so pls forgive me 
if I don't take the time to fully address any subsequent posts and 
points. Also, I think everyone else on the list would prefer we knock it 
off forthwith! To be continued in a pub at some point maybe?



-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug