I really like Python (not TCL or Perl, because of their bizarre syntax). Nonetheless, even Guido Van Rossum admits that python still has a long way to go.(see: http://www.python.org/doc/essays/cp4e.html) I don't particularly like or dislike Basic. I just like the tools. And believe me, I've tried Python, with tkinter, with wxWindows (wxPython), with pyFox, and so on; they all lack the tools necessary to speed things up. It just takes forever to manually program your controls in code, to use arcane functions to associate your controls to the event handling methods, and so on. I've got work to do!
I'll tell you what the real problem is: some people want to complicate programming to the level that only a handful of specialist can develop a system, where before, millions could produce something useful, with results matching their level, but still solve problems.
I can guarantee to you that your approach will fail. It's the users who are paying, and they, obviously, don't want what you're selling. If you are still making 50K, kiss your hands, because sooner, rather than later, it may be over.
I've posted comments pointing to that problem several times already, and I'm happy that at least one person seems to see it too.
VB, as much as quite a number slashdotters may despise it, hate it, belittle it, seems to be the method of choice for corporations around the world to develop their "automated custom office procedures".
I'm saying "method" and not "programming language". The idea that you can keep everything as simple as possible by visually painting control on a form or a report, and to bind them against a data source, or an object model, is most popular approach to developing these "automated procedures". Furthermore, the code that you then end up to write is syntax coloured, code completion-aided and visually debuggeable.
In my impression, too many slashdotters think that the whole world should enjoy typing stuff like: gcc -aL89 -kMjs2389 -oInstall.o -la.out -kMyProgram.cpp -vi -1 -2 -pALL...
As long as people with that kind of attitude continue to dominate the linux comunity, most people out there, including myself, will refuse to use linux, not even for free, regardless the fact that I'm truly sold on the idea of open source.
No, never. I'm a contractor, and I've never contracted for Microsoft. I've used both Microsoft's and Sun's products; both of which have their flaws. But there is one thing Microsoft has over Sun: both feet on the earth.
You see, I'm never going to program against the API of someone who tells me: "Oh no! Parameterised classes are too dangerous for you!" or "It must be purely object oriented!", or "In your interest, we're going to prevent you from harming yourself!"
In the world of closed source, you are forced to put up with the wrong decisions of someone else. Sun likes to shoot hard-coded rules, that they get from their Sun fundamentalist religious company rule book. They are trying to shove rules of thumb, good for a number of situations, bad in other, down the throat of everyone.
We know that Microsoft quite often creates needles hassles by trying to make things *user-friendly* beyond the level of sanity. They try to create the impression that you can achieve anything you want, if you just keep on pressing Ok.
All of this leads to programs with "Ok" -and "Yes/No" message boxes, deeply inside the nested loops, potentially firing at you a cacaphonious series of nagging "Are you sure?", "There is unknown memory error!", "Are you really sure?".
All of which tends to degenerate in an unstoppable diarrhea of focus-grabbing, noise-producing "You will not ignore me!", "I'm sure you need to know this NOW!"-kind of childish and irritating man-machine conversation with the user.
Now, let's try Sun. Are they any better?
Well, Sun seems even worse; they don't even wait until they get to the end-user. No, they even do this with the developers. Java is nothing more than a belittling, annoying, arrogant, and development tool, that nags you all the time with ridiculous rules that may be useful in some circumstances, but seldom necessary.
For example, try to read from a resultset, somewhere in a jdbc data source. First, you will have to handle all the details of the driver manager, the driver, the versions of everything, specifying all details, or else it will insist on sending diarrhea of error messages in your face. You aren't finished with the previous problem, created purposely by Sun, or the diarrhea starts again: you didn't catch the potential exceptions for your jdbc connection! Now Sun forces you to do a try/catch, because in all other cases nothing will compile. Maybe your connection is perfectly valid. Maybe there will be no error, but still, you will and must write the code to catch this exception, or else, f*ck you!
Look at Solaris. For example, I will never forget that textedit utility. When you close it, by crossing it out, it will nag you with something like:
"Do you want to close and then save or do you want to save and then close?"
Microsoft is already bad, but of one thing I'm sure: if ever, Sun will be several degrees worse!
I could simply say printf ("hello\n"); Where did you manage to compile that? You are simply denying the facts. Now imagine setting up a *PC*. You are denying another really crucial fact: Even the most computer-illiterate people are able to go the store, get a PC, switch it on, and start doing whatever they are able to do. Why do you think KDE and Gnome were created? Because there is a whole world out there, of people who need to crank out a letter, a quote, a few formatted tables, and are not interested in dealing with the details of setting up servers, networks, et cetera. I'm going to order a handful of the boxes and pass them out to our database group. Until your users start complaining to the boss, and point out, rightfully, that they are making all the money for your company, and that they want you off their back.
Listen, my friend, I've done projects at several large companies, and I can tell you that I'm getting paid very good money for my code.
I don't necessarily like C++. As a matter of fact, I rather dislike the language; which doesn't detract from the fact that Java is even worse, and much so. The fact that it is "purely object-oriented" doesn't detract from this, on the contrary.
The difference between you and me, is, that I am a coder, and you are *only* a coder.
That's why you fail to understand the larger picture. Have you noticed who exactly out there gets to making the decisions and all the money?
I guess you must be deeply frustrated for getting used and abused all the time, while other people are getting all the fun.
People who are *coders only* will never achieve anything.
Sun is brilliantly trying to solve the wrong problem; and basing their strategy on yet another illusion. Their most notorious illusions include Java and thin clients.
For example, "write once, run anywhere", because it's written in Java. Yes, but there is Java 1.0, 1.1, 1.2, 1.2.1 and your nice little application that uses the swing widgets is unfixeably incompatible with 75% of the existing Java platforms. If Sun stops issuing new versions of Java, the language will die, but if they do, the whole exercise will increasingly defeat the object.
It's among the realities of this life that even low-level C/C++ source code is much more portable than Java bytecode. At least you can fix the problems, if you have the source code.
In every of their technologies, Sun makes the same stupid mistake. It's quite simple to understand what is going wrong. If you look the problem space, you can see simple and complex problems. If you look at the solution space, you can also see simple and complex problems. Now, look at the possible combinations.
(1) A simple solution for a simple problem. (2) A complex solution for a complex problem. Ok. The complexity of the solution scales with the complexity of the problem. Everybody expects this and I don't see anybody having a problem with this. (3) A simple solution for a complex problem. This is what people call "breakthroughs". You must be almost a genius to achieve this. (4) A complex solution for a simple problem. This is the area where you people really pissed of with you, and with reason; if you do this too often, you may get thrown out of the office.
The more you look at what Sun is doing, the more you discover options that are typically area (4).
1) Java. Well, just print "hello" in Java: ... static void public main(argv[],... and so on...
2) Thin Clients. Ok. I've got this application "Hello world" application here and I want to run it in that thin client, as a test, just to try.
Oh no. I need a server first, that's why I need a network too. Someone must configure dhcpd/ip/dns/etcetera on the server first. Now someone has to configure all the security, even though there's only one user (who's only going the do a little test and then move on). I need to create user ids/home dirs/user groups. Now the thing is not going to run, because I need the specify the options for load balancing. Do you need a proxy-server running on the server? If you don't answer the question, I will send millions of error messages in your face.
Just to get the one application up and running, only for 1 minute, you will be tweaking, configuring, installing, uninstalling, setting, re-setting, debugging, and then give up, because your program was compiled in java 1.6.9.9 VM, and the install-cd features the java 1.5.9 VM.
Why is the fat client PC so appealing? Because it scales easily from 1 PC stand-alone, to 5 or 10 PCs in a small network, to 10,000 PCs in their lans, connected through wans, internet, and so on. At every stage of growth, you will, of course, need to re-structure your solution, and adapt the problems that occur along with growth. But no one will ever force you to solve the problems of very large networks, when you actually have a simple, and small one!
So, who will buy solutions from Sun? (1) People, who truly don't understand the technology, not even at the most basic level, and are impressed with the fact that it is very complex (in their ignorance they think that because the technology is complex, it will be able to solve complex problems.) (2) People, who enjoy complexity for the sake of complexity (you can even seek to make a challenge out of going to the bathroom, by placing traps in random places. Fun! Fun!). (3) People, who seek job protection by implementing solutions that are very hard to understand (and that only they and very few other people can understand).
Dive into practice and take a good look at some brilliant oo designs.
For example, quite a good number of GUI frameworks are absolutely marvellous. I'm talking about wxWindows, QT, and so on.
Certain problem areas apparently lend themselves easily to oo design. That's probably why you will find oo solutions everybody thinks, with reason, to be marvellous.
If you are interested in looking at business-oriented software, well, there doesn't seem to be one oo design that has succeeded in attracting admirors in any sizable numbers.
Regarding well-designed business software, I haven't seen any using oo designs and nobody seems to be able to mention one example.
Beware of books that mention cats and dogs, being mammals, as an example of inheritance!
I'm repeating myself, and I'll repeat myself once again for you, until you finally open your ears and then argue to the point.
Most programmers are involved in automating business procedures. What they need, and the companies that are paying for the services, are tools to better automate business procedures, and faster, that is, cheaper.
You are writing about midstr$, mid$, and other details that do not matter to the issue. There hasn't been one project in the history of mankind that has failed over the presence or the absence of midstr$.
If you have to think for more than three seconds whether your programming language is feasible for implementing an operating system or not, then you can not call your programming language a general purpose programming language. Yes, you are right and I don't disagree: Visual Basic is not a general purpose language, and you cannot implement operating systems in VB. What we disagree on, is whether the 95% of lines written daily in the world are meant to produce an operating system. In my experience, they are written to serve the organisation that is paying the person writing them. Most people are therefore involved in automating business procedures. I'm only talking about the efficiency that can be gained or lost in automating business procedures. I'm not talking about anything else.
Both the OO and the non OO program will break, but the OO program will break in several places.
When an object's attribute becomes a collection of attributes (several addresses instead of one), any class using this attribute (using customer.SetAddress()/GetAddress()) will have to cope with the fact that it's a collection now, and that at least a choice has to be made as to which of these attributes is meant to be read or set.
In fact, your can consider your classes to be virtual tables, and the attributes of your classes to be the columns in these virtual tables. The way in which classes use each other obviously define the relationsships between your classes. That's why your class framework represents an alternative database schema, on top of your existing database schema. Is this new schema less vulnerable to changes than the existing one? No. Definitely not. Furthermore, you will need, continuously, to keep these two schemas in sync.
The result is that the forms, reports, and batch processes using your class framework (classes themselves, if you want) will not be more stable.
Just like the fact that you can't prevent the interface of database schema (tables and columns) to be scattered all over your code, you will be unable to prevent details of your class framework (class interfaces) to be scattered around your final objects: forms, reports, batches, and so on.
What is the advantage then of a class framework? Furthermore, the object manipulation technology is so much less advanced than the database manipulation language. If one of your reports needs to know how much orders on customer has, it would be rather easy and efficient to query the database using SQL. If your report uses an object framework, you will writing code to loop over customer objects and order objects within the customer objects: a lot of programming to answer a trivial question, and it may be very slow too.
By using class frameworks, sitting between your final programs and the database, you lose the benefits of SQL, while gaining nothing, but heaps of useless, unmaintainable code.
My conclusion is that the people who advocate object oriented concepts don't understand what software is being developed in the real world. Just look at the examples and explanations in most textbooks on object orientation: it's all about cats and dogs, being mammals, et cetera, to explain inheritance. Why do these people (Take Grady, Booch, Meyer, Yourdon,...) choose stupid examples, instead of examples taken from real-world situations, in which we talk about orders, invoices, pay checks, and so on? Because these people simply do not have a clue about the real world! And that's why their technology has nothing to do with reality.
They didn't look at the real world and try to solve the problems we're having now!
"...but that's no more true than it is for a non OO design."
Therefore, we can state that the OO design hasn't done anything to solve the problem, or any other problem inherent to systems which have complex data structures. That's why I say that OO design is completely overrated. It's a hype, that doesn't deliver on its promises, very simply, because complex data structures are the mainstay of real-world business applications.
You also write: "If anything the OO design is advantageous here, because any changes would only have to be made within a single class. "
Wrong. The classes that use this class will be broken too, because the methods Set/GetCustomerAddress() have changed. There is more than one addres now.
If you want to push through the concept of many addresses throughout the system, all the classes that use the member Customer.GetCustomer() (or SetCustomer()) must change the way they handle the addresses of this customer object. You may opt for workarounds, but they won't change the fundamental problem: they will just be that, workarounds.
Object-oriented designs do not address the real issues in systems that maintain complex data structures, such as business applications. That's why there are no gains in modeling business objects; better even, the more you stay away from them, the more robust your programs will be.
When I wrote about querying tables, fields etcetera, I basically meant that the you can, to a large extent, avoid to break a system by adding or removing data (table columns), but as soon as you change the relationships between your data, you will break the system. Object-oriented designs will break even more easily, because in such designs there are simply more places in which you have duplicated the underlying assumptions of your system. The database model is already a strong assumption about the reality it's supposed to store data about. The OO design contains the same assumptions, just coded differently. Now, you will break two things instead of one!
Well, if your customer object is not going to read its address from the database, something else is. Whatever is reading the customer's address from the database will have to read it from a different table, and therefore it's broken, and will not be able to hand the address to your customer object, and therefore, your customer object will be broken too; until you fix whatever reads the address from the database.
Hey, hey. I did management school; and as a matter of fact, I'm considered the best coder at my company, because I'm fast and my code is bug free; and it's ready before CS guys even started writing their class headers. That's why THEY are paid peanuts. As long as THEY don't understand that someone is going to pick up the tab, to pay for the cars, the beer and the chicks, they'll continue to gaze at their screen, asking themselves why can they, and why not we? while we're having fun.
I don't know what kind of applications you're involved in. I can only tell you that most programmers around are employed by companies to help run their business. You're not going to deny that, are you?
Well, you are pointing to constructs in VB that are not an essential factor of success or failure of a business app. You are talking about details, that are far away from handling sales orders, invoices, work orders, pay checks, and so on.
Is your accounts payable module going to fail to deliver usefulness on what you've just named?
Whatever language/tool you are going to use, you should keep the real issues in mind: M mandays x S daily rate = B, the budget. How much usefulness, that is needed to do the above, are you going to deliver with your strstr() function?
By the way, I usually have this kind of final field parsing done by the database manager, by using a function in SQL. As far as I'm concerned, I don't need any crap cluttering my vision on the database, the forms, the reports, and the batches that run the business.
Object Frameworks DO KNOW THE DATA STRUCTURE of the data they manipulate. That's impossible to deny. For a starters, object frameworks need to store their data; so-called persistency. But now, we're getting to the point. If you want to store your objects, you have no more than two options.
First, you can serialize your objects into some horrible flat, binary, or for the sake of the argument, XML files. Anybody who understands business applications will be horrified, immediately, at the consequences: (1) Only the framework that created the objects can properly read and write to the files; (2) the files enforce a primary access order. For example, if you store your customer objects, with their orders and orderlines, you can perfectly well select on customer and its data, but you have to traverse every single customer to add up the number of orders for a particular product. This is a complete denial of Codd, and all advances in databases since 1973. People, who create this kind of crappy applications, with this kind of crappy data storage, should go back to school at once. As a matter of fact, this is how the dogmatic creators of Java betray themselves: object orientation at every price. How do they solve the problems of databases? Well, with the ridiculous idea of "serializable objects".
The second option is to access a relational database. Anybody with anything like half a brain will choose this option. This is the only way to share data across a large number of users without imposing a particular access strategy to the data: The guy putting in the orders can access the data per customer, and the guy handling the inventory can access the data per product, without either of them being penalised for doing so.
The result is that the database structure is scattered in your object model. As a consequence, you cannot alter the database structure without breaking the object model. For example, if a customer can suddenly have more addresses instead of one, the customer object will have read its address from a different table: it's, therefore, broken.
I can only conclude that people who think object oriented have different applications in mind than the 95% of the applications around, in production with today's companies. They live in a world that doesn't exist, and try to impose a view on software development that has failed for the last 15 years. Everybody knows it, and the emperor has no clothes.
Programming is indeed just a very thin layer of practical implementation skills on a well-established basis of numeracy, literacy, analytical and problem solving skills.
Students who have acquired the basis, through whatever means, by studying whatever subject, will be successful.
Most people, who are successful in developing software have many more skills than just knowing where to put the commas, braces, and indentation. The latter are just details, that should not even be that important, and, as a matter of fact, are not, in good development environments.
People, who vociferily advocate C/C++, Java, and that kind of languages, are usually people who have no skills at all, besides where to put the commas, braces, and so on.
I think we should all have understood by now that the criteria by which people assess the quality of a programming language/tool are mostly wrong. The worst of which are: bit-level performance and object orientation.
Bit-level performance is a non-issue for most programmers. The operative word here is "most". What do most people write anyway? Well, just look at who is paying most programmers: corporations. What do they need from programmers? Programs that run their business, that is, programs that help with order processing, manufacturing, payroll, accounting, and so on. Most of these programs spend 95% of their time in larger frameworks that manage the databases, the GUIs, et cetera. Therefore, your language of choice may be fast or slow, it won't make any difference. If you want speed in these applications, chose a fast database, a fast GUI framework and fast, other supportive components.
Object orientation is another one of these miracle cure-all solutions that almost never work, even though no one will openly admit it. By modeling business apps as objects, you will not only lose a lot of time, but, even worse, make your applications much less maintainable. Why so? Because the complexity of business applications is in their data, and the only thing you will do by modeling business applications as object frameworks, is to replicate this complexity once more in your object classes. And then you will have an extra chunk of code to maintain, when you change your database structures. Next to your database design, your GUIs and your batches that you need to maintain, you will need to maintain the so-called business objects. These business objects "know" your data structure, and, therefore, have to be informed of changes in it. The duplication effort is ridiculous and only pays off in wasted time.
The whole concept of business objects is a laughable hype. Quite naturally, the more someone is ignorant and incompetent, the more he will jump from one hype to another, trying to use the latest fad, and miserably fail. This is normal, because the only way incompetent people can judge a technology, is by hyping along with the rest.
I didn't say that object orientation is a bad idea altogether. I've said that it is of no use in typical business applications, and even dangerous.
What is a true criterion for quality in a language/tool? Well, as ever. It's definitely not new. Read the classical Greek literature for the source of true wisdom. A language/tool is of high quality if it has a high level of self-knowledge.
A relational database is a great tool, primarily, because of its self-knowledge. You can ask it what tables it contains, what relationships there are between those tables, what columns they contain, what datatype they have, and so on. You don't need to enumerate all fields in a particular table in your program. You may prefer to work at a more abstract level, and define rules that work in general, and only mention the exceptions to the rule. Therefore, You may manage your code by exceptions, instead of replicating knowledge all over the system, and create potential for inconsistencies.
Most/.ers seem to dislike Visual Basic. There can only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance. There may be a lot of things that can be done better in VB. However, VB and Access have quite a large amount of self knowledge. You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge, even worse, these languages require you to code details that are of no interest to problem at hand. C/C++ is for people who don't understand programming. What is programming? It's rather simple: A is the amount of time you have, and B is the result that you need. If you then chose C/C++, you should go and see a shrink.
The product they sell, is not only a copy of the linux cd, but an amount of free support as well.
I think, indeed, that the vendors who copy the Red Hat cd, should say either "a copy of the Red Hat cd" or "based on the Red Hat cd", or something equivalent, that clearly distinguishes their product from the services sold by Red Hat.
Maybe Red Hat too should distinguish the cd more clearly from the total product they sell.
I think it's in their interest to emphasize that they are not selling the cd or its content, especially not the content. They should make clear that they are actually selling the support service that the buyer is entitled to, and that the CD is just added for convenience.
From a business point of view, selling the cd or the content do not make sense for the Red Hat company; as you can freely copy it. As a matter of fact, people who are not interested in the support service should not buy the CD from Red Hat, but buy it from one of the cheaper resellers.
Frankly, I think Red Hat would do consumers a favour, by unbundling the support service from the CD by itself. They should sell the CD at a realistic market price, much below its current price, and offer the support service separately, probably at a much higher price. It's also fairer to consumers who buy the CD, without ever having the intention to use the support service. Furthermore, the people who want to buy support, are most likely willing to pay much more.
By bundling both the support and the service, Red Hat raises suspicion.
Are they waiting for enough market share and volume to simply fork from Linux, and produce some kind of semi-proprietary version, in which free and non-free software are inextricable mixed, making the free content unfree? After which they can capitalize on the market share Red Hat name, built using free resources, to disallow the freely copying of the CD, and in effect insisting on a license fee per copy?
Therefore, I think the GPL should be adapted quickly, to prohibit that practice of putting GPLed software on a single medium together with proprietary software, in effect removing from the buyer the freedom to copy the free content, because he is not allowed to copy the proprietary content.
By far and by large, companies prefer to shell out cash, and massively, to Micros~1, rather than deploying linux. And price is the issue!
A $150 dollar is approximately the price for 1 Windooz license. For $150 you can waste 2 hours in development. There is no way that you will lose less than 2 hours per linux installed, using linux tools. You will lose a multiple of that.
There is simple not one single decent RAD tool for linux to crank out client/server business-database applications, that will enable the company to manage sales orders, invoices, bills of materials, time sheets, and so on.
Therefore, buggy as it is, Windooz is cheap and linux, free as it is, damn expensive.
Slashdot Mirror
I really like Python (not TCL or Perl, because of their bizarre syntax). Nonetheless, even Guido Van Rossum admits that python still has a long way to go.(see: http://www.python.org/doc/essays/cp4e.html) I don't particularly like or dislike Basic. I just like the tools. And believe me, I've tried Python, with tkinter, with wxWindows (wxPython), with pyFox, and so on; they all lack the tools necessary to speed things up. It just takes forever to manually program your controls in code, to use arcane functions to associate your controls to the event handling methods, and so on. I've got work to do!
This is not FUD.
I'll tell you what the real problem is: some people want to complicate programming to the level that only a handful of specialist can develop a system, where before, millions could produce something useful, with results matching their level, but still solve problems.
I can guarantee to you that your approach will fail. It's the users who are paying, and they, obviously, don't want what you're selling. If you are still making 50K, kiss your hands, because sooner, rather than later, it may be over.
I've posted comments pointing to that problem several times already, and I'm happy that at least one person seems to see it too.
...
VB, as much as quite a number slashdotters may despise it, hate it, belittle it, seems to be the method of choice for corporations around the world to develop their "automated custom office procedures".
I'm saying "method" and not "programming language". The idea that you can keep everything as simple as possible by visually painting control on a form or a report, and to bind them against a data source, or an object model, is most popular approach to developing these "automated procedures". Furthermore, the code that you then end up to write is syntax coloured, code completion-aided and visually debuggeable.
In my impression, too many slashdotters think that the whole world should enjoy typing stuff like: gcc -aL89 -kMjs2389 -oInstall.o -la.out -kMyProgram.cpp -vi -1 -2 -pALL
As long as people with that kind of attitude continue to dominate the linux comunity, most people out there, including myself, will refuse to use linux, not even for free, regardless the fact that I'm truly sold on the idea of open source.
No, never. I'm a contractor, and I've never contracted for Microsoft. I've used both Microsoft's and Sun's products; both of which have their flaws. But there is one thing Microsoft has over Sun: both feet on the earth.
You see, I'm never going to program against the API of someone who tells me: "Oh no! Parameterised classes are too dangerous for you!" or "It must be purely object oriented!", or "In your interest, we're going to prevent you from harming yourself!"
In the world of closed source, you are forced to put up with the wrong decisions of someone else. Sun likes to shoot hard-coded rules, that they get from their Sun fundamentalist religious company rule book. They are trying to shove rules of thumb, good for a number of situations, bad in other, down the throat of everyone.
We know that Microsoft quite often creates needles hassles by trying to make things *user-friendly* beyond the level of sanity. They try to create the impression that you can achieve anything you want, if you just keep on pressing Ok.
All of this leads to programs with "Ok" -and "Yes/No" message boxes, deeply inside the nested loops, potentially firing at you a cacaphonious series of nagging "Are you sure?", "There is unknown memory error!", "Are you really sure?".
All of which tends to degenerate in an unstoppable diarrhea of focus-grabbing, noise-producing "You will not ignore me!", "I'm sure you need to know this NOW!"-kind of childish and irritating man-machine conversation with the user.
Now, let's try Sun. Are they any better?
Well, Sun seems even worse; they don't even wait until they get to the end-user. No, they even do this with the developers. Java is nothing more than a belittling, annoying, arrogant, and development tool, that nags you all the time with ridiculous rules that may be useful in some circumstances, but seldom necessary.
For example, try to read from a resultset, somewhere in a jdbc data source. First, you will have to handle all the details of the driver manager, the driver, the versions of everything, specifying all details, or else it will insist on sending diarrhea of error messages in your face. You aren't finished with the previous problem, created purposely by Sun, or the diarrhea starts again: you didn't catch the potential exceptions for your jdbc connection! Now Sun forces you to do a try/catch, because in all other cases nothing will compile. Maybe your connection is perfectly valid. Maybe there will be no error, but still, you will and must write the code to catch this exception, or else, f*ck you!
Look at Solaris. For example, I will never forget that textedit utility. When you close it, by crossing it out, it will nag you with something like:
"Do you want to close and then save or do you want to save and then close?"
Microsoft is already bad, but of one thing I'm sure: if ever, Sun will be several degrees worse!
I could simply say printf ("hello\n"); Where did you manage to compile that? You are simply denying the facts. Now imagine setting up a *PC*. You are denying another really crucial fact: Even the most computer-illiterate people are able to go the store, get a PC, switch it on, and start doing whatever they are able to do. Why do you think KDE and Gnome were created? Because there is a whole world out there, of people who need to crank out a letter, a quote, a few formatted tables, and are not interested in dealing with the details of setting up servers, networks, et cetera. I'm going to order a handful of the boxes and pass them out to our database group. Until your users start complaining to the boss, and point out, rightfully, that they are making all the money for your company, and that they want you off their back.
Listen, my friend, I've done projects at several large companies, and I can tell you that I'm getting paid very good money for my code.
I don't necessarily like C++. As a matter of fact, I rather dislike the language; which doesn't detract from the fact that Java is even worse, and much so. The fact that it is "purely object-oriented" doesn't detract from this, on the contrary.
The difference between you and me, is, that I am a coder, and you are *only* a coder.
That's why you fail to understand the larger picture. Have you noticed who exactly out there gets to making the decisions and all the money?
I guess you must be deeply frustrated for getting used and abused all the time, while other people are getting all the fun.
People who are *coders only* will never achieve anything.
Sun is brilliantly trying to solve the wrong problem; and basing their strategy on yet another illusion. Their most notorious illusions include Java and thin clients.
... static void public main(argv[], ... and so on ...
For example, "write once, run anywhere", because it's written in Java. Yes, but there is Java 1.0, 1.1, 1.2, 1.2.1 and your nice little application that uses the swing widgets is unfixeably incompatible with 75% of the existing Java platforms. If Sun stops issuing new versions of Java, the language will die, but if they do, the whole exercise will increasingly defeat the object.
It's among the realities of this life that even low-level C/C++ source code is much more portable than Java bytecode. At least you can fix the problems, if you have the source code.
In every of their technologies, Sun makes the same stupid mistake. It's quite simple to understand what is going wrong. If you look the problem space, you can see simple and complex problems. If you look at the solution space, you can also see simple and complex problems. Now, look at the possible combinations.
(1) A simple solution for a simple problem.
(2) A complex solution for a complex problem.
Ok. The complexity of the solution scales with the complexity of the problem. Everybody expects this and I don't see anybody having a problem with this.
(3) A simple solution for a complex problem.
This is what people call "breakthroughs". You must be almost a genius to achieve this.
(4) A complex solution for a simple problem.
This is the area where you people really pissed of with you, and with reason; if you do this too often, you may get thrown out of the office.
The more you look at what Sun is doing, the more you discover options that are typically area (4).
1) Java. Well, just print "hello" in Java:
2) Thin Clients.
Ok. I've got this application "Hello world" application here and I want to run it in that thin client, as a test, just to try.
Oh no. I need a server first, that's why I need a network too. Someone must configure dhcpd/ip/dns/etcetera on the server first. Now someone has to configure all the security, even though there's only one user (who's only going the do a little test and then move on). I need to create user ids/home dirs/user groups. Now the thing is not going to run, because I need the specify the options for load balancing. Do you need a proxy-server running on the server? If you don't answer the question, I will send millions of error messages in your face.
Just to get the one application up and running, only for 1 minute, you will be tweaking, configuring, installing, uninstalling, setting, re-setting, debugging, and then give up, because your program was compiled in java 1.6.9.9 VM, and the install-cd features the java 1.5.9 VM.
Why is the fat client PC so appealing? Because it scales easily from 1 PC stand-alone, to 5 or 10 PCs in a small network, to 10,000 PCs in their lans, connected through wans, internet, and so on. At every stage of growth, you will, of course, need to re-structure your solution, and adapt the problems that occur along with growth. But no one will ever force you to solve the problems of very large networks, when you actually have a simple, and small one!
So, who will buy solutions from Sun?
(1) People, who truly don't understand the technology, not even at the most basic level, and are impressed with the fact that it is very complex (in their ignorance they think that because the technology is complex, it will be able to solve complex problems.)
(2) People, who enjoy complexity for the sake of complexity (you can even seek to make a challenge out of going to the bathroom, by placing traps in random places. Fun! Fun!).
(3) People, who seek job protection by implementing solutions that are very hard to understand (and that only they and very few other people can understand).
Dive into practice and take a good look at some brilliant oo designs.
For example, quite a good number of GUI frameworks are absolutely marvellous. I'm talking about wxWindows, QT, and so on.
Certain problem areas apparently lend themselves easily to oo design. That's probably why you will find oo solutions everybody thinks, with reason, to be marvellous.
If you are interested in looking at business-oriented software, well, there doesn't seem to be one oo design that has succeeded in attracting admirors in any sizable numbers.
Regarding well-designed business software, I haven't seen any using oo designs and nobody seems to be able to mention one example.
Beware of books that mention cats and dogs, being mammals, as an example of inheritance!
Ok. I'll admit my mistake!
The object-oriented theory is brilliant.
Unfortunately, nobody has ever been able to apply it right;
that's why the overwhelming majority of OOD projects have failed to produce any benefits by using OOD.
We need Einstein to come back to the world!
Are your comments relevant to what I said?
I'm repeating myself, and I'll repeat myself once again for you, until you finally open your ears and then argue to the point.
Most programmers are involved in automating business procedures. What they need, and the companies that are paying for the services, are tools to better automate business procedures, and faster, that is, cheaper.
You are writing about midstr$, mid$, and other details that do not matter to the issue. There hasn't been one project in the history of mankind that has failed over the presence or the absence of midstr$.
If you have to think for more than three seconds whether your programming language is feasible for implementing an operating system or not, then you can not call your programming language a general purpose programming language. Yes, you are right and I don't disagree: Visual Basic is not a general purpose language, and you cannot implement operating systems in VB. What we disagree on, is whether the 95% of lines written daily in the world are meant to produce an operating system. In my experience, they are written to serve the organisation that is paying the person writing them. Most people are therefore involved in automating business procedures. I'm only talking about the efficiency that can be gained or lost in automating business procedures. I'm not talking about anything else.
Both the OO and the non OO program will break, but the OO program will break in several places.
...) choose stupid examples, instead of examples taken from real-world situations, in which we talk about orders, invoices, pay checks, and so on? Because these people simply do not have a clue about the real world! And that's why their technology has nothing to do with reality.
When an object's attribute becomes a collection of attributes (several addresses instead of one), any class using this attribute (using customer.SetAddress()/GetAddress()) will have to cope with the fact that it's a collection now, and that at least a choice has to be made as to which of these attributes is meant to be read or set.
In fact, your can consider your classes to be virtual tables, and the attributes of your classes to be the columns in these virtual tables. The way in which classes use each other obviously define the relationsships between your classes. That's why your class framework represents an alternative database schema, on top of your existing database schema. Is this new schema less vulnerable to changes than the existing one? No. Definitely not. Furthermore, you will need, continuously, to keep these two schemas in sync.
The result is that the forms, reports, and batch processes using your class framework (classes themselves, if you want) will not be more stable.
Just like the fact that you can't prevent the interface of database schema (tables and columns) to be scattered all over your code, you will be unable to prevent details of your class framework (class interfaces) to be scattered around your final objects: forms, reports, batches, and so on.
What is the advantage then of a class framework? Furthermore, the object manipulation technology is so much less advanced than the database manipulation language. If one of your reports needs to know how much orders on customer has, it would be rather easy and efficient to query the database using SQL. If your report uses an object framework, you will writing code to loop over customer objects and order objects within the customer objects: a lot of programming to answer a trivial question, and it may be very slow too.
By using class frameworks, sitting between your final programs and the database, you lose the benefits of SQL, while gaining nothing, but heaps of useless, unmaintainable code.
My conclusion is that the people who advocate object oriented concepts don't understand what software is being developed in the real world. Just look at the examples and explanations in most textbooks on object orientation: it's all about cats and dogs, being mammals, et cetera, to explain inheritance. Why do these people (Take Grady, Booch, Meyer, Yourdon,
They didn't look at the real world and try to solve the problems we're having now!
Now we're really getting to the point:
"...but that's no more true than it is for a non OO design."
Therefore, we can state that the OO design hasn't done anything to solve the problem, or any other problem inherent to systems which have complex data structures. That's why I say that OO design is completely overrated. It's a hype, that doesn't deliver on its promises, very simply, because complex data structures are the mainstay of real-world business applications.
You also write: "If anything the OO design is advantageous here, because any changes would only have to be made within a single class. "
Wrong. The classes that use this class will be broken too, because the methods Set/GetCustomerAddress() have changed. There is more than one addres now.
If you want to push through the concept of many addresses throughout the system, all the classes that use the member Customer.GetCustomer() (or SetCustomer()) must change the way they handle the addresses of this customer object. You may opt for workarounds, but they won't change the fundamental problem: they will just be that, workarounds.
Object-oriented designs do not address the real issues in systems that maintain complex data structures, such as business applications. That's why there are no gains in modeling business objects; better even, the more you stay away from them, the more robust your programs will be.
When I wrote about querying tables, fields etcetera, I basically meant that the you can, to a large extent, avoid to break a system by adding or removing data (table columns), but as soon as you change the relationships between your data, you will break the system. Object-oriented designs will break even more easily, because in such designs there are simply more places in which you have duplicated the underlying assumptions of your system. The database model is already a strong assumption about the reality it's supposed to store data about. The OO design contains the same assumptions, just coded differently. Now, you will break two things instead of one!
Well, if your customer object is not going to read its address from the database, something else is. Whatever is reading the customer's address from the database will have to read it from a different table, and therefore it's broken, and will not be able to hand the address to your customer object, and therefore, your customer object will be broken too; until you fix whatever reads the address from the database.
Hey, hey. I did management school; and as a matter of fact, I'm considered the best coder at my company, because I'm fast and my code is bug free; and it's ready before CS guys even started writing their class headers. That's why THEY are paid peanuts. As long as THEY don't understand that someone is going to pick up the tab, to pay for the cars, the beer and the chicks, they'll continue to gaze at their screen, asking themselves why can they, and why not we? while we're having fun.
I don't know what kind of applications you're involved in. I can only tell you that most programmers around are employed by companies to help run their business. You're not going to deny that, are you?
Well, you are pointing to constructs in VB that are not an essential factor of success or failure of a business app. You are talking about details, that are far away from handling sales orders, invoices, work orders, pay checks, and so on.
Is your accounts payable module going to fail to deliver usefulness on what you've just named?
Whatever language/tool you are going to use, you should keep the real issues in mind: M mandays x S daily rate = B, the budget. How much usefulness, that is needed to do the above, are you going to deliver with your strstr() function?
By the way, I usually have this kind of final field parsing done by the database manager, by using a function in SQL. As far as I'm concerned, I don't need any crap cluttering my vision on the database, the forms, the reports, and the batches that run the business.
Object Frameworks DO KNOW THE DATA STRUCTURE of the data they manipulate. That's impossible to deny. For a starters, object frameworks need to store their data; so-called persistency. But now, we're getting to the point. If you want to store your objects, you have no more than two options.
First, you can serialize your objects into some horrible flat, binary, or for the sake of the argument, XML files. Anybody who understands business applications will be horrified, immediately, at the consequences:
(1) Only the framework that created the objects can properly read and write to the files;
(2) the files enforce a primary access order. For example, if you store your customer objects, with their orders and orderlines, you can perfectly well select on customer and its data, but you have to traverse every single customer to add up the number of orders for a particular product. This is a complete denial of Codd, and all advances in databases since 1973. People, who create this kind of crappy applications, with this kind of crappy data storage, should go back to school at once. As a matter of fact, this is how the dogmatic creators of Java betray themselves: object orientation at every price. How do they solve the problems of databases? Well, with the ridiculous idea of "serializable objects".
The second option is to access a relational database. Anybody with anything like half a brain will choose this option. This is the only way to share data across a large number of users without imposing a particular access strategy to the data: The guy putting in the orders can access the data per customer, and the guy handling the inventory can access the data per product, without either of them being penalised for doing so.
The result is that the database structure is scattered in your object model. As a consequence, you cannot alter the database structure without breaking the object model. For example, if a customer can suddenly have more addresses instead of one, the customer object will have read its address from a different table: it's, therefore, broken.
I can only conclude that people who think object oriented have different applications in mind than the 95% of the applications around, in production with today's companies. They live in a world that doesn't exist, and try to impose a view on software development that has failed for the last 15 years. Everybody knows it, and the emperor has no clothes.
It's not because you succombed to the hype, along with other masses brainless people, that everyone should do so.
Listen, we've had it before: now its Ada, or no, Smalltalk, or no, Modula-2, no, Perl, or no, it's my grandma's object-oriented cat!
Why don't you just learn to program?
Yep. And this applies in particular to people who are fond of cryptical language. The question is: can you do the job?
You're right. Let the kids do the basics and have fun. If they like programming as a hobby, fine with me, but don't shove it down anybody's throat.
Programming is indeed just a very thin layer of practical implementation skills on a well-established basis of numeracy, literacy, analytical and problem solving skills.
Students who have acquired the basis, through whatever means, by studying whatever subject, will be successful.
Most people, who are successful in developing software have many more skills than just knowing where to put the commas, braces, and indentation. The latter are just details, that should not even be that important, and, as a matter of fact, are not, in good development environments.
People, who vociferily advocate C/C++, Java, and that kind of languages, are usually people who have no skills at all, besides where to put the commas, braces, and so on.
I think we should all have understood by now that the criteria by which people assess the quality of a programming language/tool are mostly wrong. The worst of which are: bit-level performance and object orientation.
/.ers seem to dislike Visual Basic. There can only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance. There may be a lot of things that can be done better in VB. However, VB and Access have quite a large amount of self knowledge. You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge, even worse, these languages require you to code details that are of no interest to problem at hand. C/C++ is for people who don't understand programming. What is programming? It's rather simple: A is the amount of time you have, and B is the result that you need. If you then chose C/C++, you should go and see a shrink.
Bit-level performance is a non-issue for most programmers. The operative word here is "most". What do most people write anyway? Well, just look at who is paying most programmers: corporations. What do they need from programmers? Programs that run their business, that is, programs that help with order processing, manufacturing, payroll, accounting, and so on. Most of these programs spend 95% of their time in larger frameworks that manage the databases, the GUIs, et cetera. Therefore, your language of choice may be fast or slow, it won't make any difference. If you want speed in these applications, chose a fast database, a fast GUI framework and fast, other supportive components.
Object orientation is another one of these miracle cure-all solutions that almost never work, even though no one will openly admit it. By modeling business apps as objects, you will not only lose a lot of time, but, even worse, make your applications much less maintainable. Why so? Because the complexity of business applications is in their data, and the only thing you will do by modeling business applications as object frameworks, is to replicate this complexity once more in your object classes. And then you will have an extra chunk of code to maintain, when you change your database structures. Next to your database design, your GUIs and your batches that you need to maintain, you will need to maintain the so-called business objects. These business objects "know" your data structure, and, therefore, have to be informed of changes in it. The duplication effort is ridiculous and only pays off in wasted time.
The whole concept of business objects is a laughable hype. Quite naturally, the more someone is ignorant and incompetent, the more he will jump from one hype to another, trying to use the latest fad, and miserably fail. This is normal, because the only way incompetent people can judge a technology, is by hyping along with the rest.
I didn't say that object orientation is a bad idea altogether. I've said that it is of no use in typical business applications, and even dangerous.
What is a true criterion for quality in a language/tool? Well, as ever. It's definitely not new. Read the classical Greek literature for the source of true wisdom. A language/tool is of high quality if it has a high level of self-knowledge.
A relational database is a great tool, primarily, because of its self-knowledge. You can ask it what tables it contains, what relationships there are between those tables, what columns they contain, what datatype they have, and so on. You don't need to enumerate all fields in a particular table in your program. You may prefer to work at a more abstract level, and define rules that work in general, and only mention the exceptions to the rule. Therefore, You may manage your code by exceptions, instead of replicating knowledge all over the system, and create potential for inconsistencies.
Most
I totally agree with Red Hat.
The product they sell, is not only a copy of the linux cd, but an amount of free support as well.
I think, indeed, that the vendors who copy the Red Hat cd, should say either "a copy of the Red Hat cd" or "based on the Red Hat cd", or something equivalent, that clearly distinguishes their product from the services sold by Red Hat.
Maybe Red Hat too should distinguish the cd more clearly from the total product they sell.
I think it's in their interest to emphasize that they are not selling the cd or its content, especially not the content. They should make clear that they are actually selling the support service that the buyer is entitled to, and that the CD is just added for convenience.
From a business point of view, selling the cd or the content do not make sense for the Red Hat company; as you can freely copy it. As a matter of fact, people who are not interested in the support service should not buy the CD from Red Hat, but buy it from one of the cheaper resellers.
Frankly, I think Red Hat would do consumers a favour, by unbundling the support service from the CD by itself. They should sell the CD at a realistic market price, much below its current price, and offer the support service separately, probably at a much higher price. It's also fairer to consumers who buy the CD, without ever having the intention to use the support service. Furthermore, the people who want to buy support, are most likely willing to pay much more.
By bundling both the support and the service, Red Hat raises suspicion.
Are they waiting for enough market share and volume to simply fork from Linux, and produce some kind of semi-proprietary version, in which free and non-free software are inextricable mixed, making the free content unfree? After which they can capitalize on the market share Red Hat name, built using free resources, to disallow the freely copying of the CD, and in effect insisting on a license fee per copy?
Therefore, I think the GPL should be adapted quickly, to prohibit that practice of putting GPLed software on a single medium together with proprietary software, in effect removing from the buyer the freedom to copy the free content, because he is not allowed to copy the proprietary content.
Linux is better than Windooz?
By far and by large, companies prefer to shell out cash, and massively, to Micros~1, rather than deploying linux. And price is the issue!
A $150 dollar is approximately the price for 1 Windooz license. For $150 you can waste 2 hours in development. There is no way that you will lose less than 2 hours per linux installed, using linux tools. You will lose a multiple of that.
There is simple not one single decent RAD tool for linux to crank out client/server business-database applications, that will enable the company to manage sales orders, invoices, bills of materials, time sheets, and so on.
Therefore, buggy as it is, Windooz is cheap and linux, free as it is, damn expensive.
*** OS without RAD tool? OS suuucks!!! ***