The undecidability if two random programs are equivalent it does not mean that there is no algorithmic way to do the transformation. It would mean that ANY transformation is impossible, which is, of course silly.
You can have operators which maintain the equivalence of the program, you can have series of that operators etc. For any program you can generate a lot of equivalent programs (which is what all the optimizers do).
But I think that this overwhelming effort to get rid of the stack is a bit misdirected. At the big picture level the question is how big the stack will be, more exactly what is the spatial complexity of the problem. And now there, indeed you have some hard limits, which depend on the problem, not on your algorithm.
Yes, he does have a problem with digital media, and does from the pure point of view of visual experience. And with the current digital standards, he is right. He also has a grievence that the movie industry is not using the 70mm film any more.
Let's make a still image of a DVD film: we get a nice, small 720 x 480 image.
What I scan from a regular 35mm film (with an amateur quality film scanner) is something like 4000 x 2500. I assume that from 70mm film, the equivalent resulution would be 8000 x 5000.
That means that the desert scenes of Lawrence of Arabia have 100 times more detail than the ones from the Attack of the Clones 2 DVD. And this is what Roger Ebert is missing, and he is right. It is not about problems with digital, it is about settling for less.
Lotzi
PS: I don't know the resolution of digital cinema equipment, it is probably higher than DVD. Still.
That thread is from May. In the meanwhile, it seems that almost all the new KDE tree is compilable with the intel compiler (at least based on the cvs logs, I didn't check it myself).
Now, for the expected performance increases. If I am correct, the intel compiler is the old KAI C++ compiler, which was highly regarded in number crunching circles as the best optimizing, more standard compliant compiler around.
Still, the spectacular increases occur only in very specific cases which are amenable to optimization. Number crunching (big math computations) are the best example, and this applies probably to mp3 encoding, divx playback and compression, image processing and other stuff like this, too. But for your average, highly heterogenous code which goes into your typical desktop apps, the increase is significatly smaller.
The major ascendance of Windows happened because the desktop capabilities of Unix workstations let's say 5-10 years ago were so poor that a developer used to have a 30.000$ SGI machine on his desk and a 2000$ Windows box to edit reports.
There was not a half decent word processor on those "graphics oriented" machines!
This inevitably meant that Windows automatically entered everywhere. While it is clear that still, Windows is the first choice if the task at hand is exclusively word processing, companies who are using Unix or Solaris for development are providing separate desktop machines any more. A client access to a centralized Windows server for the rare occasions when you need a Windows app is enough.
In conclusion: almost everybody who is using Linux as a development system (and a very large number of companies are using it), also uses it as a desktop. This in effect stops the further penetration of Windows, and provides a stable user base of desktop Linux.
besides books, the KDE API is documented at about the level of saturation and the online docs which, by the way can be generated from the code, are very comprehensive.
Besides this, the API's are very clean and complete. In fact, user interface programming is the type of code which is the best suited to object oriented approach, and the KDE libs are a good example of this.
Highly optimized kernel and driver code is naturally more difficult to grasp, so the comparison with the Linux kernel is not a good one.
In fact, there are at least four or five books either available, either in course of printing about KDE programming (mine being one of them, yes, shameless plug).
And there is the equivalent number of Gnome books, too.
I don't think you can call any of these projects undocumented, even compared to the highest commercial code standards.
Lotzi Boloni
Slowness of KDE releases? Not anymore...
on
Netscape 6 Vs. 4.7x
·
· Score: 1
You will have a 2.0.1 in three four days, and KDE 2.1 beta before Christmas.
There must be a mistake somewhere. The stations have a roughly circular orbit, so their speed must be about 11 km/s if I remember correctly which comes to about 5 miles per second.
Lotzi
On the other hand there seem to be specific differences between the kernel and the Gnome:
1. Linus
2. The perception difference between the Linux distributors and Sun. (And it is a real difference, too, because RedHat made an unprecedented effort to recompensate volunteers at his IPO)
3. The specific interests of companies and individuals to fix driver XXX, port to architecture YYY.
4. The fact that the leadership still seems to be in the hand of developers (which might boil down to point 1.).
I don't know why I prefer RedHat for Easel. Maybe because they first delivered and did not try to use questionable marketing tactics based on a half-baked product. At least their LinuxWorld presence left a very bad impression.
Well, out of about 20. But seriously: there were discussions about a common "feeling" of the desktop. Now obviously your backgrounds reflect a certain style which is prefered by a large group of people but not by everybody, which is fine.
So it was decided that we will go by default with a mixture of wallpapers such that everybody can choose one fit to his style. Right now the ones in
are:
Maybe I am mistaken about some of them being from Propaganda.
However here comes the challenge - it would be cool having corresponding icon sets to the style of these backgrounds. The current default icon themes ("High color", "Low color") are not really helpful (although in fact they differ more than just the number of colors).
Don't you think the following scenario likely is 3 months time:
-you can either hack Gnome for nothing, or hack it for money.
-in conclusion, you better go and be employed by one of the companies backing Gnome.
-or if you not, quit hacking Gnome completely.
So the developers are settled at the companies and we are back to a regular desktop consortium kinda stuff, which can be successful, or not. Only that the important and expensive initial ramp-up
was done for free, by enthusiastic hackers, "sponsoring" large companies.
Yes, konqueror.
1. It can be started in super user mode.
2. It can open a view which is a terminal emulation. You can even make it follow the views above or drag and drop files from the panels.
Lotzi
Pixmap themes are essentially images painted over the controls. Widget themes on the other hand, are actual code, loaded dynamically which draws the controls. This make it not only faster, but allows to change the way in which the control behaves. For example, in some styles KDE scrollbars have 3 buttons (2 down + 1 up), combining the advantages of different toolbar styles. With a pixmap style you can change how the button looks, but you can not switch between different behaviors. Lotzi
Despite the claims, StarOffice is a polished, mature product. Unfortunately I have a feeling that the development stalled, given the fact that the difference between 5.1 and 5.2 is minimal. And I think that Sun realized that the rented application style is not going to work, so after they lured MS into the Microsoft.NET nonsense, now they will stop the development on that.
However, let's hope for some stuff:
1. Let's hope that they will release 5.2 as it is. The Mozilla release was a failure: no working browser was released, it is still not a working browser and I think that almost nothing of the Netscape code went into the current Mozilla tree.
2. Let's hope that it is modular, at least internally. Let's hope that the word processor, the speadsheet and the presentation maker can be separated from the rest, from the forgettable database part for example.
3. Let's hope it will be easy to port the file format to an XML format.
4. Let's hope that it can be easily separated from it's proprietary widget set. It is almost sure that it will cannot survive long with that - it will be a cuckoo's egg in KDE or Gnome. It must be ported to the kdelibs and to gtk/gnome to be usable.
5. Let's hope the import/export filters will be in the GPL edition and easily reusable. This will be the first immediate benefit.
6. Let's hope the printing architecture is separated and reusable - second immediate benefit.
7. Let's hope that the component model can be easily ported to kparts. This is a requirement if you want to use it in a real component based environment.
Anyhow, I will surely take a look at the source when it will be released...
I am sorry, but that is a very bad benchmark. The ocaml program is 7-8 lines and it is basically doing several function calls to its standard library, implemented in C.
The C program uses a handwritten, non optimized hash table.
This benchmark effectively measures the speed of the hashtable used. All the the implementations use hashtables from libraries written in C. For executing code, the difference between Perl and C would be much larger, btw.
This test does not tell me anything about the relative speed of the languages.
As far as I know from Heisenberg, everything in the world has some side effects.
In fact, engineering can be defined as clever application of side effects. The fire is a clever application of the side effects of a chemical reaction.
But in the sense we are speaking here, a factorial function in C does not have any side effects, and is perfectly parallelizable and distributable.
Hm. My professor on "programming languages" (Jens Palsberg - I think he is a relative authority in type systems) managed to convince me that they are important, although I still tend to think that they are much overvalued in that peculiar type of journals.
In consequence, I don't know why the type of math used to infer types have any relationship to the language. I don't really believe in mixed language coding, and anyhow, type systems are not really working across different languages. So the conclusion is that:
-you are subordinating your representation of the world to the type system
-you are loosing power of representation and performance to have better compile time type checking
-etc.
So I really welcome type checking, but in that case the type checker algorithm should adapt itself to the language, not the other way around.
I think, that there is an unwelcome effect of the academic specialization: the ones who are researching type checking are not doing anything else, so they are creating a sort of closed universe of their own. In the meanwhile the compile time analysis of GCC is pretty bad...
Yes, I remember the fractal craze. It sort of boiled down, isn't it? And if you think of physics and chemistry, you know that nature is not recursive and lower level structures do not repeat the higher ones.
Yes, a lot of important data structures are recursive. And obviously procedural languages do support recursion.
Now about bad math. There are an infinite number of things you can work it in math. I would say that choosing to spend your life with something like continuity properties on equations without solution is a meaningless enterprise, but that's their problem. It is certainly a valid research theme.
BUT. When you propose an axiome system to describe the world and you are teaching it as the supreme solution, you are making a claim, and if the claim is not valid, it is bad math.
Now, change and time is an important property of the real world. The functional model can not capture this property, while the procedural model can. (It does not offer a good framework to reason about it, but that's something else).
For example: the functional model can not capture the fact that an algorithm can be a series of steps, in time, to be executed in a special order and at special steps. Most intelligent agents were used in this way.
Also, variables: my body temperature is sometimes higher, sometimes lower. This is very simply captured in a variable. It is conceptually impossible to fit in the functional model (and neither in the logical programming one, btw).
Ok, you can make a hack. They are computationally complete, but that's a bit of bullshit (sorry) because the Turing machine was not intended as being a panacea of describing the universe, only a model to compute the value of certain type of functions.
Still, the Turing machine itself captures change and time better than Lisp or Prolog.
So, when I say bad math, I don't mean that the proofs are flawed. I mean that the ones who proposed the formalism were misunderstanding the problem the formalism will be used for, which is to create programs working in a world evolving in time, in the presence of user interactions and other unpredictable elements.
best wishes Lotzi B.
BTW: Why do you think that type systems are specific to functional programming? I think that is a completely orthogonal problem to this...
Sorry, but can you substantiate your claims? I had all these claims turned on me about ten years ago in my undergrad years, and at that moment they were prophesizing the imminent major importance of functional programming languages.
But my experience shows that: -concurrent programs are written in C/C++ -debugging Lisp/Scheme is ridiculously problematic compared with C/C++/Java. I don't know about the current status of ML. -and the programs run slower.
And I had friends destroying their carreers by specializing themselves into Lisp Machines etc.
I am sorry, but when I see that after 30 years, the ridiculous examples of implementing Lisp in Lisp are again at vogue and are used as justification, I have a feeling that some people entered into a horrible cul de sac.
As part of the required courses for the PhD curriculum I had to revisit the functional programming. The major novelty in the course I had taken was the transformations needed to implement continuation based programming.
Sorry, but it hit me as a terrible hack: in fact I had never done anything so unnatural for performance reasons in C++. The resulting program was not elegant: it was long and completely unreadable, with the performance still being several order of magnitudes slower than a nonoptimized quick and dirty C++ program.
And all this, because some people at some moment of time did not take the effort to formalize repetition in math and they replaced it with the theory of recursion?
Sorry: but applying the same operation to all elements of a set is not recursion. Nature has rhythmic, repetitive elements: they are not recursion.
Sincerely speaking, I think that the whole insistence on functional programming is based on bad math, and misunderstanding of the phenomena the programs should computationally model, and this is the reason for the bad performance.
I guess that the real counting should be made from the original article by Matthias Ettrich about the need of an integrated desktop for Linux.
If you count it this way, KDE is about 3 3/4 years old and will be 4 in october.
In a way or another, the roots of Gnome are also traced back to that point, as the original Gnome documents where mainly about how this differs from KDE...
Lotzi
PS: Btw: we know how konqi looks like. He even have Katie now. Let's see how the Gnome looks like: is it just a big step?
Well, I remember reading one of the Lem books written in the 60's where nanobots on a foreign planet were used to build walls, etc... And I guess that the idea was floating around in various "futurologic congresses" etc.
Still, the Diamond Age is a "relatively" serious exploration of what would be the social implication of the nanotechnology age. When written, Stephenson had available another thirty years of technological advances, so he was in a better position to theoretize about this than Lem.
I guess that when he wrote about this, he considered the Diamond Age as being a serious possibility for the not too remote future (Neil, are you reading this?). Lem was probably considering the "futurological congress" as being an intellectual game - and the adventures of Pirx the pilot a serious "anticipation". Now it might happen that we will have nanobots, but no space travel...
I guess the "smartest people in the world" stuff is a bit misleading. They indeed hired a number of "big names" for the research department. Unfortunately none of them had done anything serious AFTER they've moved to Microsoft. One of the reasons might be that the research department is completely isolated from the rest of the company, and regular employees speak about them as "those idiots and weenies, they don't have release schedules, they never do anything useful". In conclusion: the big names are there to serve as a "prestige facade". For the rest of the company, the hiring philosophy is "We don't care what you know, we will teach you everything." They are not hiring "software engineers" but "smart kids". The interview questions usually contain programming riddles, not software design questions. The Bill Gates style of enthusiastic amatorism, you see. On the other hand, right now, even those wunderkids are not going to MS: what in the hell would they do there? Participate in releasing one more version of the operating system in the next 8 years? Let's remember that the internal creativity of Microsoft was generally very limited even in their heydays: I can not remember one software which in its original form was started at MS: all of them very bought from external companies! (with the companies, usually). Ok, maybe except the original Basic interpreter written by Bill Gates, but that's long ago, when he was the wunderkid. Even high ranking officials at Microsoft first leave the company and then start a startup: because the corporate culture do not let them innovate inside. Very funny that the otherwise very rigid old AT&T, even without being in the computer business created a large number of contributions: because they had a sheltered group of researchers who could do basically what they wanted at Bell Labs, while keeping a strong discipline on the external, telephony side. In conclusion: I don't think MS has the smartest people. They are certainly not hiring for the cream of universities: look at the extraordinarily drive Transmeta had done to hire Linus and the best new PhD-s around. And they are stiffling even those which they have. I am wondering what would have Linus done if hired by MS. Fixed bugs in Win2k? He certainly would have not been allowed to start a port to a new architecture: that's a "political" decision. Etc, etc. greetings Lotzi
There is an important problem with the cheaper-faster approach: no matter what you are doing, a project with a lower funding will be more likely to fall.
And unfortunately, even with the cheaper projects, they don't really have 10-20 shots: after the 5-th failed shot you've given enough ammunition into the hand of enemies to shot down the funding completely and the humankind will remain with a minimalistic space program of several telecommunication satellites + spyballs.
As generally the funding of science was radically decreasead since the end of cold war, maybe we should find a new motivation to perform science, as the low horizon approach of commercial funding does not provide a mechanism to promote branches without immediate commercial application.
Even branches of computer science were neglected recenctly although we are in a better shape than physicists for example...
Slashdot Mirror
The undecidability if two random programs are equivalent it does not mean that there is no algorithmic way to do the transformation. It would mean that ANY transformation is impossible, which is, of course silly.
You can have operators which maintain the equivalence of the program, you can have series of that operators etc. For any program you can generate a lot of equivalent programs (which is what all the optimizers do).
But I think that this overwhelming effort to get rid of the stack is a bit misdirected. At the big picture level the question is how big the stack will be, more exactly what is the spatial complexity of the problem. And now there, indeed you have some hard limits, which depend on the problem, not on your algorithm.
Yes, he does have a problem with digital media, and does from the pure point of view of visual experience. And with the current digital standards, he is right. He also has a grievence that the movie industry is not using the 70mm film any more.
Let's make a still image of a DVD film: we get a nice, small 720 x 480 image.
What I scan from a regular 35mm film (with an amateur quality film scanner) is something like 4000 x 2500. I assume that from 70mm film, the equivalent resulution would be 8000 x 5000.
That means that the desert scenes of Lawrence of Arabia have 100 times more detail than the ones from the Attack of the Clones 2 DVD. And this is what Roger Ebert is missing, and he is right. It is not about problems with digital, it is about settling for less.
Lotzi
PS: I don't know the resolution of digital cinema equipment, it is probably higher than DVD. Still.
That thread is from May. In the meanwhile, it seems that almost all the new KDE tree is compilable with the intel compiler (at least based on the cvs logs, I didn't check it myself).
Now, for the expected performance increases. If I am correct, the intel compiler is the old KAI C++ compiler, which was highly regarded in number crunching circles as the best optimizing, more standard compliant compiler around.
Still, the spectacular increases occur only in very specific cases which are amenable to optimization. Number crunching (big math computations) are the best example, and this applies probably to mp3 encoding, divx playback and compression, image processing and other stuff like this, too. But for your average, highly heterogenous code which goes into your typical desktop apps, the increase is significatly smaller.
Lotzi
The major ascendance of Windows happened because the desktop capabilities of Unix workstations let's say 5-10 years ago were so poor that a developer used to have a 30.000$ SGI machine on his desk and a 2000$ Windows box to edit reports.
There was not a half decent word processor on those "graphics oriented" machines!
This inevitably meant that Windows automatically entered everywhere. While it is clear that still, Windows is the first choice if the task at hand is exclusively word processing, companies who are using Unix or Solaris for development are providing separate desktop machines any more. A client access to a centralized Windows server for the rare occasions when you need a Windows app is enough.
In conclusion: almost everybody who is using Linux as a development system (and a very large number of companies are using it), also uses it as a desktop. This in effect stops the further penetration of Windows, and provides a stable user base of desktop Linux.
Lotzi
besides books, the KDE API is documented at about the level of saturation and the online docs which, by the way can be generated from the code, are very comprehensive.
Besides this, the API's are very clean and complete. In fact, user interface programming is the type of code which is the best suited to object oriented approach, and the KDE libs are a good example of this.
Highly optimized kernel and driver code is naturally more difficult to grasp, so the comparison with the Linux kernel is not a good one.
Lotzi Boloni
http://www.geocities.com/boloni2
In fact, there are at least four or five books either available, either in course of printing about KDE programming (mine being one of them, yes, shameless plug). And there is the equivalent number of Gnome books, too. I don't think you can call any of these projects undocumented, even compared to the highest commercial code standards. Lotzi Boloni
You will have a 2.0.1 in three four days, and KDE 2.1 beta before Christmas.
Lotzi
There must be a mistake somewhere. The stations have a roughly circular orbit, so their speed must be about 11 km/s if I remember correctly which comes to about 5 miles per second. Lotzi
Yes, probably time will tell.
On the other hand there seem to be specific differences between the kernel and the Gnome:
1. Linus
2. The perception difference between the Linux distributors and Sun. (And it is a real difference, too, because RedHat made an unprecedented effort to recompensate volunteers at his IPO)
3. The specific interests of companies and individuals to fix driver XXX, port to architecture YYY.
4. The fact that the leadership still seems to be in the hand of developers (which might boil down to point 1.).
I don't know why I prefer RedHat for Easel. Maybe because they first delivered and did not try to use questionable marketing tactics based on a half-baked product. At least their LinuxWorld presence left a very bad impression.
Best wishes and keep up the good work
Lotzi
Well, out of about 20. But seriously: there were discussions about a common "feeling" of the desktop. Now obviously your backgrounds reflect a certain style which is prefered by a large group of people but not by everybody, which is fine.
So it was decided that we will go by default with a mixture of wallpapers such that everybody can choose one fit to his style. Right now the ones in
are:
All-Good-People-1.jpg
Appropriately-Left-Handed-2.jpg
Chicken-Songs-2.jpg
No-Ones-Laughing-3.jpg
Planning-And-Probing-1.jpg
Superfluous-Organ-1.jpg
The-Good-Times-1.jpg
Time-For-Lunch-2.jpg
Totally-New-Product-1.jpg
Maybe I am mistaken about some of them being from Propaganda.
However here comes the challenge - it would be cool having corresponding icon sets to the style of these backgrounds. The current default icon themes ("High color", "Low color") are not really helpful (although in fact they differ more than just the number of colors).
have fun
Lotzi
PS: The challenge is not to Bowie only.
Havoc
Don't you think the following scenario likely is 3 months time:
-you can either hack Gnome for nothing, or hack it for money.
-in conclusion, you better go and be employed by one of the companies backing Gnome.
-or if you not, quit hacking Gnome completely.
So the developers are settled at the companies and we are back to a regular desktop consortium kinda stuff, which can be successful, or not. Only that the important and expensive initial ramp-up
was done for free, by enthusiastic hackers, "sponsoring" large companies.
cheers
Lotzi
Bowie, do you know that we have 6 Propaganda tiles
:-)
in KDE 2.0 ?
cheers, Lotzi Boloni
Yes, konqueror. 1. It can be started in super user mode. 2. It can open a view which is a terminal emulation. You can even make it follow the views above or drag and drop files from the panels. Lotzi
Pixmap themes are essentially images painted over the controls. Widget themes on the other hand, are actual code, loaded dynamically which draws the controls. This make it not only faster, but allows to change the way in which the control behaves. For example, in some styles KDE scrollbars have 3 buttons (2 down + 1 up), combining the advantages of different toolbar styles. With a pixmap style you can change how the button looks, but you can not switch between different behaviors. Lotzi
Despite the claims, StarOffice is a polished, mature product. Unfortunately I have a feeling that the development stalled, given the fact that the difference between 5.1 and 5.2 is minimal. And I think that Sun realized that the rented application style is not going to work, so after they lured MS into the Microsoft.NET nonsense, now they will stop the development on that.
However, let's hope for some stuff:
1. Let's hope that they will release 5.2 as it is. The Mozilla release was a failure: no working browser was released, it is still not a working browser and I think that almost nothing of the Netscape code went into the current Mozilla tree.
2. Let's hope that it is modular, at least internally. Let's hope that the word processor, the speadsheet and the presentation maker can be separated from the rest, from the forgettable database part for example.
3. Let's hope it will be easy to port the file format to an XML format.
4. Let's hope that it can be easily separated from it's proprietary widget set. It is almost sure that it will cannot survive long with that - it will be a cuckoo's egg in KDE or Gnome. It must be ported to the kdelibs and to gtk/gnome to be usable.
5. Let's hope the import/export filters will be in the GPL edition and easily reusable. This will be the first immediate benefit.
6. Let's hope the printing architecture is separated and reusable - second immediate benefit.
7. Let's hope that the component model can be easily ported to kparts. This is a requirement if you want to use it in a real component based environment.
Anyhow, I will surely take a look at the source when it will be released...
Lotzi
I am sorry, but that is a very bad benchmark. The ocaml program is 7-8 lines and it is basically doing several function calls to its standard library, implemented in C.
The C program uses a handwritten, non optimized hash table.
This benchmark effectively measures the speed of the hashtable used. All the the implementations use hashtables from libraries written in C. For
executing code, the difference between Perl and C would be much larger, btw.
This test does not tell me anything about the relative speed of the languages.
Lotzi
As far as I know from Heisenberg, everything in the world has some side effects.
In fact, engineering can be defined as clever application of side effects. The fire is a clever application of the side effects of a chemical reaction.
But in the sense we are speaking here, a factorial function in C does not have any side effects, and is perfectly parallelizable and distributable.
Lotzi
Hm. My professor on "programming languages" (Jens Palsberg - I think he is a relative authority in type systems) managed to convince me that they are important, although I still tend to think that they are much overvalued in that peculiar type of journals.
In consequence, I don't know why the type of math used to infer types have any relationship to the language. I don't really believe in mixed language coding, and anyhow, type systems are not really working across different languages. So the conclusion is that:
-you are subordinating your representation of the world to the type system
-you are loosing power of representation and performance to have better compile time type checking
-etc.
So I really welcome type checking, but in that case the type checker algorithm should adapt itself to the language, not the other way around.
I think, that there is an unwelcome effect of the academic specialization: the ones who are researching type checking are not doing anything else, so they are creating a sort of closed universe of their own. In the meanwhile the compile time analysis of GCC is pretty bad...
Lotzi
Ok, so why is this more elegant than
val=1
for i=1 to x
val = val * i
?
Yes, I remember the fractal craze. It sort of boiled down, isn't it? And if you think of physics and chemistry, you know that nature is not recursive and lower level structures do not repeat the higher ones.
Yes, a lot of important data structures are recursive. And obviously procedural languages do support recursion.
Now about bad math. There are an infinite number of things you can work it in math. I would say that choosing to spend your life with something like continuity properties on equations without solution is a meaningless enterprise, but that's their problem. It is certainly a valid research theme.
BUT. When you propose an axiome system to describe the world and you are teaching it as the supreme solution, you are making a claim, and if the claim is not valid, it is bad math.
Now, change and time is an important property of the real world. The functional model can not capture this property, while the procedural model can. (It does not offer a good framework to reason about it, but that's something else).
For example: the functional model can not capture the fact that an algorithm can be a series of steps, in time, to be executed in a special order and at special steps. Most intelligent agents were used in this way.
Also, variables: my body temperature is sometimes higher, sometimes lower. This is very simply captured in a variable. It is conceptually impossible to fit in the functional model (and neither in the logical programming one, btw).
Ok, you can make a hack. They are computationally complete, but that's a bit of bullshit (sorry) because the Turing machine was not intended as being a panacea of describing the universe, only a model to compute the value of certain type of functions.
Still, the Turing machine itself captures change and time better than Lisp or Prolog.
So, when I say bad math, I don't mean that the proofs are flawed. I mean that the ones who proposed the formalism were misunderstanding the problem the formalism will be used for, which is to create programs working in a world evolving in time, in the presence of user interactions and other unpredictable elements.
best wishes
Lotzi B.
BTW: Why do you think that type systems are specific to functional programming? I think that is a completely orthogonal problem to this...
Tom
Sorry, but can you substantiate your claims? I had all these claims turned on me about ten years ago in my undergrad years, and at that moment they were prophesizing the imminent major importance of functional programming languages.
But my experience shows that:
-concurrent programs are written in C/C++
-debugging Lisp/Scheme is ridiculously problematic compared with C/C++/Java. I don't know about the current status of ML.
-and the programs run slower.
And I had friends destroying their carreers by specializing themselves into Lisp Machines etc.
I am sorry, but when I see that after 30 years, the ridiculous examples of implementing Lisp in Lisp are again at vogue and are used as justification, I have a feeling that some people entered into a horrible cul de sac.
As part of the required courses for the PhD curriculum I had to revisit the functional programming. The major novelty in the course I had taken was the transformations needed to implement continuation based programming.
Sorry, but it hit me as a terrible hack: in fact I had never done anything so unnatural for performance reasons in C++. The resulting program was not elegant: it was long and completely unreadable, with the performance still being several order of magnitudes slower than a nonoptimized quick and dirty C++ program.
And all this, because some people at some moment of time did not take the effort to formalize repetition in math and they replaced it with the theory of recursion?
Sorry: but applying the same operation to all elements of a set is not recursion. Nature has rhythmic, repetitive elements: they are not recursion.
Sincerely speaking, I think that the whole insistence on functional programming is based on bad math, and misunderstanding of the phenomena the programs should computationally model, and this is the reason for the bad performance.
sincerely
Lotzi Boloni
I guess that the real counting should be made from the original article by Matthias Ettrich about the need of an integrated desktop for Linux.
If you count it this way, KDE is about 3 3/4 years old and will be 4 in october.
In a way or another, the roots of Gnome are also traced back to that point, as the original Gnome documents where mainly about how this differs from KDE...
Lotzi
PS: Btw: we know how konqi looks like. He even have Katie now. Let's see how the Gnome looks like: is it just a big step?
Well, I remember reading one of the Lem books written in the 60's
where nanobots on a foreign planet were used to build walls,
etc... And I guess that the idea was floating around in various
"futurologic congresses" etc.
Still, the Diamond Age is a "relatively" serious exploration of what
would be the social implication of the nanotechnology age. When written,
Stephenson had available another thirty years of technological advances,
so he was in a better position to theoretize about this than Lem.
I guess that when he wrote about this, he considered the Diamond Age
as being a serious possibility for the not too remote future (Neil,
are you reading this?). Lem was probably considering the
"futurological congress" as being an intellectual game - and the
adventures of Pirx the pilot a serious "anticipation". Now it might
happen that we will have nanobots, but no space travel...
Lotzi
I guess the "smartest people in the world" stuff is a bit misleading. They indeed hired a number of "big names" for the research department. Unfortunately none of them had done anything serious AFTER they've moved to Microsoft. One of the reasons might be that the research department is completely isolated from the rest of the company, and regular employees speak about them as "those idiots and weenies, they don't have release schedules, they never do anything useful". In conclusion: the big names are there to serve as a "prestige facade". For the rest of the company, the hiring philosophy is "We don't care what you know, we will teach you everything." They are not hiring "software engineers" but "smart kids". The interview questions usually contain programming riddles, not software design questions. The Bill Gates style of enthusiastic amatorism, you see. On the other hand, right now, even those wunderkids are not going to MS: what in the hell would they do there? Participate in releasing one more version of the operating system in the next 8 years? Let's remember that the internal creativity of Microsoft was generally very limited even in their heydays: I can not remember one software which in its original form was started at MS: all of them very bought from external companies! (with the companies, usually). Ok, maybe except the original Basic interpreter written by Bill Gates, but that's long ago, when he was the wunderkid. Even high ranking officials at Microsoft first leave the company and then start a startup: because the corporate culture do not let them innovate inside. Very funny that the otherwise very rigid old AT&T, even without being in the computer business created a large number of contributions: because they had a sheltered group of researchers who could do basically what they wanted at Bell Labs, while keeping a strong discipline on the external, telephony side. In conclusion: I don't think MS has the smartest people. They are certainly not hiring for the cream of universities: look at the extraordinarily drive Transmeta had done to hire Linus and the best new PhD-s around. And they are stiffling even those which they have. I am wondering what would have Linus done if hired by MS. Fixed bugs in Win2k? He certainly would have not been allowed to start a port to a new architecture: that's a "political" decision. Etc, etc. greetings Lotzi
There is an important problem with the cheaper-faster approach: no matter what you are doing, a project with a lower funding will be more likely to fall.
And unfortunately, even with the cheaper projects, they don't really have 10-20 shots: after the 5-th failed shot you've given enough ammunition into the hand of enemies to shot down the funding completely and the humankind will remain with a minimalistic space program of several telecommunication satellites + spyballs.
As generally the funding of science was radically decreasead since the end of cold war, maybe we should find a new motivation to perform science, as the low horizon approach of commercial funding does not provide a mechanism to promote branches without immediate commercial application.
Even branches of computer science were neglected recenctly although we are in a better shape than physicists for example...
Lotzi