JOB REFERRALS
    ON THIS PAGE
    ARCHIVES
    CATEGORIES
    BLOGROLL
    LINKS
    SEARCH
    MY BOOKS
    DISCLAIMER
 
 Friday, January 13, 2006
Billy Hollis on the history of programming languages

Billy Hollis, famed Visual Basic lecturer and secret programming language anthropologist, has compiled a succinct history of programming languages. As he puts it,

If you like VB, look at the history of the C family [of languages] first. If you like C#, Java or C++, look at the history of the BASIC family first.
Definitely something to quote next time you're in a (friendly) raging debate about "which language is better". :-)

Happy Friday.


.NET | C++ | Java/J2EE | Ruby

Friday, January 13, 2006 7:47:18 PM (Pacific Standard Time, UTC-08:00)
Comments [2]  | 
 Wednesday, January 11, 2006
LINQ paper comments and feedback

A number of you have made comments about my LINQ paper, and rather than respond in comments in turn, I thought I'd gather them up and respond to them en masse. So, without ado....

Stu Smith said:

Nice article. Two things occur to me immediately...
  1. Based on my current understanding of LINQ, it's purely for querying, and so compared to most O/R systems it lacks caching support. (ie its queries may be optimal but that's not much consolation if it keeps re-executing them).
  2. The O/R system we use (which admittedly only needs to support a particular kind of application) solves the 'lazy load vs N+1' issue by generating joined queries based on either the path taken to the data, or on particular routes to a marked-up tables. ie, if you navigate from a Customer to a collection of Orders, that's a single select. If you then start iterating the Orders and inner-iterating the OrderDetails, then on the first one a second joined select is issued, and for subsequent iterations the data is already cached and thus no further SQL statements are emitted.
Thanks, Stu. Responses:
  1. No, LINQ can, in fact, do any sort of relational manipulation, including INSERTs, UPDATEs and DELETEs, but the real strength of the language integration is in the query aspects, particularly the fact that LINQ can do these queries across any rectangular data store, so it's fair to say that LINQ is mostly about query.
  2. I'd be interested to hear more about your solution to solve the lazy-load issues, partcularly how you handle the situation where you need to display only a small part of the full OrderDetails data--remember, part of the criticism of O/R is that they either eager-load too much, or lazy-load too much, and can't infer the amount or areas of data to retrieve that's "just right".

Bryant wrote:

I thought the article was well written and informative. While I think it's cool that I might one day be able to use the same object model to query databases, XML documents, and even the file system I still feel compelled to look back upon my days as a DBA. This looks a lot like building ad hoc SQL statements in the code except we're a little more type safe here. LINQ still does not answer the question of storage abstraction. The developer still needs an intimate knowledge of the database structure. So, LINQ appears to cover "Conflicting type systems" and maybe "Transactional boundaries" and "Query/access capabilities". There are still four more items in your list that I don't see being solved with LINQ. Your article was a great read but sorry, I am still not excited.
We are building ad-hoc statements in the code, although this depends slightly on your definition of "ad-hoc statements" (my early experiences lead me to a definition that says "ad-hoc statements" means "users can throw SQL at the database", whereas "developers throwing SQL at the database" isn't ad-hoc, as the SQL itself is known prior to execution; I can see where others' definitions may vary on this, however). I do have to point out, however, that LINQ *does*, in fact, answer the question of storage abstraction, though perhaps not to the degree you prefer. I see LINQ's ability to hide the difference between in-memory storage and external-database storage as storage abstraction, but what it does not do (rightly, in my opinion) is try to hide the differences between rectangular (relational), hierarchical (XML) and referential (objects) storage. That is the area where the impedance mismatches kick in, and that's what's the hard part to solve. As to the last four items, well, one could always say they're not done yet... :-) Seriously, I think it's a great start, and my excitement comes not necesarily from what LINQ can do right now, but from the idea that it opens up and explores an entirely new avenue of research that nobody else seemed to be interested in exploring.

James commented:

I thought the article was great! I'm a little unclear as to why it's not getting ranked better on MSDN but for someone who didn't really understand/appreciate the problem domain LINQ is serving, your article really got me thinking and cleared up a lot of fogginess in my mind. Excellent work!
Thanks for the praise, James, and as for MSDN's ranking schemes, a couple of other MSDN authors have suggested that there's some "article assassination" going around the site, so maybe that's it. I'm glad you find it intriguing and that it "got you thinking"--that, in many ways, was the point in the first place. :-)

Andy Maule said:

Very interesting! I liked the discussion of Rail's ActiveRecord which I think is an approach that most people miss when talking about OR Mappings.

There's a good research paper discussing the same stuff here. It mentions something recently developed for doing statically typed queries in Java 'Native Queries' which is an interesting comparison to LINQ. Anyone interested in this area should take a look.

I'm currently doing a PhD in this area, and I have to say that LINQ is making things very interesting.
Well, good luck on your PhD, and thanks for the link--I'm definitely interested in following up on anybody who's pursuing this in the Java space. Along those same lines, Marius Gherorghe pointed out that
Karmencita is my lightweight alternative for in memory object querying.
and again, I appreciate the link.

As for the rest of you who offered kudos (Bart De Boeck, Dan Kahler, Paul Wilson, Eric Bachtal), thanks; every author likes to know that their work is appreciated, particularly when so much of what they say seems to stir up more controversy than discussion. :-)


.NET | Java/J2EE

Wednesday, January 11, 2006 7:52:13 AM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Friday, January 06, 2006
Am I a curmudgeon of technology? You betcha

Matt Morton commented, "One might be able to say that Ted Neward is cynical about any new technology. You might also say he puts himself in the position of the "old" kermudgeon (sp) who opposes anything new and cool." Yep, guilty as charged, for a very specific reason.

Ages ago, when EJB first shipped, I was one of the first who looked at it with stars in my eyes. It seemed like such a great, easy solution to all the problems of developers building server-side systems (and I'd done a C++-based 2-tier, CORBA-based 2-tier and Java/NetDynamics-based 3-tier system before this, so I kinda fit into that space already). I was excited. I was ready to swear it to all my friends. And then....

It was a lunch with Don Box and Kevin Jones, shortly after I'd joined DevelopMentor, and I asked Don and Kev about EJB. Don looked at Kev with this silly grin on his face, and Kev just shook his head and said, "It's a thing on a thing. That's always slower than just a thing." Slowly, the light dawned. Over the course of several conversations with Kev and Don later, I came to realize that EJB wasn't a distributed object technology, but a component technology focused on transactions. Over time, developers' stupidity in using EJB for their single-database simple-HTML-form apps drove me to be widely proclaimed as an "EJB expert who consults against EJB", which isn't exactly correct--I've recommended EJB in scenarios, but only where it seems appropriate.

Which, if you think about it, is what we're supposed to do: recommend tools where they're appropriate.

What does this have to do with being a curmudgeon? Simple: I trust no technology until it proves itself to me. Our industry is SO filled with hype, it's surprisingly easy to get caught up in the energy and excitement that surrounds a new tool, particularly those that deal with presentation issues. (Face it, folks, the "jazz factor" surrounding Avalon/WPF or Ajax is exponentially higher than that surrounding RIFE/Continuations, despite the fact that the latter is far more interesting from a technology perspective. Why is this? Because you can SEE the niftiness in Ajax; the continuations story isn't something you can show off to your mom or impress your significant other.) I look at new tools, new technologies and deliberately look to find the flaws, the various fallacies they fall prey to, and I routinely caution people against them JUST because they're new. I would much rather err on the side of caution and hestiation than fall into the trap of hyperbole and bandwagon, because I think, ultimately, it's a more responsible position to my clients and audience.

I don't think I'm unjustified in this position: there's an unhealthy absence of cynicism in our world right now. My two big examples: the terrible tragedy of the miners in West Virginia (why didn't anybody in the media CONFIRM the story of their rescue before reporting it?) and the South Korean human cloning story. Or the supposed report of "cold fusion" from a decade or two ago. Our industry could use, I think, from a large dose of, "OK, so you've created a new framework. What's it to me?" right now.

Matt went on to say,

I dont totally agree with #4 though. When a large scale Ruby project fails it wont be because of the language. Just as it is faulty to claim a language will reduce project failures, it is just as faulty to claim that a language or platform will be the cause. Projects fail because of people, plain and simple. People in general have trouble being honest especially when they have something vested emotionally (or financially) in a project. Perhaps this is what he is getting at. The proponents are so emotionally involved with Ruby that when less experienced folks try to apply it to a larger scale the project, it will blow up.
Personally I have found that Rails and Ruby are a joy to use. I guess then you could say that I get emotionally involved with things that bring me joy. Perhaps Rails strength is its weakness. It is such a joy that it blinds you to its true uses.
Let me clarify my point: Ruby and Ruby-on-Rails are like those specialized tools that my grandfather (a well-known, well-respected plastics industry founding father down in Southern California) used to use when he was doing his diemaking in his shop in Oregon--they're tools that ONLY a master craftsman can truly appreciate and use well. Put them into the hands of a novice... like me... and I'm more likely to cut off an appendage than I am to create great beauty or a workable mold for stamping out intricate plastic parts. I suspect you, and many of the others using Rails, know that. But, and here's the rub, that message isn't being heard, and it's a matter of time before a team of novices tries to use Ruby and Rails to do a project, yielding in the end nothing more than human body parts on the floor. THAT will be the well-trumpeted Rails failure, and the backlash will begin.

Which, if you think about it, is exactly the same thing that happened with EJB before it.


Java/J2EE | .NET | C++ | Ruby | XML Services

Friday, January 06, 2006 5:59:53 PM (Pacific Standard Time, UTC-08:00)
Comments [4]  | 
WHY wasn't this out for Christmas this year?

Lego, those folks who brought you Mindstorms in the first place, have done it again--they've announced a next-generation programmable brick, the NXT, that offers some really cool enhancements, including Bluetooth capability. Suddenly, the old Robotwar clones from ages ago take on an entirely new meaning....

More interestingly, supposedly they've announced that the VM itself will be documented, which leads me to wonder how long before we see J-NXT and NXT#. It's amazing how the managed environment is just spreading like wildfire through the world, if'n you ask me....

Hey, Santa, if you're listening, this just went on my list in a BIG way. :-)




Friday, January 06, 2006 4:36:54 PM (Pacific Standard Time, UTC-08:00)
Comments [0]  | 
 Thursday, January 05, 2006
Struggles with Vista 5270 and VMWare 5.5

So the December CTP of $g{Vista} is available, and I'm finding a recurring problem trying to install it into VMWare. When I tried this with the Beta1 of Vista into VMWare 5.0, the same problem occurs as what I'm getting now: when trying to boot off of the .ISO inside of VMWare (in other words, not physically off a burned CD/DVD, but out of the .ISO image itself mapped into the virtual CD in VMWare), I get a BSOD every... single... time. Is this indicative of a f-ed up installation of my VMWare image, is this a known bug in Vista (sidenote: yes, I know about the raw partition issues with Vista, but doing an XP-first install of Vista gives the same BSOD on reboot), or is it just the combination of ISO-image-and-VMWare? Anybody got ideas for a workaround or a fix?




Thursday, January 05, 2006 10:18:15 PM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
Off-topic: Acquaintance seeking a J2EE expert with familiarity in other languages/environments

I've been contacted by a third party (not a recruiting agency) who's having a hard time finding a J2EE architect with familiarity/expertise with concepts of architecture and the low-level chops not to lose sight of the code. To put it in their words:

This is strongly influenced by component-based methodologies such as OpenDoc, but would be extending the RCP Platform developed by Eclipse, and encompassing other concepts from systems such as Squeak... We are having trouble finding someone senior enough to understand the conceptual architectural issues, but technical enough to know important lower-level details such as how design choices will effect performance and scalability.
I'd take the job myself, but they have a very specific dealbreaker requirement: you must live in the Northern California area. If you're one of those guys who knows the list of technologies in the J2EE platform, has used all of them at least once or twice, and still reads the Lamba-the-Ultimate blog, drop me a note and I'll put you in touch.

By the way, DON'T send me your resumes--in your email to me, tell me what your favorite alternative language or platform is, and why. I'll use that to know if you're somewhere in the ballpark. ;-)

And no, job postings are NOT going to become a regular part of this blog; I'm doing this as a once-off. (My motivation? I just want to help these guys; this isn't an easy requirement to fill, and I'm hoping I get to meet whomever it is they end up selecting, 'cuz I'm thinking they'll be a kindred spirit. :-) )


Update: They sent me a formal job description, and it seems the desires changed just a bit. *shrug* See for yourself:

A lead software architect for [[name snipped]]. Applicant must be able to take a high level conceptual framework and architect a conceptually sound implementation using open standards in collaboration with an existing team. Experience with Java, Eclipse, and the Rich Client Platform (RCP) sub-project in Eclipse is a significant advantage. Experience with Aspect Oriented Programming is a plus. Participation in the open standards community a plus (e.g. W3C and Eclipse standards communities). Five or more years of experience required with experience as a lead software architect, industry experience preferred. Opening is for a full-time onsite position.
Doesn't sound like they want too much, ya? :-)


Java/J2EE

Thursday, January 05, 2006 4:49:25 PM (Pacific Standard Time, UTC-08:00)
Comments [2]  | 
IronPython 1.0 beta 1

Jim Hugunin strikes again: IronPython 1.0 beta 1 is out. I think Jim should get an award for "first language designer to operate on both the JVM and CLR". Now he just needs to do one more implementation to get the hat trick. ;-)


.NET

Thursday, January 05, 2006 4:17:27 PM (Pacific Standard Time, UTC-08:00)
Comments [0]  | 
LINQ and its prior art

Flame away...


.NET | Java/J2EE | Ruby | XML Services

Thursday, January 05, 2006 12:00:04 PM (Pacific Standard Time, UTC-08:00)
Comments [48]  | 
 Wednesday, January 04, 2006
New Ajax course available

The Pragmatic guys are at it again... This time it's a whole course, taught by two of the finest instructors I have had the privilege to know (and, quite honestly, argue with), on everybody's favorite presentation-layer hot topic, Ajax.

By the way, dear audience, this is one class you can attend regardless of which camp you prefer--both Stu and Justin are equally adept on both enterprise platforms (Java and .NET) and the new hot language, as is clear when they say that they will show you how "to use frameworks such as Rails, Spring, and ASP.NET"; Justin, for example, co-authored "Better, Faster, Lighter Java" and the "Spring Developer's Handbook", as well as built DevelopMentor's ASP.NET website and infrastructure. Stu was one of the COM cognoscenti back in the day (his poems on the subject (towards the bottom, search for Stu) are legend), and then took over as Java curriculum lead when DevelopMentor... well, created a Java curriculum. Two brighter guys--and better instructors--you're not likely to meet.

Oh, and, uh, they seem to know a fair amount about Ajax, too. ;-) Enough that I'd attend the course, were I not already busy that week.... Do yourself the favor, if you want to know more about Ajax, go see them. I can think of a lot worse ways to spend a grand in cash and 3 days...


.NET | C++ | Java/J2EE | Ruby | XML Services

Wednesday, January 04, 2006 1:18:21 AM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Tuesday, January 03, 2006
Question for the audience

An interesting question emerged during a discussion with some buddies/co-workers/peers/whatever-you-want-to-call-them today:

"Which conferences have you attended in the past that you thought was really good, and why? Which sessions were your favorites, and why? What made them that way?"
(The root of the question was simple at its heart: What makes a good conference session?)

Yes, this is somewhat selfish, since the new conference season is amping up, and obviously I'd like to make sure my sessions are ones that people find interesting and recommend to others, but the question actually stemmed from an unrelated discussion to that. I promise. :-)


Conferences | .NET | C++ | Java/J2EE | Ruby | XML Services

Tuesday, January 03, 2006 7:23:39 PM (Pacific Standard Time, UTC-08:00)
Comments [6]  | 
 Monday, January 02, 2006
Too quick to adopt Ruby, you were.

Microsoft has done it again--this time, they're previewing the next release of C# planned for after LINQ/C# 3.0. They call it, for obvious reasons, the YODA programming langauge. Judge me by my size, do you? As well you should not, for my ally is the Source, and a powerful ally it is, indeed.

Remember: A Jedi uses the Source only for knowledge and defense, never for a hack.


.NET | C++ | Java/J2EE | Ruby

Monday, January 02, 2006 3:50:51 PM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Sunday, January 01, 2006
Annotation let-down: A response

In a recent thread on TheServerSide.com, Rick Hightower, a fellow NFJS speaker, commented on the JSR-175/annotations specification, and I felt a little obligated to respond, since this is a common critique/criticism:

Why don't you like the implementation? I hate the fact that your code has to import the annotations and then your code is tied to the annotation. It does not seem that different than depending on a interface (i.e., a marker interface). I'd like to see a soft import for annotations that does not impact compilation. (from TheServerSide.com)
Rick, no part of JSR 175 was more hotly debated, or contested, than the requirement we made that annotations be present not only at compilation-time, but at run-time. I could go back and show you the weeks of emails that went flying back and forth between the EG members, trying VERY hard to come up with a solution to the problem, but none could really be created, given Java's basic platform requirements, one of which was that the language was strongly-typed.

The basic problem was this: if the compiler runs across an annotation, and it doesn't match an annotation type defined anywhere in the compilation classpath of imported symbols, what is the proper behavior? In any other scenario, such as:

public class App
{
  public static main(String[] args)
  {
    Systme.out.println("Hello, world!");
  }
}
the behavior is extremely clear: this is an error, and compilation needs to fail to signal as much. But the proposal for "soft imports" of annotations would lead to a much grayer--and potentially disastrous--scenario, where the compiler SHOULD flag an error during compilation, but doesn't:
public class App extends Object
{
  @Overide public String toString(Object obj) { return "App"; }
}
Here, the human eye can clearly see that the class means to take advantage of the @Override compiler annotation to ensure that the toString() method is defined similarly in a base class, but because of a typo, the compiler now, under a soft-import rule, will simply ignore the annotation. This is the worst of all violations of the Principle of Least Surprise--the programmer believes the annotation is present, and that the override is acceptable, where in reality the annotation is ignored, the override isn't checked, and the code will fail to operate as expected.

The big IDE vendors were particularly upset at this idea, leading one to claim, "If we cannot solve this problem we will consider JSR 175 to have been a failure." Unfortunately, then, we failed--there is no good way to solve this problem without breaking the fundamental vision of the Java platform. We tried a variety of ideas, including a few centered around the JDK 1.4 assertion idea (some kind of runtime flag indicating which annotations were safe to ignore), but couldn't work out the basic semantics of such without requiring a definition of the annotation to be present on the compilation path. And frankly, in the grander scheme of things, it makes sense to me that annotations ARE required at compilation time--just as interfaces, helper classes, member field types, and other types are required to be present at compilation time, as well.

Rod Johnson continued his critique of annotations by citing the following two reasons:

  1. No proper mechanism for overriding annotations at runtime, despite the fact that just about any framework that uses annotations is going to need to consider doing that.
  2. Inability for an annotation to extend an existing interface (even if that interface is simple enough to sit within annotations). Of course there are implementation issues around this one, I guess. But it means that it's hard to avoid code duplication when working with annotations and alternative metadata sources--something that's going to be particularly important until everyone and their dog uses Java 5, and anyway will remain important to work with existing code that may not have the right annotation.
Rod, the suggestion for overriding annotations at runtime was made, and we almost unanimously shot it down, because there are no facilities for changing any other of a type's static type information at runtime: I cannot change methods, fields, inheritance, or interfaces at runtime, either. Such behavior belongs in the world of MOPs, perhaps, and hence your interest in such, but in a statically-typed world such behavior is not part of the landscape. Like it or hate it, such is the world that Java is a part of. (By the way, annotations are intended for much more than just frameworks--witness the annotations the javac compiler already recognizes, and other systems beyond frameworks are going to pick up on this in spades in the coming years. Just wait until the design-by-contract folks start talking to compiler folks again.) And you already answered your second criticism, that annotations extending existing interfaces would be difficult to implement. In truth, annotations and interfaces aren't really the same thing, so expecting one to be able to inherit the other wasn't something I'd consider good design. I didn't even like the "@interface" keyword--I preferred something like "annotation" or "attribute" instead, but Josh (rightly) pointed out that introducing new keywords into a language ten years old was going to be a Bad Thing. (And yes, the same was true of "assert", and they did it anyway, and look how well that turned out--they broke JUnit, of all things!)

Nutshell version of all this, the JSR 175 EG did, in fact, think long and hard about "soft imports" and "runtime annotation modification", and both ideas were shot down for what we felt were good reasons.


Java/J2EE

Sunday, January 01, 2006 5:10:11 AM (Pacific Standard Time, UTC-08:00)
Comments [2]  | 
2006 Tech Predictions

In keeping with the tradition, I'm suggesting the following will take place for 2006:

  1. The hype surrounding Ajax will slowly fade, as people come to realize that there's really nothing new here, just that DHTML is cool again. As Dion points out, Ajax will become a toolbox that you use in web development without thinking that "I am doing Ajax". Just as we don't think about "doing HTML" vs "doing DOM".
  2. The release of EJB 3 may actually start people thinking about EJB again, but hopefully this time in a more pragmatic and less hype-driven fashion. (Yes, EJB does have its place in the world, folks--it's just a much smaller place than most of the EJB vendors and book authors wanted it to be.)
  3. Vista will be slipped to 2007, despite Microsoft's best efforts. In the meantime, however, WinFX (which is effectively .NET 3.0) will ship, and people will discover that Workflow (WWF) is by far the more interesting of the WPF/WCF/WWF triplet. Notice that I don't say "powerful" or "important", but "interesting".
  4. Scripting languages will hit their peak interest period in 2006; Ruby conversions will be at its apogee, and its likely that somewhere in the latter half of 2006 we'll hear about the first major Ruby project failure, most likely from a large consulting firm that tries to duplicate the success of Ruby's evangelists (Dave Thomas, David Geary, and the other Rubyists I know of from the NFJS tour) by throwing Ruby at a project without really understanding it. In other words, same story, different technology, same result. By 2007 the Ruby Backlash will have begun.
  5. Interest in building languages that somehow bridge the gap between static and dynamic languages will start to grow, most likely beginning with E4X, the variant of ECMAScript (Javascript to those of you unfamiliar with the standards) that integrates XML into the language.
  6. Java developers will start gaining interest in building rich Java apps again. (Freely admit, this is a long shot, but the work being done by the Swing researchers at Sun, not least of which is Romain Guy, will by the middle of 2006 probably be ready for prime-time consumption, and there's some seriously interesting sh*t in there.)
  7. Somebody at Microsoft starts seriously hammering on the CLR team to support continuations. Talk emerges about supporting it in the 4.0 (post-WinFX) release.
  8. Effective Java (2nd Edition) will ship. (Hardly a difficult prediction to make--Josh said as much in the Javapolis interview I did with him and Neal Gafter.)
  9. Effective .NET will ship.
  10. Pragmatic XML Services will ship.
  11. JDK 6 will ship, and a good chunk of the Java community self-proclaimed experts and cognoscente will claim it sucks.
  12. Java developers will seriously begin to talk about what changes we want/need to Java for JDK 7 ("Dolphin"). Lots of ideas will be put forth. Hopefully most will be shot down. With any luck, Joshua Bloch and Neal Gafter will still be involved in the process, and will keep tight rein on the more... aggressive... ideas and turn them into useful things that won't break the spirit of the platform.
  13. My long-shot hope, rather than prediction, for 2006: Sun comes to realize that the Java platform isn't about the language, but the platform, and begin to give serious credence and hope behind a multi-linguistic JVM ecosystem.
  14. My long-shot dream: JBoss goes out of business, the JBoss source code goes back to being maintained by developers whose principal interest is in maintaining open-source projects rather than making money, and it all gets folded together with what the Geronimo folks are doing. In other words, the open-source community stops the infighting and starts pulling oars in the same direction at the same time. For once.
Flame away....


.NET | C++ | Conferences | Development Processes | Java/J2EE | Reading | Ruby | XML Services

Sunday, January 01, 2006 12:25:56 AM (Pacific Standard Time, UTC-08:00)
Comments [97]  |