If that was the case, we wouldn't need Java and C#
Right, because Java and C# are new and improved systems programming languages. Don't say Singularity.
Down at the bottom, the fundamental problem with C and C++ is the "pointer=array" concept.
Of course, how stupid of them! All this work trying to support user-defined abstractions for systems programming and the problem was a tiny typing rule the whole time!!! Let me guess, the root of all Java's problems is the covariant array subtyping problem? The same with covariant argument subtyping in Eiffel too?
Perhaps you mean the ability to look at memory as a sequence of bytes... except that that's just a little bit fundamental to systems programming. So you think that the millions of lines of BIOSes, kernels, device drivers, and ROMs should be written in assembly? Trust me, although the specific memory models will change over time (certainly away from UMA), as long as there is systems programming, there will always be a high-level language (in the old meaning of the word) that takes you to the metal. Although clearly we shouldn't be using it to write e-Commerce apps, educational software, internal IT apps, and whatever you do.
You would be amazed at how many students I've tutored where the teacher is explaining virtual function pointers and still 90% of the class still doesn't know how to pass an integer to a function!
Wow, they must really be in a hurry, forcing them to combine functions pointers and virtual functions into a single concept!
I know it can still be used that way, but it seems to be more and more difficult to only code that way using C++, because you're going to have to use libraries at some point or another.
Yeah, those damned templated libraries with their: performance, type safety, design patterns, generic programming principles. I can't imagine why Java wasn't happy with containers of Objects and added Generics. C# definitely shouldn't have followed suit. All you need is void*, size_t, and int (*)(void *, void *), right?
Compiler optimization uses static analysis to find program invariants which allow the compiler to remove run-time overhead, thereby achieving efficiency. To do this, the analysis must examine all possible control flow paths. Increasing the size of a program can only add more possible executions to examine so, almost by definition, making a program bigger can only hurt optimization. When a program is small enough, you can express practically any invariant in the world in predicate logic, use weakest preconditions to derive necessary conditions for these invariants to hold, and throw the resulting implication to an automatic theorem prover! But of course this method doesn't quite scale.
To see a classic example, look at automatic parallelization. They have had it solved for toy examples for years!
... your (possibly justified) criticism that extrapolation from those papers' findings is, at least logically, invalid.
If you have ever worked with static analysis, my criticism is vacuously true.
Those papers do not show, and their authors do not state, that such a qualification is justified...
It is the absence of the qualification that requires justification.
I am not trying to knock Lisp, just the extrapolation of overall performance from small examples. Your next three examples are delightful examples of Lisp's viability and its positive effects on programmer of efficiency but with excerpts in #3 like:
"We use Lisp for the high level structure, in conjunction with a variety of other languages such as C and Java throughout the application."
in a system where it is clearly preferable to use Lisp, I can only guess that in the parts that were written in C or Java, the performance penalty of Lisp must have been significant.
Yes, as the experiments clearly show: as long as you write tiny numerical computations and programs that require code-as-data anyway.
You know, with a little static analysis and trace-based loop unrolling, even JavaScript could beat C, for tiny programs.
I'm not saying LISP hasn't grown by leaps and bounds since when its reputation was forged (if for no other reason than improvements in GC technology), but toy examples aren't going to convince anyone.
On the bright side, you didn't say "I want to be a game designer." That always had a touch of arrogance to it coming from anyone but an existing game designer. But in general, if a job seems like a dream job for you and 100 million other people, and there are no large barriers to climb, it is going to be hard to be taken seriously on passion alone.
In a way, we programmers have it easy, since a few nice demos and good answers to hard questions are a quick way to get your foot in the door. So, even though I'm really speaking outside my experience here, my advice for an aspiring writer would be to find something that makes it immediately evident to your prospective employer that you have invested serious time and energy in something that wasn't all fun and bubbles. Case and point, I had a game interview where the interviewer was evidently delighted by the *lack* of 20 cute languages and web technologies on my resume.
So, perhaps find an open source or local student game project?
On the subject of open source math, Axiom is an interesting 30 years-and-running project started (I believe) at IBM research that recently became open source. A new branch of the project started recently: http://www.open-axiom.org/ and has several people actively working on it. It differs perhaps most significantly from Maple and Mathematica in its use of strong static type checking. This allows its library creation language to be compiled into C, which gets compiled and loaded back into the interactive top-level. Altogether, a very neat system and a gigantic resource.
Slashdot Mirror
I bet the thought of people saying just that is how he drifts off to sleep every night.
If that was the case, we wouldn't need Java and C#
Right, because Java and C# are new and improved systems programming languages. Don't say Singularity.
Down at the bottom, the fundamental problem with C and C++ is the "pointer=array" concept.
Of course, how stupid of them! All this work trying to support user-defined abstractions for systems programming and the problem was a tiny typing rule the whole time!!! Let me guess, the root of all Java's problems is the covariant array subtyping problem? The same with covariant argument subtyping in Eiffel too?
Perhaps you mean the ability to look at memory as a sequence of bytes... except that that's just a little bit fundamental to systems programming. So you think that the millions of lines of BIOSes, kernels, device drivers, and ROMs should be written in assembly? Trust me, although the specific memory models will change over time (certainly away from UMA), as long as there is systems programming, there will always be a high-level language (in the old meaning of the word) that takes you to the metal. Although clearly we shouldn't be using it to write e-Commerce apps, educational software, internal IT apps, and whatever you do.
You would be amazed at how many students I've tutored where the teacher is explaining virtual function pointers and still 90% of the class still doesn't know how to pass an integer to a function!
Wow, they must really be in a hurry, forcing them to combine functions pointers and virtual functions into a single concept!
I know it can still be used that way, but it seems to be more and more difficult to only code that way using C++, because you're going to have to use libraries at some point or another.
Yeah, those damned templated libraries with their: performance, type safety, design patterns, generic programming principles. I can't imagine why Java wasn't happy with containers of Objects and added Generics. C# definitely shouldn't have followed suit. All you need is void*, size_t, and int (*)(void *, void *), right?
Educational software switching from a language with a bias towards systems programming to a language for the average programmer: that's good data from which to extrapolate.
... your (possibly justified) criticism that extrapolation from those papers' findings is, at least logically, invalid.
If you have ever worked with static analysis, my criticism is vacuously true.
Those papers do not show, and their authors do not state, that such a qualification is justified...
It is the absence of the qualification that requires justification.
I am not trying to knock Lisp, just the extrapolation of overall performance from small examples. Your next three examples are delightful examples of Lisp's viability and its positive effects on programmer of efficiency but with excerpts in #3 like:
"We use Lisp for the high level structure, in conjunction with a variety of other languages such as C and Java throughout the application."
in a system where it is clearly preferable to use Lisp, I can only guess that in the parts that were written in C or Java, the performance penalty of Lisp must have been significant.
Yes, as the experiments clearly show: as long as you write tiny numerical computations and programs that require code-as-data anyway. You know, with a little static analysis and trace-based loop unrolling, even JavaScript could beat C, for tiny programs. I'm not saying LISP hasn't grown by leaps and bounds since when its reputation was forged (if for no other reason than improvements in GC technology), but toy examples aren't going to convince anyone.
On the bright side, you didn't say "I want to be a game designer." That always had a touch of arrogance to it coming from anyone but an existing game designer. But in general, if a job seems like a dream job for you and 100 million other people, and there are no large barriers to climb, it is going to be hard to be taken seriously on passion alone. In a way, we programmers have it easy, since a few nice demos and good answers to hard questions are a quick way to get your foot in the door. So, even though I'm really speaking outside my experience here, my advice for an aspiring writer would be to find something that makes it immediately evident to your prospective employer that you have invested serious time and energy in something that wasn't all fun and bubbles. Case and point, I had a game interview where the interviewer was evidently delighted by the *lack* of 20 cute languages and web technologies on my resume. So, perhaps find an open source or local student game project?
I wonder if the Azure site is hosted on Azure. If so, then the "internal server error" I just got is probably a sign of things to come...
On the subject of open source math, Axiom is an interesting 30 years-and-running project started (I believe) at IBM research that recently became open source. A new branch of the project started recently: http://www.open-axiom.org/ and has several people actively working on it. It differs perhaps most significantly from Maple and Mathematica in its use of strong static type checking. This allows its library creation language to be compiled into C, which gets compiled and loaded back into the interactive top-level. Altogether, a very neat system and a gigantic resource.