This news is buzzing through the 'net so fast it's going to make Disney's head spin...
I first picked up on it over at Ain't it Cool News, when a post on Thursday indicated that Disney had shown something interesting at the San Diego Comic Con.
Now, anyone that's a part of my generation -- the Generation-X crowd...especially those of us born in the early-to-mid 70s, whose formative years that encompassed most of the 1980s -- were heavily influenced by many movies during our youth. Star Wars is an obvious one. Those famous movies from Lucas made us believe that technology could be bad-ass, and useful, and made space travel seem awesome. And like them, many other movies helped push the idea that technology was cool in various ways, and we've taken that to heart in our adulthood.
Tron was different.
Tron didn't just show us that tech was cool, but brought in the idea of a world inside the computer. A world that opened up the imaginations of many kids. While today the movie might seem quaint, or outdated, at the time of it's release is triggered inside many kids the ideas that have brought us what has now become the billion-dollar industry of computer games.
It also showed us that the world of the computer could be ours to command and control, and planted the seeds in many of us (myself included) that would inspire us to become programmers.
I cannot understate just how influential this movie was to many geeks from my generation.
Tron wasn't a smash hit when it was released, but it's become such an iconic movie of the Gen-X crowd that there's been talk of a sequel going back now since at least the mid-90s, if not farther. I've seen various ideas and comments from Disney, Steven Lisberger, and others talking about plans for the movie over the years, and ultimately it seemed that the passage of time, and the march of technology, had made it far too difficult to make a more modern adaptation that could even do the original credit. It just seemed that our modern world had made the idea of a sequel too difficult to pull off.
And then Gizmodo showed this, along with Autoblog, and of course Ain't it Cool News had it (but they had to pull it).
Oh...my...god...
Judging by the buzz from the super-crappy video footage, this movie may have the goods and then some. I can't wait to see this in full digital glory (hurry up already, Disney, and let the rest of us see it like it was meant to be seen!)
I honestly didn't think Disney could pull off a Tron sequel, but if this clip (even in it's crapified form currently) is any indication of what they are going to do for the sequel, this looks damn good. And I will likely be the first one in line to see it...and I haven't seen a movie on opening night in loooong time. I cannot wait to see this in a theater.
There's just one thing missing...
End of Line.
Observing the RIA Landscape
Following up on my JavaFX and Flex post, I've been following some of the commentary coming from developers about JavaFX, Flex, and even Silverlight. Since I haven't been able to investigate any of these technologies in any real depth myself, it's been informative seeing what other's have been experiencing with these RIA platforms.
Based on what I've been reading and the brief experiences I've had so far with these platforms, I'm going to give my general opinion of the JavaFX/Flex/Silverlight landscape at this point. Now before anyone decides to get evangelical on me, keep in mind that everything is still very much up in the air with regard to these technologies, and it's anyone's game to win/lose. As I stated at the end of my JavaFX/Flex comparison post, these platforms still have a lot of potential and I look forward to continuing to explore them in the future.
I also what to point out that I really have no preference between any of these technologies at this point -- a big reason being that I'm not currently involved in any project that even requires such technologies. This is just my point of view being someone whose just starting to get their feet wet and trying to figure out which direction to go.
In general, between the three technologies I think currently Flex is clearly in the driver's seat. They already have a big head start over JavaFX and Silverlight: Flex 4 is already around the corner, while JavaFX and Silverlight are really just coming out of the gate. Flex is stable and there's a huge installed base to work with through leveraging Flash as the deployment platform.
Just the same the other platforms aren't looking too shabby. Silverlight seems to have a good deal of similarities in development style as Flex, providing a clean separation between interface and code. Also, they have the advantage of the Windows platform, which opens up an even larger installed base for Silverlight beyond what even Adobe has and could give Microsoft's RIA platform the edge in the long run.
Meanwhile, Sun's JavaFX seems very similar to regular Java programming (which isn't a bad thing if you looking to leverage the existing Java developer community). However, from what I can tell there's not as clean of a separation between interface and code like you have with Flex and Silverlight. There's also the issue of deployement, which puts them at a disadvantage I think -- they have a large JVM deployment base, but it's likely that people will still need to deploy a JVM that has JavaFX support in the future, which could be a problem.
So far I think the XML-style syntax of both Silverlight and Flex makes interface development vastly easier, and this gives both platforms a clear advantage over JavaFX, which seems to use it's own stripped-down Java-like syntax, which I'm not so sure I like.
Regarding JavaFX specifically, I agree what this post has to say regarding the name:
Of course, the mere mention of Microsoft will turn plenty of people away from Silverlight, so they're not totally alone on this I think.
On the plus side, JavaFX seems to be making a good choice as far as development tools go. They're leveraging the existing NetBeans and Eclipse platforms by releasing development tools that work on both that are free. This could help speed adoption of JavaFX once they get the ball rolling, since development shops won't have to shell out any cash to get working with the technology.
On the Silverlight side, you can get the development tools for free currently, but I'm willing to bet that developers will likely have to part with some cash to get a full suite of tools that give you the full range of development options that Silverlight will have to offer. This shouldn't be a problem for most Microsoft-centric shops, but could work against adoption by those that prefer lower-cost options.
Flex development tools are between these two extreme: You have to buy Flex Builder, but it's built on the Eclipse platform which means it's easy to get up-to-speed if you already know Eclipse. I think if Adobe freed up Flex Builder it would push them further in the lead. They've already slashed the price on it once, but Adobe makes a significant amount of money on their dev tools so this might be wishful thinking. To their credit, they still provide a way to do Flex development without Flex Builder (and I've done just that...using Emacs, their command-line compiler and their Ant plug-in, too), so there are still some options.
I think another big advantage Adobe has with Flex going forward is the fact that they basically own the design tools market with Photoshop and Illustrator, and they seem to be using this fact to help push integration with them. Their upcoming Flex 4 enhancements seem to be focused on giving designers the facilities they need for doing interface design while maintaining a clean separation between developers and designers, and given their almost total lock on the design tools market they're in a unique position to be able to do this well.
Sun seems to recognize this, and (at least according to javafx.com) they look like they're going to try to leverage the existing design tools with JavaFX. I'm not sure how much success they'll have given that the company they are now directly competing with owns the very tools they're trying to integrate with, but at least they're giving it a shot.
Microsoft is taking a completely different route here, and working on their own design tools for Silverlight development. And while it's still a bit early to see how well this works, it seems that this might work against them in the long run. Serge Jespers has said something similar in this regard:
I think Microsoft is suffering from a bit of "Not Invented Here" syndrome with the design tools. Whether that's the right choice we'll have to wait and see. They have the resources to pull it off, but I'm not so sure it's the right way to go.
From a developer's perspective, as I already mentioned I think Flex is the more robust solution at this point in time. My impressions with working with Flex so far seem to indicate that Adobe has gone to great length to make sure that their Flex development APIs are simple and consistent. Working with Flex is extremely easy from what I can see so far.
JavaFX also doesn't seem to terribly difficult to work with, especially if you're already familiar with GUI development via Swing or AWT which seems to be at the core of JavaFX development (I could be wrong here...it seems JavaFX code is organized almost identially to Swing code from a interface construction standpoint). My concern with JavaFX would be if it relies too much on Swing (or AWT) under the hood. Swing's not bad, but there's enough idiosyncrasies of working with Swing that could make it a huge turnoff for developers.
Silverlight also seems pretty easy to work with, and Microsoft seems to following a similar design paradigm as Flex in using XAML as the main interface design language. I've not yet delved into Silverlight, but based on my reading from their Getting Started info on the Silverlight site, and a few other places it doesn't seem too far removed from how Flex does things.
Nevertheless, both Silverlight and JavaFX have some catching up to do, I think. Given the resources at Microsoft's disposal, they are best positioned to gain ground the fastest on Flex. They're already working on Silverlight 2 currently.
Meanwhile JavaFX is still working on their first release, which doesn't bode well for Sun. There's also been some question as to what Sun is really trying to accomplish with JavaFX, and whether they really understand the challenge they're facing in getting people to use it. As I said, Flex already has a large installed base to work with by being based on Flash, and it's decidedly more lightweight than most any Java technology, which is a big deal. And Silverlight will be trivially easy for Microsoft to get deployed since so many people use Windows. I can't help but feel that JavaFX is going to be the odd man out between all of these platforms, but I'm more than willing to be proven wrong here.
Anyway that's my view of the landscape at this point. I invite anyone else out there to add your own assesment of these technologies in the comments. I'd like to see what other developer's think of these technologies that I may have missed.
Based on what I've been reading and the brief experiences I've had so far with these platforms, I'm going to give my general opinion of the JavaFX/Flex/Silverlight landscape at this point. Now before anyone decides to get evangelical on me, keep in mind that everything is still very much up in the air with regard to these technologies, and it's anyone's game to win/lose. As I stated at the end of my JavaFX/Flex comparison post, these platforms still have a lot of potential and I look forward to continuing to explore them in the future.
I also what to point out that I really have no preference between any of these technologies at this point -- a big reason being that I'm not currently involved in any project that even requires such technologies. This is just my point of view being someone whose just starting to get their feet wet and trying to figure out which direction to go.
In general, between the three technologies I think currently Flex is clearly in the driver's seat. They already have a big head start over JavaFX and Silverlight: Flex 4 is already around the corner, while JavaFX and Silverlight are really just coming out of the gate. Flex is stable and there's a huge installed base to work with through leveraging Flash as the deployment platform.
Just the same the other platforms aren't looking too shabby. Silverlight seems to have a good deal of similarities in development style as Flex, providing a clean separation between interface and code. Also, they have the advantage of the Windows platform, which opens up an even larger installed base for Silverlight beyond what even Adobe has and could give Microsoft's RIA platform the edge in the long run.
Meanwhile, Sun's JavaFX seems very similar to regular Java programming (which isn't a bad thing if you looking to leverage the existing Java developer community). However, from what I can tell there's not as clean of a separation between interface and code like you have with Flex and Silverlight. There's also the issue of deployement, which puts them at a disadvantage I think -- they have a large JVM deployment base, but it's likely that people will still need to deploy a JVM that has JavaFX support in the future, which could be a problem.
So far I think the XML-style syntax of both Silverlight and Flex makes interface development vastly easier, and this gives both platforms a clear advantage over JavaFX, which seems to use it's own stripped-down Java-like syntax, which I'm not so sure I like.
Regarding JavaFX specifically, I agree what this post has to say regarding the name:
Why does it have to have “Java” in it? The end customer doesn’t care how the application is written. He cares that it’s easy to install. He cares that it starts fast. He cares that it runs fast. He cares that it doesn’t crash on him. He cares that it doesn’t lose his data. He cares that it does what it is supposed to be doing.It's a small quibble, but it might work against the platform in the long run. Java's settled pretty comfortably into a server-side niche at this point, and trying to force the Java name into other areas of development...again...could actually work against JavaFX. Many developers are tired of seeing Sun try to push Java into every facet of software development.
Of course, the mere mention of Microsoft will turn plenty of people away from Silverlight, so they're not totally alone on this I think.
On the plus side, JavaFX seems to be making a good choice as far as development tools go. They're leveraging the existing NetBeans and Eclipse platforms by releasing development tools that work on both that are free. This could help speed adoption of JavaFX once they get the ball rolling, since development shops won't have to shell out any cash to get working with the technology.
On the Silverlight side, you can get the development tools for free currently, but I'm willing to bet that developers will likely have to part with some cash to get a full suite of tools that give you the full range of development options that Silverlight will have to offer. This shouldn't be a problem for most Microsoft-centric shops, but could work against adoption by those that prefer lower-cost options.
Flex development tools are between these two extreme: You have to buy Flex Builder, but it's built on the Eclipse platform which means it's easy to get up-to-speed if you already know Eclipse. I think if Adobe freed up Flex Builder it would push them further in the lead. They've already slashed the price on it once, but Adobe makes a significant amount of money on their dev tools so this might be wishful thinking. To their credit, they still provide a way to do Flex development without Flex Builder (and I've done just that...using Emacs, their command-line compiler and their Ant plug-in, too), so there are still some options.
I think another big advantage Adobe has with Flex going forward is the fact that they basically own the design tools market with Photoshop and Illustrator, and they seem to be using this fact to help push integration with them. Their upcoming Flex 4 enhancements seem to be focused on giving designers the facilities they need for doing interface design while maintaining a clean separation between developers and designers, and given their almost total lock on the design tools market they're in a unique position to be able to do this well.
Sun seems to recognize this, and (at least according to javafx.com) they look like they're going to try to leverage the existing design tools with JavaFX. I'm not sure how much success they'll have given that the company they are now directly competing with owns the very tools they're trying to integrate with, but at least they're giving it a shot.
Microsoft is taking a completely different route here, and working on their own design tools for Silverlight development. And while it's still a bit early to see how well this works, it seems that this might work against them in the long run. Serge Jespers has said something similar in this regard:
It’s a fact that designers work with tools such as Photoshop, Illustrator, and Fireworks and they’re not going to use the Expression tools any time soon. So adding standard design tools to the workflow is a must. To some extent, it is possible to import artwork from Photoshop or Illustrator in to Expression Design but that’s about it.This could be a big negative for Silverlight, unless they make their design tools nearly identical to what designers are already familiar with. As some comments on that post point out, designers are going to want to work with what they already know, and many shops aren't going to be willing to make a major transition to a completely new design tool.
I think Microsoft is suffering from a bit of "Not Invented Here" syndrome with the design tools. Whether that's the right choice we'll have to wait and see. They have the resources to pull it off, but I'm not so sure it's the right way to go.
From a developer's perspective, as I already mentioned I think Flex is the more robust solution at this point in time. My impressions with working with Flex so far seem to indicate that Adobe has gone to great length to make sure that their Flex development APIs are simple and consistent. Working with Flex is extremely easy from what I can see so far.
JavaFX also doesn't seem to terribly difficult to work with, especially if you're already familiar with GUI development via Swing or AWT which seems to be at the core of JavaFX development (I could be wrong here...it seems JavaFX code is organized almost identially to Swing code from a interface construction standpoint). My concern with JavaFX would be if it relies too much on Swing (or AWT) under the hood. Swing's not bad, but there's enough idiosyncrasies of working with Swing that could make it a huge turnoff for developers.
Silverlight also seems pretty easy to work with, and Microsoft seems to following a similar design paradigm as Flex in using XAML as the main interface design language. I've not yet delved into Silverlight, but based on my reading from their Getting Started info on the Silverlight site, and a few other places it doesn't seem too far removed from how Flex does things.
Nevertheless, both Silverlight and JavaFX have some catching up to do, I think. Given the resources at Microsoft's disposal, they are best positioned to gain ground the fastest on Flex. They're already working on Silverlight 2 currently.
Meanwhile JavaFX is still working on their first release, which doesn't bode well for Sun. There's also been some question as to what Sun is really trying to accomplish with JavaFX, and whether they really understand the challenge they're facing in getting people to use it. As I said, Flex already has a large installed base to work with by being based on Flash, and it's decidedly more lightweight than most any Java technology, which is a big deal. And Silverlight will be trivially easy for Microsoft to get deployed since so many people use Windows. I can't help but feel that JavaFX is going to be the odd man out between all of these platforms, but I'm more than willing to be proven wrong here.
Anyway that's my view of the landscape at this point. I invite anyone else out there to add your own assesment of these technologies in the comments. I'd like to see what other developer's think of these technologies that I may have missed.
Logo Fun
Since I changed the layout of the blog I wanted to come up with a new logo that matched properly.
The logo I had up originally:
Just didn't suit me at all. It's nice a simple (which is always a plus), but I just wasn't happy with it.
So I wanted to come up with something different. And for some odd reason, the idea of this logo popped up in my mind today:
It's obviously a bit more involved than the other, simpler logo, but I like it a lot more than the old one.
I created this from scratch using Adobe Photoshop CS2. It blends with the background nicely to give the appearance of being embedded in the blog page itself, which I kind of like. This is probably the most complicated image I've tried to make from scratch so far -- I typically don't do much with Photoshop other than the occasional icon and whatnot. I do experiment once in a while, but usually stick to simple images.
It turned out a lot nicer than I thought it would when I originally pictured it. Usually what I imagine doesn't translate exactly the way I hope when I start making an image like this, so I end up scrapping the whole idea. Looks like I'm getting better with each try.
I may still tweak the image a bit later, but for now I'm much more satisfied with this logo.
The logo I had up originally:
Just didn't suit me at all. It's nice a simple (which is always a plus), but I just wasn't happy with it.
So I wanted to come up with something different. And for some odd reason, the idea of this logo popped up in my mind today:
It's obviously a bit more involved than the other, simpler logo, but I like it a lot more than the old one.
I created this from scratch using Adobe Photoshop CS2. It blends with the background nicely to give the appearance of being embedded in the blog page itself, which I kind of like. This is probably the most complicated image I've tried to make from scratch so far -- I typically don't do much with Photoshop other than the occasional icon and whatnot. I do experiment once in a while, but usually stick to simple images.
It turned out a lot nicer than I thought it would when I originally pictured it. Usually what I imagine doesn't translate exactly the way I hope when I start making an image like this, so I end up scrapping the whole idea. Looks like I'm getting better with each try.
I may still tweak the image a bit later, but for now I'm much more satisfied with this logo.
Syntax Highlighting and Code Snippets in a blog
Update (4/30/2010): The SyntaxHighlighter package has changed significantly since I posted this. Check out the SyntaxHighligher Wiki for the latest information. I'll be posting new Blogger-specific directions soon.
Update: As of July 2009, Google has started migrating it's users of Google Pages to Google Sites. As a result, my section referencing putting the relevant files on Google Pages will no longer work, and per an email I received from Google about the migration Google Sites will not support the capability that I've described below either. This will effectively break code snippets on any blog that uses this approach (including this one). I'll update this post with a new approach once I have one in place. In the mean time, keep this in mind when you read this post.
Of course, none of this will be an issue for those that host their own blog site -- you can just host the files locally.
I'm sure a lot of developer-types out there might want to know how I got my code snippets to look so nice in my JavaFX and Flex comparison.
So here ya go...
I'm using SyntaxHighlighter -- it's a freely available package that allows code snippets to be posted so that they actually look like code, rather than just a jumble of monospaced text, including doing syntax highlighting for most popular languages.
If you like posting code snippets on your blog this is a must-have add-on. It saves you a lot of time trying to get code samples to look pretty.
Here's a sample:
Major kudos go to Alex Gorbatchev for making this package. It's pretty easy to install and set up, and only requires you to wrap your code snippets in
The
The package is meant to be placed on the server where you host your blog, and requires some changes to your blog's template -- you need to add a few lines to include some JavaScript so that the
For most self-hosted blogs, you should be able to follow the instructions from the SyntaxHighlighter project's website to get up and running quickly.
Blogger-specific stuff
I discovered this via this blog post. I'm repeating what's been covered there, but I've also included some changes that have been made to SyntaxHighlighter to deal with some blogger-specific issues. I've also changed where the files are hosted, since it seems easier to do the way I have (but that's just me...do whatever works best for you).
If your using blogger (like I obviously am) you have to jump though a few extra hoops the get this package working. For one thing, you can't actually put the files on the server hosting your blog.
The best way around this is to use something like Google Page Creator to host the all the relevant files for you. Just upload all of SyntaxHighlighter's .js files, along with the .swf file and .css file to your own Google Page Creator space.
Once you do that, you have to add some extra code to your blogger template. Open up the the template in the "Edit HTML" section to add the following somewhere in the
After you do that, at the end of your template, right before the
In both of these samples, you'll need to replace the
Note that you don't have to include all of the .js files if you don't want to -- just include the ones that you think you will be needing for whatever type of code snippets you plan to post.
Once that's done, you can insert your code snippets in your blog posts using the
Have fun :-)
Update: As of July 2009, Google has started migrating it's users of Google Pages to Google Sites. As a result, my section referencing putting the relevant files on Google Pages will no longer work, and per an email I received from Google about the migration Google Sites will not support the capability that I've described below either. This will effectively break code snippets on any blog that uses this approach (including this one). I'll update this post with a new approach once I have one in place. In the mean time, keep this in mind when you read this post.
Of course, none of this will be an issue for those that host their own blog site -- you can just host the files locally.
I'm sure a lot of developer-types out there might want to know how I got my code snippets to look so nice in my JavaFX and Flex comparison.
So here ya go...
I'm using SyntaxHighlighter -- it's a freely available package that allows code snippets to be posted so that they actually look like code, rather than just a jumble of monospaced text, including doing syntax highlighting for most popular languages.
If you like posting code snippets on your blog this is a must-have add-on. It saves you a lot of time trying to get code samples to look pretty.
Here's a sample:
/**
* Foo class
*/
public class Foo {
private String bar;
public Foo(String bar) {
this.bar = bar;
}
public String getBar() {
return this.bar;
}
}
Major kudos go to Alex Gorbatchev for making this package. It's pretty easy to install and set up, and only requires you to wrap your code snippets in
<pre> tags, with a few additional attributes in the tag like this:
<pre name="code" class="java">
...some code in here...
</pre>
The
name attribute is always "code", and the class attribute is used to identify whatever type of code your snippet is, be it Java, C++, JavaScript, etc.The package is meant to be placed on the server where you host your blog, and requires some changes to your blog's template -- you need to add a few lines to include some JavaScript so that the
<pre> tags get parsed and the code formatted properly whenever a page is displayed (note that if a reader of your blog is using something like NoScript, the code won't get formatted)For most self-hosted blogs, you should be able to follow the instructions from the SyntaxHighlighter project's website to get up and running quickly.
Blogger-specific stuff
I discovered this via this blog post. I'm repeating what's been covered there, but I've also included some changes that have been made to SyntaxHighlighter to deal with some blogger-specific issues. I've also changed where the files are hosted, since it seems easier to do the way I have (but that's just me...do whatever works best for you).
If your using blogger (like I obviously am) you have to jump though a few extra hoops the get this package working. For one thing, you can't actually put the files on the server hosting your blog.
The best way around this is to use something like Google Page Creator to host the all the relevant files for you. Just upload all of SyntaxHighlighter's .js files, along with the .swf file and .css file to your own Google Page Creator space.
Once you do that, you have to add some extra code to your blogger template. Open up the the template in the "Edit HTML" section to add the following somewhere in the
<head> section:
<link href='http://youraccount.googlepages.come/SyntaxHighlighter.css' rel='stylesheet' type='text/css'/>
<script language='javascript' src='http://youraccount.googlepages.com/shCore.js'/>
...add a <script> tag like the last one for each .js file from the package...
After you do that, at the end of your template, right before the
</body> closing tag, you put the following:
<script language='javascript'>
dp.SyntaxHighlighter.ClipboardSwf =
'http://youraccount.googlepages.com/clipboard.swf';
dp.SyntaxHighlighter.BloggerMode();
dp.SyntaxHighlighter.HighlightAll('code');
</script>
In both of these samples, you'll need to replace the
youraccount with whatever your Google Page Creator account is.Note that you don't have to include all of the .js files if you don't want to -- just include the ones that you think you will be needing for whatever type of code snippets you plan to post.
Once that's done, you can insert your code snippets in your blog posts using the
<pre> tag as described previously.Have fun :-)
Please Stand By...
After posting my little JavaFX vs Flex fun, I kinda realized I wasn't totally happy with the blog layout. Seems code snippets get to be a wee bit uglified when all the text is smashed up into one narrow column of text.
So I've switched to a wider layout template, and I'll be tweaking things here and there until things look acceptable to me -- the default settings of this layout still aren't quite to my liking, but it's going to take me some time to get things just right.
So I've switched to a wider layout template, and I'll be tweaking things here and there until things look acceptable to me -- the default settings of this layout still aren't quite to my liking, but it's going to take me some time to get things just right.
Quick Comparison of JavaFX and Flex
A while back, I read this post over on Javalobby (via DZone, of course) showing a brief example of data binding using JavaFX. I haven't really followed the JavaFX scene much, but since I had played around with Flex a bit and liked how data binding was done using Adobe's platform I found this brief little synopsis by Jim Weaver enlightening.
So, since I have been messing around a bit with Flex (among other things) I thought it might be neat to slap together a little Flex version of the same example from that blog post.
Now, this is by no means a thorough comparison of either language. It's just a quick little comparison of the syntax they both use, and I think shows a nice contrast in the way both platforms do things.
I should also note that I'm still quite a bit of a novice when it comes to using Flex, so there's likely a better way to do things in Flex than what I'm doing here (in fact I know there are several ways to get the same result than what I have shown). I tried to make my example as close as possible to the JavaFX implementation.
So here we go...
The first thing we need is our model class -- our version of the HelloJFXModel.
Flex doesn't allow for defining classes directly in our MXML file, so unlike the JavaFX example we have to define our model in a separate file. In this case, we define ours in HelloFlexModel.as (big surprise, huh?):
Simple enough. The
Now that we have the model, we need to use it in our main application MXML file. There are actually several ways to do this -- for instance, we can use the
If you didn't pick up on it, the
The model class itself is then used via the
What's nice about importing our class this way is that it allows the class to be cleanly integrated into the MXML syntax. Instead of having some ActionScript code like
Also note that the attributes of the class we're using (in this case,
It's really a matter of personal preference. Like traditional XML, both ways are correct...just be consistent in your usage.
Another nice thing is that the font style and appearance we use for our text field can be defined via CSS syntax, which I think is a nice touch. It also helps keep the look and feel separated from the application (you can actually put all the style-related code in a separate file as well, just like traditional CSS, but I've included it in the MXML file to keep things simple).
So after all of that, we get something that looks like this:
I think both JavaFX and Flex look pretty decent. Flex appears to be the more complete platform at this point, and I personally think that Flex has the upper hand when it comes to it's MXML syntax -- It seems to provide for much cleaner organization of interface components. Just the same, I won't count JavaFX out just yet, either.
There seems to be plenty of room for improvement in both camps, and I'll be keeping an eye on both of them as much as I can.
So, since I have been messing around a bit with Flex (among other things) I thought it might be neat to slap together a little Flex version of the same example from that blog post.
Now, this is by no means a thorough comparison of either language. It's just a quick little comparison of the syntax they both use, and I think shows a nice contrast in the way both platforms do things.
I should also note that I'm still quite a bit of a novice when it comes to using Flex, so there's likely a better way to do things in Flex than what I'm doing here (in fact I know there are several ways to get the same result than what I have shown). I tried to make my example as close as possible to the JavaFX implementation.
So here we go...
The first thing we need is our model class -- our version of the HelloJFXModel.
Flex doesn't allow for defining classes directly in our MXML file, so unlike the JavaFX example we have to define our model in a separate file. In this case, we define ours in HelloFlexModel.as (big surprise, huh?):
package {
[Bindable]
public class HelloFlexModel {
public var greeting:String;
}
}
Simple enough. The
[Bindable] basically tells Flex that the class (and it's attributes) can be bound to a component, which in our case -- just like the JavaFX version -- is going to be a text field.Now that we have the model, we need to use it in our main application MXML file. There are actually several ways to do this -- for instance, we can use the
<mx:Script> to create a local variable using ActionScript embedded in the MXML file if we want. However, for this example I'm going to use a nice feature of the MXML language that allows for importing custom classes and using them just like native MXML tags in Flex. This allows for a much cleaner looking MXML file:
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:local="*"
width="400"
height="150">
<local:HelloFlexModel id="helloFlexModel" greeting="Hello Flex Developer!"/>
<mx:Style>
Text {
fontFamily: Sans Serif;
fontSize: 24;
fontWeight: bold;
color: red;
verticalAlign: top;
}
</mx:Style>
<mx:Panel title="Flex example that binds a model" width="95%" height="95%">
<mx:Canvas>
<mx:Text x="10" y="10" text="{helloFlexModel.greeting}"/>
</mx:Canvas>
</mx:Panel>
</mx:Application>
If you didn't pick up on it, the
xmlns:local="*" is how the HelloFlexModel gets imported. Since it's not really defined in a separate package, we only have the "*", but if we had placed the class in another package, we'd have used something like "org.foo.*" instead. Packages in Flex follow the same conventions as Java (package org.foo would be in a /org/foo directory), which by now most developers are familiar with.The model class itself is then used via the
<local:HelloFlexWorld> tag. The local prefix can actually be whatever you wish it to be, as long as it matches whatever you used in the xmlns import I talked about in the last paragraph.What's nice about importing our class this way is that it allows the class to be cleanly integrated into the MXML syntax. Instead of having some ActionScript code like
var model:HelloFlexModel = new HelloFlexModel(); muddying up our MXML, we have something less intrusive and probably a bit easier to read.Also note that the attributes of the class we're using (in this case,
greeting) are accessible via XML-style attributes in the MXML syntax. You could also do this via nesting of tags, like this:
<local:HelloFlexModel id="helloFlexModel">
<greeting>Hello Flex Developer!</greeting>
</local:HelloFlexModel>
It's really a matter of personal preference. Like traditional XML, both ways are correct...just be consistent in your usage.
Another nice thing is that the font style and appearance we use for our text field can be defined via CSS syntax, which I think is a nice touch. It also helps keep the look and feel separated from the application (you can actually put all the style-related code in a separate file as well, just like traditional CSS, but I've included it in the MXML file to keep things simple).
So after all of that, we get something that looks like this:
I think both JavaFX and Flex look pretty decent. Flex appears to be the more complete platform at this point, and I personally think that Flex has the upper hand when it comes to it's MXML syntax -- It seems to provide for much cleaner organization of interface components. Just the same, I won't count JavaFX out just yet, either.
There seems to be plenty of room for improvement in both camps, and I'll be keeping an eye on both of them as much as I can.
Bad Apples
You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.
I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.
I've experienced a few bad apple incidents in my career: In one situation I readily admit that I could have been labeled as a bad apple myself (and rightly so). Having been on both sides of such a situation I've seen where it's not just the individual that's deemed the bad apple who can be at fault for letting things get so bad: In some cases the team itself can cause the bad apple to emerge.
I won't try to pass blame onto anyone for me being a bad apple: I realize now the mistakes that I made and use them as a learning experience. And I learned long ago that my way isn't always the right way and that sometimes just going along with what's been decided is better than trying to change things mid-stream.
That being said, their are situations where the team itself can be at fault for the emergence of a bad apple. For instance, a developer might get the impression that their input on the project isn't wanted, or even desired. This isn't a situation where a developer is just being pig-headed about some idea and being shot down continuously, but where a developer's ideas just aren't even being discussed or considered. If a developer gets the impression that the team simply doesn't want their input, that developer may isolate themselves and simply stop engaging with the team like they should. The situation then starts to head down the road to "rotten developer."
The key to avoiding this is to maintain solid communication within the project. This is the one thing that helps both prevent accidental bad apples from emerging, as well as finding the real bad apples like Jeff describes in his post.
Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed.
Pigeonholing Programmers
Much like The Pragmatic Programmer advocates, I try to "Invest Regularly in My Knowledge Portfolio", which usually involves reading books (unlike most programmers), various programming-related blogs, and listening to a few podcasts as well.
In addition, I also make it a point to try to learn other programming languages. I think this one activity goes a along way towards making me a better programmer, as it opens my mind up to new concepts and ideas that I may not have otherwise considered while using Java, which tends to be the predominant language used in my everyday work.
So over the past few years I've made it a point to learn Python and Lisp, beefed up my skills with JavaScript (which had been waning a bit since I hadn't used it for many years), and dove into using regular expressions (regex is really an ancillary language -- a language that is typically used with some other programming language in order to process text data -- but it's still a language in and of itself and well worth learning). I've also started exploring Flex/Flash development as well.
My big concern about learning these languages is that, while I may be able to apply some of the concepts toward my own development work, which almost always involves Java, I have very limited ways in which to apply the languages themselves, which in some cases I've found far and away superior to Java for certain situations. And I'm starting to see this as a point of frustration for trying to expand my skillset as a software developer.
I think that most people agree that in order to truly understand the language paradigms, concepts, strengths and weaknesses behind many of the programming languages available nowadays, programmers really need to be able to work with a languages on a regular basis. And while I do try to work with whatever languages I choose to learn on my own time as much as I possibly can, being able to use these languages in a real-world development situation would go a long way towards helping me fully understand them. Coding examples from a book, or working on some simple toy application has indeed helped me immensely, and exposed me to new ideas, but without really being able to take the language for a spin on a substantial project I don't feel like I'm getting the full picture of what these languages can really do.
I see the potential...but I can't fully explore and exploit it.
My other fear is that, after all that effort to learn a new language, that knowledge will atrophy...resulting in wasted effort. Sure it won't be a total waste, as I'll have applied some of the knowledge to my Java work, but how will I ever know that I've been doing things the right way if I haven't really had the opportunity to fully explore alternatives?
One solution is to find some way to apply these languages in the workplace so I can really see what kind of capabilities they have. But in order to do this I have to convince the stakeholders or project managers that it's worth it to explore these alternatives, rather than just stick with the tried-and-true Java stuff...and I think we can all predict how well that will work.
It's difficult to convince people to take a risk on something they don't know for sure is going to be the best option, when they know that something like Java has a better chance (although by no means a guarantee) of success. It's always easier to go for the sure thing, and I understand this completely. But a consequence of this is that, as a developer, I feel as though I'm being limited in my growth opportunities by default -- I can't convince people there might be a better way without exploring the alternatives fully, but I can't explore the alternatives fully without having some substantial application within which to apply the technology. Chicken...meet egg....
Sure, I can try to sneak the language in somewhere, but there's a big risk in doing that...especially if you're working with a rather hard-assed client or company. They don't take kindly to being tricked and I might find myself kicked to the curb for my troubles.
An alternative is to find a place to work that allows for this kind of technology exploration -- someplace like, say Google, that sets aside time for developers to really explore programming. But I'm realistic enough to know that I have no hope of ever working at Google, and finding any other company that does the same thing seems almost impossible.
And speaking of moving on to other opportunities: This too presents some interesting points of frustration along the same lines...
Lets say that, after so many years of working with language X, I want to move into something different -- programming language Y. It may be that I'm just tired of working in X, or -- as I explained above -- I want to simply see what it's like to work with Y in an actual project. So, I throw my resume out there to some prospective companies working with Y.
(Of course, this is assuming that anyone is even currently using language Y for a project, as it could be something so new that it hasn't shown up on anyone's radar yet. In which case I'd be wasting my time even looking for a new job at all.)
At any rate, some company doing Y projects gives my resume a look, and either sees my extensive background in language X and says, "no way" (maybe because they think that my experience with X works against me in some way), or at the very least sees that I haven't worked on any substantial Y projects (aside from typical toy learning projects) and doesn't give me a second thought. They want people with so many years of Y experience, or something along those lines.
Meanwhile, because of my long extensive background using X, I get pelted by every recruiter from here to Abu Dhabi asking me if I want to work on some X project, which I don't find particularly fun...and only serves to further my frustrations. But because I can't get the time of day from the companies using Y, my choices are either: A) Stay with my current employer and continue to use language X (if they haven't tossed me out on my ear for trying to sneak Y in the back door, that is), or B) Take a job with another company that's also using language X.
I'm effectively pigeonholed into being an X programmer, whether I like it or not. And despite my best efforts to get out of the rut, various factors -- current work environment, the job market, experience -- have effectively killed any hope of moving up and out of X programming.
I've actually encountered this type of situation in my own career, albeit in a slightly different form: For many years prior to my first gig as a programmer, I was involved pretty heavily on the hardware-side of the computer world: Troubleshooting, repair, installations, upgrades, help desk, and stuff like that. Basically most of the traditional IT-type work people think of. I was one of those guys that people would call when they had a problem, or needed some piece of hardware set up or installed and whatnot.
Now, I enjoyed the work for a time, but it became fairly mundane work eventually: Once you've solved the same hardware or configuration problem 18,000 times it gets a little boring. And that's where I ended up -- very...very...very bored. So I decided to move over into software development, which I enjoyed non-professionally for quite some time working on my own little toy projects. So I headed back to school...
Now, fast-forward several years: I've still been doing the hardware stuff during that time at school, but now I decide to start throwing my resume out there to get a programming gig.
What I found was that, despite my explicit desire to move over to the software development side of world, I was met with a shitload of resistance. It seemed that everywhere I interviewed people were either surprised, or otherwise just couldn't comprehend why I wanted to do software development. It's like the idea of branching out into other areas of the computer industry, or changing professions was somehow impossible to do in their eyes. As far as they were concerned, because I had all that experience doing the hardware stuff that's where I belonged.
Now, I obviously did eventually get that first programming gig, but it took a long time to find someone willing to accept the fact that I actually enjoyed programming more than doing all the hardware work, and that I was (and still am I think) much better suited for programming.
This isn't exactly the same kind of situation I see when trying to move from one language to another, but I do see a similar mentality emerging whenever I explore the possibility of moving outside my current job to do work with another technology or company. Perhaps it's just the area that I currently live in, or just bad luck on my part, but I am definitely picking up a similar vibe that I had when trying to move from the hardware world into software development. I'm hearing a lot of "well...you're an X programmer...why the heck would you want to work with Y?"
After experiencing this kind of situation now in two different -- yet oddly similar -- ways, I can't help but get the feeling that there are probably a good number of developers out there that have gotten themselves pigeonholed into being a blub programmer in some form or another...despite their best efforts to not end up that way.
Many companies, both in their desire to stick with what works (which is not wrong in any way, mind you), and with their insistence in looking more at what developers have done, rather than what they have the potential to do for a company seem to have inadvertently worked to limit developers' opportunities for growth in this regard.
(And I won't even touch the fact that there are companies out there that actively work against their own employee's attempts to learn and grow and move on to bigger and better things...which I have also witnessed, I'm sad to say).
I don't think it's all doom and gloom. I think the opportunities for engaging and using new technologies on a regular basis on-the-job are probably out there, and I'm sure there are plenty of employers that will look at more than just "X years with blub" on a resume. At least...I hope there are.
Because otherwise I have a bad feeling about the future of programming...
In addition, I also make it a point to try to learn other programming languages. I think this one activity goes a along way towards making me a better programmer, as it opens my mind up to new concepts and ideas that I may not have otherwise considered while using Java, which tends to be the predominant language used in my everyday work.
So over the past few years I've made it a point to learn Python and Lisp, beefed up my skills with JavaScript (which had been waning a bit since I hadn't used it for many years), and dove into using regular expressions (regex is really an ancillary language -- a language that is typically used with some other programming language in order to process text data -- but it's still a language in and of itself and well worth learning). I've also started exploring Flex/Flash development as well.
My big concern about learning these languages is that, while I may be able to apply some of the concepts toward my own development work, which almost always involves Java, I have very limited ways in which to apply the languages themselves, which in some cases I've found far and away superior to Java for certain situations. And I'm starting to see this as a point of frustration for trying to expand my skillset as a software developer.
I think that most people agree that in order to truly understand the language paradigms, concepts, strengths and weaknesses behind many of the programming languages available nowadays, programmers really need to be able to work with a languages on a regular basis. And while I do try to work with whatever languages I choose to learn on my own time as much as I possibly can, being able to use these languages in a real-world development situation would go a long way towards helping me fully understand them. Coding examples from a book, or working on some simple toy application has indeed helped me immensely, and exposed me to new ideas, but without really being able to take the language for a spin on a substantial project I don't feel like I'm getting the full picture of what these languages can really do.
I see the potential...but I can't fully explore and exploit it.
My other fear is that, after all that effort to learn a new language, that knowledge will atrophy...resulting in wasted effort. Sure it won't be a total waste, as I'll have applied some of the knowledge to my Java work, but how will I ever know that I've been doing things the right way if I haven't really had the opportunity to fully explore alternatives?
One solution is to find some way to apply these languages in the workplace so I can really see what kind of capabilities they have. But in order to do this I have to convince the stakeholders or project managers that it's worth it to explore these alternatives, rather than just stick with the tried-and-true Java stuff...and I think we can all predict how well that will work.
It's difficult to convince people to take a risk on something they don't know for sure is going to be the best option, when they know that something like Java has a better chance (although by no means a guarantee) of success. It's always easier to go for the sure thing, and I understand this completely. But a consequence of this is that, as a developer, I feel as though I'm being limited in my growth opportunities by default -- I can't convince people there might be a better way without exploring the alternatives fully, but I can't explore the alternatives fully without having some substantial application within which to apply the technology. Chicken...meet egg....
Sure, I can try to sneak the language in somewhere, but there's a big risk in doing that...especially if you're working with a rather hard-assed client or company. They don't take kindly to being tricked and I might find myself kicked to the curb for my troubles.
An alternative is to find a place to work that allows for this kind of technology exploration -- someplace like, say Google, that sets aside time for developers to really explore programming. But I'm realistic enough to know that I have no hope of ever working at Google, and finding any other company that does the same thing seems almost impossible.
And speaking of moving on to other opportunities: This too presents some interesting points of frustration along the same lines...
Lets say that, after so many years of working with language X, I want to move into something different -- programming language Y. It may be that I'm just tired of working in X, or -- as I explained above -- I want to simply see what it's like to work with Y in an actual project. So, I throw my resume out there to some prospective companies working with Y.
(Of course, this is assuming that anyone is even currently using language Y for a project, as it could be something so new that it hasn't shown up on anyone's radar yet. In which case I'd be wasting my time even looking for a new job at all.)
At any rate, some company doing Y projects gives my resume a look, and either sees my extensive background in language X and says, "no way" (maybe because they think that my experience with X works against me in some way), or at the very least sees that I haven't worked on any substantial Y projects (aside from typical toy learning projects) and doesn't give me a second thought. They want people with so many years of Y experience, or something along those lines.
Meanwhile, because of my long extensive background using X, I get pelted by every recruiter from here to Abu Dhabi asking me if I want to work on some X project, which I don't find particularly fun...and only serves to further my frustrations. But because I can't get the time of day from the companies using Y, my choices are either: A) Stay with my current employer and continue to use language X (if they haven't tossed me out on my ear for trying to sneak Y in the back door, that is), or B) Take a job with another company that's also using language X.
I'm effectively pigeonholed into being an X programmer, whether I like it or not. And despite my best efforts to get out of the rut, various factors -- current work environment, the job market, experience -- have effectively killed any hope of moving up and out of X programming.
I've actually encountered this type of situation in my own career, albeit in a slightly different form: For many years prior to my first gig as a programmer, I was involved pretty heavily on the hardware-side of the computer world: Troubleshooting, repair, installations, upgrades, help desk, and stuff like that. Basically most of the traditional IT-type work people think of. I was one of those guys that people would call when they had a problem, or needed some piece of hardware set up or installed and whatnot.
Now, I enjoyed the work for a time, but it became fairly mundane work eventually: Once you've solved the same hardware or configuration problem 18,000 times it gets a little boring. And that's where I ended up -- very...very...very bored. So I decided to move over into software development, which I enjoyed non-professionally for quite some time working on my own little toy projects. So I headed back to school...
Now, fast-forward several years: I've still been doing the hardware stuff during that time at school, but now I decide to start throwing my resume out there to get a programming gig.
What I found was that, despite my explicit desire to move over to the software development side of world, I was met with a shitload of resistance. It seemed that everywhere I interviewed people were either surprised, or otherwise just couldn't comprehend why I wanted to do software development. It's like the idea of branching out into other areas of the computer industry, or changing professions was somehow impossible to do in their eyes. As far as they were concerned, because I had all that experience doing the hardware stuff that's where I belonged.
Now, I obviously did eventually get that first programming gig, but it took a long time to find someone willing to accept the fact that I actually enjoyed programming more than doing all the hardware work, and that I was (and still am I think) much better suited for programming.
This isn't exactly the same kind of situation I see when trying to move from one language to another, but I do see a similar mentality emerging whenever I explore the possibility of moving outside my current job to do work with another technology or company. Perhaps it's just the area that I currently live in, or just bad luck on my part, but I am definitely picking up a similar vibe that I had when trying to move from the hardware world into software development. I'm hearing a lot of "well...you're an X programmer...why the heck would you want to work with Y?"
After experiencing this kind of situation now in two different -- yet oddly similar -- ways, I can't help but get the feeling that there are probably a good number of developers out there that have gotten themselves pigeonholed into being a blub programmer in some form or another...despite their best efforts to not end up that way.
Many companies, both in their desire to stick with what works (which is not wrong in any way, mind you), and with their insistence in looking more at what developers have done, rather than what they have the potential to do for a company seem to have inadvertently worked to limit developers' opportunities for growth in this regard.
(And I won't even touch the fact that there are companies out there that actively work against their own employee's attempts to learn and grow and move on to bigger and better things...which I have also witnessed, I'm sad to say).
I don't think it's all doom and gloom. I think the opportunities for engaging and using new technologies on a regular basis on-the-job are probably out there, and I'm sure there are plenty of employers that will look at more than just "X years with blub" on a resume. At least...I hope there are.
Because otherwise I have a bad feeling about the future of programming...
The Programming Apocalypse...
Raganwald pulled the following quote from the latest Coding Horror post:
Hmmm. When I close my eyes I see something a little different...
...I see Lisp.
Try to imagine a world where every programmer you know is a wannabe language designer, bent on molding the language to their whims. When I close my eyes and imagine it, I have a vision of the apocalypse, a perfect, pitch-black storm of utterly incomprehensible, pathologically difficult to debug code.
Hmmm. When I close my eyes I see something a little different...
...I see Lisp.
What Hath Java Wrought: The Long Version - Part II
[Part I is here]
Java is popular because of one rather simple reason:
It's easy to use.
Java was touted as being a "simpler C++" when it was released: No pointers, no memory management (for the most part)...basically nothing that could over complicate the language, or make developers lives a living hell. This helped both existing C and C++ developers get up to speed with the language (due to similar syntax) and also allowed lesser experienced developers work out solutions with minimal fuss, and not have to concern themselves with complicated concepts.
Now, whether Java's simpler syntax was a good idea or not isn't what I want to get into. There are quite obviously trade offs to having a simple syntax (the big one being that solutions tend to get complicated as they grow...as some have already discovered). And at this point in time we're all well aware of the various strengths and weaknesses of the language.
The bigger issue I see is that the popularity of the Java language that came about from its ease of use now plays a major factor in how the language can, and should, evolve.
The Good
Having Java, or any language, gain popularity means that with the increasing interest in solving problems with it comes more basic grunt work getting done for people ahead of time. More developers solving the same problems results in patterns emerging from those solutions. Those patterns become libraries that other developers can leverage to solve even bigger problems.
As more libraries get created, other interesting problems get tackled. Frameworks emerge that allow developers to quickly work up solutions in entire problem domains, and not just some specific component of it. The frameworks evolve to work together, allowing for solutions that are almost trivially easy to put together. Development time drops considerably, as much of the boilerplate that would normally have to be constantly rewritten has been taken care of ahead of time.
Also, with such a large pool of developers to draw from, it's also very easy for companies to find developers that can hit the ground running with Java.
All of this makes good sense for businesses, as time-to-market is important. Currently, we've started to reach the limitations of what Java can do for us, and many have moved to other languages like Ruby and Python to further reduce that time to get a product out. And while those languages aren't nearly as popular currently, they may very well take that top spot from Java.
But in the meantime, Java tends to be the smart business choice as much of that grunt work has already been taken care of in the Java world.
Suffice it to say that I think popularity is a "good thing" overall for any language.
The Bad
The problem I see at this point is that since Java is so popular it can not really move forward without making things worse. Unless Sun, or whomever starts maintaining the Java language once it goes Open Source, are willing to take drastic measures, they're going to continue to suffer from I would call Windows Syndrome...
Everyone knows Microsoft's Windows OS. Company shenanigans aside, it's become the single most dominant operating system on the planet. It's not the best out there, but it gets the job done for most people.
For years now, Microsoft has been struggling to move the operating system forward, adding new features and improvement wherever it can. In many cases they've succeeded, but they've stumbled quite a few times as well. And some have pointed out that a big reason for the stumbling is because of Microsoft's need to maintain backward compatibility with older programs and systems.
Microsoft's OSes have become so popular, and the market so large that they can't ignore situations where people are using older version of both their OS and applications. This ends up putting limits on how much they can change each subsequent version, since as long as people need those older programs to run (and sometimes it's a large number of people) they have to hold back the OS to support it in some way.
Basically, they're own popularity is working against their need to evolve.
Meanwhile, you have a company like Apple, whose systems are not nearly as popular as Windows-based systems (based on market share), which took a drastic step and broke backward compatibility with their older operating system when they introduced OS X, which was a major evolutionary leap from the previous versions. Arguably this has allowed the company to gain both market and mind share, and position their systems as being far more reliable and well designed than their Windows counterparts.
A big reason Apple could do this is because they don't have nearly the same size market as Windows -- they could afford to take the risk.
Now back to language-land...
Sun has made a conscious decision both on past language enhancements (Generics) and it seems on future ones (Closures) to maintain backward compatibility with both existing code and JVMs. This puts it in the ugly position of having to ensure that any change made to the language works within the framework of what's already being used by developers.
A big reason for wanting to maintain this backward compatibility is because of the large market for Java development: Breaking backward compatibility means they risk alienating a significant chunk of the community.
Meanwhile, you have other languages with a smaller market share/less popularity (Python and Ruby, for example) that are able to evolve and make changes quickly due to the fact that any changes they make aren't going to have as significant of an impact on its user base.
Hmm...this sounds familiar, doesn't it?
Maintaining backward compatibility for Java is a worthy goal to reach for, but for some of the changes that get considered, you can't necessarily take that option off the table. At the same time, Sun can't afford to break backward compatibility if the language is to continue to be popular, so we end up with some non-optimal solution added to the language that potentially makes things worse for the developers. It's a no-win situation.
This is where other, less popular languages have an advantage: Python in particular has broken backward compatibility several times in previous versions of the language. One big reason it could do this was because the market for Python developers is smaller than it is for Java.1 If Python were in Java's position, I doubt such decisions to break compatibility would be so easy.
Much like Windows, Java's extreme popularity prevents it from evolving in necessary ways.
More Bad
With all of these changes that are trying to be made to the language, there is also the potential risk of decreasing the adoption of the language. Java's already widely in use throughout the industry, but if we expect new developers coming into the programming field to adopt the language it has to continue to be both useful and approachable. Adding complexity (as I think Generics and Closures do) works against this very goal, as it makes it harder for newer developers to get up and running with the language, and understand existing code.
(Of course, the ever-growing Java API also has this effect on new developers as well. Trying to navigate the disgustingly huge number of APIs in the Java SE is a daunting task even for seasoned developers...)
There's already evidence that Java is failing at this approachability, as there are colleges teaching Java that don't even try to talk about Generics when presenting the language to their students.2 If this is the case, then how do we expect these developers to work with features like Closures?
Another facet of this is that, with the added complexity we will undoubtedly add to the language when tacking on new functionality (either through trying to maintain backward compatibility or otherwise), we're forgetting a whole swath of current Java developers who, whether we like it or not, are going to severely impact the overall productivity of the community. And making the language more complex is just going to exacerbate an already bad problem these developers represent.
The Ugly
One thing I've grown to understand while being involved with Java-related projects is why there's so much hate towards the Java language and perhaps the community itself: The bulk of it comes down to the overall makeup of the Java "community". I use quotes here because the community I'm referring to isn't just the vast number of intelligent, enthusiastic people that inhabit places like JavaLobby, or DZone, or TheServerSide.com, but the entire group of developers out there that have made a career using the Java language.
The unfortunate consequence of having a language that's so easy to use is that, while there's plenty of very capable and smart software developers using the language, there is a vastly larger group of people that have been using Java out there who are...shall we say...less than enthusiastic about the whole art and science of software development. You know who I'm referring to: Those unfortunate (and aggravating) souls that have no desire to really learn anything more about programming than what is necessary to earn them a paycheck - the ones from whom we regularly get our laughs on sites like The Daily WTF.
Let's face it: There are a lot bad programmers in the Java world.
It's the result of the combination of the language being both approachable, and the community so large (since the more people using the language, the more likely the chances of lesser-skilled developers using it). There are quite a few of these programmers using Java, and they are not going to go away as long as having "Java" on the resume is a guaranteed chance at snagging an interview, and possibly a job. In my career as a developer working on Java-based projects, I don't think I've ever had a job where there wasn't at least one of these guys involved in a project I was on.
Now, granted this isn't necessarily a Java problem so much as an industry problem. As someone's recently pointed out rather astutely, the software development world seems to have a interesting characteristic of allowing those of both lesser capability and ambition to coast along doing programming work. So it stands to reason that since Java is so popular, the bulk of these lackadaisical programmers end up working with Java as opposed to some other language.
Unfortunately for Java, this ends up painting the language in a bad light, as there are so many of these developers using the language. The fact is that you could substitute some other language as the most popular and probably have the same result. Yes, the Java language itself does deserve some of the ridicule it receives, but I think the bulk of the ridicule is more a case of disliking this specific segment of it's user base.
At any rate, this is the group that comes to mind whenever I read about adding something like Closures to the language. It is this crop of developers that has the potential to do the most harm when new features get added to the language. Especially when those features add additional complexity.
Because what happens is that any code these non-enthusiastic, non-creative, unthinking lackey programmers create is likely going to be some bastardization of what was originally intended as the use for said features. They will drop generic classes (and possibly even closures) into their code like it's nobody's business...and turn what could have been a simple project into a nightmare.
They will basically use said features just for the sake of using them...without any clear understanding of why or how they really should be used. And they won't care either, because to them it's just a job.
And imagine that situation repeated over thousands of projects.
Of course, I realize that "because it'll be abused by bad programmers" isn't the best of arguments against adding new language features to Java. For one thing, there are ways to mitigate this sort of problem: Code reviews, good hiring practices, etc. But considering the size of the Java developer base, the odds of weeding all of these kinds of programmers out is about the same as the chances of wiping every cockroach off the face of the earth...about nil.
While the best of us out there will be able to work very intelligently with any new additions to Java, these types of bad programmers appear to be so prevalent in the Java world that it can have a very real impact on productivity for everyone - including the smart ones - since somebody will ultimately have to deal with the code that these developers produce at some point.
Eventually, the misuse of these new features (good or bad) could end up working against the Java community as a whole - resulting in Java gaining a bad reputation for creating solutions that are unnecessarily complex.3 And the reason for this may only be because developers - the bad ones - didn't use the features the way they were intended and made things much worse than had they not had the functionality available at all.
Sometimes the only solution to making sure that people don't shoot themselves in the foot is to make sure they don't have the gun in the first place.
One Step Forward...
Overall, I'm not opposed to improving Java, even if those of lesser skill can't quite get their heads wrapped around the concepts that get included in the language. And I'd rather see some improvements over none at all.
But I'd much rather have these improvements to Java done right. And in some cases, I think that means breaking backward compatibility. It's not an easy decision to make, but I think those in charge of Java's stewardship should consider the option. We all want to see Java continue to be successful, but if we insist on trying to contort additions to the language to fit the existing system we're going to end up making things harder on developers, not easier.
And we have to be cognizant of the fact that, despite our best efforts to make programmers' lives easier, we're potentially giving them something that they won't fully understand how to use properly and may make things much worse overall for the Java community.
(Stay tuned for Part III)
1 - I am not trying to make a "Java is better than Python" argument here, so save the ranting and raving. It's just a simple fact that Java is more popular than Python. That doesn't make Java better than Python. And I would certainly not try to make that argument...as I actually believe quite the opposite.
2 - Of course, the subject of teaching Computer Science in colleges is just as complicated as this whole discussion over Java...and I don't want to diverge too far from the point here. Let's just say that the fact that Generics aren't taught is both because of the complexity it introduces and because students aren't necessarily taught everything they should be, and leave it at that for now.
3 - Yes, I know, people could argue that Java already has a reputation for resulting in complex solutions...but doesn't that make the situation just that much important? If the Java is already considered to make solutions that are too complex, then what's going to happen when we add further complexity to the language?
Java is popular because of one rather simple reason:
It's easy to use.
Java was touted as being a "simpler C++" when it was released: No pointers, no memory management (for the most part)...basically nothing that could over complicate the language, or make developers lives a living hell. This helped both existing C and C++ developers get up to speed with the language (due to similar syntax) and also allowed lesser experienced developers work out solutions with minimal fuss, and not have to concern themselves with complicated concepts.
Now, whether Java's simpler syntax was a good idea or not isn't what I want to get into. There are quite obviously trade offs to having a simple syntax (the big one being that solutions tend to get complicated as they grow...as some have already discovered). And at this point in time we're all well aware of the various strengths and weaknesses of the language.
The bigger issue I see is that the popularity of the Java language that came about from its ease of use now plays a major factor in how the language can, and should, evolve.
The Good
Having Java, or any language, gain popularity means that with the increasing interest in solving problems with it comes more basic grunt work getting done for people ahead of time. More developers solving the same problems results in patterns emerging from those solutions. Those patterns become libraries that other developers can leverage to solve even bigger problems.
As more libraries get created, other interesting problems get tackled. Frameworks emerge that allow developers to quickly work up solutions in entire problem domains, and not just some specific component of it. The frameworks evolve to work together, allowing for solutions that are almost trivially easy to put together. Development time drops considerably, as much of the boilerplate that would normally have to be constantly rewritten has been taken care of ahead of time.
Also, with such a large pool of developers to draw from, it's also very easy for companies to find developers that can hit the ground running with Java.
All of this makes good sense for businesses, as time-to-market is important. Currently, we've started to reach the limitations of what Java can do for us, and many have moved to other languages like Ruby and Python to further reduce that time to get a product out. And while those languages aren't nearly as popular currently, they may very well take that top spot from Java.
But in the meantime, Java tends to be the smart business choice as much of that grunt work has already been taken care of in the Java world.
Suffice it to say that I think popularity is a "good thing" overall for any language.
The Bad
The problem I see at this point is that since Java is so popular it can not really move forward without making things worse. Unless Sun, or whomever starts maintaining the Java language once it goes Open Source, are willing to take drastic measures, they're going to continue to suffer from I would call Windows Syndrome...
Everyone knows Microsoft's Windows OS. Company shenanigans aside, it's become the single most dominant operating system on the planet. It's not the best out there, but it gets the job done for most people.
For years now, Microsoft has been struggling to move the operating system forward, adding new features and improvement wherever it can. In many cases they've succeeded, but they've stumbled quite a few times as well. And some have pointed out that a big reason for the stumbling is because of Microsoft's need to maintain backward compatibility with older programs and systems.
Microsoft's OSes have become so popular, and the market so large that they can't ignore situations where people are using older version of both their OS and applications. This ends up putting limits on how much they can change each subsequent version, since as long as people need those older programs to run (and sometimes it's a large number of people) they have to hold back the OS to support it in some way.
Basically, they're own popularity is working against their need to evolve.
Meanwhile, you have a company like Apple, whose systems are not nearly as popular as Windows-based systems (based on market share), which took a drastic step and broke backward compatibility with their older operating system when they introduced OS X, which was a major evolutionary leap from the previous versions. Arguably this has allowed the company to gain both market and mind share, and position their systems as being far more reliable and well designed than their Windows counterparts.
A big reason Apple could do this is because they don't have nearly the same size market as Windows -- they could afford to take the risk.
Now back to language-land...
Sun has made a conscious decision both on past language enhancements (Generics) and it seems on future ones (Closures) to maintain backward compatibility with both existing code and JVMs. This puts it in the ugly position of having to ensure that any change made to the language works within the framework of what's already being used by developers.
A big reason for wanting to maintain this backward compatibility is because of the large market for Java development: Breaking backward compatibility means they risk alienating a significant chunk of the community.
Meanwhile, you have other languages with a smaller market share/less popularity (Python and Ruby, for example) that are able to evolve and make changes quickly due to the fact that any changes they make aren't going to have as significant of an impact on its user base.
Hmm...this sounds familiar, doesn't it?
Maintaining backward compatibility for Java is a worthy goal to reach for, but for some of the changes that get considered, you can't necessarily take that option off the table. At the same time, Sun can't afford to break backward compatibility if the language is to continue to be popular, so we end up with some non-optimal solution added to the language that potentially makes things worse for the developers. It's a no-win situation.
This is where other, less popular languages have an advantage: Python in particular has broken backward compatibility several times in previous versions of the language. One big reason it could do this was because the market for Python developers is smaller than it is for Java.1 If Python were in Java's position, I doubt such decisions to break compatibility would be so easy.
Much like Windows, Java's extreme popularity prevents it from evolving in necessary ways.
More Bad
With all of these changes that are trying to be made to the language, there is also the potential risk of decreasing the adoption of the language. Java's already widely in use throughout the industry, but if we expect new developers coming into the programming field to adopt the language it has to continue to be both useful and approachable. Adding complexity (as I think Generics and Closures do) works against this very goal, as it makes it harder for newer developers to get up and running with the language, and understand existing code.
(Of course, the ever-growing Java API also has this effect on new developers as well. Trying to navigate the disgustingly huge number of APIs in the Java SE is a daunting task even for seasoned developers...)
There's already evidence that Java is failing at this approachability, as there are colleges teaching Java that don't even try to talk about Generics when presenting the language to their students.2 If this is the case, then how do we expect these developers to work with features like Closures?
Another facet of this is that, with the added complexity we will undoubtedly add to the language when tacking on new functionality (either through trying to maintain backward compatibility or otherwise), we're forgetting a whole swath of current Java developers who, whether we like it or not, are going to severely impact the overall productivity of the community. And making the language more complex is just going to exacerbate an already bad problem these developers represent.
The Ugly
One thing I've grown to understand while being involved with Java-related projects is why there's so much hate towards the Java language and perhaps the community itself: The bulk of it comes down to the overall makeup of the Java "community". I use quotes here because the community I'm referring to isn't just the vast number of intelligent, enthusiastic people that inhabit places like JavaLobby, or DZone, or TheServerSide.com, but the entire group of developers out there that have made a career using the Java language.
The unfortunate consequence of having a language that's so easy to use is that, while there's plenty of very capable and smart software developers using the language, there is a vastly larger group of people that have been using Java out there who are...shall we say...less than enthusiastic about the whole art and science of software development. You know who I'm referring to: Those unfortunate (and aggravating) souls that have no desire to really learn anything more about programming than what is necessary to earn them a paycheck - the ones from whom we regularly get our laughs on sites like The Daily WTF.
Let's face it: There are a lot bad programmers in the Java world.
It's the result of the combination of the language being both approachable, and the community so large (since the more people using the language, the more likely the chances of lesser-skilled developers using it). There are quite a few of these programmers using Java, and they are not going to go away as long as having "Java" on the resume is a guaranteed chance at snagging an interview, and possibly a job. In my career as a developer working on Java-based projects, I don't think I've ever had a job where there wasn't at least one of these guys involved in a project I was on.
Now, granted this isn't necessarily a Java problem so much as an industry problem. As someone's recently pointed out rather astutely, the software development world seems to have a interesting characteristic of allowing those of both lesser capability and ambition to coast along doing programming work. So it stands to reason that since Java is so popular, the bulk of these lackadaisical programmers end up working with Java as opposed to some other language.
Unfortunately for Java, this ends up painting the language in a bad light, as there are so many of these developers using the language. The fact is that you could substitute some other language as the most popular and probably have the same result. Yes, the Java language itself does deserve some of the ridicule it receives, but I think the bulk of the ridicule is more a case of disliking this specific segment of it's user base.
At any rate, this is the group that comes to mind whenever I read about adding something like Closures to the language. It is this crop of developers that has the potential to do the most harm when new features get added to the language. Especially when those features add additional complexity.
Because what happens is that any code these non-enthusiastic, non-creative, unthinking lackey programmers create is likely going to be some bastardization of what was originally intended as the use for said features. They will drop generic classes (and possibly even closures) into their code like it's nobody's business...and turn what could have been a simple project into a nightmare.
They will basically use said features just for the sake of using them...without any clear understanding of why or how they really should be used. And they won't care either, because to them it's just a job.
And imagine that situation repeated over thousands of projects.
Of course, I realize that "because it'll be abused by bad programmers" isn't the best of arguments against adding new language features to Java. For one thing, there are ways to mitigate this sort of problem: Code reviews, good hiring practices, etc. But considering the size of the Java developer base, the odds of weeding all of these kinds of programmers out is about the same as the chances of wiping every cockroach off the face of the earth...about nil.
While the best of us out there will be able to work very intelligently with any new additions to Java, these types of bad programmers appear to be so prevalent in the Java world that it can have a very real impact on productivity for everyone - including the smart ones - since somebody will ultimately have to deal with the code that these developers produce at some point.
Eventually, the misuse of these new features (good or bad) could end up working against the Java community as a whole - resulting in Java gaining a bad reputation for creating solutions that are unnecessarily complex.3 And the reason for this may only be because developers - the bad ones - didn't use the features the way they were intended and made things much worse than had they not had the functionality available at all.
Sometimes the only solution to making sure that people don't shoot themselves in the foot is to make sure they don't have the gun in the first place.
One Step Forward...
Overall, I'm not opposed to improving Java, even if those of lesser skill can't quite get their heads wrapped around the concepts that get included in the language. And I'd rather see some improvements over none at all.
But I'd much rather have these improvements to Java done right. And in some cases, I think that means breaking backward compatibility. It's not an easy decision to make, but I think those in charge of Java's stewardship should consider the option. We all want to see Java continue to be successful, but if we insist on trying to contort additions to the language to fit the existing system we're going to end up making things harder on developers, not easier.
And we have to be cognizant of the fact that, despite our best efforts to make programmers' lives easier, we're potentially giving them something that they won't fully understand how to use properly and may make things much worse overall for the Java community.
(Stay tuned for Part III)
1 - I am not trying to make a "Java is better than Python" argument here, so save the ranting and raving. It's just a simple fact that Java is more popular than Python. That doesn't make Java better than Python. And I would certainly not try to make that argument...as I actually believe quite the opposite.
2 - Of course, the subject of teaching Computer Science in colleges is just as complicated as this whole discussion over Java...and I don't want to diverge too far from the point here. Let's just say that the fact that Generics aren't taught is both because of the complexity it introduces and because students aren't necessarily taught everything they should be, and leave it at that for now.
3 - Yes, I know, people could argue that Java already has a reputation for resulting in complex solutions...but doesn't that make the situation just that much important? If the Java is already considered to make solutions that are too complex, then what's going to happen when we add further complexity to the language?
Know Your Limits...
I regularly listen to the podcasts on stackoverflow. They're not the top of developer entertainment, but I've found them generally interesting in that hearing discussions by Jeff Atwood and Joel Spolsky about software development (particularly when they're discussing building a new website from scratch) provides a nice point of comparison for my own work both professionally and personally. It's nice to hear what other people in the industry are working on, without hearing too much market-speak.
So, today I see on the stackoverflow blog a link to this post, basically knocking Jeff for not being experienced enough for what he's doing.
The last sentence sums up the whole post pretty well:
I understand the argument that perhaps Jeff Atwood may not currently have the requisite chops to build stackoverflow and make it successful, but how is he supposed to learn how to undertake such a task unless he...oh I don't know...tries to build the damn website.
People don't learn to be more than what they are unless they push their limits...even if they may not know what their limits are. If someone told me when I graduated high school that I'd be developing software in 2008, I'd have called them nuts because at that time I didn't think I had what it took. But I am now, and for no other reason than I made the effort to constantly learn and grow and improve myself -- which often involved me doing things I had never done before.
Talk like that smacks of elitism...that because someone didn't have the proper education or learning environment that's somehow "proper" for software development, or that just because he's never done this type of thing before, that he shouldn't even bother trying.
Just because Jeff doesn't know what he's doing doesn't mean he shouldn't try. It's his choice, and his failure to make. And I am certain that even if he does fail (which I hope he doesn't) he'll know better what to do the next time.
And if there's something wrong with his approach to the project, why not a) try to make something better yourself, or b) suggest to him what's wrong? Complaining that he just "doesn't have what it takes" doesn't improve his chances at all of making stackoverflow a success.
I respect Jeff for making the effort to do what he is doing...especially because he's moving beyond his own comfort zone. Not many people are willing to take that step, and are more content to just stick with what they know...and I find that a far more career-limiting move than pushing beyond your capabilities.
So let's leave the guy alone and see what becomes of his efforts, OK?
So, today I see on the stackoverflow blog a link to this post, basically knocking Jeff for not being experienced enough for what he's doing.
The last sentence sums up the whole post pretty well:
But you have to know your limits, and Jeff Atwood repeatedly shows that he doesn’t.Now, I realize that Jeff is quite capable of defending himself, but come on...you've got to be kidding me here...
I understand the argument that perhaps Jeff Atwood may not currently have the requisite chops to build stackoverflow and make it successful, but how is he supposed to learn how to undertake such a task unless he...oh I don't know...tries to build the damn website.
People don't learn to be more than what they are unless they push their limits...even if they may not know what their limits are. If someone told me when I graduated high school that I'd be developing software in 2008, I'd have called them nuts because at that time I didn't think I had what it took. But I am now, and for no other reason than I made the effort to constantly learn and grow and improve myself -- which often involved me doing things I had never done before.
Talk like that smacks of elitism...that because someone didn't have the proper education or learning environment that's somehow "proper" for software development, or that just because he's never done this type of thing before, that he shouldn't even bother trying.
Just because Jeff doesn't know what he's doing doesn't mean he shouldn't try. It's his choice, and his failure to make. And I am certain that even if he does fail (which I hope he doesn't) he'll know better what to do the next time.
And if there's something wrong with his approach to the project, why not a) try to make something better yourself, or b) suggest to him what's wrong? Complaining that he just "doesn't have what it takes" doesn't improve his chances at all of making stackoverflow a success.
I respect Jeff for making the effort to do what he is doing...especially because he's moving beyond his own comfort zone. Not many people are willing to take that step, and are more content to just stick with what they know...and I find that a far more career-limiting move than pushing beyond your capabilities.
So let's leave the guy alone and see what becomes of his efforts, OK?
Subscribe to:
Posts (Atom)