I got to thinking about this when reading a comment on a site I like to read, which said:
Rails in itself is, to me, not that impressive. It does a lot of things right, but it does probably just as many wrong. Not the least of which is scaling.
It seems that these sorts of "after the fact" "I know better" comments are a dime a dozen in the world of programming discussions. It's easy to come along after something's been built and puff yourself up by pointing to defects in existing systems and show that, therefore, by comparison, you're a clever fellow.
That's not my point, though - what I wish to explain is that yes, Rails really was that much better than what was around before it came onto the scene:
"Switching costs" between languages are high. Less so for really sharp programmers, but for the masses that use one or two languages, learning a new language, tools, deployment, etc... is a big step to take, with potentially high risks. Even most A-list programmers I know use a few languages at a time - it's simply easier if you're not tripping over your own feet by switching to a different system every day. "Flow" is easier to attain when you're ensconced in the thinking of one language. For companies, this effect is magnified, and switching to something new is not done lightly.
Since companies are beginning to explore Rails, successfully, I might add, you have to conclude that the big step into the unknown was worth it for some reason. Especially considering that a number of other languages rushed to copy various nice aspects of Rails, lessening the need for users of those systems to consider taking the leap.
Of course, that's not to say it's a perfect system, without reproach, or has no negative aspects, but in the spirit of honesty, and credit where credit is due, Rails really did move things a step forward, and the willingness of people to incur high switching costs to obtain its benefits is strong evidence of that.
Posted by David N. Welton
Thu, 22 Nov 2007 10:02:00 GMT
Aside from my hard drive crash, I've been working to figure out the best way to integrate Android and Hecl. Since Hecl has been a small, simple, humble language suitable for J2ME (or JavaME or whatever), that has meant in the past that it hasn't really been able to utilize more complex or advanced Java features like reflection, because they aren't present in the J2ME API. Android's more complete implementation of "Java" (yes, I know about the VM, but the programming language I'm writing in is still Java) opens up a number of possibilities.
First on my list of things to do was aim for a generic access layer for Java objects using reflection, so that you can do things like this:
$button settext "blah blah"
Now that we have that working, I also wanted to be able to create new Android widgets from Hecl, which is where things get tricky. The "problem" is that I want something that feels like a scripting language, not simply a reflection of the underlying Java. For instance, the XML description of a button looks like this:
Which is actually not so bad in terms of verbosity. The Java code is uglier, in my opinion:
Button button = new Button(activity);
button.setLayoutParams(new LinearLayout.LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.WRAP_CONTENT));
button.setText("Execute");
Especially the LayoutParams business, that is nowhere near as clear as the XML, where it's very obvious what values you're giving to what parameters. You wouldn't know that from the Java code without looking up the constructor for the LinearLayout.LayoutParams class.
Now, with Hecl I could of course write the code by hand to make things 'friendlier', but I'm worried that if I have to do that too much, it will take a long time to cover the rather extensive API, and it will also bloat the code. The ideal solution would be subvert the XML stuff for my own purposes, however, that's proving tricky. My first idea was to utilize the AttributeSet parameter that you pass to many View derived objects' constructors, in order to transform code like this:
Into something that Android can digest. Unfortunately, that's proving difficult, as the internals of Android barf on the class I'm passing them, even though it, to my knowledge, implements the AttributeSet interface without any problems.
This really made me wish that they would hurry up and release the source code, because I would have a far better understanding of the relationship between the XML attributes and the Java methods if I had access to what's going on under the hood. Harumph.
My next attempt was a hack that takes things like -text and transforms them into calls to setText, but that isn't as good, because you need a little bit more custom code for things like the layout parameters, which require special handling. However, lacking the source code, or some help from the Google folks with access to it (which isn't likely over the next few days as they're doubtless off consuming turkeys), it looks like that's what I'll have to do.
Posted by David N. Welton
Tue, 20 Nov 2007 14:05:00 GMT
I'm impressed. I reported the problem with my laptop (purchased in the US) to Dell Germany yesterday morning at about 10AM. Today (Tuesday), a technician with a new drive stopped by my house at about noon. Now I'm busy restoring from backups, after installing Ubuntu Gutsy.
While it's certainly been a big disruption, I'm impressed with Dell's customer service.
Posted by David N. Welton
Sun, 18 Nov 2007 11:25:00 GMT
So it looks like I will have to use the other computer, and hope that Dell sorts things out quickly. I'm pretty disappointed, as I just purchased the machine (an Inspiron 1505 with Ubuntu) in July, and haven't really traveled with it much.
[440525.460000] ata2.00: configured for UDMA/33
[440525.460000] ata2: EH complete
[440942.908000] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[440942.908000] ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in
[440942.908000] res 50/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
[440942.908000] ata2: soft resetting port
It required fsck'ing, and that was pretty much all she wrote.
The disk itself, according to smartctl:
Device: ATA ST980813AS Version: 3.AD
Serial number: 5NH0301G
It doesn't support SMART though, so I don't know if the recent fuss about Ubuntu and Laptop HD's has anything to do with it. I never ran it much without power in any case, so I doubt it.
It's especially frustrating, because I was making good progress on the Android port for Hecl, and will in the best of cases have to get a new computer "broken in", even though I do have good backups.
My fingers are crossed that the money I spent for extra coverage will be worth something and that Dell Austria will be able to resolve the problem in a hurry, without requiring that I send the machine to the US or anything else that takes a lot of time.
Posted by David N. Welton
Mon, 12 Nov 2007 23:57:00 GMT
Ok, so it's just the interpreter, which is hardly surprising. With an entirely new GUI API, that may require some more effort... we'll see. But for now, this will have to do:
The GUI API is not like MIDP2.0, so it's not compatible with existing J2ME apps, like Hecl. Hrmph. Seems like Java 5 constructs are supported (I also wonder what those hex addresses are doing in there):
In any case, very interesting, and very cool. It certainly changes things a lot, though - until this becomes commonplace, it will just add to the number of platforms that need to be supported, which might actually make life tougher for a while. All things considered, though, you can't complain about getting something that cool under an open source license!
As is often the case, they don't disappoint, with lines like
Things to bear in mind as you do, he says, include the need for your company to have purpose, to seek out ideas from the fringes, and to embrace the democratising power of the internet—none of which will be news to anyone who has been in business for more than a few minutes.
What really caught me eye, though, was this:
There is also growing demand from overloaded executives for shorter books. So in January Harvard will launch a new hardback series, “Memo to the CEO”, covering subjects such as lessons from private equity and the future of strategy. Each book will be about 100 pages long and will cost $20. In a similar vein, Harvard has adopted the approach taken by iTunes to pop albums, and has started to sell individual chapters of books online—an idea that has been a hit with academics in particular.
A lot of good business books take a sensible central idea, and then proceed to fluff it up to a length where it can be published as a book. Often, this makes for a good read, as the anecdotes and case studies and whatnot are interesting, but for those in a hurry, or simply wanting to know what the basic point of the book is about, it's just padding.
So, it looks as if the idea behind Squeezed Books is a good one, now I just need to get better at attracting more people to contribute summaries, and discuss the books on the site. One thing I've done to that end is stipulate that the summaries are available, unless otherwise noted, under a creative commons license.
Which you can test here (warning: it kills the page you're on, so if you're reading this from a feed reader or something, becareful).
There is, however a serious problem - the above code crashes Internet Explorer, so please use caution when running it. I can't figure out what the problem might be, as it works ok in Firefox and Konqueror. Now I remember why I didn't like Javascript before - "it's the implementation(s), stupid!". Advice appreciated.
Posted by David N. Welton
Wed, 07 Nov 2007 19:29:00 GMT
One of the things I love about programming is that you are always learning new things. You have to learn new things to keep up.
One of the benefits of using the Plotr Javascript library for the language popularity stats I did is that instead of having to download separate images for each statistic, a user just fetches the library once and then a few small bits of data for each chart, which is probably a net savings, especially when I start to add more statistics. However, Plotr, plus its various supporting libraries, is fairly hefty, so I needed to find a way to compress it. One of the helpful people on the freenode IRC network's #javascript channel pointed me at Yahoo's YUI Compressor, which is a nicely done project that squeezes quite a bit out of Javascript files. I would recommend it to anyone else who needs to pare down their production JS files to the bare minimum. Best of all, it's available under a very liberal open source license!
Incidentally, over the course of the language stats project, I was surprised at how much helpful stuff Yahoo provides, first and foremost, a real API for their search engine, something that Google no longer has. Hopefully, it's a sign of better things to come for them (if for no other reason than to keep Google on their toes!).
By the way, for those interested in the language stats project, I set up a forum with RSS feeds, where I will be posting updates, and accepting suggestions for further improvements.
Of course, the results aren't very scientific, but they're interesting, nonetheless. I'll be adding some more charts like trends once I have data over a few months.
I ran some similar stats a few years ago, but this time I've geared up to automate the whole process, so results should be updated regularly, once everything is up and running.
