And even if the program was incredibly flexible, I still would rather do it myself. I don't need any more programs controlling all of my data in a centralized place.
I think you are overreacting a bit. This is a research project after all so it's hardly perfect. What about your current OS, doesn't it "control all your data in a centralized place"? How is this different except for being more convenient? Do you actually care if the programs operating on your data are different processes, or plugin threads? Do you actually care what the underlying data representation is as long as its fairly efficient and allows for convenient operations=
I personally think contextual right-click menus are very convenient because they group functionality not by application, but by task. E.g. When you manage files you might also want to rename one, so that can be put in a contextual menu. The way computers work today is not an expression of great freedom that projects like Haystack endanger, but the result of systems evolution. This means that some rough points aren't being fixed even though there underlying reasons have gone away with newer hardware ages ago. Haystack-like things just offer a different views, if they are any good they might survive, otherwise they will die without causing any harm.
I don't view AI as "AI" -- it's mostly types of AI. To me, AI is something that is entirely abstract enough to handle tasks (Think self-configuring Universal Turing Machine) -- otherwise it's just statistical programs over very broad data sets.
I might misunderstand you, but does this not mean that the "AI"-methods used by Haystack would not be AI? I also have some Neural Network / Statistical processing background so I tend to share this same view that the intelligence is in the designer not in the program. However, the term AI is often used to describe both neural and statistical methods. Actually neural networks could also be perceived as statistical methods. I don't know about fuzzy logic but my intuition tends hint that they arent fundamentally very different either, just based on different mathematical theory.
To return to your relational filesystem idea, I would prefer having both relational search capabilities and google-like utilization of implicit information. I don't know about you, but I certainly am not very good at being consistent, so search and selection methods allowing some kind of fuzziness criteria would certainly be nice. The basic OS could still work with files, but my personal information should be organized in some more practical way, and should preferably be available all the time from diverse clients (home computer, work computer, PDA, cellphone...).
The "does one thing, and does it very well" philosophy was based on systems where you could integrate these utilities easily with each other, the UNIX command-line. Haystack is actually similar after a fashion, it makes all information processable within the same framework. With desktop applications you have a separated information into different applications that work on different information. What you would actually want to do is separate the different tasks into specialized interfaces optimized for that task, keeping the information processable by other programs when needed.
Receptionists might be stupid and AIs are not that bright either, but you must admit that a local google probably would allow finding the contact people anyway just based on contextual information.
To properly categorize music (in my opinion at least, which admittedly counts for little) the best technique would be to separate and identify the individual instruments (voices) in the song.
This is probably the "correct" way to categorize music, but since even humans have a hard time categorizing music I believe an automatic analyzer would have a hard time generating good results. Have you noticed that every band is X-Y with a touch of Z and W, where {X,Y,Z,W} are music styles? Then when you actually hear the music it's nowhere near what you expected based on the description.
A more useful (though boring) way to categorize music would be by doing statistical inference based on which songs the user listens to a lot. Then compare that with what people with similar preferences listen to (by some non-orwellian means) using for instance clustering or similar methods.
The problem with the term AI is that it usually when something "AI" starts to work well it's being called something else. Remember that compilers and information retrieval (google) used to be AI once. This begs the question: What did you mean when you said fuzzy logic, but not AI?
Is AI as in symbolic AI (search-based etc.)? It seems to me that all sensible information categorization systems, even those built on top of fuzzy logic could reasonably be called AI. Google uses very sophisticated data-categorization algorithms, or at least it seems so based on my search results. Those are probably based on statistical classifiers and other such AI techniques.
I guess someone should point out that even though this is indeed the quicksort algorithm, it does not sort in-place, but allocates temporary storage for the intermediate lists. The in-place sorting is a very significant reason behind quicksort's tremendous performance when sorting arrays in imperative languages. If one is going to use temporary storage, then why not use merge-sort instead which is guaranteed O(N log(N)) worst case, and has simpler code (at least in C)?
Yes type safety is certainly an issue, but I don't think that's the whole point since many type safe environments I've used don't suffer from the same problems. I think these environments verify type-safety at compile time instead of startup time. This is of course less safe, but could be at least "safe enough" using some sort of cryptographic scheme for signing the binaries. It's probably the dynamic class loading that prevents Java from checking type safety at compile time but I'm no expert in these matters.
The final declaration idea certainly makes sense to some degree, but there must be some reason why the JIT doesn't use the information for inlining. Is there some reason to avoid inlining of function calls in Java in general? Could it be that since most function calls have to be dynamically dispatched anyway it doesn't pay to optimize for the relatively rare case when it's possible to inline?
Echidna certainly seems like an interesting project. It is very unfortunate that the OS is so strongly biased towards C-style runtimes, but I guess this is very difficult to avoid. This is unfortunate because it means we will be stuck with either slow startup/bad general performance or C-style programming languages. The natural selection of "right tool for the right job" becomes severely biased towards tools which are hardly optimal for describing the program one wants to create.
But what kinds of theories are those you mention? Since you are comparing the computation with the human brain, I assume you are talking about some sort of neural simulation. However all neural simulations I've heard of are some sort of glorified statistical optimizers (MLP, Recurrent networks, etc.). They approximate some sort of function, nothing more. Then there are of course the unsupervised methods, but they pretty much just sort large amounts of data according to some previously known criteria, so they are more a case of intelligence of the author than the computer system.
If I've understood correctly we still know very little about the internal functioning of the human brain on the theoretical level. Not by far enough to reverse engineer any significant parts of it.
UML is mostly meant to be a standard notation to aid communication between people. UML is not merely a design language, but also an analysis language that can be used to model the problem domain. To do this kind of analysis in a programming language would hardly be a good idea
UML is fundamentally OO so impedance matches between UML and OO-languages should not become very big. It's a recommended practice to do design models in UML using the constraints of the implementation language. For instance UML has no problem with multiple inheritance, but Java does not support it, so systems developed in Java should not be modeled using multiple inheritance.
I agree with you that his argument about languages is rubbish, especially as he describes languages that are fundamentally so similar, that one would be best off picking the one with the best libraries for the task. This whole notion that the programming language should protect people from their own bad programming is also very stupid (which Booch also said). Bad programming is always possible. Of course I'd rather have Java created by monkeys than C created by monkeys, but neither is going to be very good. I'm not certain I'd prefer Java by geniuses over C from geniuses.
Not exactly what you are refering to, but from "The Dilbert Future":
Young people often ask me how they should prepare for the job markets od the future. Obviously, they're trying to steal all of my career secrets so they can take my job and leave me homeless and broke. I generally try to steer young people toward a life of crime in the inner cities, because I never go to the inner cities and I figure that's as good a place as any for crime.
In my opinion it's not so much about too much choice but rather too little integration. I don't dislike the fact that I can run programs developed with different toolkits, what I don't like is that they have to be configured separately, use different keybindings, don't copy/paste properly (not a problem with Gnome/KDE but some apps use other toolkits), don't have semantically equivalent buttons in the same places and so on. Now you might be thinking "Oh, what an idiot, he can't even figure out how to use something if the buttons are in different places", but that's not the point. The point is, every time one must consciously think about where a certain button is, it slows you down.
Now that you mentioned choice I certainly don't mind having choice, I would just like to have choice in a well integrated way. I know this is far from simple to provide but just to explain my opinion more concretely I'll describe The Way I Would Like It(tm):
I don't like start menus, I want a configurable option for something else (be it a dock like OSX or something completely different)
Overlapping windows should also be an option one could disable, the screen estate issues could perhaps be solved by zooming and scrolling (if anyone knows such a windowmanager please reply)
Everything having to do with user interaction is configured in the same place, keybindings, mouse configuration, locales etc.
Replace file dialogs with a filemanager instance. If one is already running use that one otherwise start a new one.
Integrate a command-line interface into the filemanager. Konqueror lets one embed an xterm, but it should follow the xterm so that when one types "cd foo" it would display the foo directory. Similarly if one clicks the TAB key it should display the possible completions and so on
But that's the way publishers want it, because it gives them 95% of the revenue.
Always those evil publishers, eh. I don't know if I read the same article you did but what I thought it said was that publishers wanted repeatability and therefore prefer sequels and license games. Developers who want to create great games should not develop what they believe that the publishers want, because the publishers are trying to solve a completely different problem than the game developers.
We theme almost everything - sawfish, metacity, gtk, nautilus, xmms, make splash screens, wallpapers, background tiles etc, making it all fit togerther
Would it not be a lot easier to achieve consistency on the desktop if all these applications used the same theming engine? I know there are people out there who like having nautilus look different from other applications and xmms look different than anything else, but there are also people who like the look and feel to be as consistent as possible, ideally so that even KDE applications would look similar to gnome apps. I know that it is not in any way trivial to provide the same theming for all apps but it would definitely be a very nice and useful feature. And while we're at it why not make all applications use the same keybindings for the same things? Isn't that very similar to themeing at least from a technical point of view?
I'm one of those people who really hates the adaptive menus. One should understand that the primary problem is not adaptation in itself, for instance the "Documents" menu in Windows that keeps recently opened documents is really useful, not to mention browser history. The problem is that the adaptive menus in Office 2K hide options that I might be looking for and that the options I've used recently suddenly appear in the wrong place. The solution to these problems would be to make finding the options one is looking for easier. Currently the only thing one can perform searches on is the Help system. For open source software the Help system is often non-existent or out of date, and even if it would be good it might not be the best way to find what you are looking for since you find an entry in the Help system rather than "the real thing". An alternative to this would be to make all (or at least most) help entries strictly part of the UI, that is make them all contextual Help in the fashion "this button performs replacement of all words 'aggghhh' to the word 'argggghh'". This information should then be searchable by an engine that would understand the semantics of the help information. Menu entry labeled "AutoCorrect" contains help entry that describes the functionality and both the labels and the help entries are indexed for searching. Ideally this functionality could be provided on the desktop level so the user would not even have to know in advance exactly which application to use or which option to adjust in order to performed the task he wanted to.
I agree with you that lots of irrelevant menu choices really is a very valid usability issue, compare for instance XCDRoast to some Windows cd-burning software. The problem is that in order to have the few correct options in the right places, the application designer needs to define the tasks their users will do most often. This is easier in an environment where planning is done first, rather than in a bazaar style evolutionary development process. To this also adds up the fact that open source users are often more technically skilled, and therefore suggest (and program) lots of features that the software might do (but maybe from a UI perspective should not).
It only makes sense when everything is "part of the operating system"
This might be very much offtopic, but this is actually one of those things that actually makes windows usability better: Integration. There are standard services for certain tasks. Even though the libraries have not stabilized yet, why not deploy them as a part of the operating system (or call it distribution if you like that word better). It is evil only in the case it creates security holes ala IIS or cannot be removed ala DirectX.
It's certainly cool, but what is so scary about it? That there will suddenly be more diversity in programming languages used? So someone who is very good with a certain language can really leverage that advantage since they don't have to code their own library bindings as well as the program.
Spinning folder icon? Shudder, we hates everything that moves without a reason, reminds us of nassty Clippy. Seriously though the information communicated by icons could be increased. The changing mailbox icon for "You've got mail" is familiar to all of us, but there could be lots of other uses. For instance download dialogs could minimize to icons and change color depending of their degree of completeness (a complete download glows of translucent green). The taskbar items of programs could turn more red when the program is using lots of CPU and so on.
Personally I suspect there's not a great deal of point in making icons vector
I agree but this is a step towards an all vector desktop which could have lots of cool applications for instance a zoomable user interface or something similar.
The only problem is how could this bug be 'harmful' to a host system if the prime directive was self perseverance?
This is so very true. I wonder how many virii just sit on thousands of computers doing absolutely nothing except for spreading slowly. Detecting such a virus would be very difficult if it doesn't cause lots of network traffic or leave other similar traces.
The next gen virii you mention sound a lot like the worms described in this this k5 article. But should viruses evolve to something like this, I still think that it would be possible to protect systems from them. It would take more powerful means and might need systems to be more isolated from networks around them but I certainly think it would be possible (By somehow sandboxing everything coming in from a network, treating programs that are not from the original install as tainted and sandbox them as well etc.).
Pointless? How is hunting worms pointless? Just because there will appear new ones doesn't mean we shouldn't clean machines that still have Code Red or Nimda and try to correct security related bugs before some new worm exploits them.
Your comparison to **AA is somehow off since **AA is more about a few big organisations wanting to control everybody while worms are something everybody except for a few individuals want to get rid of.
The point of unit testing is to test the units of some software (classes in OO systems), as opposed to testing the system as a whole for instance. What you described was test-first development which uses unit tests.
I think the original poster meant their software identifies test methods using reflection just like jUnit does, not that it generates tests from the actual code.
Slashdot Mirror
And even if the program was incredibly flexible, I still would rather do it myself. I don't need any more programs controlling all of my data in a centralized place.
I think you are overreacting a bit. This is a research project after all so it's hardly perfect. What about your current OS, doesn't it "control all your data in a centralized place"? How is this different except for being more convenient? Do you actually care if the programs operating on your data are different processes, or plugin threads? Do you actually care what the underlying data representation is as long as its fairly efficient and allows for convenient operations=
I personally think contextual right-click menus are very convenient because they group functionality not by application, but by task. E.g. When you manage files you might also want to rename one, so that can be put in a contextual menu. The way computers work today is not an expression of great freedom that projects like Haystack endanger, but the result of systems evolution. This means that some rough points aren't being fixed even though there underlying reasons have gone away with newer hardware ages ago. Haystack-like things just offer a different views, if they are any good they might survive, otherwise they will die without causing any harm.
I don't view AI as "AI" -- it's mostly types of AI. To me, AI is something that is entirely abstract enough to handle tasks (Think self-configuring Universal Turing Machine) -- otherwise it's just statistical programs over very broad data sets.
I might misunderstand you, but does this not mean that the "AI"-methods used by Haystack would not be AI? I also have some Neural Network / Statistical processing background so I tend to share this same view that the intelligence is in the designer not in the program. However, the term AI is often used to describe both neural and statistical methods. Actually neural networks could also be perceived as statistical methods. I don't know about fuzzy logic but my intuition tends hint that they arent fundamentally very different either, just based on different mathematical theory.
To return to your relational filesystem idea, I would prefer having both relational search capabilities and google-like utilization of implicit information. I don't know about you, but I certainly am not very good at being consistent, so search and selection methods allowing some kind of fuzziness criteria would certainly be nice. The basic OS could still work with files, but my personal information should be organized in some more practical way, and should preferably be available all the time from diverse clients (home computer, work computer, PDA, cellphone...).
The "does one thing, and does it very well" philosophy was based on systems where you could integrate these utilities easily with each other, the UNIX command-line. Haystack is actually similar after a fashion, it makes all information processable within the same framework. With desktop applications you have a separated information into different applications that work on different information. What you would actually want to do is separate the different tasks into specialized interfaces optimized for that task, keeping the information processable by other programs when needed.
Receptionists might be stupid and AIs are not that bright either, but you must admit that a local google probably would allow finding the contact people anyway just based on contextual information.
Very insightful post I must admit.
To properly categorize music (in my opinion at least, which admittedly counts for little) the best technique would be to separate and identify the individual instruments (voices) in the song.
This is probably the "correct" way to categorize music, but since even humans have a hard time categorizing music I believe an automatic analyzer would have a hard time generating good results. Have you noticed that every band is X-Y with a touch of Z and W, where {X,Y,Z,W} are music styles? Then when you actually hear the music it's nowhere near what you expected based on the description.
A more useful (though boring) way to categorize music would be by doing statistical inference based on which songs the user listens to a lot. Then compare that with what people with similar preferences listen to (by some non-orwellian means) using for instance clustering or similar methods.
The problem with the term AI is that it usually when something "AI" starts to work well it's being called something else. Remember that compilers and information retrieval (google) used to be AI once. This begs the question: What did you mean when you said fuzzy logic, but not AI?
Is AI as in symbolic AI (search-based etc.)? It seems to me that all sensible information categorization systems, even those built on top of fuzzy logic could reasonably be called AI. Google uses very sophisticated data-categorization algorithms, or at least it seems so based on my search results. Those are probably based on statistical classifiers and other such AI techniques.
Sounds like your missing "." from your CLASSPATH
SET CLASSPATH=.
should fix your problem
I guess someone should point out that even though this is indeed the quicksort algorithm, it does not sort in-place, but allocates temporary storage for the intermediate lists. The in-place sorting is a very significant reason behind quicksort's tremendous performance when sorting arrays in imperative languages. If one is going to use temporary storage, then why not use merge-sort instead which is guaranteed O(N log(N)) worst case, and has simpler code (at least in C)?
Yes type safety is certainly an issue, but I don't think that's the whole point since many type safe environments I've used don't suffer from the same problems. I think these environments verify type-safety at compile time instead of startup time. This is of course less safe, but could be at least "safe enough" using some sort of cryptographic scheme for signing the binaries. It's probably the dynamic class loading that prevents Java from checking type safety at compile time but I'm no expert in these matters.
The final declaration idea certainly makes sense to some degree, but there must be some reason why the JIT doesn't use the information for inlining. Is there some reason to avoid inlining of function calls in Java in general? Could it be that since most function calls have to be dynamically dispatched anyway it doesn't pay to optimize for the relatively rare case when it's possible to inline?
Echidna certainly seems like an interesting project. It is very unfortunate that the OS is so strongly biased towards C-style runtimes, but I guess this is very difficult to avoid. This is unfortunate because it means we will be stuck with either slow startup/bad general performance or C-style programming languages. The natural selection of "right tool for the right job" becomes severely biased towards tools which are hardly optimal for describing the program one wants to create.
The slow startup time is probably one of the biggest reasons why people repeat the "Java is slow" mantra. It's more that Java feels slow.
OK, so we need more powerful computers.
But what kinds of theories are those you mention? Since you are comparing the computation with the human brain, I assume you are talking about some sort of neural simulation. However all neural simulations I've heard of are some sort of glorified statistical optimizers (MLP, Recurrent networks, etc.). They approximate some sort of function, nothing more. Then there are of course the unsupervised methods, but they pretty much just sort large amounts of data according to some previously known criteria, so they are more a case of intelligence of the author than the computer system.
If I've understood correctly we still know very little about the internal functioning of the human brain on the theoretical level. Not by far enough to reverse engineer any significant parts of it.
UML is mostly meant to be a standard notation to aid communication between people. UML is not merely a design language, but also an analysis language that can be used to model the problem domain. To do this kind of analysis in a programming language would hardly be a good idea
UML is fundamentally OO so impedance matches between UML and OO-languages should not become very big. It's a recommended practice to do design models in UML using the constraints of the implementation language. For instance UML has no problem with multiple inheritance, but Java does not support it, so systems developed in Java should not be modeled using multiple inheritance.
I agree with you that his argument about languages is rubbish, especially as he describes languages that are fundamentally so similar, that one would be best off picking the one with the best libraries for the task. This whole notion that the programming language should protect people from their own bad programming is also very stupid (which Booch also said). Bad programming is always possible. Of course I'd rather have Java created by monkeys than C created by monkeys, but neither is going to be very good. I'm not certain I'd prefer Java by geniuses over C from geniuses.
Now that you mentioned choice I certainly don't mind having choice, I would just like to have choice in a well integrated way. I know this is far from simple to provide but just to explain my opinion more concretely I'll describe The Way I Would Like It(tm):
But that's the way publishers want it, because it gives them 95% of the revenue.
Always those evil publishers, eh. I don't know if I read the same article you did but what I thought it said was that publishers wanted repeatability and therefore prefer sequels and license games. Developers who want to create great games should not develop what they believe that the publishers want, because the publishers are trying to solve a completely different problem than the game developers.
We theme almost everything - sawfish, metacity, gtk, nautilus, xmms, make splash screens, wallpapers, background tiles etc, making it all fit togerther
Would it not be a lot easier to achieve consistency on the desktop if all these applications used the same theming engine? I know there are people out there who like having nautilus look different from other applications and xmms look different than anything else, but there are also people who like the look and feel to be as consistent as possible, ideally so that even KDE applications would look similar to gnome apps. I know that it is not in any way trivial to provide the same theming for all apps but it would definitely be a very nice and useful feature. And while we're at it why not make all applications use the same keybindings for the same things? Isn't that very similar to themeing at least from a technical point of view?
I'm one of those people who really hates the adaptive menus. One should understand that the primary problem is not adaptation in itself, for instance the "Documents" menu in Windows that keeps recently opened documents is really useful, not to mention browser history. The problem is that the adaptive menus in Office 2K hide options that I might be looking for and that the options I've used recently suddenly appear in the wrong place. The solution to these problems would be to make finding the options one is looking for easier. Currently the only thing one can perform searches on is the Help system. For open source software the Help system is often non-existent or out of date, and even if it would be good it might not be the best way to find what you are looking for since you find an entry in the Help system rather than "the real thing". An alternative to this would be to make all (or at least most) help entries strictly part of the UI, that is make them all contextual Help in the fashion "this button performs replacement of all words 'aggghhh' to the word 'argggghh'". This information should then be searchable by an engine that would understand the semantics of the help information. Menu entry labeled "AutoCorrect" contains help entry that describes the functionality and both the labels and the help entries are indexed for searching. Ideally this functionality could be provided on the desktop level so the user would not even have to know in advance exactly which application to use or which option to adjust in order to performed the task he wanted to.
I agree with you that lots of irrelevant menu choices really is a very valid usability issue, compare for instance XCDRoast to some Windows cd-burning software. The problem is that in order to have the few correct options in the right places, the application designer needs to define the tasks their users will do most often. This is easier in an environment where planning is done first, rather than in a bazaar style evolutionary development process. To this also adds up the fact that open source users are often more technically skilled, and therefore suggest (and program) lots of features that the software might do (but maybe from a UI perspective should not).
It only makes sense when everything is "part of the operating system"
This might be very much offtopic, but this is actually one of those things that actually makes windows usability better: Integration. There are standard services for certain tasks. Even though the libraries have not stabilized yet, why not deploy them as a part of the operating system (or call it distribution if you like that word better). It is evil only in the case it creates security holes ala IIS or cannot be removed ala DirectX.
It's certainly cool, but what is so scary about it? That there will suddenly be more diversity in programming languages used? So someone who is very good with a certain language can really leverage that advantage since they don't have to code their own library bindings as well as the program.
Spinning folder icon? Shudder, we hates everything that moves without a reason, reminds us of nassty Clippy. Seriously though the information communicated by icons could be increased. The changing mailbox icon for "You've got mail" is familiar to all of us, but there could be lots of other uses. For instance download dialogs could minimize to icons and change color depending of their degree of completeness (a complete download glows of translucent green). The taskbar items of programs could turn more red when the program is using lots of CPU and so on.
Personally I suspect there's not a great deal of point in making icons vector
I agree but this is a step towards an all vector desktop which could have lots of cool applications for instance a zoomable user interface or something similar.
The only problem is how could this bug be 'harmful' to a host system if the prime directive was self perseverance?
This is so very true. I wonder how many virii just sit on thousands of computers doing absolutely nothing except for spreading slowly. Detecting such a virus would be very difficult if it doesn't cause lots of network traffic or leave other similar traces.
The next gen virii you mention sound a lot like the worms described in this this k5 article. But should viruses evolve to something like this, I still think that it would be possible to protect systems from them. It would take more powerful means and might need systems to be more isolated from networks around them but I certainly think it would be possible (By somehow sandboxing everything coming in from a network, treating programs that are not from the original install as tainted and sandbox them as well etc.).
Pointless? How is hunting worms pointless? Just because there will appear new ones doesn't mean we shouldn't clean machines that still have Code Red or Nimda and try to correct security related bugs before some new worm exploits them.
Your comparison to **AA is somehow off since **AA is more about a few big organisations wanting to control everybody while worms are something everybody except for a few individuals want to get rid of.
Care to provide the source for that quote? I mean to someone who does not know dotNet in practice the quote does not say very much.
The point of unit testing is to test the units of some software (classes in OO systems), as opposed to testing the system as a whole for instance. What you described was test-first development which uses unit tests.
I think the original poster meant their software identifies test methods using reflection just like jUnit does, not that it generates tests from the actual code.