What exactly are you trying to infer from the trading volumes? It just looks like more people are trading Intel because Intel is a bigger company. Also, the link to ARM you posted is for an ADR, so Google might not even be including the numbers from the native exchange. And above all the, the only thing a heavily traded stock should mean is a low bid-ask spread
Finally, ARM doesn't sell any chips. They design them, and license the cores to companies that fab them, ie TI, Nvidia, and even Intel.
LISP and Self are highly dynamic languages, yet they're compiled. If they can be compiled, then so can Python.
The difference between Lisp and Python (aside from kludgey syntax) is that Lisp records are not hash-tables. Structures in Lisp are actually vectors, so a field lookup is one pointer dereference and an add over directly having the object reference (same as Java). I'm not sure how you'd do similar things in Python. Maybe caching the most recently accessed field at each access point would help.
What are you, an NI shill? Dataflow programming models suck for all but a very small domain of problems, and those problems are pretty damn easy to solve in conventional languages.
Object Orientation is just a method of organisation for procedural languages.
Do you realize that closures and OOP objects are semantically identical? Both are a function(s) and associated state. The only differences are syntactic (ignoring the unforgivable lack of GC in some languages claiming to be object oriented)
It seems like organic life would be most likely since its made of up lighter molecules which are more common in the universe, ie there's are lot more carbon around than there is silicon.
After all, when was the last time you read a book and though "Wow, the page layout in this book *rocks*?".
I've thought the opposite. The Circuit Problems Book Which Shall Not Be Named looked like someone just vomited a bunch of text and figures into MSWord. It was appallingly awful.
Would the error have been caught with a more alert programmer? Would the error have been caught with a more thorough code review? Would the error have been caught with consistent units in the project?
Programming is an exercise in managing complexity. Anything which increases the system's complexity for no good reason is a Bad Idea. English units are one of those things.
So, you can blame the person, or you can recognize that humans have a finite capacity to understand complex systems. The former approach requires you to find a group of "Heroes" to develop your software. Or if you recognize that many problems are the result of your system and you eliminate needless complexity, your group of competent programmers can do the job, and any heroes you manage to find can do something really cool.
its only the soulless who think... that all measurements should be in a base ten
No, its anybody who ever had to do an engineering or physics calculation, ever. You can take your bullshit English/Imperial system and go dance in the trees or whatever your trying to get at there.
I have always believed that the vast majority of today's programming languages have been invented out of thin air for no reason other than to ultimately ensure the employment of programmers and consultants.
For example, lots of people use Fortran, C, C++, Python, Perl, Java, or C#. I see absolutely no reason why a single language could not offer all those features. The only reason you "need" all that is because the programmers created all these funny quirks so that they could introduce more and more products and services. This is done so they can charge you more for each of those things, and also to differentiate them from their competitors.
Seriously though...
Different accounts offer different features. You could try to make do with a single deposit account instead of a checkings/savings/CC combo, but probably wouldn't get as much return as you do with specialized products. Loans are totally different from deposit accounts, though, so I don't know how you'd plan to combine them. Also, a lot of the complexity here comes from dealing with Congress's regulations. Since everybody seems to think we don't have enough of those now, that's probably not going to get simpler anytime soon.
Bear in mind that within just five years, members of the MySpace generation are going to be entering the workforce, bringing their collaborative tools with them.
Java of course walls itself because writing native code in Java is the antithesis of what Java is about.
Yes, and their solution is usually far more painful than the problem.
you should be jumping straight to pure C ( no STL even ) or ASM. Fortran is a pointless in-between step.
Actually, for numerical code, fortran for awhile would outperform C because it was easier for a compiler to auto-vectorize fortran. I think auto-vectorizers have gotten smarter now, so there may not be much of a difference making the main reason to choose one language over the other is probably mostly aesthetic. Of course, I've never done any significant amount of fortran, so those aesthetic reasons may be pretty compelling.
But Java isn't slow anymore, and hasn't been for quite a while now, either. Now it just uses massive amounts of memory:~)
That's nice, but we already have a highly optimized, debugged, and widely deployed matrix library in Fortran. Why not just call it from our higher level languages?
Personally, I use BLAS with some C++ sugar on top. Mixing Fortran, C, and C++ is actually pretty trivial since they don't feel the need to wall themselves off from the rest of the world like Java; it's even easier to call C from Lisp the contortions Java makes you go through. Also, since Java lacks operator overloading, and realtime garbage collection isn't quite there yet, I don't see how it would be an improvement, or even a possibility for the Controls work I do.
Is the newest FORTRAN even a real language yet? ( e.g. you can't write a FORTRAN compiler using FORTRAN ).
Fortran is Turing Complete, so yes. Also, wikipedia says that Pascal was first implemented in Fortran.
Java needs that much RAM to do efficient garbage collection.
Actually, it probably has more to do with braindamaged design decisions like giving every single object an extra word in case somebody ever wants to take a lock on it. There's no way a decent garbage collector would have that much overhead.
how does it come that Lisp always comes out rather high in those rankings, while newer languages like Ruby and Python and up deep down at the bottom?
Because Lisps have real compilers.
In terms of expressiveness they all are very similar, yet nobody seems to have bothered to write a proper native code compiler for the newer languages, even so the popular interest in them is much larger then that for Lisp. Is there any fundamental reason for this?
Even if Java or Python is using the same third party libraries as you might use in C, the data will still be wrapped in ungodly layers of memory management garbage.
Actually, using a garbage collector can reduce the memory used by a program since you can much more easily reuse portions of data structures. Of course, that doesn't mean Java or Python tend to do a good job of that...
If anything, current CPUs best match the imperative model (and more cores of a similar design won't change that); But they only do so out of popularity - If functional programming didn't count as a complete bitch to implement with no benefits over imperative or OO, CPUs would export a more functional-friendly ISA.
I think they tried to do that in the 80's with the lisp machines. Turned out that a RISC chip would run high-level code faster than the custom hardware, and it would also run C much faster.
In that, on Von Neuman architecture, the nonrecursive form of any given algorithm will outperform the recursive version
That's why reasonable languages optimize tail recursion. Then you can just write the recursive form when it is more clear than the iterative form.
Erlang and Lisp have been around for years. If FP was the answer, it would have happened already. The only reason it hasn't happened is because reality keeps kicking FP in the ass.
Functionaly languages haven't taken off in a large part because garbage collectors have only rather recently become "good enough."
FP is not just counterintuitive and hard to learn...
Your right that many programmers seem to have hard time grasping FP.
...it is also non-deterministic, meaning that it is not well-suited to mission critical systems.
Now that's just false. Of course FP languages are deterministic, and try telling the trading companies using Ocaml that FP isn't suited for "mission critical" work. Or tell it to Intel and AMD who use ML and Scheme to verify their processor designs. The only thing close to what your were saying is that GC can introduce unpredictable pause times; not a problem for most apps but a killer for real-time systems. Of course, there's a lot of recent research into real-time garbage collectors with very good results.
FP is a continuation of the same process/thread mentality that has gotten the industry into this mess in the first place.
Slashdot Mirror
LabVIEW makes easy things easy and hard things impossible. Those responsible should be drawn and quartered. Matlab sucks too.
When the robot wars come, then we'll see who's laughing...
You can block the ads via hosts file: http://www.mvps.org/winhelp2002/hosts.txt
debian (or netbsd)
What exactly are you trying to infer from the trading volumes? It just looks like more people are trading Intel because Intel is a bigger company. Also, the link to ARM you posted is for an ADR, so Google might not even be including the numbers from the native exchange. And above all the, the only thing a heavily traded stock should mean is a low bid-ask spread
Finally, ARM doesn't sell any chips. They design them, and license the cores to companies that fab them, ie TI, Nvidia, and even Intel.
The difference between Lisp and Python (aside from kludgey syntax) is that Lisp records are not hash-tables. Structures in Lisp are actually vectors, so a field lookup is one pointer dereference and an add over directly having the object reference (same as Java). I'm not sure how you'd do similar things in Python. Maybe caching the most recently accessed field at each access point would help.
What are you, an NI shill? Dataflow programming models suck for all but a very small domain of problems, and those problems are pretty damn easy to solve in conventional languages.
Do you realize that closures and OOP objects are semantically identical? Both are a function(s) and associated state. The only differences are syntactic (ignoring the unforgivable lack of GC in some languages claiming to be object oriented)
It seems like organic life would be most likely since its made of up lighter molecules which are more common in the universe, ie there's are lot more carbon around than there is silicon.
They sort of tried that, way back in the Atomic Age. Maybe one of these small-scale fusion guys will eventually get something energy positive, though.
I've thought the opposite. The Circuit Problems Book Which Shall Not Be Named looked like someone just vomited a bunch of text and figures into MSWord. It was appallingly awful.
Are you insane or trolling? All reasonable text editors have spell checkers.
MSWord is not the answer. Ever.
Would the error have been caught with a more alert programmer? Would the error have been caught with a more thorough code review? Would the error have been caught with consistent units in the project?
Programming is an exercise in managing complexity. Anything which increases the system's complexity for no good reason is a Bad Idea. English units are one of those things.
So, you can blame the person, or you can recognize that humans have a finite capacity to understand complex systems. The former approach requires you to find a group of "Heroes" to develop your software. Or if you recognize that many problems are the result of your system and you eliminate needless complexity, your group of competent programmers can do the job, and any heroes you manage to find can do something really cool.
No, its anybody who ever had to do an engineering or physics calculation, ever. You can take your bullshit English/Imperial system and go dance in the trees or whatever your trying to get at there.
Remember folks, English Units Crash Rockets.
I have always believed that the vast majority of today's programming languages have been invented out of thin air for no reason other than to ultimately ensure the employment of programmers and consultants.
For example, lots of people use Fortran, C, C++, Python, Perl, Java, or C#. I see absolutely no reason why a single language could not offer all those features. The only reason you "need" all that is because the programmers created all these funny quirks so that they could introduce more and more products and services. This is done so they can charge you more for each of those things, and also to differentiate them from their competitors.
Seriously though...
Different accounts offer different features. You could try to make do with a single deposit account instead of a checkings/savings/CC combo, but probably wouldn't get as much return as you do with specialized products. Loans are totally different from deposit accounts, though, so I don't know how you'd plan to combine them. Also, a lot of the complexity here comes from dealing with Congress's regulations. Since everybody seems to think we don't have enough of those now, that's probably not going to get simpler anytime soon.
God help us all.
Yes, and their solution is usually far more painful than the problem.
Actually, for numerical code, fortran for awhile would outperform C because it was easier for a compiler to auto-vectorize fortran. I think auto-vectorizers have gotten smarter now, so there may not be much of a difference making the main reason to choose one language over the other is probably mostly aesthetic. Of course, I've never done any significant amount of fortran, so those aesthetic reasons may be pretty compelling.
So very true...
That's nice, but we already have a highly optimized, debugged, and widely deployed matrix library in Fortran. Why not just call it from our higher level languages?
Personally, I use BLAS with some C++ sugar on top. Mixing Fortran, C, and C++ is actually pretty trivial since they don't feel the need to wall themselves off from the rest of the world like Java; it's even easier to call C from Lisp the contortions Java makes you go through. Also, since Java lacks operator overloading, and realtime garbage collection isn't quite there yet, I don't see how it would be an improvement, or even a possibility for the Controls work I do.
Fortran is Turing Complete, so yes. Also, wikipedia says that Pascal was first implemented in Fortran.
You've obviously never used Lisp.
Actually, it probably has more to do with braindamaged design decisions like giving every single object an extra word in case somebody ever wants to take a lock on it. There's no way a decent garbage collector would have that much overhead.
Because Lisps have real compilers.
No
Actually, using a garbage collector can reduce the memory used by a program since you can much more easily reuse portions of data structures. Of course, that doesn't mean Java or Python tend to do a good job of that...
for( i=0; 0 != fun1(i); i++) //;
non_loop_fun();
I think they tried to do that in the 80's with the lisp machines. Turned out that a RISC chip would run high-level code faster than the custom hardware, and it would also run C much faster.
That's why reasonable languages optimize tail recursion. Then you can just write the recursive form when it is more clear than the iterative form.
Functionaly languages haven't taken off in a large part because garbage collectors have only rather recently become "good enough."
Your right that many programmers seem to have hard time grasping FP.
Now that's just false. Of course FP languages are deterministic, and try telling the trading companies using Ocaml that FP isn't suited for "mission critical" work. Or tell it to Intel and AMD who use ML and Scheme to verify their processor designs. The only thing close to what your were saying is that GC can introduce unpredictable pause times; not a problem for most apps but a killer for real-time systems. Of course, there's a lot of recent research into real-time garbage collectors with very good results.
Ok, now I'm convinced that your full of crap.