I was listening to a Hanselminutes and Scott mentioned having learned a dozen or so programming languages (which is probably low for him). Which got me to thinking. Here, in the order I learned them, are the programming languages I've learned.
By "learned" I mean - became at least moderately competent with, wrote real programs in, and used for at least several months. Not just "played with over a weekend."
I'm a lightweight among my peers, but that's my story and I'm sticking to it.
It's funny how those first languages hold such a warm spot in my heart. It was with those that I first fell completely in love with programming computers.
I'd do the "tag" thing but those are lame, plus no one reads this blog for it's gripping yearly updates. But if you do manage to see this - what languages have you learned?
Link: Safari Developer FAQ.
One of Microsoft's lasting areas of dominance has been software development. No one, really, has as advanced an infrastructure, toolset, platform, community or as much momentum. But Apple is wisely recognizing this largely unchallenged market and they've got my attention. First they revealed yesterday that they're now shipping some real powerhouse machines with quad Xeon processors and 16GB of RAM if you want it. Then this: Ruby on Rails will ship with OS X 10.5 (Leopard).
That's a big deal. They're starting to appeal to nerds, not just the snobsquad of thick-frame-glasses-black-turtleneck-kenneth-cole-styled designers.
Microsoft and our community ignore the RoR movement, the clean, simple, lighter, standards compliant, "web 2.0-ish" way of doing things at our peril.
It’s been no secret that Apple is held in very high regard by the Rails community. Every single Rails Core contributer is running on Apple and the vast majority of Rails developers are too. (-emphasis mine, src)
I'm doing form validation, and it seems I have the following (acceptable*) choices.
Issues with option 1:
It's nice because: 90%+ of users will likely get their needs met with the client side checking, very quickly. If it fails, the server logic will keep it from running afoul.
It stinks because: I'll have to write validation logic twice. I'll have to do some additional voodoo to make the client-side reporting of the errors work from the server side.
Issues with option 2:
It's nice because: I only have to write my validation logic once. I can use the same logic, in fact, for the double-check on the server when the page submits.
It stinks because: I have to write the AJAX hooks, and I'll still have to find a way of making the client-side reporting of errors work after the submit.
Maybe it's a wash? Maybe if I go with 2 I'll be able to leverage the AJAX for other benefits.
Additional considerations:
This is another of many moments when I'm faced with the option of just not supporting browsers without Javascript enabled. I've come a long way without making that decision, but it's a hard one to avoid. We know it's not a good practice to do so because it alienates some visitors. But the compromise between creating graceful degradation and "getting something out there" is a tough one. 37signals decided long ago that anyone without Javascript was out of luck. They also have a very sophisticated audience, for the most part. I don't imagine they've lost many clients because of that decision. (I'd love to know the numbers). More importantly, they've released product and are making money.
* The built-in asp.net validation controls are too messy.
Yes, they really have.
But it's not over yet. With comments like this one:
"As we focus on the enterprise segment, we have the ability to drive up our revenue share."
...I worry. I understand that you need to generate revenue for shareholders. And frankly, I don't begrudge you that. Go ahead. Cater to the enterprise.
But... "Who's next?" you ask?
The lightweight RAD-that-doesn't-blow stuff like Django/RoR/PHP. Of course this is selfish on my part. I realize my tiny segment of uber geeks is hardly a market-share worth pursuing. However, we're a barometer and an early warning system. As we go, so goes the industry in the near future.
And comments like this, really don't encourage me:
Moreover, looking beyond J2EE, Microsoft has to deal with issues like AJAX (Asynchronous JavaScript and XML)-style development, as well as lighter-weight frameworks such Ruby on Rails.
Ozzie said Microsoft must create frameworks for different types of development. For instance, in the Web development space Microsoft has ASP.Net, and for AJAX-style development Microsoft has its Atlas tool.
*sigh* - Ozzie, everyone knows you're a genius, but you've obviously never looked at Atlas and you don't understand the crowd that uses (or wants to use) RoR. Atlas is fairly decent at mass-market buzz-lover appeal, and I suppose you'll get some VB6ers to convert over to it and get all excited. But no one in the serious web developer community can take Atlas seriously. It's too abstracted, too black box, too sealed. We don't want more black boxes and heavier frameworks we want (as you said) lighter-weight frameworks.
ASP.NET 2.0 is a wonderful leap forward from 1.1. Much has improved, and one exciting improvement is Master Pages.
Only Master Pages can't be used by serious web developers.
For today: serious web developers = web developers who wish to observe best coding practices, especially loose coupling and clean separation between layers.
The problem:
Master Pages use a little gremlin called INamingContainer to "help" you. It ensures that no id names on a given page will collide. It does this by kindly renaming your control ids. So if your control id is called "textbox1" - when you use it with master pages, it becomes "ctl00_ContentPlaceHolder1_TextBox1".
And I suppose in some situations, that might be helpful. But in all situations? Come on guys.
The solutions out there range from detecting what that that name is going to be, and dynamically generating your CSS or Javascript, to hard coding what the control will be into your js based on the predictable naming convention. These are completely unacceptable solutions.
The only real solution (short of writing your own control, which I'm pondering), is to skip using Master Pages all together. Which is a serious shame. They had such insanely cool promise.
*sigh*
For more info, read through some of the comments on this post by ScottGu (including our hero's silly suggested workaround) and this article (scroll down to "Name Mangling"). All the suggested solutions are preposterous.
As an undying fan of VS's intellisense and other code-helpers, I'm pretty excited about this new tool. Aptana is a very nice looking IDE for JS (any web stuff really, but it seems to shine for JS). There's even YUI (and many other libraries)-specific support. Cool!
Let's all do the happy dance!
Actually, adding the file-upload capability to the Connection Manager might just be enough to garner it some more love from the "L337" JS/Ajax weenies out there. Yahoo! User Interface Blog.