Some people are of the concerted opinion that GNUstep, Cocoa, and indeed GNOME are on the wrong path when it comes to building GUIs when compared to editors of the likes of NetBeans or Eclipse. The first set of technologies have chosen to generate data (even though Glade can generate code... the GNOME project recommends against this), whether they are serialized streams or XML, to represent thier GUIs whereas most Java GUI builders generate code.
This is a fundamentally mistaken position for a very important reason: Metadata is portable across different languages. In GNOME there is a Java interface as well as a C and C++ interface to libglade. This means that my program, no matter which of these languages it's written in, can load my interface without any problems. In NetBeans or Eclipse, it's not necessary for them to consider that SWT or Swing will ever be used by anyone but them, so they can generate the code. However, data is better in general, since it can also be manipulated outside of the program. For instance, it's possible to apply a stylesheet to an XML file and transform it as needed. Why not do this to an interface file? This way an XML interface file can be manipulated like data inside the program and the resulting XML can be loaded as the GUI.
So I hope this settles any arguments about which type is better. In my opinion, Data generating GUI builders are better, hands down.
Showing posts with label Methodology. Show all posts
Showing posts with label Methodology. Show all posts
Tuesday, November 22, 2005
Friday, June 17, 2005
The Book of Rules
Here's my book of rules. Occasionally I quote this. It's a collection of personal facts/rules that I have been compiling for some time.
Here it is:
Greg's Rules
0. In any situation involving people, there will always be politics.
1. 99% of the general public ( including technical people ) are not willing to learn anything new unless they absolutely must.
2. Most people are out for their own interests only and do not care about the big picture.
3. The mainstream media is both fickle and stupid.
4. Given a set of technologies, the worst one of the group will almost always prevail since it is
understandable to the lowest common denominator of people (see rule #1).
5. The general public will crucify that which doesn't follow the norm (again see rule #1).
6. Being a realist about how software development works is essential, idealists tend to always loose.
7. The next guy who stands up and says "look at me i've got all of the answers", usually doesn't.
8. Most things which start with Open* usually aren't. Examples OpenLook (proprietary), OpenVMS (proprietary)... etc.
9. There is such a thing as an arrogant, conceited, idiot.
10. Bugs happen.
11. Any technology which doesn't make it in the first year, won't.
12. Rule for technological success:
For a product to beat out an encumbent product in the same space, it must not violate any of the following rules:
1) It must be at least 3 times better than it's competition
2) It must be easily understandable
3) It must be affordable
Violation of any one of these rules will spell disaster for a new technology no matter how cool.
13. People tend to immediately blame that which they do not understand, usually due to their own ignorance.
14. Most people will continue to use that which they are used to despite the presence of a superiour product.
15. Rules you must know in order to appear as a genius to your co-workers:
1) Never admit that you don't know something, there's always plenty of time to look it up.
2) Never, under any circumstances, document anything. This impacts job security.
3) Always hang out with the other so called "geniuses" on the project, so that you,
by association, will be considered a genius.
4) Always eschew the opinions of others as nothing, meaningless and beneath notice.
16. People will use your software in the most obtuse, indirect and unexpected way imaginable.
17. "Why specifications survive" -- Inspired by something I once read, but can no longer find... Ever wondered why bad specifications survive? Here's a good example. Take a look at the standard railroad track. It's about three feet across. Well, the reason it's about three feet across is because the people who were employed to make the railroads were wagon makers. These wagon makers were usually immigrants from different parts of Europe who, of course, made wagons there. Well, the wagons in Europe needed to be a certain width, to fit the ruts in the road which exist due to hundreds of years of wear and tear. These ruts were caused by Roman chariots from when significant portions of Europe were under the control of the Roman Empire. As it turns out, a chariot is about as wide as the hind quarters of a horse. So the next time you wonder what horse's ass came up this this design, you'll have something to reflect on.
18. Untested code never works the way you think it will, so please test.
Here it is:
Greg's Rules
0. In any situation involving people, there will always be politics.
1. 99% of the general public ( including technical people ) are not willing to learn anything new unless they absolutely must.
2. Most people are out for their own interests only and do not care about the big picture.
3. The mainstream media is both fickle and stupid.
4. Given a set of technologies, the worst one of the group will almost always prevail since it is
understandable to the lowest common denominator of people (see rule #1).
5. The general public will crucify that which doesn't follow the norm (again see rule #1).
6. Being a realist about how software development works is essential, idealists tend to always loose.
7. The next guy who stands up and says "look at me i've got all of the answers", usually doesn't.
8. Most things which start with Open* usually aren't. Examples OpenLook (proprietary), OpenVMS (proprietary)... etc.
9. There is such a thing as an arrogant, conceited, idiot.
10. Bugs happen.
11. Any technology which doesn't make it in the first year, won't.
12. Rule for technological success:
For a product to beat out an encumbent product in the same space, it must not violate any of the following rules:
1) It must be at least 3 times better than it's competition
2) It must be easily understandable
3) It must be affordable
Violation of any one of these rules will spell disaster for a new technology no matter how cool.
13. People tend to immediately blame that which they do not understand, usually due to their own ignorance.
14. Most people will continue to use that which they are used to despite the presence of a superiour product.
15. Rules you must know in order to appear as a genius to your co-workers:
1) Never admit that you don't know something, there's always plenty of time to look it up.
2) Never, under any circumstances, document anything. This impacts job security.
3) Always hang out with the other so called "geniuses" on the project, so that you,
by association, will be considered a genius.
4) Always eschew the opinions of others as nothing, meaningless and beneath notice.
16. People will use your software in the most obtuse, indirect and unexpected way imaginable.
17. "Why specifications survive" -- Inspired by something I once read, but can no longer find... Ever wondered why bad specifications survive? Here's a good example. Take a look at the standard railroad track. It's about three feet across. Well, the reason it's about three feet across is because the people who were employed to make the railroads were wagon makers. These wagon makers were usually immigrants from different parts of Europe who, of course, made wagons there. Well, the wagons in Europe needed to be a certain width, to fit the ruts in the road which exist due to hundreds of years of wear and tear. These ruts were caused by Roman chariots from when significant portions of Europe were under the control of the Roman Empire. As it turns out, a chariot is about as wide as the hind quarters of a horse. So the next time you wonder what horse's ass came up this this design, you'll have something to reflect on.
18. Untested code never works the way you think it will, so please test.
Subscribe to:
Posts (Atom)
-
Are we really going to fall for it again?
-
I wanted to make this post to make it clear to the community regarding GNUstep's position on the new Swift language. If the langu... -
Recently, I saw this article regarding ObjCs "end of life" from JetBrains. The tiobe index seems to disagree. It’s also importa...