RE: [Embedlets-developer] RE: W hy Embedded Java is floundering.. QUESTIONS that need answering.

[James C. <ca...@vi...>]

>The reason for this is that Java is an order of magnitude
>more difficult to master than plain C is and this is a very effective
barrier
>that no amount of enticing can easily overcome.

But yet Visual Basic is the most used and arguably most useable language in
the world and it runs on an equally impressive Virtual Machine (save a few
missing concepts argueably not needed for embedded)

On a scale of 1 to 10 then, how important would it be for people to be able
to program in Visual Basic but run it on an Embedded Java Device?

On a scale of 1 to 10 then, how important is the concept of language
neutralisation, because Visual Basic runs on a VM that could run on JVM with
a little massaging, equally VB.NET, C#, even J# could all run on embedded
Java with a MSIL=>Bytecode translator with a little massaging. Especially
given that the requirements are not for FULL BLOWN java.

If I offered muvium with Visual Basic or PICBASIC or Java languages would
this make a difference? Which one would people use first?

Could language neutralisation shift the industry?

How do we get people to learn java.. WE DON'T! we bring their existing
skills to the JVM.

If you can't bring the horse to water bring the water to the horse?

How much of a priority should this work be? I have done the prelim research
and it can be done.

If java is moving at a snails pace is this work mandatory for its success?

James Caska
http://www.muvium.com
'Java Bred for Embedded'






> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Sunday, February 02, 2003 10:48 PM
> To: emb...@li...
> Subject: [Embedlets-developer] RE: W hy Embedded Java is floundering
>
>
> Chris,
>
> > in the
> > development world things do change in a positive-feed-back manner ie:
> > rapidly once initiated.
> >
> > I recall getting the first 'C' compiler for the 8051, way back
> in the last
> > century, when the only way to program the damn things was with the
> > manufacturers' assembly language tools. There was a fair amount of
> > resistence because engineers were comfortable twiddling bits
> and were not
> > interested in going back to school to learn to program.
> > It took a while but now 'C' is King and most engineers can deal with it
> > pretty well.
> >
> > The same thing will happen with embedded Java [snip]
>
> How confident are you that the analogy of the Embedded systems developer
> movement from assembly language to C holds true for their
> potential movement
> from C to Java?  My background is in computer electronics and industrial
> control systems and most of these type of curriculums usually
> only teach how to
> program in assembly language, C (not C++) and perhaps Visual
> Basic.  When I
> went through it was only assembly language and BASIC.
>
> I had to teach myself how to program in C after I graduated and it took me
> about 3 weeks because regular C is fairly straight forward and it
> is so close
> to the hardware that it is almost like a portable assembly language.
>
> When I started to teach myself Java my experience with C lead me
> to estimate
> that it should also only take about 3 week to learn but I was in
> for a very
> rude awakening!  It took me a full 3 years of pounding on Java
> almost every day
> and at least 3 hours a day to become proficient in it and the
> culmination of
> this process was my passing the Java Developer's exam in the
> Spring of 2002.
>
> In addition to this, I taught C to beginners for about 5 years and then I
> started to switch to teaching Java.  I have found that Java is an order of
> magnitude more difficult to teach to beginners than regular C is.
>
> With C, things are so simple.  One covers variables, functions,
> loops, decision
> blocks, pointers, pass-by-reference, pass-by-value, cover the #include
> statement, show them some library functions, show them the
> compiler and off
> they go.  Beginner's can work themselves up to developing reasonably
> sophisticated applications in about one quarter.
>
> With Java one needs to understand a wide range of extremely
> abstract and subtle
> concepts before one can develop code that is even close to being
> usable.  For
> example, when teaching Java to beginners one needs to cover classes, class
> methods, class variables, instance methods, instance variables,
> constructors,
> instantiation, objects, inheritance, polymorphism, composition,
> interfaces,
> abstract classes, encapsulation, an object's public API vs. its
> private methods
> and threading.  On top of this one needs to explain the JDK and
> its relation to
> the JRE that is inside of it, classpaths, packages, Jar files and
> the JavaDoc
> documentation.
>
> Now comes the task of introducing them to the huge Java standard class
> libraries and how to determine which classes they can start using
> now and which
> ones they should save for later.  As soon as one introduces Swing
> components
> then one need to cover the event mechanism and how interfaces are
> leveraged to
> enable this event mechanism.  This soon leads to things like MVC
> and the need
> for proper object oriented program design and how to start architecting a
> system.  Of course these type of concepts are extremely difficult
> to see by
> just looking at the code so one needs to introduce UML in in order to more
> easily get these ideas across.  Being able to view UML representations of
> object oriented applications raises more questions than it
> answers and this
> inevitably pushes one into discussing the need for things like
> design patterns.
>  Beyond design patterns techniques for enhancing the robustness
> and flexibility
> of a system must be understood and so things like unit testing
> and refactoring
> are introduced.
>
> If one is successful in getting them to develop reasonably well
> done desktop
> style applications then one needs to break the news to them that
> unfortunately
> there is not a market for desktop programmers and that they will
> need to learn
> how to do n-tier Enterprise programming if they want to make a
> living doing
> this stuff.  So now one needs to cover the differences between
> J2ME, J2SE and
> J2EE and that the J2EE world consists of application servers,
> Servlets, JSPs,
> EJBs, databases, directories, messaging, etc., etc, etc.
> Somewhere along the
> line you also need to open their eyes to the fact that if they do
> not have a
> firm grasp of XML and its related technologies they are dead in
> the water and
> so one needs to introduce them to SAX and DOM parsers, DTDs,
> Schemas, XSLT,
> XML-RPC, XSLT, etc.
>
> This does not even begin to take into account all the extra stuff
> one needs to
> learn in order to deal with Embedded Java.
>
> It has been my daily experience that it takes years of extremely
> hard work for
> a person to become a competent Java programmer.  At one point in
> time I naively
> thought that teaching Java from an embedded systems perspective
> through free
> online classes was the way to quickly increase the pool of Embedded Java
> developers but years of effort in this area have effectively
> cured me of this
> way of thinking.  Teaching will definitely help but it is going
> to be a very
> slow centimeter by centimeter process.
>
>
> After having taught Computer Interfacing to beginners for over 12
> years now I
> could also give an equally long description of the hell one needs
> to go through
> in order to teach these skills to beginners, but I will spare everyone the
> additional pain. ;-)  Suffice it to say that it is equally as difficult as
> learning how to properly program in Java.
>
>
> My point in laying this out in such a protracted way is to
> illustrate precisely
> why I do not think that we are going to see existing C and
> assembly language
> oriented embedded systems programmers move into Embedded Java in
> significant
> numbers anytime soon. The reason for this is that Java is an
> order of magnitude
> more difficult to master than plain C is and this is a very
> effective barrier
> that no amount of enticing can easily overcome.
>
> The lack of computer interfacing skills provides an equally insurmountable
> barrier that prevents existing Java programmers from becoming
> Embedded Java
> programmers.
>
>
> Again, my conclusion is that we Embedded Java developers
> represent a small and
> very slowly growing group that has an extremely powerful technology at our
> disposal.  Hopefully Embedlets will enable us to unlock some of
> this power, one
> way or another.
>
>
> Ted
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>