The recent article of steve jobs link
made me think about the future of flash. I'm learning actionscript 3.0 in my studies but is it the right decision still to go for it? I was pretty sure that I will be able to build application in as3 for iphones/ipads in the near future. It seems to me, while I would stay with flash, the market will be polarized by apple and adobe and you will always work double for both clientele, or just lose half of them.
Which decision would you take as a designer, if you were still at university and you intend to become a freelancer?
This question has been around a lot of times. For my opinion on flash's future please look at this answer: Should I Abandon Adobe Flash for HTML5 and <canvas>?
If you are a designer, you will probably actually feel good working with Adobe's Creative Suite, including Flash CS3/CS4/CS5. CS5 will be able to export HTML5 in the near future: http://www.9to5mac.com/Flash-html5-canvas-35409730 . You shouldn't be too worried. OTOH you should consider, that whatever CS5 exports is likely to perform poorer in HTML5, than on flash player.
From my perspective as a developer, I think there is no harm in learning any language, altough ActionScript 3 is relatively boring and easy to grasp. However this makes it a good language to learn programming, including many best practices. The most important things you learn as a programmer transcend languages. The more languages you try to really fully understand and exploit, the better you become by understanding the approaches they promote.
My personal advice to web developers is to have a look at Haxe. It is a much more powerful, elegant and expressive language than ActionScript and it allows you to target many platforms. Enough to build a whole web app on 'classic' platforms with only one language. Haxe's C++ backend allows building native iPhone apps using an SDL based port of the flash player API, although currently it's not very clear whether Apple's policy will allow distribution. Nonetheless it is an open source language with an enthusiastic community, that moves really fast and adapts to changes rapidly (e.g. unlike ActionScript Haxe can leverage flash player 10's alchemy opcodes for fast memory access) making you as a developer independant.
edit: I have personally dropped any plans of targetting the platform until Apple is willing to ease its very restictive policies, since I find this kind of behaviour intollerable. Nonetheless, I think Objective-C is a great and inspiring language, so you may actually wanna have a look at it.
I think that reports of the death of flash have been greatly exaggerated. Flash has always been "the bad guy" - self-proclaimed experts have always loudly declared that Flash sucks and is on its way out, but oddly enough I've never had any trouble finding lots of Flash work. There are things that you can do quickly and easily in Flash that are either much harder or flat-out impossible without it. It's an amazing tool and it's going to be in use at least in some capacity for the foreseeable future.
That said, even if Flash on the web goes the way of the dodo in two years (which won't happen) it's still a valuable tool. It's a wonderful way to learn Object Oriented Programming, and its uses go far beyond shiny websites. You can use something like Flash Builder in Eclipse to get accustomed to working in a code-oriented IDE, you can build AIR apps to deploy across platforms, you will soon be able to publish saleable apps to every major phone including the iPhone, etc. I've been having a lot of fun with it lately getting it to work with Arduino - it's just a hobby project but I'm trying to build a little helicopter that I can control from an AIR app. I'd be curious to see someone do that in HTML5. ;)
Flash is amazingly powerful - your abilities are in many respects limited only by your imagination and willingness to figure out how to make it work. It's really bizarre to read all of this stuff about how (some) browsers can now play (certain types of) video one their own, ergo Flash is Dead. How unimaginative. :)
This is a tough call. Flash is a fairly dominant technology at this point when it comes to media-intensive web sites. Flash is also very popular for delivering mini-games. I do think that Flash video, which is currently also dominant, will gradually be replaced by HTML5 technologies. I'm not so sure that Flash can be replaced easily when it comes to those media-intensive sites. There is a large number of very talented people comfortable with Flash that might be reluctant to adopt other technologies. I would probably hedge my bets and get comfortable with Javascript and other HTML5 technologies.
Apple vs. Adobe controversy reveals two opposite views of mobile computing.
Apple wants that its developers make the best of its devices by excluding middleware. The aim is to deliver the best possible user experience.
Adobe wants that its developers publish their work on as many platforms as possible. The aim is to reach the widest audience.
Nobody knows which view will win in the future. The mobile war is just beginning...
I think it depends on how far into the future you want to look, and what you think is most important. Flash on the desktop will not die for a long time, if ever. If that is good enough, keep going with where you're going. If not using flash on iPhone/iPad is a deal breaker, you only really have two choices - Objective-C or HTML5.
HTML5 is definitely gaining momentum, but it can't be used directly in all browsers yet, and likely for a while. However, in the mobile space, there is pretty excellent support in the major smart phones.
There isn't a single platform/technology/language that can hit everything. If I were going to bet money on the future, though, I would say HTML5 is going to win for the most reach across platforms. And given it is on the rise, I would bet that in the next few years, there will be a lot of demand for good developers in this area, but don't expect the path to be fully paved for you. You'll have to get your hands a little dirty. If you're looking for a decent editor, I use Netbeans, but I also do Java development, so that makes sense for me. Search around, though, and you'll probably find a decent set of tools that work well for you. It is a very active space.
As far as I'm concerned, Actionscript is a pretty good language to learn OOP. Javascript is a bit shit. Eitherway, I would expect you'd learn a certain set of (frontend/2d graphics) skills which will come in handy regardless of the vehicle you'll eventually use to deploy your work.
Personally, I like the flexscript language used by Flash, it's more structured and object oriented than Javascript. Also it has real inheritance, not the prototype based crap, and compiles to bytecode. For the artist, Flash is easier to use in many ways due to the available tools.
I do hope for better integration into browsers. The current flash plugin is clunky and causes crashes for many users, also the plugin system makes it integrate badly into the flow of pages.
With HTML5, I think the browser plugin idiom is dying in general. Everything from video playback to fancy vector animations can be done with just HTML + Javascript. Even a standard for 3D graphics in webpages is on the way (O3D).
Also I wonder how Adobe will cope with the current explosion of platforms/operating sytems/browsers, especially in the mobile realm. At the moment, the Flash support for systems except for Windows on PC isn't much good.
Just as projects like SVGWeb brings SVG capabilities to browsers that don't have native SVG, I would expect that if/when HTML5 gains traction against Flash there will be conversion capabilities from existing Flash to browsers without Flash. In fact, Adobe already has a conversion from Flash to iPhone using Flash Professional CS5. IMHO, there's too much Flash content in the wild for this not to happen eventually, and there are too many people for which Actionscript is their primary (or only) language for some conversion not to happen.
Career-wise, the clear long-term trend is away from Flash, and I agree with Tom that hedging your bets is wise. However, HTML5 is still fairly new, and you might do yourself a disservice to ignore Flash at this point. With conversion technologies, a Flash skillset will likely be usable for at least several years.
Related
I know this sounds a little bizarre, but there is a very simple application I want to write, a sort of unique image viewer, which requires some interactivity with the host system at the user level. Simplicity when developing is a must as this is a very small side project. The project does require some amount of graphical work and quite a bit of mouse based interactivity (as well as some keyboard shortcuts), but quite frankly, I don't want to dig my hands into OGL for something this small. I looked at the available options, and I think I've narrowed it down to two main choices: Webkit (through either QtWebkit or WebkitGtk), and the language Processing.
Since I haven't actually used Processing but I do have some amount of HTML5 canvas and Javascript experience, I am somewhat tempted to using a Webkit based solution. There are however, several concerns I have.
How is Webkit's support for canvas, specifically for more graphically intensive processes?
I've heard that bridging is handled better in QtWebkit than WebkitGtk. Is this still true?
To what degree can bridging actually do? Can a Webkit based application do everything that an application which interacts with the files on the system needs?
Looking at Processing, there are similarly, a couple things I'm wondering.
Processing is known for its graphical capabilities, but how capable is it for writing a general everyday desktop application?
There are many sources that link Processing to Java, both in lineage as well as in distributing applications over the web (ie: JApplets). Is the "Application Export" similarly closely integrated with Java?
As for directly comparing the two, the main concern I do have is the overhead of each. I want the application to start up as snappy as possible, and I know that Java has a bit of an overhead regarding start up because it first has to start up the interpreter. How do Processing and QtWebkit/WebkitGtk compare for start up?
Note that I am targeting the Linux platform only.
Thanks!
It's difficult to give a specific answer, because you're actually asking a few different kind of questions - and some of them you could be more precise.
Processing is a subset or child of java - it's really "just" a java framework with an free ide that hides the messy setup work of building an applet, so that a user can dive in and write something quickly without getting bogged down in widgets and ui, etc. So processing can exist by itself and the end user needs to know nothing of Java (except syntax - processing is java, so the user must learn java syntax).
But a programmer who already knows java can exploit the fun quick nature of processing and then leverage their normal java experience for whatever else is needed - everything of java is in processing, just a maybe slightly hidden (but only at first) It's also possible to import the processing.jars into an existing java program and use them there. See http://processing.org/learning/eclipse/ form more information.
"how capable is it for writing a general everyday desktop application?" - Not particularly on it's own (it's not made to be), but some things are possible and easy (i.e. file saving & loading, non-standard gui, etc.), and in some ways it's similar to old school actionscript or lingo. There is a library called controlP5 that makes gui stuff a bit easier.
Webkit is another kettle of fish, especially if you aren't making a web-based thing (it sounds like you're thinking on using the webkit libraries as part of a larger program. I'll admit I don't have the dev expertise with those specific libraries to give you the answer you really want, but I'm pretty certain that unless you have programming experience beyond html5/javascript you'll probably get going much faster with processing.
Good luck with whichever path you choose!
I heard someone say that developing on the mac using cocoa is great for rapid development.
Is it a good framework for building GUI based apps relatively fast?
Here's for some historical perspective:
The Cocoa framework evolved from the NeXTSTEP framework when Apple bought NeXT (and Steve Jobs along with it) to form the basis of OS X. This is why you see lots of NS littered throughout Cocoa. And NeXTSTEP was one of the earliest frameworks to call itself a RAD framework. So from that point yes, Cocoa is a RAD framework.
There was a famous demo of how fast you can develop apps in NeXTSTEP where a full-fledged text editor (with font selection, file load/save, everything) was developed during the course of the demo (I believe it was under 30 minutes).
Another famous use of NeXTSTEP was the invention of the World Wide Web. Basically HTTP and HTML. Legend has it that Tim Berners-Lee cooked up HTTP and HTML and prototyped the worlds first web browser and web server in just a couple of days. And remember, that first web browser had the ability to edit as well as view HTML -- yes, the original internet was a giant Wiki!
Even at the time it was released as Cocoa around 96/97 it was still considered one of the top RAD environments around. This was around the time Borland was heavily positioning Delphi as a RAD environment and Microsoft's MFC was painful to use in comparison.
These days I would say that it is roughly comparable to .Net. Though I personally feel (and I know lots of long-time Cocoa programmers tend to share this sentiment) that Cocoa still has an edge in how fast I can take an idea to completion and how clean the resulting code is. It's an older framework, more mature and implemented lots of things right but other frameworks have had lots of time to catch up.
I strongly believe the combination of Interface Builder and Cocoa makes prototyping an application faster than anything else I've used. Typically, creating something that is 'visible' takes just a few minutes using IB to wire controls to code, and a few more to write the code itself. Factor in the modular nature of View Controllers and the process of adding GUI elements to a large codebase is suddenly very easy. The next version of Xcode makes this process even faster, so I daresay you've got a lot to look forward to.
If you are familiar with the tools and willing to work with the provided UI elements then I think so. However because you're working with a fairly rich and stateful UI once you decide that you need custom views then you have signed up for some real work.
Overall I find web development slightly faster, largely because there's a wider selection of available libraries and frameworks to build on, but that's only an alternative for certain types of applications.
I'm trying to understand if it is worth the pain to learn XUL more thoroughly.
If you have experience with a moderately complex project (like an independent application rather than a Firefox extension), can you tell me what your experience has been like?
I am particularly worried for feature which are not supported by the XUL framework natively. There are two possibilities: either create more XPCOM components, or using external tools. The latter approach is not completely satisfactory, as interprocess communication seems somehow lacking in XUL.
On the other hand, I have no knowledge of C++. How difficult would it be for a first time learner to wrap an existing library in XPCOM dressing?
I have not written any XPCOM in my three years of developing XUL applications. It does seem intimidating. So far, though, I haven't had a good reason to create any XPCOM. I do use some external tools - for reporting, working with mobile devices, etc. I eventually figured out that you can at least get the STDOUT return value from a process that runs (at least on Windows, it seems that this particular feature might not be consistent across platforms). That allowed me to have at least a single return value, which allowed me to implement error handling.
I think that you will find that you can do quite a bit without touching XPCOM. However, everything is not polished and easy, and there is not a large, helpful, developer community/ not much developer support, so it can be a frustrating learning experience.
If this is a large application, or an application that you might be adding other developers too, you may wish to consider choosing a more supported development platform.
I'm a software developer. I've been programming in high level languages for a few years.
I would like to know, how to take my first step into programming hardware. Not something crazy complicated, but maybe some ordinary CE device? Assuming I don't need to put the PCB together with varies components, but just to program the tiny cpu?
How low-level do I have to go? ASM? C? manipulating registers? or are the dev kit quite high level now? Is Java even in the picture? OO coding in hardware, is that even a dream or a reality? Need a reality check.
I also tend to learn better with books or sites that are written in a tutorial format. Something that guides the way for me from something simple to something more complex. Any recommendations? Maybe something that will introduce me to the popular hardware (microprocessor/micro-controller) available today?
Much appreciated, thank you everyone.
The actual programming isn't a big deal. The frustrating, annoying part is getting your development environment setup and getting the tools working. Once you've done that, you're half done.
I'd suggest buying a development kit ('dev kit') that has USB built in and works with your chosen OS. Get that working, and you're halfway done.
If you're missing the knowledge, it's also important to know the basics of how a processor works. You'll be programming at a much lower level than any other programming, so the fundamentals are a bit more important.
If you know C then it's only a matter of learnig the tool chain steps to download the code.
Easy place to start (cheap hardware/software) http://www.arduino.cc/en/Guide/HomePage
I have been coding in C both as a hobby and professionally for about 16 years now, but always for userland code (i.e., programs, not kernel or drivers). Most of my jobs involved high level languages (I have done a lot of Perl and Ruby programming, with the occasional Java, Python and shell scripting in between). I did develop a lot for MS-DOS (which was probably as close to bare-metal programming as you would get on a x86 machine), but my last job involved 5 years of Perl and Ruby on Rails web development.
That being said, I am now a senior engineer for embedded Linux development, developing drivers (including an emulator for a legacy simple microprocessor inside a kernel module) for uClinux on the Blackfin platform. There are times when my inexperience with hardware related issues (i.e., floating signal levels due to lack of a pull-up/pull-down on a pin) did get in the way, but it has been mostly a highly enjoyable and thrilling experience. As stated by others, understanding your tools is essential -- for uClinux, that meant the GNU Toolchain, which fortunately I was already familiar with due to my background on FOSS technologies.
The Blackfin is hardly an entry-level microprocessor (in particular, it does not have a MMU, which has some relevant effects on Linux development), but as already stated, you can buy a Beagleboard for around US$200 with all required accessories and start messing around with it in just a few days. If you want something simpler, there are many Arduino options out there, though if you have some real development experience under your belt I believe you will find their development environment a little limiting (I know I did).
After you get comfortable with your tools you might want to spend some money on an in-circuit emulator (or ICE). These are usually highly platform specific (both in terms of target architecture and development environment), but are highly recommended for anything beyond the usual blink-LEDs-after-button-press examples I am sure you will quickly outgrow.
In few months you will find yourself building custom images for hackable customer devices using Buildroot and having a lot of fun. All I can say is, go for it, it's highly addictive and not particularly expensive to do nowadays.
Also something to look into is the Microsoft Robotics Studio. They support quite a lot of hardware boards (including CE), and with it is is fairly easy to get a small robot up and running. And what's more cool a project to learn embedded programming?
It all integrates nicely in Visual Studio (express) and their devkit also comes with a free express edition.
Get a beagleboard. Cheap, lots of users (community support will be key), many OS options. http://beagleboard.org/
Well, if you want to know what you're doing, you need to understand the assembly language of the processor and the processor's architecture.
You will need to learn C to be competent in microcontrollers. There is no way around that.
There are some VM-level languages on embedded systems. I see the Java out-of-memory exception from time to time on my cell phone(which also helps to give me a strong opinion on VM-level embedded languages).
The ARM has some support for hardware-level Java bytecodes.
Your best bet is to pick up something like the PIC or the Atmel chips and begin hacking with them.
If you want to do it with your existing hardware, get a hypervisor for your PC and begin writing a basic kernel.
I'm thinking about switching my path "slightly" by going into desktop development (VC++, MFC, C#, etc) after about 8 years within embedded telecom systems development (C, MAKE, Symbian, 100 compilers etc, etc).
My concern however is that my experience within embedded systems maybe doesn't give me much value when going into desktop development. For example that the domain specific problems and environments I've worked with for so long still doesn't give me much to negotiate salaries with since it bares little worth on the desktop.
I think this place might be good for input on this.
So, the Q:
If you disregard the obvious generic experience on programming language level, give an example of something you have learned working with embedded systems that you could reuse when working in a desktop environment.
PS:
I should note that I'm no beginner in the desktop area - since many years back all my hobby projects are focused around desktop development.
Embedded engineers in general tend to be more disciplined when it comes to validating operations and dealing with finite resources.
This can also translate into coming up with an exception handling strategy earlier on.
The quintessential example is checking the return value of malloc. I have seen very few desktop software consistently check it, but it's commonplace in embedded environments.
Discipline of having a clean, well-organized set of source-code is the key skill that translates well to the "desktop experience". -- I've noticed that the embedded projects I've written and picked up are often WAY cleaner than their desktop counterparts.
Many desktop-only developers could benefit from the experience of making a program fit in 128K of FLASH and 32K of SRAM, not to mention communicating meaningfully with a user through only an LED or two and a couple of buttons. Making that a requirement might reduce some of the endemic code bloat in the applications industry. :-)
Even if you don't switch tracks to straight application development, the embedded experience translates well to driver development, as well as to low level utilities and to long running services. All of these are also domains where the disciplines that are nearly second-nature to a successful embedded developer remain valuable.
I was a desktop developer for almost 5yrs before switching to an embedded environment.
I find working on an embedded environment more challenging as we have to deal with memory limitations, slow CPU speed, cross-compilation issues, etc.
Having learned a lot of patience, discipline and low-level intricacies, desktop development should be as easy as a walk in the park.
State machines/event driven programming on embedded systems is not that different from event driven programming on the desktop. The depth of experience you have of these coding techniques on embedded systems, especially telecoms embedded systems, should make you a great desktop programmer.
Similarly, your experience with communications protocols should transfer nicely to the desktop. Most desktop applications have some involvement with the network.