>Yes: because the stuff that's new in Wolfram is not good >and the stuff that's good is not new. The rest of the hard
Your opinion is a pathetic misinformed regurgitation of others' equally pathetic 'reviews' and 'comments'. The fact of the matter is that there is _nothing_ in the past like the approach that wolfram advocates. As for specific results, how about a model for shell growth that contradicts widely held ideas about evolution? Or in math, the shortest possible axiom system for logic? Or in physics, obliterating time, space, and matter and still being able to derive special and general relativity from a far simpler structure? Or in CS, the simplest known universal system? Not to mention an absolute mountain of important and interesting results in the notes.
>sciences have been investigating complexity theory and >the emergence of complex phenomena from simple rules >for years now, and have produced work of far greater
Like what? how many popularized accounts of fractal dimensions and power laws do we need? The fact of the matter is that the establishment has produced very few meaningful results. And the fact of the matter is almost no one investigates simple, abstract systems. Just look at the literature.
The way people use computers is determined by the whole of the environment they are confronted with... and generally no matter what kinds of interfaces people are presented with they will start gluing them together to get various tasks done. This is a pretty universal thing, but unfortunately the history of computing has ended up producing a rigid user/programmer distinction (although the *nix community has been doing a lot to blur the line)
No matter if you are using a GUI or a traditional programming language, the end result is that you are instructing the computer to do something. The thing is tho is that "programming" is so time consuming and difficult (compared to the GUI) that generally people only switch into that mode when they want to do something over and over again. Yet looking at the way people use GUI's, they do the same actions over and over again. Why? Because its impossible to script most GUI's in anything like an quick-and-easy fashion, or to combine elements of different programs into "meta" applications.
People have been talking about more holistic environments for years, but inevitably these projects fail. IMO its because people keep trying to use languages that are too low level and are too unstructured - causing enormous efforts to be expended on simply converting data formats or wrapping APIs and such, or chasing down buffer overflows, and not enough time developing programming environments that can program and extend themselves.
Currently I'm working on such a project based on the mathematica programming language.. stay tuned...
When watching the macworld stream I too was a little surprised at the choice of KHTML, and knowing about chimera wasnt too taken in by the speed argument.
But after taking a look at WebCore and reading the latest ADC news bulliten mentioning an upcoming WebCore SDK, its a little more clear what is going on.
Basically apple has wrapped an objective-c++ interface around khtml, which developers will soon be using to integrate web rendering into their apps with unprecedented ease... and i dont think anyone can argue that an apple-designed API will be easier to imbedd in os x apps than gecko.
If apple were just interested in building a browser, then Gecko may have been a better choice. But because Gecko is meant to be the basis of an entire platform, it has a whole lot of stuff that will make it tricky to tightly integrate with OS X as a core component of the system, since OS X already has its own ways of doing things (for example i dont think apple is thrilled with the prospect of xul which cannot help but violate the human interaface guidelines. But theres lots of purely technical points too.)
Debugging is a specific instance of a more general problem: How does one go about understanding what a program _actually_ does (as opposed to what it was designed to do, or in cases when there isnt much in the way of documentation - such as most open source projects).
The fact of the matter is that the dominant style of programming (procedural) is pretty difficult to understand. The basic problem is that there is a lot of stuff going on behind the scenes that is not explicitly visible to the programmer. And so, if you want to investigate the behavior of a little piece of code you end up needing to run the context of the entire program, because that little piece depends on a the initialization of a pretty complex state.
The very proccess of compilation and testing is pretty time consuming and so people tend to test only at "milestone" stages - but adding a significat chunk of code can greatly increase the possible number of states the program can have, and typically only a tiny tiny fraction of those can be explored by the tester.
I know a number of programming languages, and for a few years I've been vaguely considering getting involved in open source - like most others, usually to improve an existing program to suit my purposes better. But invevitably it becomes a major effort to just figure out the structure of the program - what source files do what kind of thing, how the various modules are related and what sort of information they pass to each other in what order. Pretty obvious questions that are really hard to answer without painstaking manual labor.
Procedural programing is partly to blame, but also very important is the fact that most programming languages are generally lacking an overall organizing principle - so that for example there is a distinction between data and functions (like in c), or between functions and the code defining them (like most oo languages). BTW, the consequence of the latter case is that its hard to perform operations on the source code that try to discover structure, or automation tasks that could be used in something like for example a debugger.
At a meta-level, consider this: What does it say about the languages we use that it seems impossible to develop a systemitized way of discovering and teaching ourselves how a given piece of code works?
For an example of how things can be different, see the Mathematica programming language. Basically its like regular expressions on 'roids - you can transform absolutely anything according to patterns, which is made possible by the fact that everything is an "expression" which has a certain simple structure. Furthermore, every expression is self-contained, which makes it easy to pull out little sections of a program and test them with various input (also easily generated).
Of course the 1.8k pricetag is a bit steep - but they've been talking about releasing the language component for years and I predict its going to happen soon. So check it out.
Slashdot Mirror
>Yes: because the stuff that's new in Wolfram is not good >and the stuff that's good is not new. The rest of the hard
Your opinion is a pathetic misinformed regurgitation of others' equally pathetic 'reviews' and 'comments'.
The fact of the matter is that there is _nothing_ in the past like the approach that wolfram advocates. As for specific results, how about a model for shell growth that contradicts widely held ideas about evolution? Or in math, the shortest possible axiom system for logic? Or in physics, obliterating time, space, and matter and still being able to derive special and general relativity from a far simpler structure? Or in CS, the simplest known universal system? Not to mention an absolute mountain of important and interesting results in the notes.
>sciences have been investigating complexity theory and >the emergence of complex phenomena from simple rules >for years now, and have produced work of far greater
Like what? how many popularized accounts of fractal dimensions and power laws do we need? The fact of the matter is that the establishment has produced very few meaningful results. And the fact of the matter is almost no one investigates simple, abstract systems. Just look at the literature.
The way people use computers is determined by the whole of the environment they are confronted with... and generally no matter what kinds of interfaces people are presented with they will start gluing them together to get various tasks done. This is a pretty universal thing, but unfortunately the history of computing has ended up producing a rigid user/programmer distinction (although the *nix community has been doing a lot to blur the line)
No matter if you are using a GUI or a traditional programming language, the end result is that you are instructing the computer to do something. The thing is tho is that "programming" is so time consuming and difficult (compared to the GUI) that generally people only switch into that mode when they want to do something over and over again. Yet looking at the way people use GUI's, they do the same actions over and over again. Why? Because its impossible to script most GUI's in anything like an quick-and-easy fashion, or to combine elements of different programs into "meta" applications.
People have been talking about more holistic environments for years, but inevitably these projects fail. IMO its because people keep trying to use languages that are too low level and are too unstructured - causing enormous efforts to be expended on simply converting data formats or wrapping APIs and such, or chasing down buffer overflows, and not enough time developing programming environments that can program and extend themselves.
Currently I'm working on such a project based on the mathematica programming language.. stay tuned...
>ease... and i dont think anyone can argue that an apple->designed API will be easier to imbedd in os x apps than gecko.
/. posts.
will->won't, for true meaning
ahh, the first few
But after taking a look at WebCore and reading the latest ADC news bulliten mentioning an upcoming WebCore SDK, its a little more clear what is going on.
Basically apple has wrapped an objective-c++ interface around khtml, which developers will soon be using to integrate web rendering into their apps with unprecedented ease... and i dont think anyone can argue that an apple-designed API will be easier to imbedd in os x apps than gecko.
If apple were just interested in building a browser, then Gecko may have been a better choice. But because Gecko is meant to be the basis of an entire platform, it has a whole lot of stuff that will make it tricky to tightly integrate with OS X as a core component of the system, since OS X already has its own ways of doing things (for example i dont think apple is thrilled with the prospect of xul which cannot help but violate the human interaface guidelines. But theres lots of purely technical points too.)
The fact of the matter is that the dominant style of programming (procedural) is pretty difficult to understand. The basic problem is that there is a lot of stuff going on behind the scenes that is not explicitly visible to the programmer. And so, if you want to investigate the behavior of a little piece of code you end up needing to run the context of the entire program, because that little piece depends on a the initialization of a pretty complex state.
The very proccess of compilation and testing is pretty time consuming and so people tend to test only at "milestone" stages - but adding a significat chunk of code can greatly increase the possible number of states the program can have, and typically only a tiny tiny fraction of those can be explored by the tester.
I know a number of programming languages, and for a few years I've been vaguely considering getting involved in open source - like most others, usually to improve an existing program to suit my purposes better. But invevitably it becomes a major effort to just figure out the structure of the program - what source files do what kind of thing, how the various modules are related and what sort of information they pass to each other in what order. Pretty obvious questions that are really hard to answer without painstaking manual labor.
Procedural programing is partly to blame, but also very important is the fact that most programming languages are generally lacking an overall organizing principle - so that for example there is a distinction between data and functions (like in c), or between functions and the code defining them (like most oo languages). BTW, the consequence of the latter case is that its hard to perform operations on the source code that try to discover structure, or automation tasks that could be used in something like for example a debugger.
At a meta-level, consider this: What does it say about the languages we use that it seems impossible to develop a systemitized way of discovering and teaching ourselves how a given piece of code works?
For an example of how things can be different, see the Mathematica programming language. Basically its like regular expressions on 'roids - you can transform absolutely anything according to patterns, which is made possible by the fact that everything is an "expression" which has a certain simple structure. Furthermore, every expression is self-contained, which makes it easy to pull out little sections of a program and test them with various input (also easily generated).
Of course the 1.8k pricetag is a bit steep - but they've been talking about releasing the language component for years and I predict its going to happen soon. So check it out.