The D-BUS spec would be less than a page long if it were specified as an application of CORBA, would gain an emourmous amount of flexibility by deriving from CORBA, and would require little if any extra code to be written beyond what is already available in multiple open-source CORBA implementations. Just as a single example of flexibility: D-BUS is bound to a specific protocol and marshalling spec. CORBA would make the protocol and marshalling transparent and pluggable, enabling, for example, the ability to choose ultra-low-latency communication via shared memory with no extra coding needed.
And this idea that because something has a long spec it shouldbn't be used - I don't know where that comes from. The XML specs aren't exactly miniscule, and no one seems to be having trouble creating XML apps. Hell, RFC2616 by itself is no picnic, but there's no shortage of interoperable HTTP apps out there. The point of standards like CORBA is to abstract away complexity so that we can focus on the interesting problems. Projects like D-BUS merely create unecessary coupling between boring, alread-solved middleware issues and the actual domain problems being solved.
Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:
So I skimmed through the D-BUS spec and, as I expected, they are simply reinventing CORBA.
When will Open Source developers figure out that just because the OS community didn't come up with a technology, doesn't mean it has to be re-written with fewer features?
I gaurantee that whatever aspects of CORBA the D-BUS developers found unnacceptable - complexity, overhead - will be reintroduced into D-BUS by the time it reaches maturity. That's just how these things go - someone decides that Standard X is "cool, but too complicated", and then five years later they realize that their solution has become just as complicated as Standard X because, lo and behold, all that complexity was there for a reason. Real-world solutions never stay simple, because real-world problems aren't simple.
Having pointed out that Oram's economics are faulty, let me make a suggestion for fighting the REAL problem, which is not the loss of jobs, but the movement of jobs into new sectors.
If you want to help people cope with the fact that advances in technology have rendered them redundant, either supply or support education. If you have a valuable technical skill, look into opportunities for teaching it to others. If you're not the teacher type, find ways to support local technical education programs, especially those that target people who might not have the means to pay for a college education. The goal here is not to maintain the number jobs in any given field, but to make the transition from an old field to a new field as easy as possible.
The article's biggest strike against Qt is "Very business-oriented main Web site". What the hell is that about? "I'm shocked, shocked! to find marketing going on in this business!". Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web. That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow. If you object to their business model, just say so. But objecting to the fact that their corporate website is "very business oriented" is like objecting to the fact that Slashdot is "very geek oriented".
That's irrellevant. I can keep Gkrellm, gtop, a weather app, etc. running on a seperate desktop if I want to have a "system stats" desktop. There's no advantage to having them embedded in the root window.
I've never understood the popularity of "active desktop" style embedded desktop widgets. I for one see my computer desktop about as often as I see my physical desktop, which is maybe once a month when I get one of my rare cleaning urges or have to find some document I printed out awhile back. What the hell do these people do at work, that they actually spend a signifigant amount of time without their deskop completely obscured by other windows?
99% Of the times I've had to hard-reset a box, it's not because the OS itself crashed but because XFree86 decided to freeze and take the monitor, mouse and keyboard with it. I don't care how brilliant X's client/server design is; the dominant implementation is a bloated, obtuse, crash prone pile of decades-accumulated cruft.
Re:He is reimplementing the Remembrance Agent !
on
Nat Demos Dashboard
·
· Score: 3, Insightful
Not exactly. While RA is quite a nifty tool, all it does is index your home directory and run searches against what it finds their based on the current document in Emacs. RA doesn't have the ability to note that you're having an IM conversation with someone, and automatically show you: their email address and other FOAF contact information; their last few blog entries; when you last talked to them; their schedule; etc. That's the kind of thing Dashboard is intended to do. Dashboard integrates semantic information from many different applications, rather than just doing a smart grep against your home dir.
Apache, Quake, JDK aren't jargon, they are product names. Anyone curious about what they are can punch them into google and find their home pages. The Jargon file documents common to ultra-obscure terms that have become a part of the shared language of hackers. It isn't a comprehensive product listing, nor is it a comprehensive listing of technical terms. If you want technical terms defined, use FOLDOC.
Now, I think certain slang terms (such as "fragging") from the Quake community have become sufficiently common in the wider geek lexicon that they could legitimately be called "Jargon" at this point. And, lo and behold, there is in fact an entry for "frag", with a note to see also "gib". Looks like ESR is doing a fine job of keeping up with the times.
Let's be fair here, this is a case of the pot calling the kettle black. I used to read NTK until I got sick of the snotty political commentary they tended to work into many of of their (quite interesting and witty) reports. In particular, IIRC, they've always been fond of slinging mud at ESR, who's views happen to be about as far as you can get from the generally leftist slant of NTK. There's no question that ESR puts his own spin on just about everything he does, but NTK calling him on it is a bit like IndyMedia accusing CNN of being "controlled by the Man". I don't really expect neutral content from either source.
I'm not talking about overloading. I'm talking about polymorphism. If you take issue with polymorphism, fine, but that must mean you don't do any OO programming in Perl. If I have a class "Car" with a method "run()", and I also have a class "Truck" with a method "run()", that's polymorphism. If I have a class "Int" with a method "<=>", and I have a class "SensorReading" which also has a method "<=>", that's polymorphism.
Overloading isn't even available in Ruby.
"Overloading is good in places where you want to do the same thing with different types of data but not when they do different things, at least imo"
And how is that different from what I was describing? I'm not advocating defining the "<=>" method to actually do multiplication. I'm advocating letting the programmer define correct comparison semantics for the "<=>" method of any user-defined type. And having standard library functions which actually utilize those user-defined methods.
I find it interesting that a math double-major, who's considering becoming a math professor, uses C++ as his language of choice, with Java coming second. Not Lisp, not Scheme, not Haskell - C++.
I'm not sure what conclusion to draw from that fact, I just find it interesting.
Sounds like you've been coding to a very old pre-standard version of C++ for a long time. Don't complain that the standard keeps "refining" - what you are talking about are things that have been stable for years. Count yourself lucky that compilers actually let you get away with it all this time.
And I hope you aren't putting "using namespace std" in new code. Ugh.
Well the problem is that you can't make a smart function that knows what you want to do in perl or any other typeless language.
Yes, you can do it in some "typeless" languages other than perl. The need is not for a "smart function", but for polymorphic functions. The enabler is in whether the language treats all values uniformly as objects. If so, than any object can overload some kind of standard "compareTo" method with a sensible default (in Ruby that method happens to be spelled out "thing1 <=> thing2", but it's still a method like any other). The sort call then uses that standard comparison method as it's default.
And perl has a default like the others and you can specify a specific sort method.
The only default perl has is for lexical string sorting. Anything else you have to specify.
I do not see why mylist.sort! {...some comparison code... } is easier or better than sort {...some comparison code.. } @mylist
It's not. But in Perl that's my only option unless I happen to want to sort strings (or things that can be converted to strings) alphabetically. In Ruby all objects,system or user-defined, can have sensible defaults, so that 90% of the time all I have to do is mylist.sort!. So in the rare case Ruby is equally as verbose as Perl; and in the typical case Ruby is even more terse than Perl (without losing readability).
I was in the same place recently. I finally decided that come hell or high water, I was learning Haskell if it killed me, and dammit, I was gonna learn it via freely available resources.
Here's the method that worked for me:
1. Attempt to read the "Gentle" Introduction: http://www.haskell.org/tutorial/. Put it down hours later with a splitting headache and admit that for once a language tutorial is beyond me. 2. Allow concepts partially-comprehended from the Gentle Intro to slowly seep into my brain over a period of weeks. 3. With brain appropriately softened, read this rather more approachable intro: http://www.isi.edu/~hdaume/htut/tutorial.pdf. It's incomplete, but it's still quite good. 4. Read the Gentle Intro again. 5. Re-read the bits on I/O and Monads. 6. Re-read the bits on I/O and Monads. 7. Do a little experimental coding in the Emacs haskell mode. Find self instinctivley using Monads to chain together a series of operations that may or may not succeed. Experience "a-ha!" moment. 8. Re-read the bits on I/O and Monads. 9. Nod sagely at new enlightenment. 10. Realize that with all my newfound knowledge and perspective, I now comprehend how to write procedural code! Yea verily, canst even bring forth exceptions and other species of flow-control from the raw aether! 11. Realize that I just spent a whole weekend learning how to write simple procedural code, and yet somehow the forces of Computer Science have conspired to make me feel as if this is a momentous accomplishment. 12. Experience an epiphany about Computer Science departments the world over: if this stuff seemed easy, how would CS proffessors ever get tenure? 13. Find self unable to shake off desire to code more things in Haskell, despite having peeked at the man behind the curtain.
That's a tad circular. You're using Perl's lousy extension facilities as a reason why not to use Perl, and then saying that that it doesn't matter how easy Perl gets to extend, why would you want to write code in such a stupid language anyway?
That's a bit like saying "Python sucks because it's object model is a kludge. But even if they fixed the object model, I still wouldn't use it, because it sucks (as I pointed out above)".
A point to you, on the subject of continuations. I don't actually know Lisp very well - I know a lot about what Lisp and Scheme are capable of from all my reading, but I haven't used them much beyond Emacs Lisp hacking. Which doesn't count, I know. So I think there I was confusing Lisp with Scheme.
I don't think Larry Wall or Bjarne Stroustrup held Lisp in contempt; in fact, I'm sure I've seen them both speak highly of it in various writings. Both Larry and Bjarne were trying to do something very, very different than Lisp with Perl and C++, and I think they succeeded admirably in their goals. Larry wanted a glue language what would roll all of the power of the various UNIX command-line utillities into one, in a way that enabled powerful programs to be expressed very concisely, and which bore enough resemblance to it's forbears that it wouldn't have a steep learning curve. Bjarne wanted to see how many modern abstraction techniques he could add to the domininant systems programming language of the day, C, without sacrificing backward-compatibility or efficiency. Ultimately, both of them wanted a language they enjoyed coding in, at which by all reports they succeeded. This claim that they held Lisp in contempt is just absurd though; read their writings long enough and you come to see that not only were they aware of it, they understood it and had a good deal of respect for it. That they chose different solutions for a different problem space in their own work doesn't indicate any lack of understanding on their part.
As for your closing paragraph - I'm just going to assume you are joking. So: hah hah. Pity the poor fool who names his language "Queer".
1. Anything you can Python-ize using SWIG, you can do the same for Perl. 2. Have you ever used the Inline::C, Inline::Java, etc. modules from CPAN? I'm not a huge Perl fan, but those are the most incredible example of language interop I've ever seen. With them you can literally write C, C++, Java, and various other languages (possibly including Python) inline inside your Perl functions, referencing variables defined in the Perl code. The module writes, and if necessary compiles, all the necessary scaffolding necessary to wire the languages together in the background the first time it is run.
Put bluntly: the designers of those "reactionary" languages didn't understand or appreciate or learn from or react to Lisp, while the designers of Python did.
You've yet to point to any actual data which supports that claim. And the idea that the creators of C++, Java, and Perl didn't "understand or appreciate or learn from or react to Lisp" is pure bullshit. I've read their writings. All of them were quite aware of Lisp, and consciously took what they wanted from it. In the case of those languages, what they wanted from Lisp was "not a lot", at least not directly. But this notion that their decisions were not even informed by Lisp knowledge just shows an ignorance of history.
The fact that Python code is not literally structured data is alleviated by the fact that the parser and compiler are available as part of the Python runtime, and you can easily manipulate and evaluate strings in Python.
So, in other words, it's no more Lisp-like than, oh, Perl or TCL in that regard. Code-as-data is often referenced as Lisp's "Big Idea", the thing that makes Lisp Lisp.
I'm glad that lambdas have been fixed in Python since they had problems in the earlier days, but I don't know what you mean by "severly limited form".
That last I checked they are still limited to a single expression, which makes them less useful than the equivalent construct in Perl, Smalltalk, Lisp, Scheme, Ruby and Java. In fact, using the Lambda Library, I can probably do more in a C++ "lambda" then I can in a Python one.
Continuations are not as useful in every-day programming as most CS grad students with no experience in the real world would have you believe. Just what problem are you actually trying to solve, that you can't solve with threads, exceptions, generators, or better programming techniques?
I'll grant that continuations are rarely useful in a relatively featureful language. However, they are useful building blocks for adding any given control structure that your language happens to lack. Moreover, they are part of what makes Lisp and it's derivatives special. You made the claim that "Python is Lisp without macros"; the burden is on you to prove how continuations are not am important part of Lisp. I suspect a lot of Lispers would disagree with you.
As a matter of fact, the Python architecture was easily modified to support continuations (called "Stackless Python [stackless.com]")
And last I read, the changes are never going to be rolled back into the Python trunk, making it irrelevant. Apparently there was some unacceptable tradeoff involved. We're talking about Python here, not Stackless Python.
Also, Python now has "generators" (aka "weightless threads" or "coroutines"), which are quite useful for some of the other common uses to which people put continuations, but they are much easier to use and understand.
If you're talking about the feature I'm thinking of, it's the one that due to a flaw in Python's architecture can't be used alongside exceptions. Making it practically useless. Tell me, what about Python's lisp heritage makes it so difficult to merge in generators, continuations, and full-fledged lambdas without breaking something else?
CLOS is great, but I don't miss it most of the time, because I'm happy with the current object system in Python. Python's object system is quite simple, practical and flexible, and can be easily extended in its own way. ScriptX's object system was a lot like CLOS, as was Dylan's. But again, you usually don't need the enormously powerful generality of CLOS, and it comes at a cost in speed, space and complexity, that most people aren't willing to pay
Once again, "Python is like Lisp!...except in all those areas where it isn't".
Ok, so MORE shorthand syntax makes a language easier to read? Somehow I don't follow -- isn't that the whole reason why many find Perl the equivalent to line-noise?
By this logic, assembly language should be be the easiest language of all to read, since it's such a simple, regular syntax. Syntax is added to languages in order to make them more expressive and readable, not less. Sometimes this can be done wrong, like in Perl's case, where a very expressive array of syntax is hobbled by a commitment to maximum terseness. Removing syntax for "simplicity's" sake often has the opposite effect, though.
Examples of this in Java include:
The lack of enums, which leads to long, repetative lists of public static final ints which are maintenance nightmares because the entire list has to be updated if a new value is added in the middle, and which have none of the typesaftey of their C++ counterparts
The lack of default arguments to methods, which leads to long, repetative lists of constructors; another maintenance liability, and less readable than a single constructor with default arguments
The lack of switch statements, requiring the use of if/else instead. This makes the intent slightly less clear, and is yet another maintenance problem when the variable being switched on is changed
Operator overloading is important. While it can certainly abused, the fact that I can't define a new domain object and then compare it for a domain-specific definition of equality with thing1 == thing2 means that working with domain-level entities will never be either as concise or as intuitively readable as working with builtins.
The only thing that makes coding in Java productive at all is a really clever refactoring IDE which automates a lot of those chores, along with a really enourmous set of standard libraries. Nearly everything I can express in Java I can express more quickly in C++ without any loss in readability, and often with in a way that better expresses my intent to the reader.
It's really comparing apples and oranges though. In general, Java and C++ are applicable to two mostly orthoganal domains; but most of Java's domain is better served by less wordy dynamic languages like Smalltalk, Ruby, Python, or Scheme.
to sort in place. Same syntax for lists of strings, numbers, dates, you name it - the sort is based on the overloadable <=> operator. If you need to specify the sorting order manually, it's:
mylist.sort! {...some comparison code... }
C++ has the same kind of consistancy. The way to sort any kind of list of any kind of values is:
std::sort(mylist.begin(), mylist.end());...to use the default criterion, or:
Consistency is good, and sensible defaults are good. The sorting case is one of several cases where I think Perl falls short in it's stated goal of "making easy things easy".
Slashdot Mirror
The D-BUS spec would be less than a page long if it were specified as an application of CORBA, would gain an emourmous amount of flexibility by deriving from CORBA, and would require little if any extra code to be written beyond what is already available in multiple open-source CORBA implementations. Just as a single example of flexibility: D-BUS is bound to a specific protocol and marshalling spec. CORBA would make the protocol and marshalling transparent and pluggable, enabling, for example, the ability to choose ultra-low-latency communication via shared memory with no extra coding needed.
And this idea that because something has a long spec it shouldbn't be used - I don't know where that comes from. The XML specs aren't exactly miniscule, and no one seems to be having trouble creating XML apps. Hell, RFC2616 by itself is no picnic, but there's no shortage of interoperable HTTP apps out there. The point of standards like CORBA is to abstract away complexity so that we can focus on the interesting problems. Projects like D-BUS merely create unecessary coupling between boring, alread-solved middleware issues and the actual domain problems being solved.
What are the problems with a slightly souped-up syslog?
Nothing, I imagine. syslog-ng and metalog come to mind. However, they have nothing to do with what CORBA and D-BUS do.
Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:
Init Replacements: simpleinit, minit, jinit, runit, daemontools, serel. Progeny also has their own system based on Gooch's need/provide architecture.
D-BUS: CORBA
HAL: Discover
So I skimmed through the D-BUS spec and, as I expected, they are simply reinventing CORBA.
When will Open Source developers figure out that just because the OS community didn't come up with a technology, doesn't mean it has to be re-written with fewer features?
I gaurantee that whatever aspects of CORBA the D-BUS developers found unnacceptable - complexity, overhead - will be reintroduced into D-BUS by the time it reaches maturity. That's just how these things go - someone decides that Standard X is "cool, but too complicated", and then five years later they realize that their solution has become just as complicated as Standard X because, lo and behold, all that complexity was there for a reason. Real-world solutions never stay simple, because real-world problems aren't simple.
Having pointed out that Oram's economics are faulty, let me make a suggestion for fighting the REAL problem, which is not the loss of jobs, but the movement of jobs into new sectors.
If you want to help people cope with the fact that advances in technology have rendered them redundant, either supply or support education. If you have a valuable technical skill, look into opportunities for teaching it to others. If you're not the teacher type, find ways to support local technical education programs, especially those that target people who might not have the means to pay for a college education. The goal here is not to maintain the number jobs in any given field, but to make the transition from an old field to a new field as easy as possible.
Unfortunately the article is premised on a classic economic fallacy: that advances in technology and efficiency result in net job loss. For a good debunking, see Paul Krugman's review of William Greider's "One World, Ready or Not: The Manic Logic of Global Capitalism".
So we went from rationality into denial, eh? Sad, but not surprising.
The article's biggest strike against Qt is "Very business-oriented main Web site". What the hell is that about? "I'm shocked, shocked! to find marketing going on in this business!". Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web. That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow. If you object to their business model, just say so. But objecting to the fact that their corporate website is "very business oriented" is like objecting to the fact that Slashdot is "very geek oriented".
That's irrellevant. I can keep Gkrellm, gtop, a weather app, etc. running on a seperate desktop if I want to have a "system stats" desktop. There's no advantage to having them embedded in the root window.
I've never understood the popularity of "active desktop" style embedded desktop widgets. I for one see my computer desktop about as often as I see my physical desktop, which is maybe once a month when I get one of my rare cleaning urges or have to find some document I printed out awhile back. What the hell do these people do at work, that they actually spend a signifigant amount of time without their deskop completely obscured by other windows?
99% Of the times I've had to hard-reset a box, it's not because the OS itself crashed but because XFree86 decided to freeze and take the monitor, mouse and keyboard with it. I don't care how brilliant X's client/server design is; the dominant implementation is a bloated, obtuse, crash prone pile of decades-accumulated cruft.
Not exactly. While RA is quite a nifty tool, all it does is index your home directory and run searches against what it finds their based on the current document in Emacs. RA doesn't have the ability to note that you're having an IM conversation with someone, and automatically show you: their email address and other FOAF contact information; their last few blog entries; when you last talked to them; their schedule; etc. That's the kind of thing Dashboard is intended to do. Dashboard integrates semantic information from many different applications, rather than just doing a smart grep against your home dir.
Apache, Quake, JDK aren't jargon, they are product names. Anyone curious about what they are can punch them into google and find their home pages. The Jargon file documents common to ultra-obscure terms that have become a part of the shared language of hackers. It isn't a comprehensive product listing, nor is it a comprehensive listing of technical terms. If you want technical terms defined, use FOLDOC.
Now, I think certain slang terms (such as "fragging") from the Quake community have become sufficiently common in the wider geek lexicon that they could legitimately be called "Jargon" at this point. And, lo and behold, there is in fact an entry for "frag", with a note to see also "gib". Looks like ESR is doing a fine job of keeping up with the times.
Let's be fair here, this is a case of the pot calling the kettle black. I used to read NTK until I got sick of the snotty political commentary they tended to work into many of of their (quite interesting and witty) reports. In particular, IIRC, they've always been fond of slinging mud at ESR, who's views happen to be about as far as you can get from the generally leftist slant of NTK. There's no question that ESR puts his own spin on just about everything he does, but NTK calling him on it is a bit like IndyMedia accusing CNN of being "controlled by the Man". I don't really expect neutral content from either source.
I'm not talking about overloading. I'm talking about polymorphism. If you take issue with polymorphism, fine, but that must mean you don't do any OO programming in Perl. If I have a class "Car" with a method "run()", and I also have a class "Truck" with a method "run()", that's polymorphism. If I have a class "Int" with a method "<=>", and I have a class "SensorReading" which also has a method "<=>", that's polymorphism.
Overloading isn't even available in Ruby.
"Overloading is good in places where you want to do the same thing with different types of data but not when they do different things, at least imo"
And how is that different from what I was describing? I'm not advocating defining the "<=>" method to actually do multiplication. I'm advocating letting the programmer define correct comparison semantics for the "<=>" method of any user-defined type. And having standard library functions which actually utilize those user-defined methods.
I find it interesting that a math double-major, who's considering becoming a math professor, uses C++ as his language of choice, with Java coming second. Not Lisp, not Scheme, not Haskell - C++.
I'm not sure what conclusion to draw from that fact, I just find it interesting.
Sounds like you've been coding to a very old pre-standard version of C++ for a long time. Don't complain that the standard keeps "refining" - what you are talking about are things that have been stable for years. Count yourself lucky that compilers actually let you get away with it all this time.
And I hope you aren't putting "using namespace std" in new code. Ugh.
Well the problem is that you can't make a smart function that knows what you want to do in perl or any other typeless language.
...some comparison code... } is easier or better than sort { ...some comparison code.. } @mylist
Yes, you can do it in some "typeless" languages other than perl. The need is not for a "smart function", but for polymorphic functions. The enabler is in whether the language treats all values uniformly as objects. If so, than any object can overload some kind of standard "compareTo" method with a sensible default (in Ruby that method happens to be spelled out "thing1 <=> thing2", but it's still a method like any other). The sort call then uses that standard comparison method as it's default.
And perl has a default like the others and you can specify a specific sort method.
The only default perl has is for lexical string sorting. Anything else you have to specify.
I do not see why mylist.sort! {
It's not. But in Perl that's my only option unless I happen to want to sort strings (or things that can be converted to strings) alphabetically. In Ruby all objects,system or user-defined, can have sensible defaults, so that 90% of the time all I have to do is mylist.sort!. So in the rare case Ruby is equally as verbose as Perl; and in the typical case Ruby is even more terse than Perl (without losing readability).
I was in the same place recently. I finally decided that come hell or high water, I was learning Haskell if it killed me, and dammit, I was gonna learn it via freely available resources.
Here's the method that worked for me:
1. Attempt to read the "Gentle" Introduction: http://www.haskell.org/tutorial/. Put it down hours later with a splitting headache and admit that for once a language tutorial is beyond me.
2. Allow concepts partially-comprehended from the Gentle Intro to slowly seep into my brain over a period of weeks.
3. With brain appropriately softened, read this rather more approachable intro: http://www.isi.edu/~hdaume/htut/tutorial.pdf. It's incomplete, but it's still quite good.
4. Read the Gentle Intro again.
5. Re-read the bits on I/O and Monads.
6. Re-read the bits on I/O and Monads.
7. Do a little experimental coding in the Emacs haskell mode. Find self instinctivley using Monads to chain together a series of operations that may or may not succeed. Experience "a-ha!" moment.
8. Re-read the bits on I/O and Monads.
9. Nod sagely at new enlightenment.
10. Realize that with all my newfound knowledge and perspective, I now comprehend how to write procedural code! Yea verily, canst even bring forth exceptions and other species of flow-control from the raw aether!
11. Realize that I just spent a whole weekend learning how to write simple procedural code, and yet somehow the forces of Computer Science have conspired to make me feel as if this is a momentous accomplishment.
12. Experience an epiphany about Computer Science departments the world over: if this stuff seemed easy, how would CS proffessors ever get tenure?
13. Find self unable to shake off desire to code more things in Haskell, despite having peeked at the man behind the curtain.
That's a tad circular. You're using Perl's lousy extension facilities as a reason why not to use Perl, and then saying that that it doesn't matter how easy Perl gets to extend, why would you want to write code in such a stupid language anyway?
That's a bit like saying "Python sucks because it's object model is a kludge. But even if they fixed the object model, I still wouldn't use it, because it sucks (as I pointed out above)".
A point to you, on the subject of continuations. I don't actually know Lisp very well - I know a lot about what Lisp and Scheme are capable of from all my reading, but I haven't used them much beyond Emacs Lisp hacking. Which doesn't count, I know. So I think there I was confusing Lisp with Scheme.
I don't think Larry Wall or Bjarne Stroustrup held Lisp in contempt; in fact, I'm sure I've seen them both speak highly of it in various writings. Both Larry and Bjarne were trying to do something very, very different than Lisp with Perl and C++, and I think they succeeded admirably in their goals. Larry wanted a glue language what would roll all of the power of the various UNIX command-line utillities into one, in a way that enabled powerful programs to be expressed very concisely, and which bore enough resemblance to it's forbears that it wouldn't have a steep learning curve. Bjarne wanted to see how many modern abstraction techniques he could add to the domininant systems programming language of the day, C, without sacrificing backward-compatibility or efficiency. Ultimately, both of them wanted a language they enjoyed coding in, at which by all reports they succeeded. This claim that they held Lisp in contempt is just absurd though; read their writings long enough and you come to see that not only were they aware of it, they understood it and had a good deal of respect for it. That they chose different solutions for a different problem space in their own work doesn't indicate any lack of understanding on their part.
As for your closing paragraph - I'm just going to assume you are joking. So: hah hah. Pity the poor fool who names his language "Queer".
1. Anything you can Python-ize using SWIG, you can do the same for Perl.
2. Have you ever used the Inline::C, Inline::Java, etc. modules from CPAN? I'm not a huge Perl fan, but those are the most incredible example of language interop I've ever seen. With them you can literally write C, C++, Java, and various other languages (possibly including Python) inline inside your Perl functions, referencing variables defined in the Perl code. The module writes, and if necessary compiles, all the necessary scaffolding necessary to wire the languages together in the background the first time it is run.
You've yet to point to any actual data which supports that claim.
And the idea that the creators of C++, Java, and Perl didn't "understand or appreciate or learn from or react to Lisp" is pure bullshit. I've read their writings. All of them were quite aware of Lisp, and consciously took what they wanted from it. In the case of those languages, what they wanted from Lisp was "not a lot", at least not directly. But this notion that their decisions were not even informed by Lisp knowledge just shows an ignorance of history.
So, in other words, it's no more Lisp-like than, oh, Perl or TCL in that regard. Code-as-data is often referenced as Lisp's "Big Idea", the thing that makes Lisp Lisp.
That last I checked they are still limited to a single expression, which makes them less useful than the equivalent construct in Perl, Smalltalk, Lisp, Scheme, Ruby and Java. In fact, using the Lambda Library, I can probably do more in a C++ "lambda" then I can in a Python one.
I'll grant that continuations are rarely useful in a relatively featureful language. However, they are useful building blocks for adding any given control structure that your language happens to lack. Moreover, they are part of what makes Lisp and it's derivatives special. You made the claim that "Python is Lisp without macros"; the burden is on you to prove how continuations are not am important part of Lisp. I suspect a lot of Lispers would disagree with you.
And last I read, the changes are never going to be rolled back into the Python trunk, making it irrelevant. Apparently there was some unacceptable tradeoff involved. We're talking about Python here, not Stackless Python.
If you're talking about the feature I'm thinking of, it's the one that due to a flaw in Python's architecture can't be used alongside exceptions. Making it practically useless. Tell me, what about Python's lisp heritage makes it so difficult to merge in generators, continuations, and full-fledged lambdas without breaking something else?
Once again, "Python is like Lisp! ...except in all those areas where it isn't".
This is like me saying that imaginary lan
By this logic, assembly language should be be the easiest language of all to read, since it's such a simple, regular syntax. Syntax is added to languages in order to make them more expressive and readable, not less. Sometimes this can be done wrong, like in Perl's case, where a very expressive array of syntax is hobbled by a commitment to maximum terseness. Removing syntax for "simplicity's" sake often has the opposite effect, though.
Examples of this in Java include:
The only thing that makes coding in Java productive at all is a really clever refactoring IDE which automates a lot of those chores, along with a really enourmous set of standard libraries. Nearly everything I can express in Java I can express more quickly in C++ without any loss in readability, and often with in a way that better expresses my intent to the reader.
It's really comparing apples and oranges though. In general, Java and C++ are applicable to two mostly orthoganal domains; but most of Java's domain is better served by less wordy dynamic languages like Smalltalk, Ruby, Python, or Scheme.
The Ruby way:
...some comparison code... }
...to use the default criterion, or:
sorted = mylist.sort
or:
mylist.sort!
to sort in place. Same syntax for lists of strings, numbers, dates, you name it - the sort is based on the overloadable <=> operator. If you need to specify the sorting order manually, it's:
mylist.sort! {
C++ has the same kind of consistancy. The way to sort any kind of list of any kind of values is:
std::sort(mylist.begin(), mylist.end());
std::sort(mylist.begin(), mylist.end(), myComparison );
to manually specify the comparison method.
Consistency is good, and sensible defaults are good. The sorting case is one of several cases where I think Perl falls short in it's stated goal of "making easy things easy".