[opensource] Printing files from the command line

Timothy Normand Miller millerti at cse.ohio-state.edu
Sat Feb 7 20:28:34 EST 2009

One other thought.  I've noticed that one's chosen discipline has a  
lot to do with one's feelings on things like programming languages,  
operating systems, freedom, etc.  Most of the EE people I know (e.g.  
chip designers) tend to want to learn one specific programming  
language and stick with it.  They're not so interested in software  
programming.  They want to design hardware.  So all this philsophizing  
about this programming language or that operating system is a bore and  
an impediment to what they want to do.  This is why you have so many  
Free software tools, while most of the hardware design tools remain  
expensive and commercial.  On the other hand, a hardware person will  
get really ticked off when they can't get schematics to something.  We  
all have our own sense of freedom, but we focus on different things.   
I imagine that the mechanical engineer isn't so concerned about what  
OS his machine tools use but that machine tools should be accessible,  
and that there should be rich open literature on mechanical designs.

So let's not be tempted to look down on Aaron because he wants to be  
"overly practical" about programming languages.  While you, the CSE  
major, grok the separation between idea and the language you implement  
it in, you're likely missing something interesting that Aaron is  
abstracting just as well in his own field.

On Feb 7, 2009, at 8:07 PM, Timothy Normand Miller wrote:

> I don't completely agree that Resolve C++, as a language is  
> completely useless to you.  Theoretically, you could continue to use  
> the libraries after you graduate.  If you don't, then the language,  
> in and of itself, is useless to you.  I have always said that trying  
> to know all of the nuances of Verilog or VHDL doesn't improve your  
> ability to translate a circuit design into HDL code.  Likewise,  
> knowing one language or another does little for you as a software  
> engineer.  Languages come and go as fads, and different languages  
> are best suited to different purposes.  You need to abstract away  
> from the specific language and understand how to architect  
> algorithms, properly engineer software, modularize, comment, debug.   
> First and foremost, you have to understand how to translate ideas  
> into processes, optimize those processes, and then finally translate  
> those processes into maintainable code.  It doesn't matter what  
> languages you use:  If you're a major C or even Assembly guru and  
> can write a fantastically optimized bubble sort, I'm still going to  
> beat you with my hackish quicksort written in interpreted Ruby with  
> any interesting amount of data.
> It's a waste of time to get caught up in the specifics when those  
> specifics change with the direction of the wind.  (Not to say that  
> you shouldn't find the specifics interesting.)  Otherwise, you'll  
> never be able to adapt.  That being said, when working at Tech  
> Source, I interviewed a number of people with CS degrees who did not  
> seem to know any programming language.  While it's not the a CS  
> department's job to teach you specific languages, it's kinda sad  
> when someone is so uninterested in computers that they somehow make  
> it all the way through a CS degree without having picked up at least  
> a handful of languages on their own.  I'm not saying that you should  
> be ashamed for not knowing some particular language.  Of all the  
> languages, I've learned, I've never learned Perl.  What matters is  
> that you cared enough to learn SOMETHING.  I doesn't matter if you  
> know C++, PHP, and 6502 assembly, or if you come out knowing Lisp,  
> Haskell, and Smalltalk.  If you want to be strategic about it and  
> come out being well-rounded, then make sure you choose languages  
> that are VERY different from each other.  How about Lisp, Ruby, and  
> Verilog.  :)

Timothy Normand Miller
millerti at cse.ohio-state.edu

More information about the Opensource mailing list