Technical Difficulties from on Top of the Mountain
  Avoiding the moss.
I've learned a couple computer languages in my time. I've even written some frighteningly large programs in several of them.

My first language was BASIC. And it was pretty cool, because you just typed a few things into memory and ran it. It was pretty quick to try things out. And typing things in from scratch was usually the way you did things because the external storage on those early machines were pretty sad. I remember working for three weeks on a more complicated game, loading my work in from a cassette tape, adding to it, and then saving out before the end of recess.

One afternoon, I discovered the horror which is magnetic media. I had worn out the first part of the tape that I had been using over and over, and my work was gone. We eventually upgraded the lab to also have a floppy drive, but these had similar problems in terms of reliability.

Still I pressed on. BASIC had a few drawbacks. First it was slow, and second it didn't have much in the way of support for more advanced data structures. It was great if your biggest worry was to keep a list of 10 numbers, but if you wanted to do bigger and better things, Pascal had the moves. It was also the language of choice if you were trying to pass the AP Computer Science exams. So I learned about references, and lists, and other good things and built some pretty large projects in Pascal ( once hard drives and larger memory computers came along ), but there was a new language coming along that was threatening to surpass everything that had come before it: C.

C was actually a pretty old language, but it was finally breaking out of its roots and spreading out to the modern micro platforms. Its big thing over the languages before it was pointers. Pointers are a shortcut for walking around in memory without a lot of overhead. All the languages before it had things like arrays, where you accessed an element by saying "val := my_array[i]" but there were costs to doing this. To find where val was coming from, the program had to multiply i by the size of each element of my_array and then add that to the base address of the block.

Compared to loading, adding, comparing, and clearing values; multiplying two things takes an eternity on a computer (even today). And often you were going to look at elements from my_array in order, from beginning to end, or some such, so there really wasn't any need for all that multiplying. C let you code your program to take advantage of that. You would say, "my * ptr= my_array" and then p would start out having the same address as the first element in my_array. Then you would say, "p ++" and the compiler would add the size of one element to the address in p (an add being much cheaper than a multiply) and you would be ready to look at the next element in my_array.

If you were trying to write fast code, like I was because I was doing computer graphics, then this was great. It was also dangerous, since you could add any value to p and then look and see what was there. Sometimes you ran off the end of the world and started trying to look at memory that didn't exist, which caused bad things to happen, but if you kept things in check, it was great.

C carried me forward for more than a decade, but you can only write so much code before things become un-manageable, and in C you were always writing pretty low level code. On top of C, an object structure was added, it was called C++. It was pretty cool because you could create these families of objects that could share code when it made sense, and specialize when they needed to. They also added another language into the pre-processor, called STL which was a code generating language that does amazing things, only some of which I understand.

I built an amazing networking library in C++ (after nine revisions), and some other cool generic algorithms, and used those to build some pretty large network servers and other cool processing tools, but it took a fair amount of work to get things done. Around the same time, my friend tim was playing with another language called Perl, which was heading in an entirely different direction then my language choices before.

First, it was interpreted (ya just like BASIC way back in the day). Second it had some amazing stuff built into it already, like string handling and regular expressions, and data structures like arrays and hash tables. Sure, you could build these things in C++, but Perl already had it done, and with memory handling, you didn't worry about allocating things or getting rid of them when you were done. You just simply started writing things like,

  my $x_= { a => [ 1, 2, 4, ], b => [1, 2, 3], complex => [ { u => 1, v => -1 }, { u=> 2, v => 0 } ] } ;
  my $yflat = [ grep { $_ > 0 } map { @$_ } values %$x_ ] ;
and it did all the work for you. (don't ask me to explain what ends up in $yflat, I just made it up as an example.)

So I had two pretty powerful languages at my disposal at that point, C++ for writing heavy iron server stuff, and Perl for writing data manipulation/database/text/web stuff. That caused me quite a problem.

I like to continually improve myself as much as the next ultra-geek, but I had mastered such power tools, that other newer things out there just didn't seem to have much appeal. Ruby happened upon the scene, but its performance was dismal. Python seemed to have a lot more traction than Perl, but it was like Perl with training wheels. Sure, I know better than to write if ( a= calc() ) { ... } most of the time, but sometimes that actually is the clearest way to do things, and its valid C and Perl, but not Python. Java suffered from the same problem, it was a language designed for people who were not very good programmers.

I tried looking for other languages to try out. Lua seemed interesting, and fit a niche on small embedded systems (like phones and video games), but didn't even support simple shortcuts like a += 10, requiring the longer form a= a +10. Ocaml seemed to have some neat ideas, and good performance, but I had already done some ML type stuff in Perl, and having to type my plus operator seems a little tedious.

So I was sort of coasting along, expanding my skills in other areas, like database SQL calls, and the like when the web started getting interesting. I had done a little copy and pasting of web scripts for the front end to one of our gianormous perl apps, and I went back and started looking at the pieces, thinking to myself, this new javascript could be interesting. Then I got a chance to help tim out again on another project, and I dived way in on javascript and prototype.js and made quite a mess out of things, but did get the demo done.

Its at this point, where I either move on or get serious. I had just enough knowledge and experience to be dangerous, so it was time to find out more. Thankfully these days there's so much information online that you can just go nuts without much effort. I learned how the javascript inheritance model is completely different from C++, and how javascript has nothing really to do with java, and is really a closer cousin to lisp than anything else. Now my head is full of even more ideas and I need to go bang them out on some projects to figure out what I actually know, and where I'm just fooling myself.

A book like this is probably something I'll wade into shortly.

So I learned C, then C++, then tcl, Perl and Python, and finally javascript. But I learned object oriented programming with C++, and Python does things the same way. You literally don't need Python documentation if you have a C++ class library wrapped up. I did quite a lot of stuff in Python with Qt using only the C++ docs.

Javascript seems like a deformed child compared to C++/Python. You do this software stuff because it's fun. Why would you twist yourself to match Javascript's compromises? Javascript didn't turn out the way it did because of some grand deep theoretical strategy. It was a series of ignorant half-steps mixed in with industry compromises and back-stabbings and rationalizations. Don't give it the credit it doesn't deserve.
Post a Comment

<< Home
Life in the middle of nowhere, remote programming to try and support it, startups, children, and some tinkering when I get a chance.

January 2004 / February 2004 / March 2004 / April 2004 / May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / May 2008 / June 2008 / August 2008 / February 2009 / August 2009 / February 2010 / February 2011 / March 2011 / October 2011 / March 2012 / July 2013 / August 2013 / September 2013 / October 2013 / November 2013 / December 2013 / December 2014 / February 2015 / March 2015 / July 2016 / September 2016 / December 2016 / April 2017 /

Paul Graham's Essays
You may not want to write in Lisp, but his advise on software, life and business is always worth listening to.
How to save the world
Dave Pollard working on changing the world .. one partially baked idea at a time.
Eric Snowdeal IV - born 15 weeks too soon, now living a normal baby life.
Land and Hold Short
The life of a pilot.

The best of?
Jan '04
The second best villain of all times.

Feb '04
Oops I dropped by satellite.
New Jets create excitement in the air.
The audience is not listening.

Mar '04
Neat chemicals you don't want to mess with.
The Lack of Practise Effect

Apr '04
Scramjets take to the air
Doing dangerous things in the fire.
The Real Way to get a job

May '04
Checking out cool tools (with the kids)
A master geek (Ink Tank flashback)
How to play with your kids

Powered by Blogger