In fact, Apple had this gaming image that was negative for their bussiness. (See the last paragraph of this) It was in the times of the Amiga. So they fought hard to avoid being seen in the gaming space.
However, since the times of Doom and Quake (ten years ago), there was a big hardware demand for gaming pcs, and being seen as a gaming platform would have helped sales.
Even now, one of the main buying concerns is "would this computer run my favorite games?".
The lack of games for the mac is more about the game developers not wanting to invest in a small market (they are even going out of the PC market because console sales are so much bigger), than anything Apple had done recently about games.
No business will go Linux for general purpose use (ie, if you standardise on a distro to run a particular app, then you're fine, but you have a controlled ecosystem) where users use it to do everything because it doesn't have the "shrink-wrapped" approach to apps.
You can't buy an app and expect it to work on your distro, because maybe it isn't readily supported on that.
A single mayor toolkit would help prevent that. Programming styles and editors don't make that issue better or worse, they are irrelevant.
If you don't care about commercial propietary software, it's fine. But some people do.
In this comparison test, Tom's Hardware Guide finds itself unable to recommend any of the products it tested. That is because they're either too fragile or we simply couldn't overcome our reservations about certain features or components.
The article is good in the sense that not everyone has your experience, and can believe that those features are good.
I know you're trolling, but I will answer the post, just to avoid that you mislead some readers.
I know there are languages that don't are/fit in that line. They are Fortran, ML, Haskell, Forth and Ocaml. And may be prolog, and cobol, but they are of little interest. I've heard very nice things of Ocaml, and I want to learn it in the future.
So yes, this is a limited view because it doesn't include these languages, and that's why I said "Almost every language" instead of "Every language". But it's not much limited, because those other languages are almost never used except for academic purpouses, and even now people are just getting some interest in Ruby. And the languages included are the most used programming languages, that comprise 99.99% of all code written.
Now you say: "Programming languages don't fall on a single axis between functional and procedural. That's ridiculous." I totally agree with that.
The part you got wrong is that Lisp is not a purely functional programming language. It's not been for about 40 years. It's just the first ever functional programming language. Lisp can do imperative, procedural, object oriented, aspect oriented, and who-knows-what-comes-next programming just fine.
On the other hand, Haskell IS a pure functional programming language, and ML and Ocaml are mostly functional programming languages and that's a reason for them to not to fit in that line. Forth, being stack based, is a whole different beast, it couldn't fit even if we try. I don't know Fortran, so I could not place it in the line.
However, there is a reason for that line.
It means: In this extreme (C) you're can do this: imperative structured programming.
Move a little (C++) and you can still do that, but you have this too: object oriented programming, generic programming.
Move a little (Java), and you can still do what you did (except template-metaprogramming and some other stuff), but you have this too: garbage collection, multiplatform runtime.
Move a little (Python), and you can still do what you did, but you have this too: dynamic typing, first order functions, closures, an interactive prompt.
Move a little (Ruby), and you can still do what you did, but you have this too: anonymous blocks / lambda functions, continuations, some automatic code generation, native big number support.
Move a little (Lisp), and you can still do what you did, but you have this too: -CLOS: The most powerful object oriented system. In normal object oriented programming, you have single class method dispatching, in CLOS you have any number of classes method dispatching, pre and post methods, and several other stuff. -Native Rational number support. -Full functional programming. -Lisp macros, the stuff that makes Lisp a programmable programming language and can make lisp adapt to any paradigm you want, like aspect oriented programming (which was in turn inspired by CLOS).
Lisp is even more multiparadigm than C++!
This line also lies in the axis of compiled vs interpreted. However due to heavy investment in that area most Lisps are compilers too, so there is a performance jump going from Ruby to Lisp, toghether with the expresiveness jump and the weird parenthesis syntax. Lisp needs the parenthesis syntax because of the macro system.
In fact, if there is a problem in the line I drew, it's in the jump from C++ to Java. Java can't do everything C++ can. In fact, java is a very limited programming language, compared with the ones around it. It just has an awesome IDE and a shitload of libraries.
If I had put Haskell in the other end of C, instead of Lisp, your post would had made sense. But it does not. I guess you need to learn more about Lisp. It's been evolving for almost 50 years.
When you do math's in school, is exactly like what you describe as "small picture stuff". Because you're not doing really groundbreaking work, and teachers are too dumb to guide students to discover math by themselves which is IMO the right way to teach maths.
You have homework, you look in a "recipe book" and fill in the blanks.
However, if you keep going up in the math stuff, you will reach a point where you have to actually ask yourself "and now, what the heck do I have to do to finish this proof". You stare at the sheet of paper without a clear idea of what to do. Is in this point where pure left-brain reasoning falls apart, and with it, any possibility of automatizing the process. You have to use your right-brain, be creative, inventive. If you must sleep and dream about a proof in order to complete it, then you're being very creative, you're learning something new.
Then you start in some path. You spend hours in that path. And then you realize that it's wrong. So start again. You even have to do that a couple of times. And without automatized help! Just pen and paper and your head.
You keep going up, and then some proofs can take weeks. And sometimes you have to backtrack and start again. However you start to get better at that stuff. You can figure right in your head the consecuences of some paths of though and you can even do some proofs in your head that you though impossible some years ago.
There is no algorithm to perform a mathematical proof, except for the most simple ones. Remember Fermat's Last Theorem, it took centuries and several of the greatest minds to crack, and there is still some controversy about the proof, because is too long.
The end result, the proof in the paper, may look like just math stuff, a formal reasoning that anyone can repeat (and anyone should be able to), but this sidesteps the mental process behind the proof. And I believe that at least some part of that mental process can't be automatized. And is precisely to be able to perform that complex mental processes that helps you with programming issues, which is the whole point of comparing maths to programming.
Programming in small scale is like old homework, you took a "recipe book" and fill in the blanks. Programming in big scale, is as you say, architecture and design. But it's also like having to prove a complex proof. A proof you never tried before, or one you tried with unsatisfactory results.
So what you're asking me is like: "I have to do this ugly proof. I don't want to, just give me the result sheet so I can fill in the blanks." I will try, however I acknowledge these are not trivial design issues.
You describe having to rewrite tons of code. I propose that you should not write that code by hand in the first place. However this answer includes Lisp. You can write code in Lisp that describes your protocol, in a formal way, but at the same time, when it runs, it writes all the code that implements both parts, client and server of the protocol.
I did once some code in C++ to store data in binary files. It's a binary data protocol. But I never really wrote that C++ code. I wrote Lisp code that in turn wrote the C++ files. So if I had to change something, instead of changing a lot of code (and it really was tedious and error prone to change that much code by hand) I changed one of two lines of Lisp code and then run a function in the REPL and then go to the C++ editor and compile and run. It's great to save all that work. And you can keep tweaking your design as you go!
Changing a database schema is no harder in Lisp, because a line of code creates the classes to map objects to the database, and it handles relations and other stuff just fine. Lisp can write all the rest of the tedious and repetitive code for you. If performance is an issue, and it could be for I/O and numerical stuff, do as I did, make Lisp write C++ code.
"Worse: how about determining what is the best possible compatible architect
And as for likelihoods... Nobody KNOWS what the likelihood of a cell mutating to X is. So they can't say with any reasonable accuracy how likely this is to happen a third time.
A random atom decay in a radioactive substance is a random thing. You can't predict if a single atom will decay or not. However you can predict the decay rate, and you have the half-life of the substance, which is the time the number of radioactive isotopes will be half than what they are at time zero.
Of course they can't know about a single cell any more they can know about a single atom. But for two populations to get to the same final state, there happened a LOT of mutations and is on that many mutations that they can use statistics.
About the post you responded: there is 99.999999999% probabilities that the stuff is not random. Your comment doesn't change that.
However it doesn't say what the reason for the mutations is, if it's not random. And that it's the entire point of my first post. That you can use statistics to predict something, but it doesn't increase a bit the knowledge about the inner workings of the observed fenomena.
If the probability of such particular outcome was 50%, then two repetitions would give them only like 75% of probabilities that this would not be random. Very small and everybody would complain.
None of the following numbers are exact, but you get the idea:
Their experiment suggest that the probability of every particular outcome would be very very small if guided by random behavior. Think about 1/700000 or something like that based in the number of mutations.
So the probability of that particular outcome twice is much smaller, like 1/490000000000 (or something close).
Is like when you try to test random primes. The first time it passes the test, then there is something like a 89% probability that is prime. Twice, it's like 98%. After five passes, the probability is 99.99%. After some more, the probability is very high.
So they have something like 99.99999999% (1 - 1/490000000000).
After such high probability you could start to think that this particular outcome is not really random, but deterministic.
That's how I interpreted the experiment. Correct me if I'm wrong.
I don't think you can conclude that evolution can be predicted from that kind of experiments. Just that evolution can be observed. Evolution just happens. But the fact that we can observe it doesn't mean we can understand and predict it.
Even if in some cases the expected outcome is deterministic, we don't know how really works, see folding@home, that stuff is really computationally expensive. We would need to know the folding behavior of all possible protein and then a fast, effective way to model the interactions between those proteins. Then we can think about modelling organisms with some features (notice that this is a huge jump, we skipped modelling tissues and organs, however because some organism features are directly mapped to specific proteins, it can be done after some assumptions/observations).
If evolution can be predicted, they would not need to make experiments to make hypothesis, they would feed that data to a computer, the computer would predict some outcome (including specific genes and mutations), and then the experiment would match (or not) the outcome.
We are years, even centuries away from that.
This experiment is just bayesian inference. The sun appeared today (and appeared every day of my life before that), so I predict it will appear tomorrow, with (very close to 1) probability. I don't need to understand HOW the sun appears to predict that.
But if the article had said: "evolution can be observed" then I would agree with the article.
Slashdot Mirror
Hey would you like to outsource some of it to SouthAmerica ?
I'm willing to try to convince you.
I second that.
And Opera is much faster on older hardware than FireFox.
If it had happened to me I would have chosen a career in physics to try to repeat that event.
Or as a musician... imagine a concert with all the big speakers having blue spheres of light!
Yeeees...
May be I just found the Alice article I posted when I really was looking for the Puzzle article.
Anyway, both articles from Folklore.org are relevant.
In fact, Apple had this gaming image that was negative for their bussiness. (See the last paragraph of this)
It was in the times of the Amiga. So they fought hard to avoid being seen in the gaming space.
However, since the times of Doom and Quake (ten years ago), there was a big hardware demand for gaming pcs, and being seen as a gaming platform would have helped sales.
Even now, one of the main buying concerns is "would this computer run my favorite games?".
The lack of games for the mac is more about the game developers not wanting to invest in a small market (they are even going out of the PC market because console sales are so much bigger), than anything Apple had done recently about games.
So, that article is outdated by about 15 years.
And is addictive as hell.
:P (and learning, I'm still a low 22k? )
In fact, I'm testing the new glGo client
I still play Descent from time to time. It's just fun and scary and these robots have their personality.
I use D2X-XL version 1.6.6.
I tried to play Quake2 in the last month but it was just boring compared to descent, which is older.
I expected the super ultra duper new Expandable Comment Tree !!!
Where is it ???
(and I know about greasemonkey, but this should be here for all browsers to use)
I do agree, but FF has made a lot of websites to take standards into account.
And as Opera users we benefit from standards compliant web pages.
As long as IE has the lions share of the market, I want both browsers to increase their use.
MOD PARENT UP!
Way too insighful.
If what you say is true, then that's the reason there are so few MS Windows applications.
Windows surely needs more GUI toolkits, one for each programming style, may be then more programmers could do applications for that platform.
Hopefully those applications can use a simple installer (NSIS) that just works from Windows 98 to Windows XP, with all those GUI toolkits and stuff.
Thanks! that's what I wanted to see.
When I click on the comments link it goes to the normal comments page.
I want to see how comments look, it's more important than to see the homepage.
No business will go Linux for general purpose use (ie, if you standardise on a distro to run a particular app, then you're fine, but you have a controlled ecosystem) where users use it to do everything because it doesn't have the "shrink-wrapped" approach to apps.
You can't buy an app and expect it to work on your distro, because maybe it isn't readily supported on that.
A single mayor toolkit would help prevent that. Programming styles and editors don't make that issue better or worse, they are irrelevant.
If you don't care about commercial propietary software, it's fine. But some people do.
From the article:
In this comparison test, Tom's Hardware Guide finds itself unable to recommend any of the products it tested. That is because they're either too fragile or we simply couldn't overcome our reservations about certain features or components.
The article is good in the sense that not everyone has your experience, and can believe that those features are good.
The bad thing, this text was in page 25.
May be he meant Java's reputation as being slow.
I know you're trolling, but I will answer the post, just to avoid that you mislead some readers.
I know there are languages that don't are/fit in that line. They are Fortran, ML, Haskell, Forth and Ocaml. And may be prolog, and cobol, but they are of little interest. I've heard very nice things of Ocaml, and I want to learn it in the future.
So yes, this is a limited view because it doesn't include these languages, and that's why I said "Almost every language" instead of "Every language". But it's not much limited, because those other languages are almost never used except for academic purpouses, and even now people are just getting some interest in Ruby. And the languages included are the most used programming languages, that comprise 99.99% of all code written.
Now you say: "Programming languages don't fall on a single axis between functional and procedural. That's ridiculous." I totally agree with that.
The part you got wrong is that Lisp is not a purely functional programming language. It's not been for about 40 years. It's just the first ever functional programming language. Lisp can do imperative, procedural, object oriented, aspect oriented, and who-knows-what-comes-next programming just fine.
On the other hand, Haskell IS a pure functional programming language, and ML and Ocaml are mostly functional programming languages and that's a reason for them to not to fit in that line. Forth, being stack based, is a whole different beast, it couldn't fit even if we try. I don't know Fortran, so I could not place it in the line.
However, there is a reason for that line.
It means: In this extreme (C) you're can do this: imperative structured programming.
Move a little (C++) and you can still do that, but you have this too: object oriented programming, generic programming.
Move a little (Java), and you can still do what you did (except template-metaprogramming and some other stuff), but you have this too: garbage collection, multiplatform runtime.
Move a little (Python), and you can still do what you did, but you have this too: dynamic typing, first order functions, closures, an interactive prompt.
Move a little (Ruby), and you can still do what you did, but you have this too: anonymous blocks / lambda functions, continuations, some automatic code generation, native big number support.
Move a little (Lisp), and you can still do what you did, but you have this too:
-CLOS: The most powerful object oriented system. In normal object oriented programming, you have single class method dispatching, in CLOS you have any number of classes method dispatching, pre and post methods, and several other stuff.
-Native Rational number support.
-Full functional programming.
-Lisp macros, the stuff that makes Lisp a programmable programming language and can make lisp adapt to any paradigm you want, like aspect oriented programming (which was in turn inspired by CLOS).
Lisp is even more multiparadigm than C++!
This line also lies in the axis of compiled vs interpreted. However due to heavy investment in that area most Lisps are compilers too, so there is a performance jump going from Ruby to Lisp, toghether with the expresiveness jump and the weird parenthesis syntax. Lisp needs the parenthesis syntax because of the macro system.
In fact, if there is a problem in the line I drew, it's in the jump from C++ to Java. Java can't do everything C++ can. In fact, java is a very limited programming language, compared with the ones around it. It just has an awesome IDE and a shitload of libraries.
If I had put Haskell in the other end of C, instead of Lisp, your post would had made sense. But it does not.
I guess you need to learn more about Lisp. It's been evolving for almost 50 years.
Well, I think so, but I don't know myself enough perl (and don't plan to learn it) so I wouldn't know where to put it.
I would guess it's between Java and Python.
And also get a good book about LISP and learn it. Almost every language out there is placed somewhere between C and LISP.
You can draw a line like C____C++_Java____Python___Ruby_Lisp
I suggest Common Lisp an Interactive Approach.
Uhhh? I've seen tabbed toolbars in Dreamweaver for ages!
This ribbon thing just replaces the menu with the tabs.
Hey, not only 14 year old people have brain waves!
I believe it's really the other way around.
When you do math's in school, is exactly like what you describe as "small picture stuff". Because you're not doing really groundbreaking work, and teachers are too dumb to guide students to discover math by themselves which is IMO the right way to teach maths.
You have homework, you look in a "recipe book" and fill in the blanks.
However, if you keep going up in the math stuff, you will reach a point where you have to actually ask yourself "and now, what the heck do I have to do to finish this proof". You stare at the sheet of paper without a clear idea of what to do. Is in this point where pure left-brain reasoning falls apart, and with it, any possibility of automatizing the process. You have to use your right-brain, be creative, inventive. If you must sleep and dream about a proof in order to complete it, then you're being very creative, you're learning something new.
Then you start in some path. You spend hours in that path. And then you realize that it's wrong. So start again. You even have to do that a couple of times. And without automatized help! Just pen and paper and your head.
You keep going up, and then some proofs can take weeks. And sometimes you have to backtrack and start again. However you start to get better at that stuff. You can figure right in your head the consecuences of some paths of though and you can even do some proofs in your head that you though impossible some years ago.
There is no algorithm to perform a mathematical proof, except for the most simple ones. Remember Fermat's Last Theorem, it took centuries and several of the greatest minds to crack, and there is still some controversy about the proof, because is too long.
The end result, the proof in the paper, may look like just math stuff, a formal reasoning that anyone can repeat (and anyone should be able to), but this sidesteps the mental process behind the proof. And I believe that at least some part of that mental process can't be automatized. And is precisely to be able to perform that complex mental processes that helps you with programming issues, which is the whole point of comparing maths to programming.
Programming in small scale is like old homework, you took a "recipe book" and fill in the blanks. Programming in big scale, is as you say, architecture and design. But it's also like having to prove a complex proof. A proof you never tried before, or one you tried with unsatisfactory results.
So what you're asking me is like: "I have to do this ugly proof. I don't want to, just give me the result sheet so I can fill in the blanks." I will try, however I acknowledge these are not trivial design issues.
You describe having to rewrite tons of code. I propose that you should not write that code by hand in the first place. However this answer includes Lisp. You can write code in Lisp that describes your protocol, in a formal way, but at the same time, when it runs, it writes all the code that implements both parts, client and server of the protocol.
I did once some code in C++ to store data in binary files. It's a binary data protocol. But I never really wrote that C++ code. I wrote Lisp code that in turn wrote the C++ files. So if I had to change something, instead of changing a lot of code (and it really was tedious and error prone to change that much code by hand) I changed one of two lines of Lisp code and then run a function in the REPL and then go to the C++ editor and compile and run. It's great to save all that work. And you can keep tweaking your design as you go!
Changing a database schema is no harder in Lisp, because a line of code creates the classes to map objects to the database, and it handles relations and other stuff just fine. Lisp can write all the rest of the tedious and repetitive code for you. If performance is an issue, and it could be for I/O and numerical stuff, do as I did, make Lisp write C++ code.
"Worse: how about determining what is the best possible compatible architect
And as for likelihoods... Nobody KNOWS what the likelihood of a cell mutating to X is. So they can't say with any reasonable accuracy how likely this is to happen a third time.
A random atom decay in a radioactive substance is a random thing. You can't predict if a single atom will decay or not. However you can predict the decay rate, and you have the half-life of the substance, which is the time the number of radioactive isotopes will be half than what they are at time zero.
Of course they can't know about a single cell any more they can know about a single atom. But for two populations to get to the same final state, there happened a LOT of mutations and is on that many mutations that they can use statistics.
About the post you responded: there is 99.999999999% probabilities that the stuff is not random. Your comment doesn't change that.
However it doesn't say what the reason for the mutations is, if it's not random. And that it's the entire point of my first post. That you can use statistics to predict something, but it doesn't increase a bit the knowledge about the inner workings of the observed fenomena.
If the probability of such particular outcome was 50%, then two repetitions would give them only like 75% of probabilities that this would not be random. Very small and everybody would complain.
None of the following numbers are exact, but you get the idea:
Their experiment suggest that the probability of every particular outcome would be very very small if guided by random behavior. Think about 1/700000 or something like that based in the number of mutations.
So the probability of that particular outcome twice is much smaller, like 1/490000000000 (or something close).
Is like when you try to test random primes. The first time it passes the test, then there is something like a 89% probability that is prime. Twice, it's like 98%. After five passes, the probability is 99.99%. After some more, the probability is very high.
So they have something like 99.99999999% (1 - 1/490000000000).
After such high probability you could start to think that this particular outcome is not really random, but deterministic.
That's how I interpreted the experiment. Correct me if I'm wrong.
I don't think you can conclude that evolution can be predicted from that kind of experiments. Just that evolution can be observed. Evolution just happens. But the fact that we can observe it doesn't mean we can understand and predict it.
Even if in some cases the expected outcome is deterministic, we don't know how really works, see folding@home, that stuff is really computationally expensive. We would need to know the folding behavior of all possible protein and then a fast, effective way to model the interactions between those proteins. Then we can think about modelling organisms with some features (notice that this is a huge jump, we skipped modelling tissues and organs, however because some organism features are directly mapped to specific proteins, it can be done after some assumptions/observations).
If evolution can be predicted, they would not need to make experiments to make hypothesis, they would feed that data to a computer, the computer would predict some outcome (including specific genes and mutations), and then the experiment would match (or not) the outcome.
We are years, even centuries away from that.
This experiment is just bayesian inference. The sun appeared today (and appeared every day of my life before that), so I predict it will appear tomorrow, with (very close to 1) probability. I don't need to understand HOW the sun appears to predict that.
But if the article had said: "evolution can be observed" then I would agree with the article.