Thread: [Embedlets-developer] Lego, markets, disruption, trade shows 2003, etc
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Bruce B. <bb...@sy...> - 2003-02-02 05:08:18
|
At 02:46 AM 2/1/2003 -0800, emb...@li... wrote: Ted and Bruce chat: > > >I suppose that if the graphical wiring aspect of Embedlets were done right > > >(which is an extremely high priority item on my personal goals list) then > > >it is > > >conceivable that Embedlets might prove to be a good candidate for the next > > >generation of Lego Mindstorms programming technology. > > > > Yes yes yes! > >Since our target was business usage, I am a bit hesitant about tackling Lego >Mindstorms activities with the Embedlets project. It might damage our >credibility for "real world" applications, which we first set out to address. That's OK, I wasn't suggesting that embedlets change direction. We're addressing the "advanced" Lego market for a a variety of business and technical reasons which don't have to share much - or anything - with your reasons for embedlets. >I think that while the Lego system has ties to the toy industry which may be >viewed as less than industrial strength by some the Mindstorm platform >seems to be a pretty good, low cost platform to prototype and demonstrate >new ideas, especially in wireless, location aware devices, robotics and >educational areas. Bingo! Chris has got it. >AND > >Lego could be a substantial supporter/sponsor of the Embedlet standard if it >was proven to be easy enough to deploy at the entry level. Don't hold your breath for this one. Lego is *huge* and JCX/Systronix is not even on their radar screen. We're smaller than a speck on their windshield. I don''t mean this pejoratively at all. The Lego folks probably get letters every day from well-intentioned people who think they have the greatest idea since sliced bread. Lego is very focused and exceptionally good at what they do, and they can't get too sidetracked from that. It's more likely that the eduational arm of Lego, Pitsco-Legodacta (what does that name mean?) http://www.pitsco-legodacta.com/ might be interested in some of this, but only when it's demonstrable. Great ideas are about $1 per 1000. >Come to think of it I wouldn't mind sitting at my desktop using a browser to >monitor a lego robot as it looks for the cat... This summer if all goes well, you will be able to do just that. >In addition to the existing number of Embedded Java programmers being very >small ,the rate of new programmers entering the Embedded Java group is equally >small (see #3). I would recommend the book "The Innovator's Dilemma" http://www.amazon.com/exec/obidos/tg/detail/-/0875845851/qid=1044159725/sr=8-2/ref=sr_8_2/102-9445003-7535349?v=glance&s=books Summary: you can't reasonably view a new, 'disruptive' technology from the perspective of the status quo. Well, you can, but 90% of the time you will come to the wrong conclusions. That's the premise of this book, based on case studies of new technologies with which we are all familiar. After talking to several hundred developers at trade shows the last four years, thousands of emails, etc, and being one of the "status quo" developers (C, assy, traditional 8- to 32- bit embedded micros) I have changed my ideas about marketing embedded Java. I could (a) be completely wrong, and (b) I'd rather discuss this over drinks, and (c) I don't want to share my theories with the world -- so I won't say more here. >Every piece of my input into the brainstorming process has centered around the >goal of finding markets for embedded Java through allowing *non-programmers* >(this is where 90% of the market is) to construct useful embedded system >solutions using graphic embedded component assembly techniques. Here's where Ted and I are going different directions (but still working together on some of the same goals). I just don't have a clue at the moment how to market to this group of folks, but I think it's good that Ted and others are thinking about them. >So, after working extremely hard for years to 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. There are some we are aiming at and should have shipping by summer 2003. Will they be the killer app we are seeking? Dunno. >ARE THERE MARKETS FOR EMBEDDED JAVA? > >Yes! Lots of them and they are huge! But the only way Embedded Java is going >to gain access to these markets is by not requiring them to learn how to >program in Embedded Java. 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. >Here are some low hanging fruit markets that graphic assembly Embedlets has >access to: > >- PIC programmers (huge group of non-Java developers). >- 8051 programmers (huge group non-Java developers). >- AVR programmers (huge group of non-Java developers). >- PLC programmers (huge group of non-Java developers). >- Non-Programmer IT personnel (millions of members). >- Lego Mindstorms programmers (huge group of non-Java programmers). >- etc. Dinner sometime is the best place to get me to discuss this. I don't share the same perspective. But I could be wrong. I'll go back to lurking now, for a while, at least. One parting thought: Get something working ASAP and get it into the hands of users. Almost every time we have done so, the users have led us in an unexpected direction. You just can't get very far theorizing, you have to implement and then listen to what people say, and interpret that into what they mean, then try to deliver that. Then keep iterating until you get there. See this book: http://www.amazon.com/exec/obidos/tg/detail/-/0471292524/qid=1044161150/sr=1-1/ref=sr_1_1/102-9445003-7535349?v=glance&s=books Or put another way "the difference between theory and practice, while small in theory, is large in practice". There are a number of high profile embedded companies I've been more or less following who have each burned through upwards of $50 million in venture funding and still have no clear market or customer base. They've had several detailed roadmaps in the last five years. Tons of PR and glitzy marketing. Problem was, no one wanted to go where they were leading. It's interesting and potentially educational to try to understand where they failed and why. On the other hand look at Rational and TogetherSoft. Why have they succeeded so well and been able to cash out very profitably even in a down economy? (More dinner topics). So one really, final, parting shot. The big tradeshows for us are ESC West in SFO April 23-25: http://cmp.iconvention.com/sf/v33/index.cvn?id=10008&stab=2 and JavaOne also in SFO, June 10-13: http://servlet.java.sun.com/javaone/sf2003/home/index.en.jsp We have booths reserved at both the above. We might also do the embedded east show in BOS Sep 15-18 http://esconline.com/boston/ So I'd encourage you all to try to have something to show at each of these. We can discuss providing some space in our booth when the time gets closer and the product gets "realer". Let me know if there is anything reasonable Systronix can do to help. For now, we'll provide some of the hardware blocks for you to wrap code around. Bruce |
|
From: James C. <ca...@vi...> - 2003-02-02 05:20:33
|
Bruce, All I can say is that we have a lot in common. Looking forward to those drinks someday :-) James Caska http://www.muvium.com 'Java Bred for Embedded' > -----Original Message----- > From: emb...@li... > [mailto:emb...@li...]On Behalf Of > Bruce Boyes > Sent: Sunday, February 02, 2003 4:08 PM > To: emb...@li... > Subject: [Embedlets-developer] Lego, markets, disruption, trade shows > 2003, etc > > > At 02:46 AM 2/1/2003 -0800, > emb...@li... wrote: > Ted and Bruce chat: > > > > >I suppose that if the graphical wiring aspect of Embedlets > were done right > > > >(which is an extremely high priority item on my personal > goals list) then > > > >it is > > > >conceivable that Embedlets might prove to be a good > candidate for the next > > > >generation of Lego Mindstorms programming technology. > > > > > > Yes yes yes! > > > >Since our target was business usage, I am a bit hesitant about > tackling Lego > >Mindstorms activities with the Embedlets project. It might damage our > >credibility for "real world" applications, which we first set > out to address. > > That's OK, I wasn't suggesting that embedlets change direction. We're > addressing the "advanced" Lego market for a a variety of business and > technical reasons which don't have to share much - or anything - > with your > reasons for embedlets. > > > >I think that while the Lego system has ties to the toy industry > which may be > >viewed as less than industrial strength by some the Mindstorm platform > >seems to be a pretty good, low cost platform to prototype and demonstrate > >new ideas, especially in wireless, location aware devices, robotics and > >educational areas. > > Bingo! Chris has got it. > > >AND > > > >Lego could be a substantial supporter/sponsor of the Embedlet > standard if it > >was proven to be easy enough to deploy at the entry level. > > Don't hold your breath for this one. Lego is *huge* and JCX/Systronix is > not even on their radar screen. We're smaller than a speck on their > windshield. I don''t mean this pejoratively at all. The Lego > folks probably > get letters every day from well-intentioned people who think they > have the > greatest idea since sliced bread. Lego is very focused and exceptionally > good at what they do, and they can't get too sidetracked from that. > > It's more likely that the eduational arm of Lego, Pitsco-Legodacta (what > does that name mean?) http://www.pitsco-legodacta.com/ might be > interested > in some of this, but only when it's demonstrable. Great ideas are > about $1 > per 1000. > > >Come to think of it I wouldn't mind sitting at my desktop using > a browser to > >monitor a lego robot as it looks for the cat... > > This summer if all goes well, you will be able to do just that. > > >In addition to the existing number of Embedded Java programmers > being very > >small ,the rate of new programmers entering the Embedded Java > group is equally > >small (see #3). > > I would recommend the book "The Innovator's Dilemma" > http://www.amazon.com/exec/obidos/tg/detail/-/0875845851/qid=10441 > 59725/sr=8-2/ref=sr_8_2/102-9445003-7535349?v=glance&s=books > > Summary: you can't reasonably view a new, 'disruptive' technology > from the > perspective of the status quo. Well, you can, but 90% of the time > you will > come to the wrong conclusions. That's the premise of this book, based on > case studies of new technologies with which we are all familiar. > > After talking to several hundred developers at trade shows the last four > years, thousands of emails, etc, and being one of the "status quo" > developers (C, assy, traditional 8- to 32- bit embedded micros) I have > changed my ideas about marketing embedded Java. I could (a) be completely > wrong, and (b) I'd rather discuss this over drinks, and (c) I > don't want to > share my theories with the world -- so I won't say more here. > > >Every piece of my input into the brainstorming process has > centered around the > >goal of finding markets for embedded Java through allowing > *non-programmers* > >(this is where 90% of the market is) to construct useful embedded system > >solutions using graphic embedded component assembly techniques. > > Here's where Ted and I are going different directions (but still working > together on some of the same goals). I just don't have a clue at > the moment > how to market to this group of folks, but I think it's good that Ted and > others are thinking about them. > > >So, after working extremely hard for years to 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. There are some we are aiming at and should have shipping by > summer 2003. Will they be the killer app we are seeking? Dunno. > > >ARE THERE MARKETS FOR EMBEDDED JAVA? > > > >Yes! Lots of them and they are huge! But the only way Embedded > Java is going > >to gain access to these markets is by not requiring them to learn how to > >program in Embedded Java. > > 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. > > >Here are some low hanging fruit markets that graphic assembly > Embedlets has > >access to: > > > >- PIC programmers (huge group of non-Java developers). > >- 8051 programmers (huge group non-Java developers). > >- AVR programmers (huge group of non-Java developers). > >- PLC programmers (huge group of non-Java developers). > >- Non-Programmer IT personnel (millions of members). > >- Lego Mindstorms programmers (huge group of non-Java programmers). > >- etc. > > Dinner sometime is the best place to get me to discuss this. I > don't share > the same perspective. But I could be wrong. > > I'll go back to lurking now, for a while, at least. One parting thought: > > Get something working ASAP and get it into the hands of users. > Almost every > time we have done so, the users have led us in an unexpected > direction. You > just can't get very far theorizing, you have to implement and then listen > to what people say, and interpret that into what they mean, then try to > deliver that. Then keep iterating until you get there. See this book: > http://www.amazon.com/exec/obidos/tg/detail/-/0471292524/qid=10441 61150/sr=1-1/ref=sr_1_1/102-9445003-7535349?v=glance&s=books Or put another way "the difference between theory and practice, while small in theory, is large in practice". There are a number of high profile embedded companies I've been more or less following who have each burned through upwards of $50 million in venture funding and still have no clear market or customer base. They've had several detailed roadmaps in the last five years. Tons of PR and glitzy marketing. Problem was, no one wanted to go where they were leading. It's interesting and potentially educational to try to understand where they failed and why. On the other hand look at Rational and TogetherSoft. Why have they succeeded so well and been able to cash out very profitably even in a down economy? (More dinner topics). So one really, final, parting shot. The big tradeshows for us are ESC West in SFO April 23-25: http://cmp.iconvention.com/sf/v33/index.cvn?id=10008&stab=2 and JavaOne also in SFO, June 10-13: http://servlet.java.sun.com/javaone/sf2003/home/index.en.jsp We have booths reserved at both the above. We might also do the embedded east show in BOS Sep 15-18 http://esconline.com/boston/ So I'd encourage you all to try to have something to show at each of these. We can discuss providing some space in our booth when the time gets closer and the product gets "realer". Let me know if there is anything reasonable Systronix can do to help. For now, we'll provide some of the hardware blocks for you to wrap code around. 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: Ted K. <tk...@ya...> - 2003-02-02 07:48:07
|
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 |
|
From: James C. <ca...@vi...> - 2003-02-02 08:19:27
|
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 > > |
|
From: Christopher S. <cs...@oo...> - 2003-02-02 09:09:09
|
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 |
|
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: 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 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: 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 |
