It looks like Java's generics are much like C++'s templates
No, they are not. In fact, they are very different. C++ templates are heterogenious (every parameter set means a new class, hence you get lots of additional classes); Java generics are homogenious (one class serves all parameters). C++ templates' requirements for the parameters are "as they come" -- the code is simply recompiled with the new parameter classes; Java generics' parameters need to implement interfaces/extend classes if a particular method of the parameter is to be used (which is much neater from a design perspective, if you appreciate this kind of thing). The only thing in common is the first glance appearance.
The CLR together with C# completly owns Java
Yes, it is a better solution in some respects and much worse in others. Given that it was designed 5 years after Java, the first was to be expected, the second was not. It merits a look, until you realize that any advantages are only marginal, and that there is only one company that provides major products for it (like application servers) and defines its interfaces. Given the fact that the company has a long notorious history and it has standardized less than 10% of the API does not make things better. And then there is Mono that now has to rely on Wine... Ah well.
Re:JDO vs EJB Entity Beans?
on
Java Data Objects
·
· Score: 2, Informative
This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.
This feature has actually been available in older versions of Eclipse (2.0) -- I use it when necessary. You can double click on an exception trace in the console output, and it will take you to the code.
The difference in 2.1, I think, is that the places where you can click are now explicitly underlined. It is also possible that the recognition of those places has been improved. In any case, if I understand correctly, this is an old feature with better UI.
First, what you say is definitely not true. The MS features do very little to improve performance (and I do not see how removing RMI helps at all). In addition, the MS Java implementation has practically not been used for years now (it is still at the 1.1.4 level, after all) and Java is very far from being DOA.
Second, it was certainly okay for Microsoft to deliver this functionality IN ADDITION to the standard one which they omitted. They could have provided both if they wanted to. But they didn't, and it is quite clear why they didn't -- the functionality competed with their technology and that made it dangerous.
Not liking Java does not change the fact that MS acted on ulteriour motives.
Microsoft developed their own non-portable mechanism for interfacing with C/C++ and did not include JNI (the standard for doing that) in their Java distribution. They did not include RMI either, presumably because it competed directly with DCOM.
That's not "trying to adopt". That's skewing the standard to make developers tied to the Windows. They could have adhered to the requirements of the license very easily if they wanted. That's why they lost in court. That's why they developed.NET -- to have full control over the technology and make it follow their long-term strategy.
Needless to say, Mono will end up following their strategy as well due to the compatibility requirements of the community that will soon get hooked.
Heh. I do wish all that could happen by 2010. In fact, I wish that it had already happened (it could have, given enough funding).
But I just don't see it. Do you really believe that NASA can cut down its fat or that it can collect billions of dollars from alternative sources? I am not saying it is impossible, I am saying that unfortunately it won't happen. If you are realistic, you'll see that there is no chance for that at all in real life. That's just not how things work.
Yes, but Kennedy poured huge amount of money into the space program -- something simply not possible at the moment. There isn't a cold war to spur the development either.
It seems to me 2010 is a fairly unrealistic goal. First, the technology proposed has not been properly tested to put people to ride on it. To do that you need _at least_ 10 years.
Second, in order to send people, the whole 'going there and coming back' routine needs to be run a few times without a hiccup. I mean, this was done for the Moon, and a Mars mission would be far more risky.
Finally, I have no doubt that if the engineers are given sufficient resources, all of this can be done by, say, 2015. I do not think that this will simply happen, however, especially given the political situation and current fiscal policy that implies huge deficits well into the future. In fact, 2020 seems far more reasonable given the current situation.
Notice that Sun and the Liberty Aliance do NOT offer a centralized identity repository a la Passport. This is a distributed solution -- as a provider (internet store, etc.) you install an authentication server and decide yourself what other providers you can trust, so that if a user is logged in their site, he can be considered logged in yours as well (put simply).
The only requirement is that the server implements the Liberty Aliance protocol standards. I _think_ one can make an open source server that implements those standards as well.
Re:Who still uses structs? Tapestry the way to go
on
Manning's Struts in Action
·
· Score: 3, Informative
I have to disagree completely.
If you come from a Swing background, Tapestry is way more intuitive than Struts. You have components in both, and building your gui involves putting components in components, and finally into a frame (Swing) or a page (Tapestry). You don't have to care about how the JTable (Swing) or Table (Tapestry) components are implemented, you just follow the API and use them. I really don't see the similarity between this and JSP or Struts.
I think Tapestry is the only free Java framework out there that actually allows you to really build components rather than pages (as it is in most of the rest). You can build a component to edit the user preferences, for example, and it really does not matter which page or another component you put it in, how you put it in, and what the layout is. It IS Swing for the web.
It also has a lot of other things that are worth using, but for those check the Tapestry home page.
According to the survey of 104 companies in North America, the cost advantage of Windows over Linux for the four workloads ranges from 11 percent to 22 percent over a five-year period.
How can this both be a survey and record data over a 5 year period, given that we are talking about Windows 2000 here?
Just curious. Perhaps there is a logical explanation.
J2EE apps are 3 or more tier, while simple web apps running within a servlet container are almost always 2 tier only.
As such J2EE apps are more scalable, available, and reliable, especially when the app server chosen offers clustering.
On the other hand, EJBs are a definite overkill for 90% of all scenarios for web-based applications, since those features are not really necessary, hence one should make the choice carefully. The bottom line is that each approach is appropriate for certain situations.
As for J2EE complexity, the tools currently available make developing such apps a very simple process.
I just want to clarify a couple of things that seem to confuse people a lot.
Tomcat, Jetty, Resin, etc. are Servlet containers. They are designed to run web applciations built on top of servlets and JSP. They also integrate with Web servers such as Apache and IIS to optimize the serving of static or other (e.g. PHP) content.
JBoss, as well as IBM WebSphere, BEA WebLogic, Macromedia JRun, Orion, etc. are J2EE servers. They provide support for Enterprise Java Beans, as well as a lot of other technologies in J2EE, including Servlets and JSP. Some of the J2EE servers have their own internal implementation of a servlet container (e.g. Orion), while others use independent servlet containers. Comparing Tomcat to those is like comparing apples to fruits.
JBoss, in particular, comes in several different standard distribution, one of which integrates with Tomcat, and another that integrates with Jetty by default. I am sure it can be confugured to use other Servlet containers as well.
To address the main question, my personal experience is that Jetty is best for development because of its quick startup, although Tomcat is also fine as long as your development environment integrates with it well. In a production environment, I would recommend Resin and the Orion servlet container if performance is necessary. If it is not, Tomcat is okay, and the hot deploy feature in 4.x makes it a very attractive option. (I would just note that the hot deploy feature does not work in all cases, e.g. it does not work for Tapestry applications)
What's more important, however, is that the printf family of functions have no support for internationalization (e.g. different order of printing the arguments and locale support), which is a must for any contemporary app development. That essentially makes them useless for generating strings that are to be seen by the users.
Here is an example of something typical that you can do with the standard Java library:
MessageFormat.format("At {1,time} on {1,date}, there was {2} on planet {0,number,integer}.", arguments)
output: At 12:30 PM on Jul 3, 2053, there was a disturbance in the Force on planet 7.
Java may be a bit clumsier than C, but it addresses the application and enterprise developer concerns much better (especially with respect to stability and maintainablity). This is just a simple example, but it demonstrates the point.
A post that did not give a single factual argument to begin with and was so wildly incorrect does not deserve the time for a factual response. If you really want facts, why don't you start first?
And just for the record, this "Java monkey" has over 10 years of C++ experience, a number of commercial products and easily over 1 mil lines of code in that language behind his back, so it would be pretty hard to accuse him of bias.
This effect, along with rampant VM bugs, explains why use of Java doesn't increase software quality.
This has to be the most erroneos statement I have seen in a long time. Java programs tend to be an order of magnitude more stable than comparable C++ programs and are usually developed in half the time.
Which brings us to the real reason people use Java. Java programmers are cheaper, since you can hire less skilled programmers and not worry about then leaking memory all over the place or blowing away unrelated parts of memory.
First of all, Java programmers are not cheaper. On the contrary, J2EE developers tend to get some of the highest salaries in the industry.
And the real reason why people choose Java is that it allows them to concentrate on the design of the application, rather than worry about idiotic things like leaking memory, uncaught exceptions, and buffer overflows.
Java does have things to be criticized for, but this post is so much off the target, that it is sickening.
Re:Not just any art... the next generation of art!
on
Are Videogames Art?
·
· Score: 1
I apologize for the "me too" post, but I think you make an excellent point. Video games can provide dimensions that conventional art cannot.
Case in point: Planescape Torment. As another player once thoughtfully said about that game, "This is the best book that I have ever played". In a sense it is a book -- at 1,000,000 words (I believe that was the quoted number) it contains far more text than most books out there. But as in most RPGs, the incredibly engaging story is also additionally reinforced by the fact that the player/reader takes part in it, and his/her choices significantly affect the way the story develops. That leads to a much greater indentification with the main character and a much greater emotional response than a normal book can provide.
I think one phenomenon that we are becoming witnesses to is the dawn of truly interactive fiction. I think it is logical to assume that with the advent of electronic paper, that market could only grow in new and unexpected directions.
GNU Classpath and its related projects, while trying to fulfill the noble goal of creating an open source implementation of the Java Runtime Environment, has nothing to do with Litris' "predicament". Sun's JRE (and a number of others, notably the IBM's JRE) can be used freely to execute any kind of software, and is fully compatible with open source.
As the article and many people here have pointed out before, it is easily demonstratable that the whole issue is a smoke screen -- equivalent open source projects (e.g. JBoss) have never had problems with Sun.
Sun's policy in respect to Java (including the JRE) has been to provide a mechanism for the definition of standard specifications via the Java Community Process, and let players in the market provide different implementations of those specifications. The JCP is also obliged to provide a reference implementation and a compatibility testing suite to ensure that different implementations work well with each other. The whole idea is precisely to avoid vendor lock-in and to promote excellence via competition between different implementations (compare this with.NET). This policy plays very well with open source, since it allows the open source community to create competitive and highly compatible implementations of those standards. JBoss (an open source implementation of the J2EE specification) is excellent example of that.
Languages do matter. Certain language features can significantly improve productivity and the quality of the code. Especially in respect to team environments and large projects.
Case in point: Java has checked exceptions, C# does not. The extensive use of exceptions in large projects is typically a significant source of program instability if you do not have the benefit of compile time checking. This is a very simple language feature, but it makes a major programming mechanism from one that requires caution to one that is ubiquitously useful.
Even carefuly selected syntactic sugar can make the code clearer and simple and cause some boost in productivity as a result (e.g. 'foreach' in C#). Of course, badly selected syntactic sugar can have just the opposite effect -- massive confusion. I find it astonishing that in C# you can never be sure what the expression 'a.b = c' does (assignment or function call). Are the several characters that are saved from 'a.setb(c)' worth the amount of programming time that would almost certainly be lost due to misunderstandings? I very much doubt it. (although anyone who has public members probably deserves that)
So languages do matter, and even the small differences can have a big impact on the stability and maintainability of a large program.
Your example does not describe a parallel connection of units, but a serial one instead.
A simple example of parallel operation would be using your arms. Assume that your spine and legs are sufficiently strong and the weak link in your body is your arm. You can lift much greater weight using your two arms together than when using one arm only. That beats the "weakest link" limit.
The main problem with swarms is getting the power and leverage to manipulate large objects as the swarm is only as strong as it's weakest link.
I am not sure why this should be the case (if I understand what you are saying correctly). If the elements of the construction, say N robot units, are connected in parallel, then the "strength" of the construction can increase to up to N times the "strength" of a single element. Obviously that is not easy to do, but it should definitely be doable.
I agree with you completely. The X-Y method for laying out forms is an abomination. It breaks down spectacularly when i18n, l10n, and/or UI customization (e.g. font selection) are introduced. In Windows you can eliminate some of these by designing each dialog separately for each locale -- it works, but... yuck!
Since Java provides a flexible layout manager mechanism, there are some RAD tools in the Java world that provide dynamic layouts -- JBuilder is one, for example. [Nevertheless, I personally find the RAD generated code to be rather unmaintainable, so I prefer not to use it if I can help it. If you have the proper layout tools, doing it by hand is actually faster and cleaner.]
I find it really hard to understand why MS resists the dynamic layouts idea so much. Even when they copied Java, they omitted this feature in.Net. It's very strange and rather sad...
Most of the people here seem to equate GUI development environments with RAD tools for fast building of UI forms (dialogs, etc). [I do not mention the "IDE aspect" here, since few would call Emacs a GUI tool, but it can be a full featured IDE nevertheless]
There is another class of GUI tools, however, that allow you to incorporate UML diagrams within your design and development process. I guess that the two programs that best represent this class of "modeling tools" are RationalRose and Together.
RationalRose is more popular, since it was out first, and essentially set the standard, but it supports only a one-directional process (unless that has changed recently) -- design your UML diagrams, and generate code from them (some OO people actually see this as an advantage, but that's another discussion).
Together, on the other hand, is bi-directional -- it constantly updates the UML diagrams to keep them in sync with the code you are writing. As a result it has the neat property that you can actually write your code w/o going through the UML modeling/design stage, and yet you get complete UML diagrams of the code when you are done.
Personally, I am ambivalent about the utility of RAD tools for building GUIs -- they can be great for quick prototyping, but on the other hand they tend to produce code that is not very maintainable and thus not too suitable for large commercial application (although a lot of people are so used to them, that it is hard for them to see the alternatives).
On the other hand, UML modeling tools can be tremendously useful, especially in team environments. A picture is worth a thousand words, and that is very true even in programming. Even if you do not use UML for design, Together's ability to generate diagrams representing the code is invaluable when you have to take over or maintain someone else's code. It is much easier to see how classes relate to each other at a first glance, than to try to figure that out by going through the code manually.
Slashdot Mirror
No, they are not. In fact, they are very different. C++ templates are heterogenious (every parameter set means a new class, hence you get lots of additional classes); Java generics are homogenious (one class serves all parameters). C++ templates' requirements for the parameters are "as they come" -- the code is simply recompiled with the new parameter classes; Java generics' parameters need to implement interfaces/extend classes if a particular method of the parameter is to be used (which is much neater from a design perspective, if you appreciate this kind of thing). The only thing in common is the first glance appearance.
The CLR together with C# completly owns Java
Yes, it is a better solution in some respects and much worse in others. Given that it was designed 5 years after Java, the first was to be expected, the second was not. It merits a look, until you realize that any advantages are only marginal, and that there is only one company that provides major products for it (like application servers) and defines its interfaces. Given the fact that the company has a long notorious history and it has standardized less than 10% of the API does not make things better. And then there is Mono that now has to rely on Wine... Ah well.
And this one is free for non-commercial use: Libelis
Also, there are a number of open source implementations that are "in-progress" -- Apache's Object Relational Bridge, etc.
This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.
This feature has actually been available in older versions of Eclipse (2.0) -- I use it when necessary. You can double click on an exception trace in the console output, and it will take you to the code.
The difference in 2.1, I think, is that the places where you can click are now explicitly underlined. It is also possible that the recognition of those places has been improved. In any case, if I understand correctly, this is an old feature with better UI.
As long as that platform runs Windows.
http://www.go-mono.com/winforms.html
First, what you say is definitely not true. The MS features do very little to improve performance (and I do not see how removing RMI helps at all). In addition, the MS Java implementation has practically not been used for years now (it is still at the 1.1.4 level, after all) and Java is very far from being DOA.
Second, it was certainly okay for Microsoft to deliver this functionality IN ADDITION to the standard one which they omitted. They could have provided both if they wanted to. But they didn't, and it is quite clear why they didn't -- the functionality competed with their technology and that made it dangerous.
Not liking Java does not change the fact that MS acted on ulteriour motives.
Microsoft developed their own non-portable mechanism for interfacing with C/C++ and did not include JNI (the standard for doing that) in their Java distribution. They did not include RMI either, presumably because it competed directly with DCOM.
.NET -- to have full control over the technology and make it follow their long-term strategy.
That's not "trying to adopt". That's skewing the standard to make developers tied to the Windows. They could have adhered to the requirements of the license very easily if they wanted. That's why they lost in court. That's why they developed
Needless to say, Mono will end up following their strategy as well due to the compatibility requirements of the community that will soon get hooked.
Heh. I do wish all that could happen by 2010. In fact, I wish that it had already happened (it could have, given enough funding).
But I just don't see it. Do you really believe that NASA can cut down its fat or that it can collect billions of dollars from alternative sources? I am not saying it is impossible, I am saying that unfortunately it won't happen. If you are realistic, you'll see that there is no chance for that at all in real life. That's just not how things work.
Yes, but Kennedy poured huge amount of money into the space program -- something simply not possible at the moment. There isn't a cold war to spur the development either.
It seems to me 2010 is a fairly unrealistic goal. First, the technology proposed has not been properly tested to put people to ride on it. To do that you need _at least_ 10 years.
Second, in order to send people, the whole 'going there and coming back' routine needs to be run a few times without a hiccup. I mean, this was done for the Moon, and a Mars mission would be far more risky.
Finally, I have no doubt that if the engineers are given sufficient resources, all of this can be done by, say, 2015. I do not think that this will simply happen, however, especially given the political situation and current fiscal policy that implies huge deficits well into the future. In fact, 2020 seems far more reasonable given the current situation.
Notice that Sun and the Liberty Aliance do NOT offer a centralized identity repository a la Passport. This is a distributed solution -- as a provider (internet store, etc.) you install an authentication server and decide yourself what other providers you can trust, so that if a user is logged in their site, he can be considered logged in yours as well (put simply).
The only requirement is that the server implements the Liberty Aliance protocol standards. I _think_ one can make an open source server that implements those standards as well.
If you come from a Swing background, Tapestry is way more intuitive than Struts. You have components in both, and building your gui involves putting components in components, and finally into a frame (Swing) or a page (Tapestry). You don't have to care about how the JTable (Swing) or Table (Tapestry) components are implemented, you just follow the API and use them. I really don't see the similarity between this and JSP or Struts.
I think Tapestry is the only free Java framework out there that actually allows you to really build components rather than pages (as it is in most of the rest). You can build a component to edit the user preferences, for example, and it really does not matter which page or another component you put it in, how you put it in, and what the layout is. It IS Swing for the web.
It also has a lot of other things that are worth using, but for those check the Tapestry home page.
According to the survey of 104 companies in North America, the cost advantage of Windows over Linux for the four workloads ranges from 11 percent to 22 percent over a five-year period.
How can this both be a survey and record data over a 5 year period, given that we are talking about Windows 2000 here?
Just curious. Perhaps there is a logical explanation.
J2EE apps are 3 or more tier, while simple web apps running within a servlet container are almost always 2 tier only.
As such J2EE apps are more scalable, available, and reliable, especially when the app server chosen offers clustering.
On the other hand, EJBs are a definite overkill for 90% of all scenarios for web-based applications, since those features are not really necessary, hence one should make the choice carefully. The bottom line is that each approach is appropriate for certain situations.
As for J2EE complexity, the tools currently available make developing such apps a very simple process.
-mb
I just want to clarify a couple of things that seem to confuse people a lot.
Tomcat, Jetty, Resin, etc. are Servlet containers. They are designed to run web applciations built on top of servlets and JSP. They also integrate with Web servers such as Apache and IIS to optimize the serving of static or other (e.g. PHP) content.
JBoss, as well as IBM WebSphere, BEA WebLogic, Macromedia JRun, Orion, etc. are J2EE servers. They provide support for Enterprise Java Beans, as well as a lot of other technologies in J2EE, including Servlets and JSP. Some of the J2EE servers have their own internal implementation of a servlet container (e.g. Orion), while others use independent servlet containers. Comparing Tomcat to those is like comparing apples to fruits.
JBoss, in particular, comes in several different standard distribution, one of which integrates with Tomcat, and another that integrates with Jetty by default. I am sure it can be confugured to use other Servlet containers as well.
To address the main question, my personal experience is that Jetty is best for development because of its quick startup, although Tomcat is also fine as long as your development environment integrates with it well. In a production environment, I would recommend Resin and the Orion servlet container if performance is necessary. If it is not, Tomcat is okay, and the hot deploy feature in 4.x makes it a very attractive option. (I would just note that the hot deploy feature does not work in all cases, e.g. it does not work for Tapestry applications)
System.out.print(new DecimalFormat("#######.##").format(x));
You can also do things that you cannot do with printf:
System.out.print(new DecimalFormat("####000.0#").format(x));
What's more important, however, is that the printf family of functions have no support for internationalization (e.g. different order of printing the arguments and locale support), which is a must for any contemporary app development. That essentially makes them useless for generating strings that are to be seen by the users.
Here is an example of something typical that you can do with the standard Java library:
MessageFormat.format("At {1,time} on {1,date}, there was {2} on planet {0,number,integer}.", arguments)
output: At 12:30 PM on Jul 3, 2053, there was a disturbance in the Force on planet 7.
Java may be a bit clumsier than C, but it addresses the application and enterprise developer concerns much better (especially with respect to stability and maintainablity). This is just a simple example, but it demonstrates the point.
A post that did not give a single factual argument to begin with and was so wildly incorrect does not deserve the time for a factual response. If you really want facts, why don't you start first?
And just for the record, this "Java monkey" has over 10 years of C++ experience, a number of commercial products and easily over 1 mil lines of code in that language behind his back, so it would be pretty hard to accuse him of bias.
This has to be the most erroneos statement I have seen in a long time. Java programs tend to be an order of magnitude more stable than comparable C++ programs and are usually developed in half the time.
Which brings us to the real reason people use Java. Java programmers are cheaper, since you can hire less skilled programmers and not worry about then leaking memory all over the place or blowing away unrelated parts of memory.
First of all, Java programmers are not cheaper. On the contrary, J2EE developers tend to get some of the highest salaries in the industry.
And the real reason why people choose Java is that it allows them to concentrate on the design of the application, rather than worry about idiotic things like leaking memory, uncaught exceptions, and buffer overflows.
Java does have things to be criticized for, but this post is so much off the target, that it is sickening.
I apologize for the "me too" post, but I think you make an excellent point. Video games can provide dimensions that conventional art cannot.
Case in point: Planescape Torment. As another player once thoughtfully said about that game, "This is the best book that I have ever played". In a sense it is a book -- at 1,000,000 words (I believe that was the quoted number) it contains far more text than most books out there. But as in most RPGs, the incredibly engaging story is also additionally reinforced by the fact that the player/reader takes part in it, and his/her choices significantly affect the way the story develops. That leads to a much greater indentification with the main character and a much greater emotional response than a normal book can provide.
I think one phenomenon that we are becoming witnesses to is the dawn of truly interactive fiction. I think it is logical to assume that with the advent of electronic paper, that market could only grow in new and unexpected directions.
And Real Men rewrite the entire kernel when a new processor comes along.
GNU Classpath and its related projects, while trying to fulfill the noble goal of creating an open source implementation of the Java Runtime Environment, has nothing to do with Litris' "predicament". Sun's JRE (and a number of others, notably the IBM's JRE) can be used freely to execute any kind of software, and is fully compatible with open source.
As the article and many people here have pointed out before, it is easily demonstratable that the whole issue is a smoke screen -- equivalent open source projects (e.g. JBoss) have never had problems with Sun.
Sun's policy in respect to Java (including the JRE) has been to provide a mechanism for the definition of standard specifications via the Java Community Process, and let players in the market provide different implementations of those specifications. The JCP is also obliged to provide a reference implementation and a compatibility testing suite to ensure that different implementations work well with each other. The whole idea is precisely to avoid vendor lock-in and to promote excellence via competition between different implementations (compare this with .NET). This policy plays very well with open source, since it allows the open source community to create competitive and highly compatible implementations of those standards. JBoss (an open source implementation of the J2EE specification) is excellent example of that.
Languages do matter. Certain language features can significantly improve productivity and the quality of the code. Especially in respect to team environments and large projects.
Case in point: Java has checked exceptions, C# does not. The extensive use of exceptions in large projects is typically a significant source of program instability if you do not have the benefit of compile time checking. This is a very simple language feature, but it makes a major programming mechanism from one that requires caution to one that is ubiquitously useful.
Even carefuly selected syntactic sugar can make the code clearer and simple and cause some boost in productivity as a result (e.g. 'foreach' in C#). Of course, badly selected syntactic sugar can have just the opposite effect -- massive confusion. I find it astonishing that in C# you can never be sure what the expression 'a.b = c' does (assignment or function call). Are the several characters that are saved from 'a.setb(c)' worth the amount of programming time that would almost certainly be lost due to misunderstandings? I very much doubt it. (although anyone who has public members probably deserves that)
So languages do matter, and even the small differences can have a big impact on the stability and maintainability of a large program.
Your example does not describe a parallel connection of units, but a serial one instead.
A simple example of parallel operation would be using your arms. Assume that your spine and legs are sufficiently strong and the weak link in your body is your arm. You can lift much greater weight using your two arms together than when using one arm only. That beats the "weakest link" limit.
I am not sure why this should be the case (if I understand what you are saying correctly). If the elements of the construction, say N robot units, are connected in parallel, then the "strength" of the construction can increase to up to N times the "strength" of a single element. Obviously that is not easy to do, but it should definitely be doable.
I agree with you completely. The X-Y method for laying out forms is an abomination. It breaks down spectacularly when i18n, l10n, and/or UI customization (e.g. font selection) are introduced. In Windows you can eliminate some of these by designing each dialog separately for each locale -- it works, but... yuck!
.Net. It's very strange and rather sad...
Since Java provides a flexible layout manager mechanism, there are some RAD tools in the Java world that provide dynamic layouts -- JBuilder is one, for example. [Nevertheless, I personally find the RAD generated code to be rather unmaintainable, so I prefer not to use it if I can help it. If you have the proper layout tools, doing it by hand is actually faster and cleaner.]
I find it really hard to understand why MS resists the dynamic layouts idea so much. Even when they copied Java, they omitted this feature in
There is another class of GUI tools, however, that allow you to incorporate UML diagrams within your design and development process. I guess that the two programs that best represent this class of "modeling tools" are RationalRose and Together.
RationalRose is more popular, since it was out first, and essentially set the standard, but it supports only a one-directional process (unless that has changed recently) -- design your UML diagrams, and generate code from them (some OO people actually see this as an advantage, but that's another discussion).
Together, on the other hand, is bi-directional -- it constantly updates the UML diagrams to keep them in sync with the code you are writing. As a result it has the neat property that you can actually write your code w/o going through the UML modeling/design stage, and yet you get complete UML diagrams of the code when you are done.
Personally, I am ambivalent about the utility of RAD tools for building GUIs -- they can be great for quick prototyping, but on the other hand they tend to produce code that is not very maintainable and thus not too suitable for large commercial application (although a lot of people are so used to them, that it is hard for them to see the alternatives).
On the other hand, UML modeling tools can be tremendously useful, especially in team environments. A picture is worth a thousand words, and that is very true even in programming. Even if you do not use UML for design, Together's ability to generate diagrams representing the code is invaluable when you have to take over or maintain someone else's code. It is much easier to see how classes relate to each other at a first glance, than to try to figure that out by going through the code manually.