Duet is Dead?
rynando
Posts: 68
<rant>
So there've been zero posts in the duet forum for close to two months now. Is Duet dead or what? I'm interested in it as I'd like to write modules in Java however I'm not spending some serious $$$ for something that might be *cough* bug-laden and has no community surrounding it.
I think AMX might want to consider making Duet either free or charging something similar to what MS charges for Visual Studio (~$300). How else are they ever going to get people using it? Also, a free trial would do wonders for me. Again, I and/or my employer don't want to spend a bunch of money (compared to what other's charge for much nicer IDEs) on a license for something that I never end up using because it functions poorly and has zero support from a non-existent user base.
Seriously, Duet is a great idea. The Netlinx language is very, very painful for programmers who have Java/C#/(Insert OOP Language Here) backgrounds. I realize that it "gets the job done" however I feel compelled to don my father's 1980's vintage "Member's Only" jacket every time I use it. It?s archaic compared to modern languages and is very painful for programmers who are switching back and forth from C# (for example) to Netlinx.
How long do you think it?s going to be until the evil-C company lets people start writing code in .NET languages? Not long I?d imagine. I can write .NET apps for my cell phone . . . I don?t think it?s a stretch to picture Cr*ptron running some variant of the .NET compact framework on their products. When they do look out because they?re opening up their product the legions of programmers out there who can write high-quality, modern code in at least one of the .NET languages. Guess what, I?d take a super hard look at it.
The high pricing of this "exciting" new product is exactly the opposite of what software companies do when they want something to catch on. They usually give a beta version of the product away (excitement building, bugs/feature requests being reported) followed by a free trial of the 1.0 release (more bugs reported and more positive comments resonating throughout the community, bosses being sold on how great the thing is) and then a reasonable price for what boils down to, in my understanding of it, an Eclipse module.
The lame pricing of this thing almost makes me think that AMX doesn?t want people to use it which furthers my distrust of it and is keeping me from purchasing it. I hope AMX proves me wrong and starts either giving this thing away or at least begins offering a free trial download.
Ryanado
</rant>
So there've been zero posts in the duet forum for close to two months now. Is Duet dead or what? I'm interested in it as I'd like to write modules in Java however I'm not spending some serious $$$ for something that might be *cough* bug-laden and has no community surrounding it.
I think AMX might want to consider making Duet either free or charging something similar to what MS charges for Visual Studio (~$300). How else are they ever going to get people using it? Also, a free trial would do wonders for me. Again, I and/or my employer don't want to spend a bunch of money (compared to what other's charge for much nicer IDEs) on a license for something that I never end up using because it functions poorly and has zero support from a non-existent user base.
Seriously, Duet is a great idea. The Netlinx language is very, very painful for programmers who have Java/C#/(Insert OOP Language Here) backgrounds. I realize that it "gets the job done" however I feel compelled to don my father's 1980's vintage "Member's Only" jacket every time I use it. It?s archaic compared to modern languages and is very painful for programmers who are switching back and forth from C# (for example) to Netlinx.
How long do you think it?s going to be until the evil-C company lets people start writing code in .NET languages? Not long I?d imagine. I can write .NET apps for my cell phone . . . I don?t think it?s a stretch to picture Cr*ptron running some variant of the .NET compact framework on their products. When they do look out because they?re opening up their product the legions of programmers out there who can write high-quality, modern code in at least one of the .NET languages. Guess what, I?d take a super hard look at it.
The high pricing of this "exciting" new product is exactly the opposite of what software companies do when they want something to catch on. They usually give a beta version of the product away (excitement building, bugs/feature requests being reported) followed by a free trial of the 1.0 release (more bugs reported and more positive comments resonating throughout the community, bosses being sold on how great the thing is) and then a reasonable price for what boils down to, in my understanding of it, an Eclipse module.
The lame pricing of this thing almost makes me think that AMX doesn?t want people to use it which furthers my distrust of it and is keeping me from purchasing it. I hope AMX proves me wrong and starts either giving this thing away or at least begins offering a free trial download.
Ryanado
</rant>
0
Comments
Duet is too expensive and AMX doesn't even give a chance to "try & buy".
Why only "qualified"? Just because I didn't take Java or know any Java, then I shouldn't buy it? That seems silly...
Having said that, I too would like to use some of the advantages of Java when programming AMX systems. I work a lot in NetBeans. I often find myself wanting to port something over to what I'm doing in AMX but don't have a good way to make that happen.
The cost is too prohibitive. I'm not blaming AMX or asking them to eat a huge cost so, as Dave pointed out, a few hundred of us can have some fun.
Which gets to a larger point. AMX had to have known what the end user price point would have to be. Why would AMX go down this path if it was pretty obvious that it is not viable? (at least as it stands now.)
I can download NetBeans for free and write software all I want. Perhaps AMX should open up Duet so you can develope from a third-party application like NetBeans. (I think) That would eliminate the need to have a Duet development environment and effectively remove the Sun fees.
However, I am but a simple cave man an no nothing of Sun licensing fees...
If this is true and Sun's licensing fees are so high it's a wonder AMX even started down this road to begin with. There was so much hype from AMX about this thing . . . I'd be interested in knowing how many licenses they've actually sold.
Even at its current price I would probably purchase it if I knew it worked. I hate writing and debugging in Netlinx and I'm sure I'm not the only one. For me the convenience of using a modern language is worth the tax IF it works properly. I hate to say it but I don't trust AMX to produce quality software. I'm not willing to shell out $1,000 to be part of the beta-team.
I'll I've got to say is if the competition releases a product which will run .NET code halfway decent look out.
Rynando
I find that hardly unlikely. They're very committed to their symbolic language and actively discourage users from using their existing C style language.
Yes, but having access to VS does little to sell Microsoft's end user products. Duet is a tool which assists dealers in producing systems in order to sell AMX gear to customers. It's a bit rough having to pay extra as an inducment to sell more AMX gear...
For any faults they may have they still do a ** MUCH ** better job than a certain other company, believe me.
I think MS sells VS for what it does so it can continue to sell uber expensive server product licenses. If the development tools for their server products are out of reach, people aren?t going to buy the server products. I actually doubt if MS makes any significant money off any of its development tools. Most MS shops don't pay for VS anyway. It's bundled with other license packages. On the flip side, have you priced SQL Server 2005 on an eight-way system . . .
Same thing with AMX. AMX shouldn't be trying to make money selling dealers software development tools. They should be producing high quality development tools so we can keep creating compelling TP systems so they can keep selling expensive hardware products.
I can do a lot of what an AMX system can do with my Windows Mobile phone, a $100 ebay serial server, Visual Studio and an afternoon. In many ways, I can do a whole lot more with that platform then I can with a Netlinx system (databases, media playback etc). AMX needs to focus on giving its dealers the highest quality development tools they can so we can continue to keep them relevant through innovative software design.
Rynando
First, just because you can, doesn't mean you should If you really can do this in a repeatable fashion for as little money as you say, I would highly recommend you pursue this. Offering a product that you describe would appeal to the masses, especially if you could do it as cheaply as you indicate.
As for the Java costs, I believe that part of the cost of Cafe Duet is there to force a commitment on the part of the dealer to really invest time and effort into using Cafe Duet to further their business without an unbalanced need for tech support. If you are familiar with Java and you really think it will help your business grow, I would suggest you talk with your sales rep and discuss this, maybe they can workout a deal with you. The worst they can say is "No".
Just my 2 cents,
Jeff
I've seen them in action on many occasions and there's still two areas that AMX has them completely beat on.
1) The hardware is much better looking and designed around integration specs and that is important to the client. Without exception, every computer based solution I've seen ends up looking like a total rat's nest. These system are just not designed to be mounted in a rack and managed. (this even with rack mount CPUs) They eventually degrade to total unreliability due to the lack of wire management and the fact that you end up having a big box CPU with a bunch of black boxes connected with CAT5 cables.
2) Hardware reliablilty. I very rarely have to reboot a Netlinx master. It doesn't run hot. It has plenty of I/Os. (I don't need to install cards.) It is very scaleable from very small systems to very large. It's not a popular hackable thing.
You just don't need all the overhead of a PC to do this kind of stuff.
I have no doubt that there will be a viable PC based system soon. But it's just not there yet.
If they can get the manufacturers to commit to developing solid Duet modules as part of their partnership program, that would be more than good enough for most of our purposes.
I too seem to remember at Prog III class in 2003 that the idea was that you could choose to write AMX code in Netlinx, Java or a combination of both. I remember blinking at that statement thinking, "how do they intend to do that???"
I came back and began looking to get the develpment tools but was quickly suffering from Sticker Shock.
I don't know about "actively discourage"... They try very hard to stress that there's a time & place for it, and if you can write the code you need without it, then don't use it. The reason behind this is that the compiled "C-like" code requires the processor to switch out of it's native mode (for lack of a more detailed/accurate description than called for here) to execute, then switch back - which causes a performance hit. In smaller systems this is beyond imperceptable, but larger systems with gobs and gobs of S+ modules can see hiccups if they're not put together carefully.
That said, don't be surprised if you hear about a totally re-vamped language in the near future to replace or at least work more seamlessly with the symbolic one.
- Chip
I believe this statement is correct. I don't think the duet java programming was intended for the everyday veteran AMX programmer. I have talked with several people at AMX - in training and tech support and the general consensus they gave to me is that there is nothing I would normally use that that couldn't be written faster, cleaner and smaller and run more efficiently as a normal studio module instead of using java. The idea behind java was just as stated above - to give windows developers that work for hardware manufacturers a platform to write modules they were familiar with. The are some limited functions that the java modules can do, but not something we would use in our everyday programming.
I wonder if they'll come out with this language when they come out with a totally re-vamped NetLinx Studio. Maybe it won't be called that, maybe it'll be . . . "Lunar Studio" and the new language will be SunLinx.
~shudder~
I am not sure if I totally disagree, but I understand why this is the thinking. First off, there is a lot of Java functionality that has yet to be documented. I also do not think many people within AMX are familiar enough with Java to make it an efficient programming language for them.
A lot of the value of Java comes into play when you are coding a very flexible automation system. If all you are integrating with is a Theater room and the touch panel is basically a very pretty universal remote with some 2 way feedback, I would agree that NetLinx would be my language of choice for the project. On the other hand, if you have an 80 room house with every system being monitored and controlled by AMX and you have 2 or 3 programmers working on the project, I think Java provides a better base for development.
Also, it comes down to the complexity of code you are dealing with. If all you are doing is waiting for some button presses to drive events, I would definitely choose NetLinx. If you are dealing with a device that has a vast array of functionality (that is similar to one of the Duet Device types), and you need to deal with queuing, I would probably choose Java. (Especially if I did not have NetLinx code in place to handle queuing)
As for speed, in Programmer 3, we saw first hand that the speed of Java code can actually be faster than NetLinx code. There is a catch to this tho... the speed is faster within the java code itself, but when the Java code needs to interact with NetLinx code, the communication procedure tends to negate the gains of the faster java processing.
I apologize for not posting anything further in the I'm Learning Java thread, but I have been slammed the last few months with a couple of very large jobs and I have been focusing on completing them. As soon as I have them complete, I will get back to the java modules I was working on and see if I can provide some documentation to help others that are thinking about making the move. I can say that some of the philosophies behind Java have made their way into the code I am writing in NetLinx and I feel that it has made my NetLinx code better.
This is all of course just my opinion,
Jeff
I have been writing all of my systems solely in java since last October. In the beginning i was very wary that i was going to break something and or push the box to hard. Thus far i have used a lot of the features and libraries that java 1.4 offers and am happy to say they all work. I have even gone as far as to write a class for an IP controlled Christie projector on my pc in netBeans then import it into eclipse and use it without any issues on an NI. I believe there is always the right tool for the job and there have been projects that i have done much faster in NetLinx than I could have in java but I think the benifits of OOP fit the control system paradigm too well.
What are the real pros and cons of developing in java? The last time I went to class to take Programmer 3 (a few years ago) the thought was that if someone knew "netlinx" style modules then there was absolutely no advantage of developing anything in java. Is this still a true statement?
The last poster mentions programming exclusively in java over the last year - this might be good for someone that has any idea what "netBeans" or "eclipse" means. But for those of us that have not the slightest idea how to even begin writing anything in java is it worth the time to get on board and learn java even if the only type of programming ever done is Netlinx?
The more exciting part for me was seeing an entire program written in Java. Touch panel events, timelines, data to/from a device... Granted it was a VERY basic program, but all the tools are there. OOP is the way to go, in my opinion, and if I had Cafe Duet I would be hacking away right now trying to figure it out.
The problems as I see them:
* Cost
* Learning curve - basically starting everything from square one
* What will dealers think when I hand over the final code in a format they can't touch?
Forget the "who owns the code" debate for a minute and assume it is always provided unprotected. How many dealers have Java/Duet programmers to make a change if necessary? Great for me if they come back for updates/changes, bad for me if they don't want to use me in the first place because they know they get a final product in a format they can't use.
I guess for the independents that don't provide source code this is a non-issue, but for those of us that have been on the other end too often, and do provide source code, this is a concern.
I don't think there currently is an advantage to an experienced NetLinx programmer. Every Duet module I have seen in a side-by-side comparison with a NetLinx module designed to do the same job has been bloated and underperformed. That said, there are a few things Duet can do that NetLinx cannot, but so few as to be nearly inconsequential. The only advantages I see to Duet are: (1) providing a way for the manufacturer to develop a device module in Java without re-training programmers, and (2) establishing an API for automated programming environments like VA.
I also don't see any advantage to me by creating Java modules to use with a Netlinx coded system. To do that you either have to use the SNAPI protocol or design your own protocol. I view this as an unnecessary step to controlling a device.
I think the real Java advantage will be systems that are programmed entirely in Java. It avoids the whole SNAPI/homegrown protocol issue and provides an easy way to modularize code for reuse.
...though I haven't done this yet so I definitely could be wrong!
IMHO, Java is way too deep for home automation. Of course it sounds cool, but where's the value? Right now, NetLinx is bogged down with legacy syntax and and a totally obsolete compiler. I would rather see upgrading the environment to a standard C language with a standard library. Efficient, well understood and cheap. Wouldn't a two pass compiler be nice? How about one that actually tells you where the syntax error actually is, and tells you about more than one error at a time? There are lot's of compilers that run on Wind River and other embedded OSs with many tools such as editors, source code control, debuggers, etc that make development easy. Reducing the time to deliver the project to the customer should be the driving force in determining the software environment not forcing the adoption of the 'language du jour'.
Whilst the NetLinx language is far from being a portable, cross platform standard language in which to write code, I find it to fit the bill perfectly in most situations. That said I would love to be able to use certain OO features that Duet would make available, but am not willing to fork over the dollars.
I have found that the design work which went into the development of the NetLinx language was extremely sound with no notable exceptions. It is for the most part elegant, compact and extremely rapid to develop in which make it a perfect tool for creating the fast turnaround, low lead time systems most of us are required to produce.
I think very few programmers who work with the NetLinx language on a daily basis would be able to pump out systems anywhere near as quickly if they were working with ANSI C or similar. Nor would said systems be as robust as a rule. Another notable control system company seem to recognise this as they have a C compiler which is in widespread use producing the code to run on their control systems and, instead of making it available to developers, hide it behind a b@stardised, poorly developed high level C style language.
Each to their own I guess. I wouldn't go so far as to say that the NetLinx language is 'obsolete' though, I think it has its place.