[ale] Hello World - in C# - in Mono - in Ubuntu is done

Tim Watts tim at cliftonfarm.org
Mon Sep 20 13:29:43 EDT 2010


On Mon, 2010-09-20 at 10:19 -0400, Ron Frazier wrote:
> Tim,
> 
> Gulp! Ouch!  OK, you make some very good points about this big chunk of 
> cheese.  My goal is to have a basic but usable understanding of a 
> commercially desirable modern language within 6 mo - 1 yr and be employable 
> at a salary of $50 K or so.  I've been close to that level before in 
> maintenance and troubleshooting or teaching.  I think it's doable.  I'm 
> sure the rest will take longer!
> 

Didn't mean to sound discouraging; just the opposite. Just meant that if
after a year's time you find you're not an expert in all those areas,
don't give up. Or if you are an expert by then, then you're either a
frickin' genius or seriously deluded! But I don't think its unreasonable
to be employable in that time frame.


> You mean there's anything else besides procedural !!!  Just kidding.  It's 
> the modern syntax that really puts me off.  They don't even use the word 
> function any more.  That's a method, right?  I'm not at all convinced that 
> the new way to design software is the best.  

Ah, and so your struggle has already begun. :-) That's actually not an
entirely invalid point. Part of the struggle with "getting" object
oriented design (OOD) is that it's more helpful the more complex the
problem is. If you're just learning object orientation, then forcing an
OO design on a simple command line utility can seem like an exercise in
futility -- all pain, no gain. Some people will at this point conclude
that OOD is just a lot of hype. Which is sad because they'll likely go
on to tackle more complex problems with their limited toolbox and come
up with some really tortured designs that reach rigor mortis long before
their time. (BTW, I've written some command line utils with quite
elegant OODs).

Another problem for newbies is the tendency to model a system entirely
with real world objects. It just doesn't work well. Also, I think
textbooks tend to overemphasize inheritance. It's critically important
but it's not the centerpiece that some books make it seem. Focusing on
the contracts between objects tends to yield more flexible designs than
focusing on inheritance (generally speaking).

Design patterns are your friend. Learn by example.

> By the way, a GUI is when you put 15 
> options (in colored text) on the screen and tell the user to press the key 
> for the one he wants, right?  (Does that make me an old fart?  I'm only 45.)
> 

Yeah, that's right. If by GUI you mean ghastly user interface. :-)


> You're right.  I've always said I don't want to design the nut on the panel 
> of the space shuttle.  I want to design the shuttle.  I'd like to have one 
> foot in the software engineering side and one in the programming side.  I 
> don't want to get into managing people however - too unpredictable.  8-)
> 

Sadly, the trend in the biz (like all biz'es) is to avoid the position
where you actually have to value people (cuz geez then they'll start
asking for things like descent wages, working conditions and, god
forbid, health benefits ... frickin' malcontents). The larger the org
the more they value "interchangeable parts". But this can be good for a
candidate like yourself ... in the beginning. Oh, and moving to
Bangalore or Bejing might help too. :-)





More information about the Ale mailing list