You are right of course that the human body does make use of modularization, as well- But not always.
My main point is just that 10 years ago it was pretty foolish not to learn object-oriented programming, because it had a lot of great ideas to offer-
Recently, however, I have been amazed by some great stuff you can do with techniques that are pretty much entirely incompatible with OOP programming and have led me to revisit my views on OOP in terms of program design in general.
> That doesn't mean that all layers are actual code,but can be just proxies for a possibility.
If you look at a button control in the latest iteration of.NET, it has 18 levels of inheritance above it, all designed for these kinds of hooks. Are you able to break the concept of a button into 18 separate levels? I can't. Do you think this is a good design? I don't.
> an engineer makes things as modular as they need to be and no more. But they design so that they can replace with better technology later.
If that was really the case, I think that line of reasoning would be justifiable. Personally, though, I find a lot of the complex software written that I have to deal with is filled with good modularization intentions that would have been a lot less problematic if people had thought to themselves "Don't write what I don't need right now, today."
> You don't know what you are talking about
You make some good points. Why follow them with attacks?
> This is why your job is being exported to India. It's easier to stomach incompetent development for pennies on the dollar.
I think my statements about parts serving only one function versus multiple functions was arguably, legitimately, interesting and on-topic for this discussion, Anonymous Coward.
There is no doubt that MVC is a great concept and a useful vocabulary for communicating with other programmers. Must of the GOF book, in my opinion, is overrated, however. Look at patterns like the Singleton, for instance, for an example reams of source code that virtually serves no actual function.
> The fact that you even have it out for modularization...
A pretty radical notion, I admit. But clearly things can be well designed without modularization (like the human mouth, as an example) My point is that breaking things down until each part only performs one function is not always automatically the correct approach. There are other, still less common, paradigms to cleanly structure programs (like "referential transparency", "domain specific languages", "higher order functions") that do not carry as heavy complexity penalies as traditional OOP modularization.
Of course, modularization needs to be understood properly as a concept by anyone who wishes to break the rules and use more modern organizational techniques.
Engineers love to break things into smaller parts, each part serving one and only one function, like pulleys, shafts, rotors, etc.
For really effective design each part has to serve multiple functions, like evolution is able to do: The human mouth can be used to eat, breathe, talk, etc etc.
That's why a robot can't compete with an animal- In a robot each part usually severs only one function, making the machine inefficient as a whole.
This problem is just magnified in computer software and will only get worse unless engineers start changing their tune. I think the worst offender of this philosophy is object oriented programming: It's the ultimate embodyment of this philosophy- Most big object-oriented software have only about 2-3% of code that performs any real work, with the rest only is window dressing to fulfill the engineer's urge to "modularize".
The best software I see seems to be written either in more pragmatic procedural styles, or uses better mathematical underpinnings for its structure, like you'll find in functional programming languages (Haskell, Lisp, etc.)
Toolbar buttons require a lot of work from the user- You have to memorize them, or take time reading the tooltip to learn what they are for. Usually it is much better to put commands into menus with regular text since you can tell what they do by their text.
However, sometimes a command is used so frequently that it is worth forcing the user to learn to use a toolbar button, because toolbar buttons have some important advantages:
1. They take up less space and because of that can be left on the screen all the time 2. The human eye is great at recognizing toolbar icon once they're meaning has been learned
But usually, making a toolbar button for a command is a bad idea, unless you know otherwise. Look at Firefox: It only has 5 buttons on its basic toolbar and places everything else into the menus- Great design!
Peter is the author of "Paradigms of Artificial Intellignece Programming", a cornerstone of LISP programming and A.I.
He dissects the political issues for this debate with great reason and skill:
http://www.norvig.com/hiring-president.html
Please vote tomorrow! It's important!
-Conrad Barski
Open source has two main strengths:
1. quality
2. easy fixes/improvements
The minor successes so far I think are clearly due to quality: Even mainstream technology enthusiasts can recognize that Apache, Firefox, and a few other tools are super-solid and finely-tuned applications.
But appreciation for a specific application does not translate into success for open-source as a whole, because it does not engage the user in the paradigm of open source.
But someday, the second strength of open source will become more evident: The ease with which it can be fixed and improved, and by this I mean improvements that are personal and specific to the user, something that is still very rare and unappreciated.
Consider, for instance, an average user of a mail program muttering to him/herself "I wish my email program could set off my alarm clock if I get an early email from work in the morning..." Suppose that person could post $100 improvement fee to a website, where it might be merged with similar requests from other users and leads to a new extension to be developed by an independent developer...
This idea is often discussed, but it is still only in its infancy. However, I believe it is critical for the success of open source, because it both engages the user in the OS philosophy and also allows a viable financial model to exist for mainstream software companies to participate in the OS revolution.
If you look at the video carefully you will see that this system uses a dictionary to work: Certain motions on the keyboard are ambiguous, requiring the system to compare it against the dictionary (pay special attention to the popup menu half-way through the video).
ream ember tea probe lamb with the Apple Newton?
Dictionary systems always look great in a demo, but the great advantage of Grafitti-like systems like on the Palms is that you can type anything and it works even if its not in the dictionary!
Borland has always had brilliantly creative and powerful development tools. If you've ever used Borland Builder you know what a wonderful tool it was. Delphi (basically the same design but using Pascal instead of C++) is still eekeing by.
But what Borland had to offer (OK performance with OK ease of use) has just been a loser's strategy in the current market place. Performance just isn't as important as it used to be, allowing Java and VB (which typically have worse performance) to eat Delphi's & Builder's lunch.
The future is all about a 100% focus on ease of use in a programming tool- Performance has now been delegated to be an afterthought, as evidenced by the popularity of tools such as JIT compilers and VMs, which place language flexibility first and allow the performance to still remain acceptable.
Companies like Borland that sacrifice some of the ease-of-use and RAD abilities of their tools in exchange for better performance via static compilation and language constructs that emphasize performance (no garbage collection in Delphi, for instance) are bound to become extinct at the hands of Moore's Law.
Slashdot Mirror
You are right of course that the human body does make use of modularization, as well- But not always.
My main point is just that 10 years ago it was pretty foolish not to learn object-oriented programming, because it had a lot of great ideas to offer- Recently, however, I have been amazed by some great stuff you can do with techniques that are pretty much entirely incompatible with OOP programming and have led me to revisit my views on OOP in terms of program design in general.
good points.
> That doesn't mean that all layers are actual code,but can be just proxies for a possibility.
.NET, it has 18 levels of inheritance above it, all designed for these kinds of hooks. Are you able to break the concept of a button into 18 separate levels? I can't. Do you think this is a good design? I don't.
If you look at a button control in the latest iteration of
> an engineer makes things as modular as they need to be and no more. But they design so that they can replace with better technology later.
If that was really the case, I think that line of reasoning would be justifiable. Personally, though, I find a lot of the complex software written that I have to deal with is filled with good modularization intentions that would have been a lot less problematic if people had thought to themselves "Don't write what I don't need right now, today."
> You don't know what you are talking about
You make some good points. Why follow them with attacks?
> This is why your job is being exported to India. It's easier to stomach incompetent development for pennies on the dollar.
I think my statements about parts serving only one function versus multiple functions was arguably, legitimately, interesting and on-topic for this discussion, Anonymous Coward.
--Conrad Barski
> ... Model-View-Controller ...
There is no doubt that MVC is a great concept and a useful vocabulary for communicating with other programmers. Must of the GOF book, in my opinion, is overrated, however. Look at patterns like the Singleton, for instance, for an example reams of source code that virtually serves no actual function.
> The fact that you even have it out for modularization...
A pretty radical notion, I admit. But clearly things can be well designed without modularization (like the human mouth, as an example) My point is that breaking things down until each part only performs one function is not always automatically the correct approach. There are other, still less common, paradigms to cleanly structure programs (like "referential transparency", "domain specific languages", "higher order functions") that do not carry as heavy complexity penalies as traditional OOP modularization.
Of course, modularization needs to be understood properly as a concept by anyone who wishes to break the rules and use more modern organizational techniques.
Engineers love to break things into smaller parts, each part serving one and only one function, like pulleys, shafts, rotors, etc.
For really effective design each part has to serve multiple functions, like evolution is able to do: The human mouth can be used to eat, breathe, talk, etc etc.
That's why a robot can't compete with an animal- In a robot each part usually severs only one function, making the machine inefficient as a whole.
This problem is just magnified in computer software and will only get worse unless engineers start changing their tune. I think the worst offender of this philosophy is object oriented programming: It's the ultimate embodyment of this philosophy- Most big object-oriented software have only about 2-3% of code that performs any real work, with the rest only is window dressing to fulfill the engineer's urge to "modularize".
The best software I see seems to be written either in more pragmatic procedural styles, or uses better mathematical underpinnings for its structure, like you'll find in functional programming languages (Haskell, Lisp, etc.)
My apologies for living up to my user name!
Conrad Barski
I remember these were being touted a couple of years ago by Splashpower: link
My guess is these just take too long to charge your phone... or is there another reason these never caught on?
Toolbar buttons require a lot of work from the user- You have to memorize them, or take time reading the tooltip to learn what they are for. Usually it is much better to put commands into menus with regular text since you can tell what they do by their text.
However, sometimes a command is used so frequently that it is worth forcing the user to learn to use a toolbar button, because toolbar buttons have some important advantages:
1. They take up less space and because of that can be left on the screen all the time
2. The human eye is great at recognizing toolbar icon once they're meaning has been learned
But usually, making a toolbar button for a command is a bad idea, unless you know otherwise. Look at Firefox: It only has 5 buttons on its basic toolbar and places everything else into the menus- Great design!
Peter is the author of "Paradigms of Artificial Intellignece Programming", a cornerstone of LISP programming and A.I. He dissects the political issues for this debate with great reason and skill: http://www.norvig.com/hiring-president.html Please vote tomorrow! It's important! -Conrad Barski
Open source has two main strengths:
1. quality
2. easy fixes/improvements
The minor successes so far I think are clearly due to quality: Even mainstream technology enthusiasts can recognize that Apache, Firefox, and a few other tools are super-solid and finely-tuned applications.
But appreciation for a specific application does not translate into success for open-source as a whole, because it does not engage the user in the paradigm of open source.
But someday, the second strength of open source will become more evident: The ease with which it can be fixed and improved, and by this I mean improvements that are personal and specific to the user, something that is still very rare and unappreciated.
Consider, for instance, an average user of a mail program muttering to him/herself "I wish my email program could set off my alarm clock if I get an early email from work in the morning..." Suppose that person could post $100 improvement fee to a website, where it might be merged with similar requests from other users and leads to a new extension to be developed by an independent developer...
This idea is often discussed, but it is still only in its infancy. However, I believe it is critical for the success of open source, because it both engages the user in the OS philosophy and also allows a viable financial model to exist for mainstream software companies to participate in the OS revolution.
How can we make this happen?
If you look at the video carefully you will see that this system uses a dictionary to work: Certain motions on the keyboard are ambiguous, requiring the system to compare it against the dictionary (pay special attention to the popup menu half-way through the video).
ream ember tea probe lamb with the Apple Newton?
Dictionary systems always look great in a demo, but the great advantage of Grafitti-like systems like on the Palms is that you can type anything and it works even if its not in the dictionary!
video
Borland has always had brilliantly creative and powerful development tools. If you've ever used Borland Builder you know what a wonderful tool it was. Delphi (basically the same design but using Pascal instead of C++) is still eekeing by. But what Borland had to offer (OK performance with OK ease of use) has just been a loser's strategy in the current market place. Performance just isn't as important as it used to be, allowing Java and VB (which typically have worse performance) to eat Delphi's & Builder's lunch. The future is all about a 100% focus on ease of use in a programming tool- Performance has now been delegated to be an afterthought, as evidenced by the popularity of tools such as JIT compilers and VMs, which place language flexibility first and allow the performance to still remain acceptable. Companies like Borland that sacrifice some of the ease-of-use and RAD abilities of their tools in exchange for better performance via static compilation and language constructs that emphasize performance (no garbage collection in Delphi, for instance) are bound to become extinct at the hands of Moore's Law.