I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.
Yup. Common Lisp does all that plus everything you reference below... To keep this short(er), search slashdot for Kent Pitman and read his two-postings interview about Lisp. Go to www.paulgraham.com and download his free book On Lisp. Download GCL, CLISP, CMUCL, or Xanalys' or Franz's personal editions and work through every example in Paul's book, typing it in running it until you understand.
Common Lisp compiles to very fast code, Xanalys offers unlimited runtime distributions and, I've been told, very flexible support for what's included in the runtime.
On Lisp changed my programming worldview. I've been programming STL for years but now see large parts of it as an attempt to bring a small part of Lisp to C++. STL succeeds in that, and I do enjoy STL programming. However, why not just use Common Lisp which has all that and much, much more?
...templates can can be used to create programs that run at compile time to do some very clever optimizations
Lisp does that...
But the code to make this stuff happen is ATROCIOUS!
Not in Common Lisp, it's not. Define a macro instead of a function and selectively add backquotes and commas. Otherwise, it's plain old normal CL.
I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax....
Lisp does that.
...say something Lisp-like...
You mention Lisp but you don't mention that Lisp does everything you're asking for. Hope I'm not boring you, and there's probably someone else who didn't know Lisp does all this. In addition, I know that Xanalys in particular (as probably do all the others, with whom I have less direct experience) makes calling OS functions nearly trivial. I've not yet tried callback functions under Windows. Your mileage may vary. I am not associated with Xanalys although I did just buy their Lisp because of the unlimited runtime distribution. I learned Lisp using GCL under Linux. I am not a lawyer. I....
Sounds to me like it's time for some new language stud to come and save us.
Sound to me like it's time to pay attention to the old language studs. Seriously, with GPL implementation, commercial implementations with unlimited runtime distributions, etc., very fast compiled code.... it seems to me that unless you:
are doing real-time apps where garbage collection is unacceptable (and you're unable to write Lisp code that avoids the GC)
really need to pay attention to the final object code's size (critically need - as noted before, STL doesn't cause template bloat in non-debug compiles).
hmmmmm I'm running out of reasons here
Human factors - "nobody uses Lisp", "we'd never find programmers", "all those parenthesis"
Note: modern editors make the parenthesis comfortable. They are the key to making Lisp extensible because anything following an open parenthesis is a function to be called. Define a function, you just added new syntax to Lisp. You can redefine existing functions, including those in the base package such as addition:
(defun + (* a b))
and addition is broken everywhere. Lisp is a power tool and should be kept away from children. Use it if you really need to build something incredible.
What other reasons are there not to use Lisp? Lisp has had the features you named as important. Lisp has had them for years. And, speaking as one who has experience with STL, you simply don't need an STL in Lisp. Lisp is truly a giant STL. I don't have to define and name all the miscellaneous little structures I need, I just construct and use them on the fly. Not to mention closures, functions as first-class objects, lambda's (i.e. unnamed functions defined even in parameter lists), macros, run-time typing... the read-eval-print loop for debugging, the ability to replace a function in the middle of a running system with no giant compile/link... geeze Louise it's phenomenal. All those things combined seem to obviate the need for 98% of the things I use classes for in C++/STL. I'll know more after I build something really big in Lisp and have a lot of people using it. I'm working on that...
I enjoy C++ and STL a lot. I'm really looking forward to a lot more finger time with Common Lisp. Don't want to give either one up. But my sense at the moment is that Lisp is by far the more powerful environment. It certainly does everything you mention in your post.
Regarding STL debugging, you said:
If something's not compiling that you think should, you end up wading through the mile-long error messages.
With a little practice it's easy. Look at the beginning of the error message and maybe the end. Never the middle. 90% of the time it's invalid parameters (template type vs. parameter type). Perhaps you forgot to add std:: to less in
That one took about five minutes to find because the compile error showed up in something like xtree.cpp. It took a few minutes to discover that it was the map declaration causing the problem. Once you 'grok' the essence of STL philosophy, it's really not any harder than that. My most common runtime error is dtor'd objects in an STL container - so far always my own fault, not the library's.
If it does compile but doesn't work right, you're going to find yourself in the debugger trying to step through some of that crazy obscure STL C++ code
I say don't ever step through that stuff unless you're trying to learn how it works. Just look at the parameters to the calls and then look at the results. Lots of times I'll change e.g.
for(it=...blahblahblah { pair<int,std::string> p=*it;// I'd avoid the pair and go directly to the int and string int i=p.first; std::string s=p.second; ProcessMine(i,s); }
for the simple reason that I can set a breakpoint on the ProcessMine(...) call and see what the iterator is referencing. I put things back when I've fixed the bug. But I do not go mucking around in the STL code itself other than to learn more about how it works. The point is, it does work as long as it's called properly (except when it doesn't, which hasn't happend to me that I know of).
If his claim is that no behaviour is seen at the higher level which is not in principle explainable from what happens at the lower level... That's one of his claims. He says "All arrows point to quarks and leptons...". He specifically stated that today we cannot generate the higher principles from lower ones, i.e. the arrows go only one way. Lower principles can explain but not generate the higher ones. He continues: "Unfortunately we can't go the other way." (from quarks and leptons to diamonds - his example - or to Jet Stream waves - your example.
If his claim is that no behaviour is seen at the higher level whose explanations involve principles specific to the higher level... That is not his claim. His claim is the opposite.
He says: "We have no clue now as to how to explain a virus starting with quarks and leptons, in fact we can't even explain the curious properties of the carbon atom. Bucky Balls or a girl's best friend. We couldn't have predicted a diamond from knowing everything that we know about carbon. On the other hand once you have a diamond you can reduce that to the proper behavior of quarks and leptons." He is clearly stating that, as you say, we "won't have a clue unless (we) step back from the problem (diamonds, the Jet Stream) and apply higher level principles."
When he said "That would be a first time in science that a theory can't be reduced.", he first said "Some complexity experts believe that out of complexity will emerge new laws of physics that can't be reduced to quarks and leptons. We treat that with a great deal of skepticism. We don't know though, and that would be an interesting thing to see. That would be a first time in science that a theory can't be reduced."
He is saying that a) he is skeptical that complexity will produce laws that cannot be reduced and b) if such were discovered it would be the first time.
Therefore I disagree with your statement that "Depending what you mean, this is either a trivial claim that is utterly meaningless, or else it is a strong claim which is complete BS."
In fact, he believes that a) the emergent principles are required (today) for understanding the higher-level phenomena (i.e. we must be presented with the diamond; we cannot first concieve it) and b) once the emergent behavior is exhibited it is consistent with the lower-level principles. In fact, he said exactly the same thing you said.
And the "test" is if, among other things, the employee is engaged in work that is primarily intellectual, managerial, or creative, and which requires exercise of discretion and independent judgment and the employee receives compensation of not less than a specified amount per month.
Hmm let's see. Is software development intellectual and creative? Is discretion required? Independent judgment? Do the vast majority of us make more than 2 time the state minimum?
Slashdot Mirror
I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.
Yup. Common Lisp does all that plus everything you reference below... To keep this short(er), search slashdot for Kent Pitman and read his two-postings interview about Lisp. Go to www.paulgraham.com and download his free book On Lisp. Download GCL, CLISP, CMUCL, or Xanalys' or Franz's personal editions and work through every example in Paul's book, typing it in running it until you understand.
Common Lisp compiles to very fast code, Xanalys offers unlimited runtime distributions and, I've been told, very flexible support for what's included in the runtime.
On Lisp changed my programming worldview. I've been programming STL for years but now see large parts of it as an attempt to bring a small part of Lisp to C++. STL succeeds in that, and I do enjoy STL programming. However, why not just use Common Lisp which has all that and much, much more?
Lisp does that...
But the code to make this stuff happen is ATROCIOUS!
Not in Common Lisp, it's not. Define a macro instead of a function and selectively add backquotes and commas. Otherwise, it's plain old normal CL.
I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax. ...
Lisp does that.
You mention Lisp but you don't mention that Lisp does everything you're asking for. Hope I'm not boring you, and there's probably someone else who didn't know Lisp does all this. In addition, I know that Xanalys in particular (as probably do all the others, with whom I have less direct experience) makes calling OS functions nearly trivial. I've not yet tried callback functions under Windows. Your mileage may vary. I am not associated with Xanalys although I did just buy their Lisp because of the unlimited runtime distribution. I learned Lisp using GCL under Linux. I am not a lawyer. I ....
Sounds to me like it's time for some new language stud to come and save us.
Sound to me like it's time to pay attention to the old language studs. Seriously, with GPL implementation, commercial implementations with unlimited runtime distributions, etc., very fast compiled code.... it seems to me that unless you:
Note: modern editors make the parenthesis comfortable. They are the key to making Lisp extensible because anything following an open parenthesis is a function to be called. Define a function, you just added new syntax to Lisp. You can redefine existing functions, including those in the base package such as addition:and addition is broken everywhere. Lisp is a power tool and should be kept away from children. Use it if you really need to build something incredible.
What other reasons are there not to use Lisp? Lisp has had the features you named as important. Lisp has had them for years. And, speaking as one who has experience with STL, you simply don't need an STL in Lisp. Lisp is truly a giant STL. I don't have to define and name all the miscellaneous little structures I need, I just construct and use them on the fly. Not to mention closures, functions as first-class objects, lambda's (i.e. unnamed functions defined even in parameter lists), macros, run-time typing... the read-eval-print loop for debugging, the ability to replace a function in the middle of a running system with no giant compile/link... geeze Louise it's phenomenal. All those things combined seem to obviate the need for 98% of the things I use classes for in C++/STL. I'll know more after I build something really big in Lisp and have a lot of people using it. I'm working on that...
I enjoy C++ and STL a lot. I'm really looking forward to a lot more finger time with Common Lisp. Don't want to give either one up. But my sense at the moment is that Lisp is by far the more powerful environment. It certainly does everything you mention in your post.
With a little practice it's easy. Look at the beginning of the error message and maybe the end. Never the middle. 90% of the time it's invalid parameters (template type vs. parameter type). Perhaps you forgot to add std:: to less in
That one took about five minutes to find because the compile error showed up in something like xtree.cpp. It took a few minutes to discover that it was the map declaration causing the problem. Once you 'grok' the essence of STL philosophy, it's really not any harder than that. My most common runtime error is dtor'd objects in an STL container - so far always my own fault, not the library's.If it does compile but doesn't work right, you're going to find yourself in the debugger trying to step through some of that crazy obscure STL C++ code
I say don't ever step through that stuff unless you're trying to learn how it works. Just look at the parameters to the calls and then look at the results. Lots of times I'll change e.g.
to something like this:
for the simple reason that I can set a breakpoint on the ProcessMine(...) call and see what the iterator is referencing. I put things back when I've fixed the bug. But I do not go mucking around in the STL code itself other than to learn more about how it works. The point is, it does work as long as it's called properly (except when it doesn't, which hasn't happend to me that I know of).
If his claim is that no behaviour is seen at the higher level whose explanations involve principles specific to the higher level... That is not his claim. His claim is the opposite.
He says: "We have no clue now as to how to explain a virus starting with quarks and leptons, in fact we can't even explain the curious properties of the carbon atom. Bucky Balls or a girl's best friend. We couldn't have predicted a diamond from knowing everything that we know about carbon. On the other hand once you have a diamond you can reduce that to the proper behavior of quarks and leptons." He is clearly stating that, as you say, we "won't have a clue unless (we) step back from the problem (diamonds, the Jet Stream) and apply higher level principles."
When he said "That would be a first time in science that a theory can't be reduced.", he first said "Some complexity experts believe that out of complexity will emerge new laws of physics that can't be reduced to quarks and leptons. We treat that with a great deal of skepticism. We don't know though, and that would be an interesting thing to see. That would be a first time in science that a theory can't be reduced."
He is saying that a) he is skeptical that complexity will produce laws that cannot be reduced and b) if such were discovered it would be the first time.
Therefore I disagree with your statement that "Depending what you mean, this is either a trivial claim that is utterly meaningless, or else it is a strong claim which is complete BS."
In fact, he believes that a) the emergent principles are required (today) for understanding the higher-level phenomena (i.e. we must be presented with the diamond; we cannot first concieve it) and b) once the emergent behavior is exhibited it is consistent with the lower-level principles. In fact, he said exactly the same thing you said.
Jeff
The HP J1439A 4 port monitor switch works extremely well. You hit print screen to get a menu, then 1-4 to choose the machine.
intellectual, managerial, or creative, and which requires exercise of
discretion and independent judgment and the employee receives
compensation of not less than a specified amount per month.
Hmm let's see. Is software development intellectual and creative? Is discretion required? Independent judgment? Do the vast majority of us make more than 2 time the state minimum?
Nahhh. We're covered, I'm sure.