Over recent years, we have seen the introduction of numerous new technologies and languages that
make applications development a little bit more exciting. Languages such as Python and Ruby have
appeared that, while not necessarily providing groundbreaking features, lend some support to providing
alternative ways to producing software. Ruby on Rails, or RoR, is one such feature that has enabled
developers to produce web - based applications with remarkable speed and ease, making the
development of common application functionality less painful.
This is a great move in the right direction, and many developers have since made the transition to such
languages to further lessen the strain that was ever present with languages such as C++ or Java, but it
doesn ’ t provide a be - all - and - end - all for applications development as it still means having to learn a
new technology. What ’ s more, despite the surge of new technologies that have been appearing, you can
see that they are only really of benefit to desktop or server - side web development, while the client side
for web applications remain firm with Flash, HTML, JavaScript, and VBScript, for the simple reason
that older browser technologies have a greater coverage on users ’ machines. This means that, while we
now have a larger choice of tools for creating our applications, we are perhaps further segregating our
development team members and forcing possible rifts into our software stability and production
timescales.
So why are we suffering these issues and what can be done to dispose of these rifts we keep making for
ourselves while continuing to embrace technology developments? The issues here are not about how
such technologies interact, or about the functionality they provide, but about how we develop for them.
Think about that for a second. If humans, like technology, needed to interact with one another, we
would use an agreed form of communication; written English in the case of this book. If we were to seek
employment in a country whose entire population didn ’ t speak our language, we are sure this would
hinder our progress very much, as it would be hard enough to even convey that we were seeking
employment, let alone be capable of performing many of the available work positions on offer. Yet, in
respect of many programming languages and technologies available, they often communicate very well
with each other using processes of their own, but the way in which we interact with them can be
very diverse.

Originally Posted by devu

Man.. the reason why my letter is so long is because i wanted to give you wider picture.

Originally Posted by smoku

You lost me at "Flash is already Open Source solution".

The Flash Player itself is not Open Source, though many of the related technologies are....

While fully possible, it's not a trivial thing to create your own Flash Player. Creating just the simplest player that supports a tiny subset of features is hard enough and the Gnash project is the only active effort we know about. This is not because Adobe prevents others from creating their own Flash Player, but rather since it's not a trivial thing to do. In blog comments all over the web, you'll find anonymous trolls that post comments saying that "Adobe's Flash Player sucks", "the Flash Player has a rotten code base" and so on. It's very easy to make such bold statements when you never even read the spec or tried to implement it yourself.

Originally Posted by gerbick

Flash file *.swf = open source
Anyway, carry on...

Originally Posted by devu

@gerbic what do you think about haXe and this whole concept. I just realized you said somewhere you have Linux experience. Possible? Like it?

Originally Posted by gerbick

And don't overlook OpenLazlo. I learned how to code better for Flex 2 via OpenLazlo.

Originally Posted by smoku

This was the point I stopped reading your post - you're obviously have no idea what you are talking about.