embedlets-developer Mailing List for Outpost Embedlet Container (Page 35)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher S. <cs...@oo...> - 2003-02-03 03:00:32
|
This is all very speculative but my point and I stand by it is that if there are: A. Compelling reasons - ie. plug-in hardware drivers, dynamic configurability, Enterprise connectivity. B. A direct and concise API, with packaged functionality - Embedlets should not take 3 years to learn or we have failed! C. Available and understandable manageable tools - such as your GUI wiring tool and unlike the J2EE design/deployment process. , the most entrenched 'C' coder will convert, either by choice or by market pressure. The pressure will be in the form of: "Are you Embedlet compatible?" "Why can't you just plug this thing into the network? I hear that Embedlets make it easy!". " Why do I have to spend thousands of dollars just to get a little change made? My friend at Acme manages his own changes with Embedlets" This is a matter of reaching a critical mass issue. At some point we have to take a leap of faith, based on a solid foundation of experience and forge ahead. Let's focus our energy on where we agree and start putting some tracks down! -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Ted Kosan Sent: Sunday, February 02, 2003 3:48 AM 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 |
|
From: Ted K. <tk...@ya...> - 2003-02-03 01:17:06
|
Jac, > * OpenOffice > + free full blown office suite with editor and graphics module > + wysiwyg > = XML based storage, however with proprietary DTD > - large (a lot of disk space and not very fast) > - no pdf creation without commercial plugins (afaik) Why do you say the DTDs are proprietary? I thought they were open? Also, OpenOffice outputs in PDF format out of the box. Just go to File -> Printer Setup, select PDF as the print format and then select Print To File when you print. This generates very nice PDF files of both text and graphics! Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-03 00:14:40
|
Jac suggests: > But only experienced developers are able to write good ones :-) Fortunately we have one or two of those kicking around. I see your ;-) and raise you a ;-P James suggests: > Teds going to love you now! I doubt it! He hasn't read the Architecture Discussion Doc yet. <grins> Nicola offers: > Since I'm getting quite used to shameless plugs ;-P I'd suggest a look > at Krysalis Centipede http://www.krysalis.org/centipede/. I'm not sure we'll need anything more than just Ant (or want anything more). JBoss is built using Ant, so it should be more than enough for us. I would hesitate to build in any more dependencies than absolutely necessary. > I can give a hand in the Ant stuff if you need Thanks for the offer, Nicola...you may live to regret making it. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Jac K. <j.k...@th...> - 2003-02-02 23:31:49
|
Hi, I've got a real life problem and was wondering how this would be solved using our (currently imaginary) embedlets. The situation: hardware: 6 X10 lamp switches, some X10 remotes, X10 gateway (CM11), Couple of 1-Wire devices, some PIR motion sensors, handfull of TINIs, some JStamps, one Sun Ultra10 (Solaris 9), a couple of PCs (WinXP Prof and Linux) and a SaJe board, plenty of networking cable and hubs/switches to connect everything equiped with RJ45s, a couple of J2ME phones, one iMode phone. software: all the development tools needed to create software for the listed hardware. SUN ONE Application server (platform edition) & Directory server. And everything legally available on the Internet of course... goal: - record the status of the X10 switches (according to the info provided by the CM11 [all actions with remotes are available this way]) - present the current status of the X10 devices (on at xx% of max capacity/off) to both J2ME and iMode (chtml can be used for browser as well) - detect arrival of 1-Wire ID on network (signals one of the PIR detectors detected movement) - store all state changes of X10 and 1-Wire in persistant storage for reporting etc In the (near) future a couple of 1-Wire temperature and/or humidity sensors will be added to the setup and I want to extend the software to control the X10 devices. I've got code to sample all of the sensors at this moment and monitoring infrastructure is up and running already, but a redesign is in order to add the temperature sensors and X10 control, so I'm offering to become a test site for our effords. (If you guys promise to behave I might even allow remote access to the system :-) ) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 22:51:54
|
Jac Kersing wrote: > On Sun, 2 Feb 2003, Andrzej Jan Taramina wrote: > > >>It's like makefiles...you don't have to know how to write them to be >>able to use them. > > But only experienced developers are able to write good ones :-) Since I'm getting quite used to shameless plugs ;-P I'd suggest a look at Krysalis Centipede http://www.krysalis.org/centipede/. It's Ant on steroids, with pre-built ant snippets that are auto-downloaded and used, and are called "cents". One could make an "embedlet" cent for the common buildfile snippets and tasks needed. Having hacked quite a lot in Ant (the latest XmlProperty task came from me :-) , I can give a hand in the Ant stuff if you need, and make you have a look at Centipede. I'm really ignorant in the stuff you are discussing here, although I'm really interested. If I can help by offloading some work on non-core work like docs (Forrest et all) and build (Ant/Centipede), I'll be happy to give a hand. Cheers! :-) -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 22:28:58
|
Ted said: > This is the way I saw the Wiring Tool being developed too. Embedlets > should not have any dependencies on a Wiring Tool but they need to be able > to support manipulation by a Wiring Tool. Since you have (thankfully!) > taken the lead on the Embedlets architecture my plan is to put together > enough of an Alpha level Wiring Tool to be able to provide solid feedback > to the architecting process. Super. But keep in mind that given the very tight constraints we will have on the Container architecture/implementation (to squeeze into small devices), and the need for code generation to accomplish this, the Container design will probably define the XML vocabulary (to a great degree), and thus will drive the process. But that is just syntax. So long as you design a Wiring tool that can generate an XML representation of that wiring, we should be able to bolt the two together without much work. > >Are you suggesting that we develop hardware as well as > >the software infrastruction for Outpost? > > You found me out! Yes, this is exactly what I am proposing and this is > what I and some of the developers on the Cork list have been researching > as a side project. OK. I have no problem with that. But trying to define and set hardware standards (where those don't already exist) might be a tough thing without the backing of larger players (Dallas, Systronix/aJile, PIC, etc.). So long as it stays a "side project" to the Outpost Container development. Trying to integrate all of these efforts into one will make the whole too big and unmanageable. I see that we already have 5 concurrent subprojects loosely defined: 1) Outpost Container for Embedlets (the software infrastructure) 2) Graphical Wiring Tool 3) JAPL specification and concrete implementations 4) Hardware interface standardization/development. 5) uVM It also looks like we are naturally specializing in the areas that interest us the most as follows (same numbering as the above....and not this does not mean that you're not interested in the other areas...just a primary interest): 1) Andrzej 2) Ted 3) CORK team 4) CORK team 5) James Funny how that is shaping up. ;-) > So what was so different about the IBM XT that all of a sudden it > caused this toy market to became legitimate? Lotus 1-2-3 was the "disruptive" technology back then that caused this market/technology shift. I want Embedlets to be the 1-2-3 of the early 2000's embedded area! > Why do you say they have not succeeded? Most Java applications that use AWT > and Swing use lots of JavaBeans components and every modern Java IDE supports > graphic configuration of JavaBeans using an inspector. They have them....but they are rarely used for commercial software because the "glue" code they generate is abysmally unmaintainable. And any real app developer soon discovers that they HAVE TO maintain and change the ugly generated code. Any decent Java programmer can slap together a Swing/AWT UI just as fast using code...which IS extensible and maintainable. That is why I say it hasn't succeeded...it provides little benefit except for trivially simple applications. Graphical construction of UI's using JavaBeans for anything but simple, one-use applications is just not practical for real-world applications. Graphical creation of UI apps using IDE's was a futile attempt to take junior/intexperienced programmers and make them as productive as the expert/seniors. Problem is it doesn't work...and likely is not going to for quite some time. JB's are used for many things (I use them all the time)...so what I should have said is that they have not succeeded as a Graphical Component Assembly technology. Brill gets swamped: > Sheesh... I'm not paying attention for a couple of days, and the list fills > up! Yup...ya gotta pay attention! ;-) Some great discussion and massive traffic on the list this weekend. Awesome! Then Brill adds: > it must be able to connect to a standard telephone line Aw man! Not the aJile PPP stack thread again (subtly disguised). <grins> and: > How many of us have architecture experience from the *start*? Moi. > Personally, I love "just doing it" but I think for this one, with so many > active people working on it, we definitely need a little more structure. Given the challenges we face in marketing, adoption, constrained devices and such, "just doing it" (eg. hacking some code), plus the challenges of group- development of Open Source (mainly communications issues) will not achieve the lofty goals we set out for Outpost. A more structured approach is warranted (for all facets: design/architecture/vision, documentation, project structure, etc.) > Hmm... maybe someone needs to write up a "manifesto" or something ;) Hold that thought, Brill (from an Container architecture & vision perspective)! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: James C. <ca...@vi...> - 2003-02-02 22:15:19
|
>We don't need competent Java programmers......what we need are people that >can construct small, simple Embedlets and then wire them together. Teds going to love you now! James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Andrzej Jan Taramina > Sent: Monday, February 03, 2003 8:59 AM > To: emb...@li... > Subject: [Embedlets-developer] Re: C vs Java > > > Ted: > > > 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? > > Your comparison of C programming to the complexities of Java is an apples > and oranges comparison. > > First off....no programmer can learn enough in 3 weeks to write > good desktop > GUI-based apps or scalable server-side (J2EE/XML) solutions, > regardless of > what language they pick. To learn to be a good programmer in any > language > (if it's your first) takes years, as you discovered. But this is > not a valid > comparison to a proposed Embedlet programming environment. You won't > need Swing, XML parsing, most Java libraries, large inheritance > hierarchies, > UML or all the rest. Since the subset of Java that you need to > know will be so > much smaller, it might be possible to write credible Embedlets > much faster. > > The corrollary is that you can hack simple stuff together easily > in almost any > language, including Java. You can create a main() method, and > just string a > bunch of code in there to do something simple....and surprisingly > enough, it > will look almost identical (syntatically) to C code. > > If you want to write well structured, maintainable, performing complex > applications, then it's gonna take you a long time to learn how > to do that. In > Java, C or anything else for that matter. > > So if the existing embedded programmers are just hacking simple stuff, it > should be possible to provide an Outpost container that lets them > continue to > do just that...with a minimum of Java knowledge required (OO > stuff), especially > since Java and C syntax are not that far apart (if/then/else, > while, for and such > are all pretty similar). As James said, they should only have to > learn a very > small subset of the gamut of Java skills to be able to hack out Embedlets. > > As I had said in an earlier post....a good tutorial and example > should go a long > way to get them there. > > > It has been my daily experience that it takes years of > extremely hard work for > > a person to become a competent Java programmer. > > The above sentence would be even more accurate if you drop the word > "Java". ;-) > > We don't need competent Java programmers......what we need are > people that > can construct small, simple Embedlets and then wire them together. > > > > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.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 > > |
|
From: James C. <ca...@vi...> - 2003-02-02 22:01:31
|
> Have you had any sign of interest from Microchip? I went to the 3 day Microchip Masters last July and spoke extensively with their customers, their field application engineers, development staff, trainers and some of the lower management. It was a really interesting experience which really helped me understand their 'sell silicon' business. The thing that struck me is that for a technology company just how 'heavyweight' their sales and support side is. It was a real lesson. Anyhow, yes, they are interested in anything that can help them sell more silicon. I can't claim to have it 'in the bag' but I have met the right people and have pitched the case to interested ears that are now waiting for the 'demo'. What was most interesting was the interest from the FAE's. They see it as an additional sales tool to get get design wins. There seemed to be a growing feeling that the complexity of the Microchip devices, which are now starting to get bigger and more complex, is starting to outstrip the assembly origins and many FAE's are starting to get a bit frustrated - they 'just want it to work' So what I am shooting for and I have a 'in principle' agreement for this is to take a workshop as part of the Microchip Masters 2003 to demonstrate muvium ( Embedlets! ). My goal is to 'train the trainer' ie train their FAE's on muvium and have these guys onsell muvium to their customers as part of their toolbox to solve their customers problems. ie Inherit Microchips sales channel Obviously muvium has to prove itself yet but so far my goals to shape it naturally into Microchips business model is looking good. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Bruce Boyes > Sent: Monday, February 03, 2003 4:21 AM > To: emb...@li... > Subject: [Embedlets-developer] Microchip? > > > At 11:32 PM 2/1/2003 -0800, you wrote: > >From: "James Caska" <ca...@vi...> > > >Disruptive technologies are rarely (if ever) > > >adopted by the incumbents, since they have too much vested interest. > > > >Interestingly this is a key strategy for uVM. Because I am not competing > >with Microchip rather I am building a bridge for them to enter the java > >market I am hoping to get uVM to be a linecard product for Microchip and > >then for others also.. > > I thought they had already entered. Oops, I'm thinking of Ubicom, > who wrote > the almost-Java support for Javelin stamp for Parallax. > > Have you had any sign of interest from Microchip? > > Bruce > > > > > ------------------------------------------------------- > 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 > > |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 22:01:08
|
Ted: > 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? Your comparison of C programming to the complexities of Java is an apples and oranges comparison. First off....no programmer can learn enough in 3 weeks to write good desktop GUI-based apps or scalable server-side (J2EE/XML) solutions, regardless of what language they pick. To learn to be a good programmer in any language (if it's your first) takes years, as you discovered. But this is not a valid comparison to a proposed Embedlet programming environment. You won't need Swing, XML parsing, most Java libraries, large inheritance hierarchies, UML or all the rest. Since the subset of Java that you need to know will be so much smaller, it might be possible to write credible Embedlets much faster. The corrollary is that you can hack simple stuff together easily in almost any language, including Java. You can create a main() method, and just string a bunch of code in there to do something simple....and surprisingly enough, it will look almost identical (syntatically) to C code. If you want to write well structured, maintainable, performing complex applications, then it's gonna take you a long time to learn how to do that. In Java, C or anything else for that matter. So if the existing embedded programmers are just hacking simple stuff, it should be possible to provide an Outpost container that lets them continue to do just that...with a minimum of Java knowledge required (OO stuff), especially since Java and C syntax are not that far apart (if/then/else, while, for and such are all pretty similar). As James said, they should only have to learn a very small subset of the gamut of Java skills to be able to hack out Embedlets. As I had said in an earlier post....a good tutorial and example should go a long way to get them there. > It has been my daily experience that it takes years of extremely hard work for > a person to become a competent Java programmer. The above sentence would be even more accurate if you drop the word "Java". ;-) We don't need competent Java programmers......what we need are people that can construct small, simple Embedlets and then wire them together. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Jac K. <j.k...@th...> - 2003-02-02 21:44:37
|
On Sun, 2 Feb 2003, Andrzej Jan Taramina wrote: > It's like makefiles...you don't have to know how to write them to be > able to use them. But only experienced developers are able to write good ones :-) -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 21:03:59
|
Ted pointed out: > My position is that any product or tool that requires an individual to > know both computer interfacing and object oriented Java programming is > going to fail because the Embedded Java developer pool contains an > estimated <10000 members and it is growing very slowly. A good point....there are few of us on this list that can do both. > At least half the battle here is to simply acknowledge this to be a fact > and then figure out a way to work around it. If even just for the sake of > argument one accepts this position to be true, what do the possible > workaround solutions look like? From the software perspective (eg. get the hardware geeks on board), Graphical Wiring helps for simple apps. For more complex apps (which I believe there will be a demand for very quickly), the more the Outpost Container does for the user, the less a programmer will have to know of Java. One way to help this process along is to have a few examples of custom embedlets that ship with the Outpost distribution. If a hardware hacker can sling C/Asm, I would be willing to bet they would be able to look at a simple example Embedlet and some documentation on what the container provides you, along with a good tutorial that walks you through the process of creating/modifying an Embedlet, and then hack that code to do something useful. Java can be written in a pure procedural style, ignoring almost all OO concepts (just like C) if you want to (not adviseable, but it is doable). I think a good example/tutorial would go a long way to helping this issue...and should be part of our deliverables very early on. From the hardware perspective, the only thing I can think of is having a company like Systronix provide some standardized connectors and components so that the assembly of the sensors and components is more akin to slotting in boards in a PC or wiring CAT5/Serial/Parallel cables. That would make the hardware assembly less forbidding. I think designing and marketing such hardware is beyond the scope of the Embedlet list/group/project though. But if someone wants to get into the fabrication business, it might be a viable business model. Any other thoughts? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 21:03:56
|
Ted > Ant is still mostly just Java and it targets a market that consists of > millions of existing Java programmers. It takes a Java programmer much > less than a day to start using Ant because they can easily leverage their > exiting Java skills when learning how to use it. Ant has very little to do with Java (despite being written in it and having good Java build support). It has everything to do with XML. To learn to use Ant you have to be proficient in XML, not Java. It's extensible nature makes it a very powerful tool, since we could write Ant targets to handle all sorts of platform specific linking tasks (eg. JEMBuilder invocation, uVM compiling and more). Ant build files can be created to be quite flexible and automated (huge builds are controlled with Ant very successfully). I've used Ant to control many non- Java based processes. Note...I am not suggesting that Embedlet users would write the Ant build files...that would be the responsibility of the Embedlet development team. But with a bit of documentation (primarily command line and properties file options), users could easily use Ant to build embedlets and whole Outpost Container-based applications. It's like makefiles...you don't have to know how to write them to be able to use them. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 21:03:51
|
James elaborates on small PIC's: > muvium's minimal footprint is 4K flash 368 byte RAM device (PIC16F87) and > runs up to 64K Flash + 64K RAM *guestimate for PIC18F8720 device. The > first device available now being the PIC16F877A at 8K Flash 368byte RAM ( > 4k RAM extended mode real soon) > > This is exactly what I am shooting for. To ensure that embedlets can run > on the muvium minimal platform so that java/Embedlets is a one-stop-shop > single development plaform for the full range of applications and that > there is no reason or need on the basic of cost or otherwise to drop out > to alternative languages/devices to handle the last point in the wide-fan > application chain. We can try, but I'm not sure that a container-based implementation, even a minimal one, will be able to be shoehorned into a 4K flash, 368 byte RAM device. The event queues could easily grow beyond the RAM in even a trivial embedlet implementation. 64k/64K should be definitely doable. Quite a challenge you have set for us, James! I'm willing to try...but no promises. James then elaborates on how to resolve the training issues Ted brought up: <snip some good stuff> > Sounds like a good 'co-operative' open source project to me! The key will be to use design/archtiecture best practices such as encapsulation, layering, modularity, black-boxing and the like, so that each segment can contribute to the project (be they wrappered PIC asm code with a JAPL interface, or java-based Embedlets, or Protocol/Transport Communications Adapters) yet still have all the pieces be able to work smoothly together. Yup....not a bad approach! I like it....it would be doable with my current architectural ideas. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 18:47:28
|
Jac Kersing wrote:
> On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote:
>
>>This is a feature that's been worked upon.
>
> Any information on when it will be ready?
In opensource? A date? ;-)
If it's an important point for you, I'll bump it's priority.
>>There are errors in the above, because you are mixing tools that are not
>>the same thing.
>
> That's intentionaly, it provokes response :-)
;-P
That's a typical opensource mantra:
- bad ideas with bad code don't attract anybody.
- good ideas with good code attract users.
- good ideas with bad code attract developers.
>> - Openoffice here is a wordprocessor and a vector drawing program.
>> - Docbook is a file format
>> - Forrest is a publishing tool
>>
>>One could use all of them if he wanted: people are working on a
>>OO->Docbook filter, and Forrest can quite easily work with DocBook.
>
> OO is not able to handle DocBook and a filter will never be able to do a
> perfect job. To write documents with a DocBook DTD one needs an editor
> accepting a generic DTD or a specialized DocBook editor.
I agree.
>>Forrest as a publishing system has no rivals in the above comparison.
>
> ...
>
>> - simplified docbook (almost there)
>
> Ok, that sounds good, any ETA? Because we're looking at a lot of 'not yet
> ready' components already and I'm hestitant to start using tools that
> have not been proven yet. This project is challenging without our need to
> worry about tools.
I'd not suggest to use Docbook unless there's a compelling reason. The
stylesheet is there, but not yet tested extensively.
As for Forrest, the tool is really Apache Cocoon, that is more than
proven. Forrest is an application built on Cocoon, and used to build
many Apache websites.
>> - SVG (automatic rendering to SVG)
>
> And rendering SVG to PDF???
In the pages they can automatically render as PNG.
FOP is capable of rendering to PDF too IIRC, I can enable it.
>>It has only one issue: no editor.
>>Solution: make Forrest accept openoffice files as a source of content.
>>Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add
>>this kind of functionality.
>
> That would require creating a translation for every OpenOffice tag to an
> equivalent tag for the publishing format. I'm not sure this is an efford
> we should start, writing this kind of xslt stylesheet is a project itself.
Not really. I did it for HTML and it's quite easy. The fact is that we
don't support every HTML tag. We only support the semantical ones, not
the presentational ones. Same would be with OO.
>>The problem of the CVS diffs remains though, since diffing binaries file
>>is not possible, and diffs of the xml format of OpenOffice sucks badly.
>
> That was to be expected. However, StarOffice includes functions to merge
> changes different people made into a master document. A quick search in
> the OpenOffice help suggests it is supported as well... (See help index:
> Version management)
I find CVS diffs to be really better because of the way CVS works with
multiple committs, merges, etc.
>>Currently Forrest is able to use html files as input, so using a simple
>>html editor is another option. The html DTD doesn't suck that much, and
>>decent editors make decent html source.
>
> Not decent are:
> Word, Frontpage, MacroMedia tools and a lot more.
>
> Just tried the OpenOffice (StarOffice 6 in my case) html mode and it
> actually didn't do as badly as I feared it would. The html code was
> reasonable clean and might even conform to a DTD. :-)
For Forrest consumption it doesn't need to conform, we pass it through
jtidy.
>>Basically, it all boils down to the editor and the format it saves in.
>>AbiWord for example saves in docbook, but deosnt' have sections and no
>>tables :-(
>
> An editor without tables and sections won't work. Scrap Abiword, at least
> for the moment.
I reckoned.
>>Any further suggestion about editors and formats they save in?
I use Mozilla composer, btw.
> Nope, may-be one of the other participants????????
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Jac K. <j.k...@th...> - 2003-02-02 17:29:03
|
On Sun, 2 Feb 2003, Nicola Ken Barozzi wrote: > This is a feature that's been worked upon. Any information on when it will be ready? > There are errors in the above, because you are mixing tools that are not > the same thing. That's intentionaly, it provokes response :-) > - Openoffice here is a wordprocessor and a vector drawing program. > - Docbook is a file format > - Forrest is a publishing tool > > One could use all of them if he wanted: people are working on a > OO->Docbook filter, and Forrest can quite easily work with DocBook. OO is not able to handle DocBook and a filter will never be able to do a perfect job. To write documents with a DocBook DTD one needs an editor accepting a generic DTD or a specialized DocBook editor. > Forrest as a publishing system has no rivals in the above comparison. ... > - simplified docbook (almost there) Ok, that sounds good, any ETA? Because we're looking at a lot of 'not yet ready' components already and I'm hestitant to start using tools that have not been proven yet. This project is challenging without our need to worry about tools. > - SVG (automatic rendering to SVG) And rendering SVG to PDF???? > It has only one issue: no editor. > Solution: make Forrest accept openoffice files as a source of content. > Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add > this kind of functionality. That would require creating a translation for every OpenOffice tag to an equivalent tag for the publishing format. I'm not sure this is an efford we should start, writing this kind of xslt stylesheet is a project itself. > The problem of the CVS diffs remains though, since diffing binaries file > is not possible, and diffs of the xml format of OpenOffice sucks badly. That was to be expected. However, StarOffice includes functions to merge changes different people made into a master document. A quick search in the OpenOffice help suggests it is supported as well... (See help index: Version management) > Currently Forrest is able to use html files as input, so using a simple > html editor is another option. The html DTD doesn't suck that much, and > decent editors make decent html source. Not decent are: Word, Frontpage, MacroMedia tools and a lot more. Just tried the OpenOffice (StarOffice 6 in my case) html mode and it actually didn't do as badly as I feared it would. The html code was reasonable clean and might even conform to a DTD. :-) > Basically, it all boils down to the editor and the format it saves in. > AbiWord for example saves in docbook, but deosnt' have sections and no > tables :-( An editor without tables and sections won't work. Scrap Abiword, at least for the moment. > Any further suggestion about editors and formats they save in? Nope, may-be one of the other participants???????? Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Bruce B. <bb...@sy...> - 2003-02-02 17:21:09
|
At 11:32 PM 2/1/2003 -0800, you wrote: >From: "James Caska" <ca...@vi...> > >Disruptive technologies are rarely (if ever) > >adopted by the incumbents, since they have too much vested interest. > >Interestingly this is a key strategy for uVM. Because I am not competing >with Microchip rather I am building a bridge for them to enter the java >market I am hoping to get uVM to be a linecard product for Microchip and >then for others also.. I thought they had already entered. Oops, I'm thinking of Ubicom, who wrote the almost-Java support for Javelin stamp for Parallax. Have you had any sign of interest from Microchip? Bruce |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 17:15:17
|
James raises a good point: > I think it is the real-time nature of Embedded programming that puts > people in a bit of a spin. I've been thinking about this. Creation of a container implementation that can support real-time (in the strict, embedded sense of the word) is a very difficult task. My current thinking is that Embedlets won't be able to support pure real time (with the millisecond response times and prioritizations this requires) in it's first few incarnations, and that this would be too ambitious a goal for us to try and tackle out of the gate. Thoughts? > only need to look back at the Nutty Threading problems to understand that > simulataneous processes are confusing. That was primarily confusing due to the bug that is buried in the aJile runtime. Though threads are confusing to many. > With the combinatorial problem of > so many things going on at once, embedded programmers first instinct is to > reduce the number of possible things that can be wrong. Compared to modern server side containers, embedded controllers can be very simple, with much less simultaneous stuff going on that in something like an EJB or Servlet container. I see the push to simplify as something that happens in all levels of software development, from embedded to enterprise. Part of the problem solving and debugging process. I think Ted hit a nerve, noting that many software guys are afraid of hardware. Which is amusing, since so many of them have no problem building and reconfiguring their PC hardware. Diff'rent strokes I suppose. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-02-02 17:15:14
|
James replies to Bruce: > All I can say is that we have a lot in common. Looking forward to those > drinks someday :-) Ditto. JavaOne sounds good! I'm hoping some of my session proposals get accepted, in which case I'll have a forum to discuss embedlets to a large audience as well. I'm also presenting to the Toronto Java Users Group this Tuesday....MGDP (embedded GPS/Systronix project) and ebXML topics. Will probably mention the embedlets project as well in passing. Brill said he might drop by....so two members of this list might actually get to meet! ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 14:46:05
|
Jac Kersing wrote:
> On Sun, 2 Feb 2003, Ted Kosan wrote:
>
>>What do other people think of the possibility of using Forrest for our
>>documentation needs?
>
> First impression, very nice. However I do have some questions:
> - Is Forrest able to handle large multi chapter documents? All the
> webpages have the 'printer friendly' button, but that's only that single
> page and I would like our pdfs to contain all chapters, not one pdf for
> each chapter.
This is a feature that's been worked upon.
> - What would we use to edit the documents and diagrams? I'm not
> particulary fond of having to edit XML files when creating documentation.
> The tags tend to distract from the contents... (would that be one of the
> reasons the word userbase outnumbers the TeX [or insert your favorite
> here] userbase??)
>
> BTW, my second concern is valid for docbook as well. XmlMind XML Editor
> enables more or less wysiwyg editing, but it's not OpenOffice.
I understand this concern. Currently we support SVG for diagrams, and
Openoffice can
> The options so far are (if I remember correctly):
> * OpenOffice
> + free full blown office suite with editor and graphics module
> + wysiwyg
> = XML based storage, however with proprietary DTD
> - large (a lot of disk space and not very fast)
> - no pdf creation without commercial plugins (afaik)
> * DocBook
> + XML standard documents use whatever editor you like
> + output to pdf, html, rtf and more
> - no real wysiwyg tools for editing
> - no standardized graphics input format
> * Forrest
> + XML documents
> + ouput to HTML and pdf
> + standard graphics format????
> - no wysiwyg editors
>
> Please help by adding to/correcting this list...
There are errors in the above, because you are mixing tools that are not
the same thing.
- Openoffice here is a wordprocessor and a vector drawing program.
- Docbook is a file format
- Forrest is a publishing tool
One could use all of them if he wanted: people are working on a
OO->Docbook filter, and Forrest can quite easily work with DocBook.
Let's see if we can get the best of these tools:
Forrest as a publishing system has no rivals in the above comparison.
It can not publish sites that use these file formats:
- Forrest document DTD
- html
- wiki format
- simplified docbook (almost there)
- SVG (automatic rendering to SVG)
It has only one issue: no editor.
Solution: make Forrest accept openoffice files as a source of content.
Forrest is based on Cocoon, and with Apache Cocoon it's very easy to add
this kind of functionality.
The problem of the CVS diffs remains though, since diffing binaries file
is not possible, and diffs of the xml format of OpenOffice sucks badly.
Currently Forrest is able to use html files as input, so using a simple
html editor is another option. The html DTD doesn't suck that much, and
decent editors make decent html source.
Basically, it all boils down to the editor and the format it saves in.
AbiWord for example saves in docbook, but deosnt' have sections and no
tables :-(
Any further suggestion about editors and formats they save in?
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Jac K. <j.k...@th...> - 2003-02-02 13:49:17
|
On Sun, 2 Feb 2003, Ted Kosan wrote: > What do other people think of the possibility of using Forrest for our > documentation needs? First impression, very nice. However I do have some questions: - Is Forrest able to handle large multi chapter documents? All the webpages have the 'printer friendly' button, but that's only that single page and I would like our pdfs to contain all chapters, not one pdf for each chapter. - What would we use to edit the documents and diagrams? I'm not particulary fond of having to edit XML files when creating documentation. The tags tend to distract from the contents... (would that be one of the reasons the word userbase outnumbers the TeX [or insert your favorite here] userbase??) BTW, my second concern is valid for docbook as well. XmlMind XML Editor enables more or less wysiwyg editing, but it's not OpenOffice. The options so far are (if I remember correctly): * OpenOffice + free full blown office suite with editor and graphics module + wysiwyg = XML based storage, however with proprietary DTD - large (a lot of disk space and not very fast) - no pdf creation without commercial plugins (afaik) * DocBook + XML standard documents use whatever editor you like + output to pdf, html, rtf and more - no real wysiwyg tools for editing - no standardized graphics input format * Forrest + XML documents + ouput to HTML and pdf + standard graphics format???? - no wysiwyg editors Please help by adding to/correcting this list... Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Ted K. <tk...@ya...> - 2003-02-02 13:05:34
|
Nicola, > Take a look at this too. > http://xml.apache.org/forrest/ After spending some time studying the information on the Forrest site it does not take one long to see that the site does an exceptional job of marketing Forrest's virtues. In my opinion, wrapping the Embedlet project's documentation inside an XML file format was always a must but I had not given too much thought on how to make this information available to the public aside from placing periodic snapshots of it on a website or having them pull it from the CVS. If the periodic CVS snapshot technique is considered to be a country lane that can be used to publish CVS contents to the web, then in comparison Forrest appears to provide a 6 lane highway that can pump the contents in a CVS to the web in a wide variety of flexible formats on an on-demand basis. I also like Forrest's Documentation DTDs better than OpenOffice's DTDs because they appear to be optimized for use with software project documentation while OpenOffice's DTDs are much more generic. Finally, I had been wondering how we were going to put together the Embedlets main website and how much of a pain it was going to be to maintain it. If we decide to go with something like Forrest then a lot of hard work has already been done for us and we would have a much higher quality website on day one then we could ever achieve with a home grown website. What do other people think of the possibility of using Forrest for our documentation needs? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: James C. <ca...@vi...> - 2003-02-02 12:39:55
|
>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 > > |
|
From: Ted K. <tk...@ya...> - 2003-02-02 11:47:47
|
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 |
|
From: James C. <ca...@vi...> - 2003-02-02 11:19:12
|
>The same thing will happen with embedded Java, especially if forward looking >companies like Dallas back it and provide plug-in drivers rather than >publish a little vague 6800 code and expect everyone to create their own >bit- banger routines. But they didn't really back it in that way.. they created there own new hardware (iButtons) and then new java drivers for that hardware. Quite different than showing how to interface to other companies hardware. James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Christopher Smith > Sent: Sunday, February 02, 2003 8:10 PM > To: emb...@li... > Subject: RE: [Embedlets-developer] RE: W hy Embedded Java is floundering > > > Ted, > > I agree with your analysis of the current state of affairs, > however, 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, especially if > forward looking > companies like Dallas back it and provide plug-in drivers rather than > publish a little vague 6800 code and expect everyone to create their own > bit- banger routines. > > Ted, > > Great diagram Ted and I completely agree. > > A = Embedded Systems Programmers > B = Enterprise Systems Programmers > C = A + B > > Looks like a fantastic opportunity for C to create a bridge for A and B to > work together. I don't think A will(or wants to) learn B anytime > soon and I > don't think B will(or wants to) learn A anytime soon BUT I think we are on > the right track with the legacy wrapper technologies. It makes > sense and has > historical precendent. > > (A) takes their interfaces and driver experitise and wrap them into Java > wrappers compliant with the JAPL interface. They then Register their new > platform dependent JAPL object with Embedlets.source forge and get credit > for moving the world to a better place. > > (B) takes their java language and abstract cleverness and wrap up their > idea's as generic re-useable Embedlets and then Register their > new Embedlet > with Embedlets.source forge and get credit for moving the world > to a better > place. > > (C) contribute by creating the Embedlets specification and reference > implementation framework in the first place and also go about the business > of writing the cork abstract versions of JAPL libraries which over time > replace the platform dependent versions of the JAPL libraries. > > > Then A or B or C use Ted's now very FAMOUS! graphical wiring tool , or an > XML editor ;-) , and drag and drop Embedlets and JAPL components to create > entire interconnected systems ranging from the latest tamogotchi > through the > weather bureau's initiative to record the temperature of every square > centimeter of the planet. > > Sounds like a good 'co-operative' open source project to me! > > > 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 6:48 PM > > To: emb...@li... > > Subject: [Embedlets-developer] RE: W hy Embedded Java is floundering > > > > > > Bruce, > > > > >>So, after working extremely hard for years to > > >>help increase the size of the Embedded Java developer > > >>pool I can confidently state that it is going to > > >>happen *very* slowly and it is going to be an > > >>uphill battle every centimeter of the way. > > >>I now know the reasons for this but we do not need > > >>to go into them here. > > > > > > "All" it would take to break through this inertia is some very > > compelling > > > applications.[snip] > > > > Here is the reason that Embedded Java has floundered in the > > marketplace since > > it was introduced in the mid 1990s: > > > > http://tkosan.javadevices.org/misc/embeddedjava/flounder.jpg > > > > Even without the help of very compelling applications Embedded > > Java is more > > than compelling enough already. It is not compellingness that is the > > constraint here, it is the extreme difficulty of becoming skilled in 2 > > extremely demanding disciplines in order to us it. > > > > > > > > > But what about the success of tools like Ant that *do* require > > people to > > > think and program in new ways? The secret here, I think, is > > that Ant meets > > > a need which is not addressed by any other solution. In other > > words, it's > > > very compelling. > > > > Ant is still mostly just Java and it targets a market that > > consists of millions > > of existing Java programmers. It takes a Java programmer much > > less than a day > > to start using Ant because they can easily leverage their exiting > > Java skills > > when learning how to use it. > > > > My position is that any product or tool that requires an > > individual to know > > both computer interfacing and object oriented Java programming is > > going to fail > > because the Embedded Java developer pool contains an estimated > > <10000 members > > and it is growing very slowly. > > > > At least half the battle here is to simply acknowledge this to be > > a fact and > > then figure out a way to work around it. If even just for the > > sake of argument > > one accepts this position to be true, what do the possible > > workaround solutions > > look like? > > > > > > 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 > > > > > > > > ------------------------------------------------------- > 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 > > > > > ------------------------------------------------------- > 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 > > |
|
From: Nicola K. B. <nic...@ap...> - 2003-02-02 10:44:46
|
Brill Pappin wrote: > Hey, cool... > > Really a Wiki is the way we want to go, but I think it would require hosting > on someones server... It can be done on Sourceforge too. I use a simple file-based one: http://www.krysalis.org/cgi-bin/krywiki.pl >>Take a look at this too. >>http://xml.apache.org/forrest/ >> >>It can now use plain html too or wiki syntax. >>It renders svg to png too, makes pdfs and is completely skinnable. > >>Ok, it's a shameless plug, I'm a developer there ;-P > > > Hey, it does look good... have you guys got a desktop app for it yet (or > will you)? Guess I could build one... but I'm so swamped I'd get it working, > then leave you all to deal with it ;) ;-) No desktop app, and none planned. But you can use any html editor ATM. Probably we'll support Openoffice too in the future, we'll see. -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
11 messages has been excluded from this view by a project administrator.
