Linked by Takuya Murata on Tue 18th May 2004 06:26 UTC
General Development My physics teacher likes to say that physics like to make problems they face look like ones that they know how to solve. A simple harmonic oscillation was one he frequently used in class, as is presumably the case in physics in general.
Permalink for comment
To read all comments associated with this story, please click here.
A troll and a bad one at that.
by Myron on Tue 18th May 2004 08:04 UTC

"The creators of Next thought it is (sic) insanely great but not many people, many enough for being commercially feasible, shared the view. Smalltalk was meant to be intelligent tools for all of us humans, but it simply did not solve our problems for computers: number cranking. Then we ask why? The following are reasons I suspect might be a case."

First of all, NeXT engineers _did_ succeed. Their creation lives on, very successfully and commercially viably as the NS frameworks in Cocoa. Second, since when was computing about number cranking? What is a computer? There are only numbers in a computer because _we_ assign them to symbols and lower down, voltages. The Turing Machine? That works on _symbols_, not numbers. Ditto for lambda calculi--there's a reason why Church numerals exist, it shows how totally irrelevant numeric constants are to computation. Your premise of falling back on numerical computation therefore makes no sense.

"No one knows what is OOP"? Not quite. Perhaps it's hard to pin down an exact definition, but it's a far fetch to say _no_ one knows it. Oop modeling the real world is a fallacy that you might've picked up, but there are others who didn't. Smalltalkers are among the best example for this--that using objects to simulate real-world objects is only half the story. The other half is that they can be used to represent concepts and modules of functionality. Observe that it's quite hard to map MVC to real-world objects. The point is, this limitation of OOP that you imply is a self-imposed limitation--you make what you want of objects, no more, no less.

"Concurrency is a fantasy." It's hard, but it's sure as hell not a fantasy. There's a diverse amount of research in this field and I'm willing to bet your exposure to concurrency starts and ends at Java or C++ threads. Try Concurrent ML to see another take on this.

"Haskell, despite the affection of computer scientists, is miserable failure. Lisp and its derivatives like Scheme are ones that are used largely and taught in school as a general functional programming language. Haskell may improve productivity dramatically but if non-geniuses cannot use it, it will remain as a toy not a tool for real programmers."

Haskell and Lisp are far from failures. The real failure lies with people who refuse to learn anything past syntactical differences and knock languages down for being different than what they're used to. Please, keep an open mind. A decade ago, garbage collection was often scoffed at, but now it's a feature almost taken for granted. See that the same may occur to many of the items you listed as failures or things not worth caring about.

"Computers cannot be more than computers. And so we must try to solve problems in the way we know, or the way that was used to because the architecture of computers is still the same today as decades ago." And what is this "way we know"? Crunching numbers?

I'm sorry, but what is the point of your article? You asked why we have recurring problems in programming and briefly mention "cranking numbers", then you proceed to knock down a bunch of technologies--which proves nothing for your thesis--finally you wave your hands a bit and say we should return to old time-tested practices without saying what they are? If you'll permit me to say so, you're obviously unhappy with the programming world, but languishing in our own ignorance and publishing it is not a solution.