The creator emphasizes that the system cannot recognize voices or words, but his previous research into speech recognition systems suggests otherwise."
Yes, his "previous research" suggests that his new claims are just as bogus as his old claims.
Re:Living with AIDS will cause it to spread?
on
HIV Vaccine
·
· Score: 1
If you regularly get bitten by mosquitoes, you are in serious trouble and should be taking more precautions.
That should have been:
If you regularly get bitten by mosquitoes, you are at serious risk for debilitating and fatal diseases other than HIV and should be taking more precautions.
Re:Living with AIDS will cause it to spread?
on
HIV Vaccine
·
· Score: 2, Informative
AIDS does have low grade secondary transmission vectors.
No, it does not. HIV has never been shown to be transmitted by mosquitoes, and it isn't even clear how a mosquito could transmit HIV.
If over 99% of the population is AIDS free then the likelhood of a mosquitoe carrying AIDS and picking on a new victim is extremely low. However if 50% of the population has AIDS then the likelihood is quite significant.
50 times zero is still zero.
And even if you live with the misconception that HIV can be transmitted at a low rate, 50 times a very low rate is still a very low rate. If you regularly get bitten by mosquitoes, you are in serious trouble and should be taking more precautions.
If you don't have unprotected sex and don't share needles, you should be more worried about traffic accidents, falls, the flu, heart disease, cancer, and crossing the street, because one of those probably will get you.
What chance do I have in the real world with a not-so-prestigious degree?
A prestigious degree may get people to notice your resume, open doors for you and give you a few opportunities you wouldn't otherwise have for your first couple of jobs. After that, your previous jobs are usually more important.
Another important aspect of where you attend college is the people you get to know: those will be part of your Rolodex for the rest of your life.
Am I likely to be learning what's important?
Probably not, but that's the same with every degree. Ultimately, you yourself are responsible for learning what's important.
Am I looking at a series of awful jobs if I don't transfer?
Maybe, or maybe not.
Overall, it's probably better to do well and learn a lot at a less well-known university than to be unhappy, do poorly, and/or learn little at a prestigious university. Prestigious universities are prestigious for a reason, and they tend to be highly competitive even after you get in.
They are out of their core business, which was to develop high-end graphics workstations with specialized graphics hardware and software (IRIX, GL), now made pretty much redundant by PC-based systems.
These days, they are shipping Linux clusters. That's a nice business, but it's a different business.
So that XORP might be open source, but it has to be commercialized as well.
Of course. That's how open source works: people share the source code, but support, integration, add-ons, and improvements are pay-for-service kinds of deals. In fact, for a lot of open source software, it's the companies offering commercial support that are also paying developers for continued improvements to the open source project.
As for Open Source projects, usually, they are known by "fix-it-yourself".
I'm sure Microsoft's FUD machine likes to present open source projects that way, but in the real world, that is totally wrong. If you want support for your open source projects, you can buy it, and you still end up with lower support costs and lower risk than if you buy closed-source software with support.
That a bunch of general purpose commodity hardware is going to replace their highly engineered, specialized hardware.
Yes, and SGI probably never thought that PC hardware would drive them out of business either.
Also, only a small core needs to be high performance; hardware vendors can take this kind of open platform, add a small piece of specialized hardware and custom software, and save themselves a boatload of development effort, and their customers a lot of training costs.
it's hardly the first effort to make routing software in an open-source format, it may be the most promising, due to $3 million in funding from high-powered backers such as Intel, Microsoft (MSFT ), and the National Science Foundation.
The biggest news here is perhaps not that there is an effort to create open source routing software, but that such an effort is backed by Microsoft.
Along that line, are there any technical limitations--e.g., about the compiler design, etc.--that prevent the sort of numerical libraries you mention from being developed? Is it just a matter of a critical mass of effor being focused on numerical computing in OCaml?
I think it's the usual combination of things:
It requires some small language changes that people who don't need the feature consider unnecessary language complexity, so these kinds of proposals usually cause lengthy discussions.
It requires a large chunk of work on an implementation that was designed without those features in mind.
The people who need the feature are generally not the ones that are in a position to modify the compiler and runtime; and the people who can modify the compiler and runtime think (incorrectly IMO) that other needs are more pressing and find other topics (call/cc, whatever) more interesting to work on.
It seems to take a few decades until efficient numerical abstraction facilities get added to languages/language families. With Fortran, it took until the 1990's. With C, it took until C++ came out. With Pascal, it also took until the 1990's. Java has steadfastly refused to do anything about this (despite lots of recommendations and push from users), but C# is picking up the torch there. The core of what is needed is efficient value classes, efficient arrays of value classes, built-in mono-typed multidimensional arrays, a small amount of overloading, and a few smaller sundry things. Nice, but not stricly speaking necessary, are built-in data-parallel array operations and linear algebra functionality in the standard library.
There have been some timid attempts at efficient functional programming languages for numerical computations. One of the best known is probably SISAL. But while SISAL was a valiant attempt specifically for numerical applications, it fails at being a good general purpose language: that is, numerical code is all you ever want to write in it.
I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types
Don't get me wrong: I think OCAML is a great language for specific application domains (theorem provers, compiler writing, etc.), and Java has become a decent language for traditional server-side applications. But in order to become general purpose languages, languages that people can use instead of C/C++ without reservation, I think they must get better numerical support.
Better numerical support does not mean that those languages have to get implementations that can beat optimized Fortran. It also does not just mean that it is possible, in principle, to write fast numeric code (you can write fast numeric code in Java and OCAML if you really have to--it just is a lot of work). It means that people can write decently clean, maintainable numerical code without having to make much of an effort.
The thing that is frustrating is that language designers keep underestimating the importance of good support for that kind of programming, and one promising language after another dies because of of that misjudgement.
In the case of Java, people now have an alternative: C# is basically Java with those missing pieces added. There are lots of political issues surrounding the two languages, but if it just came down to technology, it would be a no brainer to figure out which one would win in the market. And I think functional programming languages won't make it big time until one of them adds analogous functionality.
1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.
That code doesn't use a complex datatype--it uses real arrays and writes out the complex number operations. The FFT example was not to get an FFT, it was to illustrate a point about what operations a language can and cannot support.
2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.
FFT itself is needed by lots of applications: financial software, image processing software, speech recognition software, speech synthesis software, etc. But it isn't about FFT in particular or complex numbers in particular: you encounter analogous problems with datatypes appearing in graphics, reliable numerical computing, graph algorithms, language processing, statistics, and lots of other areas.
3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.
You just don't get it, do you? Numerical, semi-numerical, statistical, scientific, graphics, and visualization code is moving into applications and the people who are writing want better tools for writing it than using C or even C++. We are f*cking tired of being told by ivory-tower compiler writers that we should just write our code in C just so that they don't have to get their hands dirty. I have "just linked in" C code for 20 years: it's a lot of work, it's difficult to package, and it erases all the runtime safety that writing in OCAML should give you. It's time that language designers with aspirations for designing general purpose languages get a clue.
Languages like OCAML and Java are defective as general purpose languages because they don't support efficient data abstraction for numerical types. The fact that their designers just don't get that fact is a testament to the ignorance of their designers. It's also what people really mean when they say that those kinds of languages are "just not efficient as C/C++": it means that in C/C++, you can get whatever code you write to run fast, while in OCAML or Java, there are always problems where you have to drop down to C.
I didn't realize Python supported closures. Can the closure variables be modified or are they read only?
You can't modify them. That's a deliberate decision based on Python design principles (see here for a discussion). Personally, I disagree with the decision because I consider the consequences unintuitive, but it isn't worth worrying about it because it's not a big issue in practice: Python has much less need for them because it supports bound methods, iterators, and comprehensions, and when you really need a modifiable location in the enclosing scope, it's still easy to express. (If you want to talk language cleanliness, I think Python makes up for that wart relative to CL just by treating functions and closures consistently as values alone.)
Also, using 'def' in a Python function sounds identical to using FLET or LABELS in a CL function. Of course in CL you can also just use LAMBDA.
Yes; I would argue, however, that the Python syntax is a bit more natural. Scheme implementations also often support nested DEFINEs.
Also, could you define more than one local 'def' function and return them all? Could they access the same closure variables?
Yes, but you really want to use a class in that case.
Any serious numerical programming needs an array type. List types based on indirection, whether from Lisp or Python just don't do the job -- too much overhead.
Python "lists" are extensible 1D arrays; there is no extra indirection.
Python is working on arrays -- Numeric and Numarray -- but adoption seems slow in stuff like plot and graphics packages.
Numeric and Numarray are widely used by people who need them and they are great and mature packages. But I think the fact that they aren't used universally is deliberate: if their performance and/or functionality isn't needed for a particular application, it's probably better to stick with regular Python lists to keep things simple.
I would like to use Python as a replacement for Matlab -- I am bothered that we are so stuck on Matlab in our engineering curriculum -- a university shouldn't be shilling for a properietary language from a single vendor. Besides, Matlab is so ad hoc and cobbled together -- I think we could use something with a better theoretical foundation in language design.
I fully agree there. And the way to make that happen is to create more packages. I am writing numerical Python packages and making them available publicly. The more people do that, the sooner we can replace Matlab.
OCAML is a great language. Unfortunately, despite its excellent performance on many benchmarks, OCAML performance on common kinds of numerical or graphics code is still lacking.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications. Java fails this test, too. Among commonly used modern languages, C++, C#, and Fortran 90 pass that test.
the Linux desktop also was impenetrable, but only was only targeted by 0.26% of all attacks."
People like to infer that Linux gets targeted very little because it is used very little. But that's wrong: Linux is used a lot for well-connected servers--a juicy target for botnets.
I suspect a big reason Linux gets targeted very little is because attackers realize the futility of targeting it: Linux systems are generally more secure out of the box, and they are generally maintained better.
Well, my main point was that what Linus uses probably shouldn't matter to most people because what Linus does is pretty atypical.
It's not that they have blinders on, it's that you can only do so much well.
The problem is that we have far too many languages of the form that language designers like to design. We don't a dozen variants of ML, we need some more languages like SISAL.
So, in your example, tools like Matlab can go back and forth between letting Matlab routines be called from C,
Ah, Matlab calling C--the unspeakable calling the inedible. Seriously, both Matlab and C were steps backward from systems that preceded them.
Python is a lot like CommonLisp: dynamic typing, reflection, eval, lexical scoping, extensive iteration and looping constructs, strings-as-sequences, and on and on.
For once thing is the "big difference" you describe: you can't transparently process code as data. That means no MACROS, which is what makes Lisp so damn powerful.
Go back and read the original papers on hygienic macros: you don't need Lisp syntax or code-as-data in order to have a macro facility as powerful as Scheme's (and Scheme got by for many years without macros anyway). I wouldn't be surprised if Python at some point gets a hygienic macro facility. Furthermore, there is a separate data syntax for Python that takes source that looks very similar to Python code and represents it as a DOM tree.
How do you return an anonymous function from a function in Python?
In the obvious way:
A ``def'' form executed inside a function definition defines a local function that can be returned or passed around. Free variables used in the nested function can access the local variables of the function containing the def.
That part is actually more natural than doing the same in CommonLisp (Python, like Scheme, but unlike CommonLisp, does not have separate value and function slots on symbols).
How do you build a function at run time? It's not easy or obvious.
There are two things you could mean by that. The first is to build it from source or structure. You can do this:
exec "def c(x): return x*x*x"
The second is to build complex functions using functions that take functions as arguments. You do that the same way you do in CommonLisp, since Python supports the same primitives: lexical closures, dynamic typing, and functions that take functions as arguments.
I think people see "lambda" and they somehow think that Python has something to do with Lisp.
I think Lisp zealots incorrectly think nothing that isn't exactly Lisp could even come close. Python, in fact, is very close to Lisp; the two big differences are syntax and lack of macros. Lack of macros can be addressed, and there are separate Python-like syntactic representations of data.
Linux is good at what he does, but what he does represents only a small slice of programming. So, his choice of language and tools really shouldn't have any bearing on your choice unless you happen to be in the business of writing big, monolithic kernels for PC hardware.
Actually, a lot of language and systems designers have blinders on when it comes to the needs of large chunks of their potential user communities. In particular, numerical and scientific users get short-changed in this because most people who develop programming languages think about their needs as an afterthought. As a result, languages like Java end up being awful for scientific programming, while languages like Matlab and Fortran, which have a lot of the features scientific programmers need, end up being awful languages.
Python is an excellent language for lots of applications; give it a try. There is a good chance you will like it and find it very useful.
Agreed: decimal representations are pretty useless. You might as well use binary integers and appropriate scaling. And that is what any implementation of decimal arithmetic should be: binary numbers with implicit decimal scale factors.
I'm not sure what it means, but Python is looking an awful lot like CommonLisp, down to the somewhat controversial syntax.
There are two big differences. One is that CommonLisp made it a lot easier to treat programs as data and vice versa, and it had a built-in high-performance native compiler. On the other hand, Python integrates a lot better with Linux and UNIX, there are tons more libraries for it, and is easier for new users to learn.
Re:Languages die for a reason
on
Delphi Renaissance
·
· Score: 2, Insightful
You are naive if you think that C, C++, Java, or C# are "superior languages". Languages used commercially are basically going in circles and are still at the level of 1960's and 1970's technology.
Re:Delphi has always been under-rated
on
Delphi Renaissance
·
· Score: 1
Delphi was one of the first truly great object-oriented development environments
Delphi was a good programming environment, but it came out in 1995. Apple had a powerful visual Pascal-based OO programming environment a decade earlier. And both Delphi and Apple's environments paled in comparison to the Smalltalk environments available since the early 1980's.
Tognazzini is the one to complain: he was at Apple and probably had more opportunity than just about anybody else to fix these problems. Yet, Apple stuck with its ROM-based, disk-based architecture. Why? It's not because it was technically the best design; that was clear even then. It's because it allowed Apple to deliver a sufficiently good product at a sufficiently low price. And that's how all those decisions are made: engineering tradeoffs between cost, backwards compatibility, programmer acceptance, complexity, time-to-market, and usability. No company that wants to stay in business can optimize just usability alone.
Slashdot Mirror
The creator emphasizes that the system cannot recognize voices or words, but his previous research into speech recognition systems suggests otherwise."
Yes, his "previous research" suggests that his new claims are just as bogus as his old claims.
If you regularly get bitten by mosquitoes, you are in serious trouble and should be taking more precautions.
That should have been:
If you regularly get bitten by mosquitoes, you are at serious risk for debilitating and fatal diseases other than HIV and should be taking more precautions.
AIDS does have low grade secondary transmission vectors.
No, it does not. HIV has never been shown to be transmitted by mosquitoes, and it isn't even clear how a mosquito could transmit HIV.
If over 99% of the population is AIDS free then the likelhood of a mosquitoe carrying AIDS and picking on a new victim is extremely low. However if 50% of the population has AIDS then the likelihood is quite significant.
50 times zero is still zero.
And even if you live with the misconception that HIV can be transmitted at a low rate, 50 times a very low rate is still a very low rate. If you regularly get bitten by mosquitoes, you are in serious trouble and should be taking more precautions.
If you don't have unprotected sex and don't share needles, you should be more worried about traffic accidents, falls, the flu, heart disease, cancer, and crossing the street, because one of those probably will get you.
It is NOT a vaccine
Of course, it's a vaccine. It's a "therapeutic vaccine".
It is NOT a cure. It's a temporary (at best) treatment.
No, it's not a cure and it may not be a very good treatment. But neither of those observations has anything to do with it being a vaccine.
I'm sorry if you don't like the official terminology, but that doesn't mean you can just change it.
Furthermore, the discovery that anything can create a somewhat effective immune response against HIV is a major breakthrough.
What chance do I have in the real world with a not-so-prestigious degree?
A prestigious degree may get people to notice your resume, open doors for you and give you a few opportunities you wouldn't otherwise have for your first couple of jobs. After that, your previous jobs are usually more important.
Another important aspect of where you attend college is the people you get to know: those will be part of your Rolodex for the rest of your life.
Am I likely to be learning what's important?
Probably not, but that's the same with every degree. Ultimately, you yourself are responsible for learning what's important.
Am I looking at a series of awful jobs if I don't transfer?
Maybe, or maybe not.
Overall, it's probably better to do well and learn a lot at a less well-known university than to be unhappy, do poorly, and/or learn little at a prestigious university. Prestigious universities are prestigious for a reason, and they tend to be highly competitive even after you get in.
SGI isn't out of business,
They are out of their core business, which was to develop high-end graphics workstations with specialized graphics hardware and software (IRIX, GL), now made pretty much redundant by PC-based systems.
These days, they are shipping Linux clusters. That's a nice business, but it's a different business.
So that XORP might be open source, but it has to be commercialized as well.
Of course. That's how open source works: people share the source code, but support, integration, add-ons, and improvements are pay-for-service kinds of deals. In fact, for a lot of open source software, it's the companies offering commercial support that are also paying developers for continued improvements to the open source project.
As for Open Source projects, usually, they are known by "fix-it-yourself".
I'm sure Microsoft's FUD machine likes to present open source projects that way, but in the real world, that is totally wrong. If you want support for your open source projects, you can buy it, and you still end up with lower support costs and lower risk than if you buy closed-source software with support.
That a bunch of general purpose commodity hardware is going to replace their highly engineered, specialized hardware.
Yes, and SGI probably never thought that PC hardware would drive them out of business either.
Also, only a small core needs to be high performance; hardware vendors can take this kind of open platform, add a small piece of specialized hardware and custom software, and save themselves a boatload of development effort, and their customers a lot of training costs.
The biggest news here is perhaps not that there is an effort to create open source routing software, but that such an effort is backed by Microsoft.
I think it's the usual combination of things:
It seems to take a few decades until efficient numerical abstraction facilities get added to languages/language families. With Fortran, it took until the 1990's. With C, it took until C++ came out. With Pascal, it also took until the 1990's. Java has steadfastly refused to do anything about this (despite lots of recommendations and push from users), but C# is picking up the torch there. The core of what is needed is efficient value classes, efficient arrays of value classes, built-in mono-typed multidimensional arrays, a small amount of overloading, and a few smaller sundry things. Nice, but not stricly speaking necessary, are built-in data-parallel array operations and linear algebra functionality in the standard library.
There have been some timid attempts at efficient functional programming languages for numerical computations. One of the best known is probably SISAL. But while SISAL was a valiant attempt specifically for numerical applications, it fails at being a good general purpose language: that is, numerical code is all you ever want to write in it.
I'm not sure I agree with the conclusion that OCaml (like Java) is defective due to deficiencies in handling of numeric types
Don't get me wrong: I think OCAML is a great language for specific application domains (theorem provers, compiler writing, etc.), and Java has become a decent language for traditional server-side applications. But in order to become general purpose languages, languages that people can use instead of C/C++ without reservation, I think they must get better numerical support.
Better numerical support does not mean that those languages have to get implementations that can beat optimized Fortran. It also does not just mean that it is possible, in principle, to write fast numeric code (you can write fast numeric code in Java and OCAML if you really have to--it just is a lot of work). It means that people can write decently clean, maintainable numerical code without having to make much of an effort.
The thing that is frustrating is that language designers keep underestimating the importance of good support for that kind of programming, and one promising language after another dies because of of that misjudgement.
In the case of Java, people now have an alternative: C# is basically Java with those missing pieces added. There are lots of political issues surrounding the two languages, but if it just came down to technology, it would be a no brainer to figure out which one would win in the market. And I think functional programming languages won't make it big time until one of them adds analogous functionality.
Imaging techniques that control the illumination are not new. This is a nice and simple application of them, though.
1) What do you consider "about as efficiently?" A ten-second search turns up an FFT benchmark written by Xavier Leroy; he reports that it runs about 2/3 as fast as C code.
That code doesn't use a complex datatype--it uses real arrays and writes out the complex number operations. The FFT example was not to get an FFT, it was to illustrate a point about what operations a language can and cannot support.
2) What the hell kind of "modern general-purpose application" needs to compute FFTs quickly? That's a highly specialized application.
FFT itself is needed by lots of applications: financial software, image processing software, speech recognition software, speech synthesis software, etc. But it isn't about FFT in particular or complex numbers in particular: you encounter analogous problems with datatypes appearing in graphics, reliable numerical computing, graph algorithms, language processing, statistics, and lots of other areas.
3) If certain algorithms cannot be computed quickly in OCaml, just write them in C. Bindings to C functions are trivial to write. You want to do FFTs? It's already been done.
You just don't get it, do you? Numerical, semi-numerical, statistical, scientific, graphics, and visualization code is moving into applications and the people who are writing want better tools for writing it than using C or even C++. We are f*cking tired of being told by ivory-tower compiler writers that we should just write our code in C just so that they don't have to get their hands dirty. I have "just linked in" C code for 20 years: it's a lot of work, it's difficult to package, and it erases all the runtime safety that writing in OCAML should give you. It's time that language designers with aspirations for designing general purpose languages get a clue.
Languages like OCAML and Java are defective as general purpose languages because they don't support efficient data abstraction for numerical types. The fact that their designers just don't get that fact is a testament to the ignorance of their designers. It's also what people really mean when they say that those kinds of languages are "just not efficient as C/C++": it means that in C/C++, you can get whatever code you write to run fast, while in OCAML or Java, there are always problems where you have to drop down to C.
I didn't realize Python supported closures. Can the closure variables be modified or are they read only?
You can't modify them. That's a deliberate decision based on Python design principles (see here for a discussion). Personally, I disagree with the decision because I consider the consequences unintuitive, but it isn't worth worrying about it because it's not a big issue in practice: Python has much less need for them because it supports bound methods, iterators, and comprehensions, and when you really need a modifiable location in the enclosing scope, it's still easy to express. (If you want to talk language cleanliness, I think Python makes up for that wart relative to CL just by treating functions and closures consistently as values alone.)
Also, using 'def' in a Python function sounds identical to using FLET or LABELS in a CL function. Of course in CL you can also just use LAMBDA.
Yes; I would argue, however, that the Python syntax is a bit more natural. Scheme implementations also often support nested DEFINEs.
Also, could you define more than one local 'def' function and return them all? Could they access the same closure variables?
Yes, but you really want to use a class in that case.
Any serious numerical programming needs an array type. List types based on indirection, whether from Lisp or Python just don't do the job -- too much overhead.
Python "lists" are extensible 1D arrays; there is no extra indirection.
Python is working on arrays -- Numeric and Numarray -- but adoption seems slow in stuff like plot and graphics packages.
Numeric and Numarray are widely used by people who need them and they are great and mature packages. But I think the fact that they aren't used universally is deliberate: if their performance and/or functionality isn't needed for a particular application, it's probably better to stick with regular Python lists to keep things simple.
I would like to use Python as a replacement for Matlab -- I am bothered that we are so stuck on Matlab in our engineering curriculum -- a university shouldn't be shilling for a properietary language from a single vendor. Besides, Matlab is so ad hoc and cobbled together -- I think we could use something with a better theoretical foundation in language design.
I fully agree there. And the way to make that happen is to create more packages. I am writing numerical Python packages and making them available publicly. The more people do that, the sooner we can replace Matlab.
OCAML is a great language. Unfortunately, despite its excellent performance on many benchmarks, OCAML performance on common kinds of numerical or graphics code is still lacking.
Basically, if you can't write a complex FFT with a user-defined complex number type and have it work about as efficiently (in both space and time) as equivalent Fortran 90 or C++ code, then the language is not suitable for modern general-purpose applications. Java fails this test, too. Among commonly used modern languages, C++, C#, and Fortran 90 pass that test.
the Linux desktop also was impenetrable, but only was only targeted by 0.26% of all attacks."
People like to infer that Linux gets targeted very little because it is used very little. But that's wrong: Linux is used a lot for well-connected servers--a juicy target for botnets.
I suspect a big reason Linux gets targeted very little is because attackers realize the futility of targeting it: Linux systems are generally more secure out of the box, and they are generally maintained better.
Well, my main point was that what Linus uses probably shouldn't matter to most people because what Linus does is pretty atypical.
It's not that they have blinders on, it's that you can only do so much well.
The problem is that we have far too many languages of the form that language designers like to design. We don't a dozen variants of ML, we need some more languages like SISAL.
So, in your example, tools like Matlab can go back and forth between letting Matlab routines be called from C,
Ah, Matlab calling C--the unspeakable calling the inedible. Seriously, both Matlab and C were steps backward from systems that preceded them.
Python is a lot like CommonLisp: dynamic typing, reflection, eval, lexical scoping, extensive iteration and looping constructs, strings-as-sequences, and on and on.
For once thing is the "big difference" you describe: you can't transparently process code as data. That means no MACROS, which is what makes Lisp so damn powerful.
Go back and read the original papers on hygienic macros: you don't need Lisp syntax or code-as-data in order to have a macro facility as powerful as Scheme's (and Scheme got by for many years without macros anyway). I wouldn't be surprised if Python at some point gets a hygienic macro facility. Furthermore, there is a separate data syntax for Python that takes source that looks very similar to Python code and represents it as a DOM tree.
How do you return an anonymous function from a function in Python?
In the obvious way: That part is actually more natural than doing the same in CommonLisp (Python, like Scheme, but unlike CommonLisp, does not have separate value and function slots on symbols).
How do you build a function at run time? It's not easy or obvious.
There are two things you could mean by that. The first is to build it from source or structure. You can do this: The second is to build complex functions using functions that take functions as arguments. You do that the same way you do in CommonLisp, since Python supports the same primitives: lexical closures, dynamic typing, and functions that take functions as arguments.
I think people see "lambda" and they somehow think that Python has something to do with Lisp.
I think Lisp zealots incorrectly think nothing that isn't exactly Lisp could even come close. Python, in fact, is very close to Lisp; the two big differences are syntax and lack of macros. Lack of macros can be addressed, and there are separate Python-like syntactic representations of data.
Linux is good at what he does, but what he does represents only a small slice of programming. So, his choice of language and tools really shouldn't have any bearing on your choice unless you happen to be in the business of writing big, monolithic kernels for PC hardware.
Actually, a lot of language and systems designers have blinders on when it comes to the needs of large chunks of their potential user communities. In particular, numerical and scientific users get short-changed in this because most people who develop programming languages think about their needs as an afterthought. As a result, languages like Java end up being awful for scientific programming, while languages like Matlab and Fortran, which have a lot of the features scientific programmers need, end up being awful languages.
Python is an excellent language for lots of applications; give it a try. There is a good chance you will like it and find it very useful.
Agreed: decimal representations are pretty useless. You might as well use binary integers and appropriate scaling. And that is what any implementation of decimal arithmetic should be: binary numbers with implicit decimal scale factors.
I'm not sure what it means, but Python is looking an awful lot like CommonLisp, down to the somewhat controversial syntax.
There are two big differences. One is that CommonLisp made it a lot easier to treat programs as data and vice versa, and it had a built-in high-performance native compiler. On the other hand, Python integrates a lot better with Linux and UNIX, there are tons more libraries for it, and is easier for new users to learn.
You are naive if you think that C, C++, Java, or C# are "superior languages". Languages used commercially are basically going in circles and are still at the level of 1960's and 1970's technology.
Delphi was one of the first truly great object-oriented development environments
Delphi was a good programming environment, but it came out in 1995. Apple had a powerful visual Pascal-based OO programming environment a decade earlier. And both Delphi and Apple's environments paled in comparison to the Smalltalk environments available since the early 1980's.
Tognazzini is the one to complain: he was at Apple and probably had more opportunity than just about anybody else to fix these problems. Yet, Apple stuck with its ROM-based, disk-based architecture. Why? It's not because it was technically the best design; that was clear even then. It's because it allowed Apple to deliver a sufficiently good product at a sufficiently low price. And that's how all those decisions are made: engineering tradeoffs between cost, backwards compatibility, programmer acceptance, complexity, time-to-market, and usability. No company that wants to stay in business can optimize just usability alone.