Log in

No account? Create an account
19 December 2007 @ 02:37 pm
For all you programmer-y types: Steve Yegge wrote a lovely article about duplication and code size, and the Java (and C++, and C#, and C, and...) culture around it. It's very well explained, and it's explained with reference to the technical parts, but it's mostly about the culture.

I'm sure as programmers you're all already familiar with the weird little question, "so if software evolves so fast, why does it take 10-15 years for a computer language to catch on?" The answer, of course, being, "computer languages only look like software, they're actually human culture that happens to have supporting software." This is an examination of one of those pieces of slow-changing culture.
r_transpose_pr_transpose_p on December 21st, 2007 07:53 am (UTC)
I am a curse upon language paradigms
It does not surprise me that Java is rapidly becoming passe, given that I've finally gotten around to "learning" it ;)

I think I was busy getting deeply into C++ during the tail end of Java's heyday.

I think the only language I've learned without cursing into instant deprecation has been Python. I take this as an indication that either Ruby or Perl will be the scripting language of the future.

P.S. I finally got around to learning FORTRAN77 two years ago.
Noahangelbob on December 21st, 2007 02:53 pm (UTC)
Re: I am a curse upon language paradigms

I believe Ruby is the language of the future, but I say that because it's really hard not to love. Some day I will look into this phenomenon known as "LISP" and discover that rabid language partisans do not, by themselves, make an actual language of the future. In the mean time, leave me my delusions ;-)
r_transpose_pr_transpose_p on December 23rd, 2007 06:34 am (UTC)
Re: I am a curse upon language paradigms
To be fair, LISP has been "the language of the future" for much of the history of programming languages. Certainly if one looks at the first two high-level languages (Lisp and FORTRAN) one quickly becomes astounded at how advanced LISP was. As its advanced features have slowly been absorbed into other languages, however, its been harder to make the related claim that "in the future we will all program in LISP"

For one thing, one of Lisp's roles back in the 80s was the ease of adding it as a scripting language to a large software project (emacs and autoCAD come to mind, but many large projects benefit from a built-in scripting language to allow users to quickly write small extensions). LISP made sense for this role at the time (it was easy to write a parser/interpreter for, everyone knew it, it was easy to write small programs in, etc) but most programmers, given the choice today, would probably choose to embed Ruby, Python or some language starting with a "J" into their project to fill this role. Another large community that used to favor Lisp has now mostly moved on to things like Haskell, SML, OCaml, etc which were clearly inspired by LISP. I am guessing, Noah, that you fall more into the Python/Ruby camp of would-be LISP users then the ML camp. I certainly do (although OCaml intrigues me).

I have to say that about half of what I love about Python are things it inherited from LISP. I have heard that Ruby is nearly as easy to program in, prototype in, and read (readability being Python's main edge over Perl) but I have also been hearing that it lacks many of the LISP-like features that are present in Python. I will have to try Ruby and make that evaluation for myself.

I do like the fact that the current candidates for "language of the future" all appear to be fairly easy to learn. This bodes well for the future of programming (in my opinion).
Noahangelbob on December 31st, 2007 06:17 am (UTC)
Re: I am a curse upon language paradigms
I disagree thoroughly that Ruby lacks many LISPy features in Python. I would strongly suggest that it goes the other way -- Ruby has a lot of LISPy features that Python lacks.

The one significant exception to that is that Python is a lot easier to parse than Ruby, though of course far less so than LISP.
r_transpose_pr_transpose_p on December 31st, 2007 08:18 pm (UTC)
LISP -- the mother of all (good) languages
I am sufficiently baffled that I will have to dig further into Ruby to verify this.

A list of such features, however, may whet my appetite, and would thus be appreciated.
Noahangelbob on December 31st, 2007 08:35 pm (UTC)
Re: LISP -- the mother of all (good) languages
Ruby has:

* good closures, though too many variations on them
* good higher-order functions, and more than Python
* a very clean syntax to pass a block (simple lambda) to a function, and *lots* of standard functions that do this
* the ability to encapsulate blocks/procs/lambdas and pass them around, and common practices that encourage this
* excellent metaprogramming and general dynamic class/object/method creation
* the ParseTree gem to take block/proc-type objects and iterate through their code, permitting tools like Heckle to do macro-like tricks that alter code in neat ways
* symbols built into the language. They start with a colon.

Metaprogramming is used by Ruby on Rails to pretty remarkable effect. It's not exactly LISP-y, but it's similar enough in spirit to rate in my book. It certainly has a similar "types and objects should be easy to create and alter" dynamic spirit.
Noahangelbob on December 31st, 2007 08:46 pm (UTC)
Re: LISP -- the mother of all (good) languages
If this whole Ruby 'metaprogramming' thing intrigues you, I've actually put together some good source material on it. The "on this site" links are my own writing.

Probably the best example of Ruby metaprogramming is called Active Record, but I don't know a good simple introduction to it. The basic idea is:

* declare a class to be inherited from ActiveRecord::Base
* configure ActiveRecord::Base, through static methods, with a database connection
* ActiveRecord will read the database's tables and fields, and suddenly you'll have a bunch of classes and objects that happen to perfectly reflect your database schema, with method calls that are database-agnostic so that you can use MySQL, PostgreSQL, SQLite, Oracle, etc, without worrying much about which

This isn't exactly LISP-y, but again, I feel reflects a similar spirit in terms of type dynamism.

Oh, and hey -- that thing with adding specific methods to a single individual object and using it for an API thing? Here is a slightly more cogent explanation of same.
Noahangelbob on January 5th, 2008 04:57 pm (UTC)
Re: LISP -- the mother of all (good) languages
As an alternate answer: here is an explanation of how Python isn't very good on lambdas and second order functions, and is getting even less good via the removal of the reduce() function.
r_transpose_pr_transpose_p on December 23rd, 2007 07:05 am (UTC)
Re: I am a curse upon language paradigms

You can add a new method to a particular instance of a class, but not to the class definition at large.

I can see no good use for this, but I am fascinated by the myriad of bad-programming-but-slick-anyways possibilities.

For instance -- one could interact with an agent by sending it a list of classes, each of which had a "command" method for causing the agent to do something or other. The agent could then modify these instances by attaching a new method which, when called, gave the (success/failure) result of the command. Pure spaghetti code!
Noahangelbob on December 31st, 2007 06:20 am (UTC)
Re: I am a curse upon language paradigms
I have seen two good interesting uses for this feature. One is to add class-level methods, effectively static methods, to call roughly like "String.mynewmethod". That's the relatively sane one.

The less sane way is to have your interfaces just plan to call a bunch of functions on whatever object is passed in, no matter what type it is. You can then do the equivalent of Java interfaces if Java interfaces were done in a completely ad-hoc and per-object way. Despite that, it's a pretty slick way to write an API for a GUI. Ruby's Shoes library works this way, partly because it's written by Why the Lucky Stiff, a phenomenal Ruby programmer who is also the author of "Why's Poignant Guide to Ruby", and is totally batshit insane. But mostly in a good way. I think.