Computer Languages

Lasagna Code: Redux

November 25, 2011
By

I write here as sort of a pressure release valve. It seems that my little rant on Lasagna Code got some attention. I read through the comments. It seems most get what I’m on about. But I figure I might as well be a bit clearer, in case any of those posters revisit. Yes, I’m against object oriented programming. I’ve been against it for years. I find it an obtuse and bloated way to code. And beyond Smalltalk, I’ve really not found another decent object-oriented language within which to code. This obsession language designers have of wedging an object system into a language “just because” is rather stupid. After all, all objects are is formalized data structures. It’s really that simple. For those that are about to jump up and down and scream they aren’t, I won’t argue because it’s pointless. I’ve used OO since the early 80s, initially in Smalltalk. Later, much to my horror, C++, and then for a brief period with Java — but I refuse to ever touch Java again. Too horrible and, happily, I’m sufficiently old enough to not have to do what I don’t want to do. Python, as I said, is a very

Read more »

Lasagna Code

November 1, 2011
By

Anyone who claims to be even remotely versed in computer science knows what “spaghetti code” is. That type of code still sadly exists. But today we also have, for lack of a better term — and sticking to the pasta metaphor — “lasagna code”. Lasagna Code is layer upon layer of abstractions, objects and other meaningless misdirections that result in bloated, hard to maintain code all in the name of “clarity”. It drives me nuts to see how badly some code today is. And then you come across how small Turbo Pascal v3 was, and after comprehending it was a full-blown Pascal compiler, one wonders why applications and compilers today are all so massive. Turbo Pascal v3 was less than 40k. That’s right, 40 thousand bytes. Try to get anything useful today in that small a footprint. Most people can’t even compile “Hello World” in less than a few megabytes courtesy of our object-oriented obsessed programming styles which seem to demand “lines of code” over clarity and “abstractions and objects” over simplicity and elegance. Back when I was starting out in computer science I thought by today we’d be writing a few lines of code to accomplish much. Instead, we

Read more »

RIP John McCarthy

October 24, 2011
By

The creator of my favourite programming language passed away yesterday. Lisp is, in my view, the best language ever devised. Sadly, too few in the computer industry realize or comprehend this fact. Lisp, and its descendants such as Scheme, are beautifully consistent programming languages wherein the programs and the data are defined identically and as such can be manipulated similarly. This allows one to generate code easily that can then be executed. Most people stare at Lisp-like languages and can’t get past the parentheses. Ironically, most every language uses parentheses of one sort or another. If one does a quick comparison with C, for example, one will quickly realize that Lisp doesn’t have that many more parentheses than does C. And with C, you can’t work in a fully interactive environment wherein you develop your code and test it all in a fully integrated way. Instead, you’re still stuck with the stupid edit-compile-run-debug cycle that made sense when we used punch cards but doesn’t today. Even “modern” languages such as Java are really only prettied up C, though truth be told, I’d rather code in C because it’s powerful and puts the onus on the programmer to do things right

Read more »

RIP Dennis Ritchie

October 12, 2011
By

Dennis Ritchie passed away this evening at the age of 70. I doubt it’ll get the play in the papers that Steve Jobs death did even though Ritchie’s impact was greater in my opinion. For those unfamiliar a brief writeup on Unix and its founders. Rob Pike posted a note re: Ritchie’s passing. A true passing of an era. And man does it make me feel old. I still remember first using Unix back in 1979 and then used it pretty much constantly ever since. The  most apropos send off comes from Muppet Labs, albeit no relation to the Muppets or their infamous lab.

Read more »

Lots of Irritatingly Silly Parentheses

November 7, 2010
By

That’s what many people I know think of when they hear my favourite languages are all Lisp derivatives such as Scheme or Clojure. They usually follow that up with a statement indicating that there are just too many brackets in Lisp. For a while I’ve wondered about this and after a little bit of study I think most people are wrong. They’re fixated on the position of the brackets not on the number. Most languages use a lot of brackets, be they , ( … ), { … } or < … >. Anyone who codes up XML knows all too well how many of those < … > brackets they’ll be dealing with. So I looked around for some simple samples of accumulator code fragments and found this on Paul Graham’s site. Sure, Graham is a Lisp geek, but a quick look at the following C++ code quickly shows something: struct Acc { Acc(T n) : n(n) {} template <typename U> Acc(const Acc<U>& u) : n(u.n) {} template <typename U> T operator()(U i) { return n += 1; } T n; }; template <typename T> Acc<T> foo(T n) { return Acc<T>(n); } vs. Scheme which is as

Read more »

How About noOS?

October 16, 2010
By

We have NoSQL but maybe it’s time for noOS. I’ve talked about this with colleagues for a while. Many are old enough to realize why we have operating systems, but some of the younger crowd don’t. The reason for an operating system is to equitably share the resources of a computer. This made sense when the systems were large, hulking brutes sitting in air conditioned rooms. It makes no sense today when one core of an average computer is faster than any mainframe of 40 years ago — or even a roomful of them. It’s why I’ve had discussions asking why we even need an OS anymore. Perhaps it’s time to revisit another  idea that came out of the great CS labs, namely machines that only ran a language. I’m talking about Lisp Machines, Smalltalk Machines, APL Vector Machines, etc. These machines had the beauty of allowing you to program extensions into their core via well-defined languages all within a fully interactive environment. It was bliss programming these types of systems. And it’s not like computers aren’t fast enough to allow for fully interactive, dynamic environments as the way to build applications. Today’s hardware makes those old Smalltalk, Lisp and

Read more »

Computers

October 7, 2010
By

For the most part computers just aren’t that much fun anymore. I’ve come to this stark conclusion of late and realize that part of my general malaise regarding the industry is that my passion for and love affair with computers is over, or at least in the latter waning stages. When I first got into computers in 1978 I thought they were simply the neatest things I’d ever seen. The whole industry was still new back then, and personal computers were something few talked about and many dared not dream of. But that was more than 30 years ago! I remember my first encounter with a computer via a batch card system while in high school. Mr. Lane, our computer and Functions and Relations teacher, introduced a large number of Grade 13 students — and a few Grade 12s — to computers. He had a passion for them and loved teaching the course. I think most people who took the course were taking it either out of sheer curiosity or from the need for one more math/science credit to complete their high school diploma. Regardless, I found the notion of algorithms and applying what I had learned in Algebra, Calculus,

Read more »

Asylum Seekers

September 26, 2010
By
Asylum Seekers

One book I constantly reference is Alan Cooper’s The Inmates Are Running the Asylum. It is an excellent book explaining the difference between what a techie sees are how software should function versus what a normal person sees and wishes software would do. It all boils down to the difference of putting the onus on the developer to make the software as easy and intuitive as possible versus making the poor end-user jump through hoops to get anything accomplished. It’s the notion that whatever is done should be as easy as possible for the programmer to code as opposed to making sure the end-product is something that doesn’t aggravate, confuse, or otherwise enrage the end-user. Cooper further states that software should just be “good enough”. This is a common refrain today, but a few years ago was rather heady stuff. I’ve long believed “good enough” would solve a lot of our troubles but most people in high-tech are perfectionists who spend an infinite amount of time honing their craft and their software to such an extent that it either never gets out or when it does get out is rather useless. In this way Cooper is also proclaiming that Agile

Read more »

Revisiting Code of Yore

August 30, 2010
By

I’ve started a new job. I’m now working with some of smartest people I’ve ever worked with, an impressive lot. One of them I owe a lot. He was a former prof. And he still makes my head spin with how easily he handles technology and how it can be applied to the real world. But what really gets me is that he remembers everything be it technology from the 70s or technology from yesterday. And he knows how to apply it individually or in concert to any given problem. It’s made me do something I should have done a long time ago, take a step back. I’ve been so close to problems that I’ve just been running. Running to stand still, as the old saying goes. I think it was partially the environment I found myself in. I needed to focus on getting work in and out as quickly as possible that I would grasp onto the first reasonable solution and run with it. Luckily, most of the time it was the optimal or near-optimal solution. But sometimes it wasn’t. The other day I realized that a few technologies I haven’t used in years — decades — were possibly

Read more »

Density

July 6, 2009
By

I’ve long been complaining — some would say bitching — about how verbose it is to code in many languages today. In many cases I am sorry witness to people programming in C/C++ or Java and writing thousands upon thousands of lines of code only to end up with a piece of code that coudl easily have been expressed in a denser language in a few hundred lines of code. Today I came across a nice table produced by Larsson Omberg comparing the code required to do some value decomposition in Mathematica, Matlab, and Python. It’s from 2005 but much of this probably still holds for his example.  What we see is the following: Mathematica: 276 lines of code Matlab: 52 lines of code Python: 71 lines of code What we see is a density advantage of 5 times for Matlab and about 4 for Python over Mathematica. And Mathematica is already a dense language. Imagine coding the same solution in C/C++ or Java? We’d probably see at least twice as much code over Python for C/C++ and Java. That means the Mathematica code would be 10 times as dense, an order of magnitude. What that means is that on

Read more »

Page 1 of 3
1 2 3

Musings

A blog of my musings. Some folks find it interesting and so I continue. Hopefully it will remain fairly interesting. At worst, it'll keep me writing orthogonally to my day job.

Month at a Glance

February 2012
M T W T F S S
« Dec    
 12345
6789101112
13141516171819
20212223242526
272829  

StatPress

Visits today: 31
Total page views: 89210