Erik Naggum <e...@naggum.net> writes: > You know, I see no principal difference between what the GNU GPL is > trying to enforce and what the entertainment industry and Microsoft are > trying to enforce.
True. It should be noted, however, that the folks at the FSF are fully cognizant of this fact, and regret having to use "evil means" (licenses, copy{right,left}, etc) in order to pursue what they regard as a "noble goal" (i.e. the right to share).
Whether the ends justifies the means is a question dealt with in fairy tales and history books.
--ap -- It would be difficult to construe Larry Wall, in article this as a feature. <1995May29.062427.3...@netlabs.com>
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes: > t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > I don't understand this. Are you saying C++ isn't powerful;
> I doubt both its power and its expressiveness.
Got it, so you're saying you're ignorant of a language which is very difficult to fully understand, and you're taking other people's word on it that it's not that powerful or expressive. Since you seem to be in the business of taking people on their word, maybe you should take me on mine and doubt the ability of the doubters to fully use C++. Think of all the worst examples of someone who "knows what they're doing" in Lisp, and to whom the language seems stiff and powerless (like maybe they tried to do MD5 using a character stream). Now imagine if CL were really difficult to fully understand, rather than being amazingly easy and orthogonal. That's the situation with C++.
Many perported "experts" in the language don't really know what they're doing, both the ones who praise it, and the ones who detract from it. Some of these "highly skilled" C++ people *would* fully understand CL if they put the same amount of effort into it, but C++ takes a lot more.
I've seen people who are very comfortable with the entirety of the C++ language, and it's really quite amazing. It's a powerful, expressive language. Of course, it's absurdly difficult, and has weird, obscure syntax, and these are definite problems with the language (and reasons why I'll never be one of those people who's very comfortable with it), but I think a lot of misconceptions about C++ are because people haven't put in the absurd effort it takes to learn the language fully.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
* Thomas F. Burdick -> Espen Vestre | Got it, so you're saying you're ignorant of a language which is very | difficult to fully understand, and you're taking other people's word | on it that it's not that powerful or expressive.
What he actually _said_ was that he took the pattern literature as evidence of its lack of strength and expressiveness. I happen to agree that the need for patterns shows a significant weakness in C++.
| Since you seem to be in the business of taking people on their word, | maybe you should take me on mine and doubt the ability of the doubters | to fully use C++.
I tend to believe that the patterns people he actually referred to are not doubters, but people who try to make using C++ easier for people.
| Some of these "highly skilled" C++ people *would* fully understand CL if | they put the same amount of effort into it, but C++ takes a lot more.
Hence my saying: Life is too long to be good at C++. But is a language really expressive if it takes a lifetime to become fluent in it? Is not "expressiveness" a function of the invested effort required to achieve something?
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
> You know, I see no principal difference between what the GNU GPL is > trying to enforce and what the entertainment industry and Microsoft are > trying to enforce.
That's easy to see by asking what would happen if each side was carried to its logical conclusion, so that *all* software was released with either Microsoft-type licenses or with GNU GPL licenses.
The MegaBucks way: users only have the right to use, not to study, modify, redistribute, etc., locking them into the role of passive consumers.
The Stallman agenda: users everywhere have the right to use, modify, study, redistribute, etc., all code in all software everywhere.
It's a pretty big difference.
...
> It is legally uncertain whether you can require people to give you their > work for free.
If a programmer X works his ass off on a project and then thinks to himself, "I worked my ass off on that. I want to make my work available for everyone to see so that poor people and college students can learn from it and use it." (Sneer if you must, but there are people without money trying to learn programming.)
X didn't have to do the work, but he did. He didn't have to release the work but he does. He uses the GNU GPL specifically because his personal aim is for the fruit of his *own* work to be available to everyone. He could care less about stuff that MegaBucks adds to his code -- his aim is to make his own work be a resource to others.
Of course, the benefit derived from the work X has done is not limited to a file or distribution. Wherever the results of his work shows up, that's *his work*. X wants those results to be available forever to everyone.
...
> | You mean the original release of the code remains in the public domain. > | The part you're not attending to, though, is that public domain code can > | be modified and redistributed in products that have quite restrictive > | licenses.
> This does not _need_ attending to, because public domain is explicitly > unconcerned with what happens to that which is in the public domain. > That is sort of the whole _point_.
It is exactly the whole point. Look at the original aim of the programmer in the example above. He wanted to make sure that the fruit of his work would be available for everyone, no matter what form it takes or where it shows up. He is not unconcerned.
If there is one public domain distribution with 1000 users, then there are zero users denied the rights that programmer X intended.
If there is one public domain distribution with 2000 users and one MegaBucks product that relies on programmer X's work and has 400000 users, then 400000 users are denied the rights that programmer X intended. Those users may or may not know about X's public domain release. They probably won't know, in fact.
The only real reason to use the GNU GPL is if you feel that those 400000 users are worse off than if they had the right to modify, study, redistribute the code. That's the kicker.
[Ed writes about public domain software that's released in products with restrictive licenses:]
> | If the author of the original code is OK with that, so be it -- I'm not > | saying it's wrong at all. But it is important to acknowledge that when > | that happens, the same code is making a new appearance in the world as > | restricted software.
> How does this differ from two different licenes for the same software so > people _can_ make money with software that is encumbered with the GNU GPL?
I don't know. It doesn't appear to me to differ at all.
> | It's true that the public domain version may (or may not) still be > | available, but it is easy to see that the rights of the users of the > | version with the restrictive license have less freedom.
> This does not quite parse, but I assume you mean the users have less > freedom. What _are_ those "rights of the users", anyway?
to run the program, study it and adapt it, redistribute it, improve it
> What kinds of > legal bases do they actually have? But how can you get _less_ freedom if > you (1) have access to the public domain source code _and_ (2) a better > version of same?
You have less freedom specifically with regard to the product with the restrictive license. If you are fortunate enough to know that there's a public domain product that has the same code that's used in the restricted product, then you can enjoy all the freedoms with regard to that specific release.
> (1) should cause you to have exactly as much freedom as > you had without (2). For this to produce less freedom, you would have to > consider (2) to have taken something away from you, probably in exchange > for some real money. In other words, you were an idiot for choosing (2).
Hmm.
> Now, we do not restrict anyone's "right" to be an idiot, but it is pretty > damn stupid to argue that losing your freedom because of it is anybody > else's fault.
Hmm. That's a pretty interesting take on it. I'll have to consider that. Some people would never want to look at the source code. They *want* to be locked into the role of passive consumer.
Russell Senior <seni...@aracnet.com> writes: > >>>>> "Erik" == Erik Naggum <e...@naggum.net> writes:
> Erik> I believe the purpose of the GNU GPL and "Free Software" is to > Erik> ensure the consumers, not the creators, are free to use the code > Erik> any way they want. This works just fine if you do not consider > Erik> the rights of any creators, [...]
> Creators have every right *not* to use "Free Software", so the GNU GPL > does not infringe anyones rights.
t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> [C++ is] a powerful, expressive language. > I think a lot of misconceptions about C++ are because people haven't > put in the absurd effort it takes to learn the language fully.
It can't be `expressive' if it takes an `absurd effort' to express things in it.
> Then so was Maclisp on the PDP10. It had a 256K address space. And, come > to think of it, all of my computer systems are finite in size. Does > pretending that finite size is smaller and providing an operator that > grows things with your eyes closed, not seeing the upper bound make the > basis for Turing equivalence? I think not.
I think this is a difference between implementation and specification: did the maclisp *spec* say that there could only be 256kwords of space, or that it was some build-time constant? FORTRAN says basically this.
And of course you can escape with I/O, practically anything can, which is why I excluded it (see below).
However I think you've missed my points. There are basically three:
1. Using the term `power' for an informal description of a programming language is kind of dangerous since it is so close to a formal term.
2. Power in the formal sense turns out not to be as interesting as it is made out to be in CS / AI courses, because non-TE languages (in particular the subset of fortran which does no I/O) can do good simulations of interesting things because of some convenient features of physics like continuity.
3. *However* it turns out that, actually, non-TE languages or languages with significant non-TE subsets turn out to be a significant pain to use. Although I actually quite like FORTRAN, I have found the lack of recursion, and even more so the inability to dyamically-allocate arrays to fit the problem to be significantly painful. (OK, you can do this on almost all systems in practice, but it's a significant pain if your code needs to run on n varying machines and you're not smart enough to find out if anyone has written the portability layer you need.) Even more so is the trick of using I/O to simulate memory: sure you can do it, but it's *really* a pain - like overlays are a really a pain.
I just thought it was interesting that these unpleasant aspects of the language do correlate with the fact that subsets of it are non-TE (I'm avoiding defining subset here because I can see I'll just get bogged down, forgive me). Is be like Lisp without CONS & recursion (and without any other compound data types) and where MAKE-LIST only takes literal numbers as arguments. Sure you can use it, but it's just not fun.
That's all I was trying to say.
--tim
(This is the first article I've posted through google, since the ssh connection to my proper machine seems to have been permanently firewalled off (I need a better job...). I hope it doesn't have horrid long lines &c.)
> > t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > > [C++ is] a powerful, expressive language.
> > > I think a lot of misconceptions about C++ are because people haven't > > > put in the absurd effort it takes to learn the language fully.
> > It can't be `expressive' if it takes an `absurd effort' to express > > things in it.
> Nonsense.
> I.e., "thanks for your absurd yet expressive effort to debunk this."
> ;-)
I would have said `absurd *amount* of effort', but that would have been misquoting. And sure, one could always *invest* an absurd amount of effort being expressive, but the issue is that C++ *requires* one to.
The amount of effort it is taking to express this is absurd.
* Erik Naggum | You know, I see no principal difference between what the GNU GPL is | trying to enforce and what the entertainment industry and Microsoft are | trying to enforce.
* Ed L Cashin <ecas...@terry.uga.edu> | That's easy to see by asking what would happen if each side was | carried to its logical conclusion, so that *all* software was released | with either Microsoft-type licenses or with GNU GPL licenses.
The same kind of argument is used when some people kill people in the name of some religion, and some other people kill people in the name of some other religion. They both kill people. Some think that is bad completely regardless of whatever mumbo-jumbo they sputter in order to defend killing people.
| > It is legally uncertain whether you can require people to give you | > their work for free. | | If a programmer X works his ass off on a project and then thinks to | himself, "I worked my ass off on that. I want to make my work | available for everyone to see so that poor people and college students | can learn from it and use it." (Sneer if you must, but there are | people without money trying to learn programming.)
I am not sure how this relates to my objection. The original author has obviously decided to do whatever he did of his own will and desire, but the question is: Does he have the legal right to require that those who want to use his work be required to give away _their_ work for free?
| Some people would never want to look at the source code. They *want* to | be locked into the role of passive consumer.
Yes, and with good reason. They know that they are not competent to accept a modified version of the software they want to use from anyone but a vendor they trust (or could sue (possibly collectively) if things failed). Trust really is a big issue in our industry, since there are so few objective measure of quality and so many vendors who explicitly avoid accepting responsibility for their products.
To make one thing very clear: I am strongly in favor of having access to the source code of certain products. I think it should be a requirement of vendors of compilers and operating systems to make them available, but _not_ just to any random comer and _not_ for free. Considering the sheer number of incompetent programmers out there who would do serious harm to themselves and others if they had access to the source code and modified it badly, and who blame their tools and just about anybody but themselves for the negative consequences of their incompetence. I also believe in distributed development and all that, but I do not trust people to write good code unless they are under guidance from more experienced designers and programmers. It is fairly obvious that people are willing to write code and give it away, but it is getting increasingly obvious that all the boring work of meticulous quality control and good documentation is much less rewarding. It is for that reason that I want a responsible vendor to be able to take the source code and do all the boring work in exchange for real money and the same guarantees that they will not only recover their costs but be sufficiently profitable to attact investors and be able to invest in other endeavors. I think the Open Source and so-called Free Software movement is a financial failure because it does not allow, or actively discourages, "release quality products" that could help them get rich by selling products to those "passive consumers".
Incidentally, it is sometimes _great_ to be a passive consumer. Having things just _work_ is sometimes a serious relief from all the stuff that _almost_ works.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <86pu72eu7c....@gondolin.local.net>, Alain Picard wrote: > Erik Naggum <e...@naggum.net> writes:
>> You know, I see no principal difference between what the GNU GPL is >> trying to enforce and what the entertainment industry and Microsoft are >> trying to enforce.
> True. It should be noted, however, that the folks at the FSF are > fully cognizant of this fact, and regret having to use "evil means" > (licenses, copy{right,left}, etc) in order to pursue what they > regard as a "noble goal" (i.e. the right to share).
I do no think that the gpl is built around rights. I think it is built around imposing oblagations on others. If you use 1 gpled file in your applacation by mistake and distribute it FSF claims that the app is now gpl and the people who used my app now have the right to all of my work for free and I have no right to compensation for the extra value provided by the source. I think for most end users source has no real value most of the time, they just want it to work. This would apply even if you removed the file and redistributed your app.
> Whether the ends justifies the means is a question dealt with > in fairy tales and history books.
That attitude is realy well and truly fucked up. You do not care about the fabric of the society you live in. This one or any other.
>>>t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>>>[C++ is] a powerful, expressive language.
>>>>I think a lot of misconceptions about C++ are because people haven't >>>>put in the absurd effort it takes to learn the language fully.
>>>It can't be `expressive' if it takes an `absurd effort' to express >>>things in it.
>>Nonsense.
>>I.e., "thanks for your absurd yet expressive effort to debunk this."
>>;-)
> I would have said `absurd *amount* of effort', but that would have > been misquoting.
<heh-heh> I thnk you /did/ misquote! Didn't he say the absurd effort was in /learning/ C++ fully? I thought Burdick was saying that once once had with great effort mastered C++ it was indeed easy to work with it.
Now for my money I never want to sit thru a link again, nor do I want to work with a language that cannot do the equivalent of (list 1 :two "three), nor could I live without lisp macros, and no matter how much C++ I learn I still won't be able to do those things. But getting back to your original remark, I was thinking more along these lines, something even stronger:
"The Tao says no language that is hard to learn can be easy to work with, no matter how well you learn it."
In other words, the fundamental misconceptualization which must underly a hard-to-learn language will also be manifested in one's ability to live with it even if mastered.
Erik Naggum <e...@naggum.net> writes: > Incidentally, it is sometimes _great_ to be a passive consumer. > Having things just _work_ is sometimes a serious relief from all the > stuff that _almost_ works.
The notion of having a "distribution" for operating systems like Linux, FreeBSD, and such demonstrates this very thing.
One of the major merits of using the Debian Linux distribution is that it allows the user to be a "passive consumer" of those components about which (s)he wishes to be passive, and to be "activist" about other components. Personally, I don't care to worry about maintaining [say] the Apache web server, but like having a working copy around to use. If I cared to be an "activist," I could submit enhancements and/or fixes, but it so happens that I don't.
There's a pretty big argument hole in the GPL argument about "ability to modify;" there aren't that many people generally interested in actually modifying the software.
That's not to say that there's not merit to the capability; it's kind of nice that the software is available with permission to modify, on the off-chance that whomever first developed it loses interest in continued maintenance. I've seen people burned by the problem that the software that their operations depend on are no longer maintainable; licenses like the GPL provide the merit that you can't be so painfully burned by someone else's corporate reorganization.
But the notion that everybody's planning to hack on _all_ this stuff is just nonsense. We're all passive about _some_ things, unless the goal is to build a minscule embedded system from scratch, and keep refining that... -- (reverse (concatenate 'string "gro.mca@" "enworbbc")) http://www.cbbrowne.com/info/languages.html Hard work pays off in the long run. Laziness pays off now.
* Kenny Tilton <ktil...@nyc.rr.com> | In other words, the fundamental misconceptualization which must underly a | hard-to-learn language will also be manifested in one's ability to live | with it even if mastered.
Hm. Can the ideas behind C++ be re-expressed sanely? There should be a lot of really good ideas and good material in that language, but I tend to believe that the sheer pain of expressing oneself in it creates a "creative climate" that produces really weird results. It is very much like the SGML/XML crowd, who also do amazingly stupid things because of the sheer painfulness of working with their misconceptualization of their core problems and solutions.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
* cbbro...@acm.org | One of the major merits of using the Debian Linux distribution is that | it allows the user to be a "passive consumer" of those components about | which (s)he wishes to be passive, and to be "activist" about other | components.
Good point.
| There's a pretty big argument hole in the GPL argument about "ability to | modify;" there aren't that many people generally interested in actually | modifying the software.
The threshold to actually modify is also high. Since the program has to be recompiled, the whole compilation environment has to be dragged in, and this is sometimes no small feat. If modifications have been made to other parts of the environment, the probability that one cannot rebuild something from scratch becomes non-zero. E.g., I remember when I made a number of changes to Emacs. Patching every new version and making sure that things worked right was getting to be a major pain. Those changes that did not get accepted by the maintainers were simply too hard to keep in my version. I still build my own Linux kernels because of a few bugs that the maintainers do not to consider bugs, but got _seriously_ burned when building with gcc-3.0. The dependency chain for building something from scratch is often so subtle that it is difficult to specify fully.
| But the notion that everybody's planning to hack on _all_ this stuff is | just nonsense. We're all passive about _some_ things, unless the goal is | to build a minscule embedded system from scratch, and keep refining | that...
Imagine how different this would be if users did not have to recompile the whole system, if the system had a compiler that could compile patches that could be loaded into a system without rebuilding all of it, etc... This is a much easier way to obtain the goal of user modifiability than requiring people to have all the source and to recompile from scratch.
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Erik Naggum <e...@naggum.net> writes: > * cbbro...@acm.org > | One of the major merits of using the Debian Linux distribution is that > | it allows the user to be a "passive consumer" of those components about > | which (s)he wishes to be passive, and to be "activist" about other > | components. > Good point. > | There's a pretty big argument hole in the GPL argument about > | "ability to modify;" there aren't that many people generally > | interested in actually modifying the software. > The threshold to actually modify is also high. Since the program > has to be recompiled, the whole compilation environment has to be > dragged in, and this is sometimes no small feat. If modifications > have been made to other parts of the environment, the probability > that one cannot rebuild something from scratch becomes non-zero. > E.g., I remember when I made a number of changes to Emacs. Patching > every new version and making sure that things worked right was > getting to be a major pain. Those changes that did not get accepted > by the maintainers were simply too hard to keep in my version. I > still build my own Linux kernels because of a few bugs that the > maintainers do not to consider bugs, but got _seriously_ burned when > building with gcc-3.0. The dependency chain for building something > from scratch is often so subtle that it is difficult to specify > fully.
GCC 3.0 definitely sits in the "subtlety chain" position; it appears that there are some places where Linux ("the kernel") has dependencies on the way GCC works, so that if and when the developers change anything, there is significant risk of breakage of code.
It's a pretty big problem, parallelling some of the discussions of what to do about tail calls. (In both cases it may have something to do with tail calls :-).)
> | But the notion that everybody's planning to hack on _all_ this > | stuff is just nonsense. We're all passive about _some_ things, > | unless the goal is to build a minscule embedded system from > | scratch, and keep refining that... > Imagine how different this would be if users did not have to > recompile the whole system, if the system had a compiler that could > compile patches that could be loaded into a system without > rebuilding all of it, etc... This is a much easier way to obtain > the goal of user modifiability than requiring people to have all the > source and to recompile from scratch.
.. Then there's the BSD model where the system is specifically designed to support all the dependancies required to recompile the whole system, including allowing local patches.
Take it to that extreme, where they _have_ to make it _downright easy_ to recompile the whole thing, and you get some similar properties. -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www.cbbrowne.com/info/unix.html This login session: only $23.95!
Erik Naggum <e...@naggum.net> writes: > * Kenny Tilton <ktil...@nyc.rr.com> > | In other words, the fundamental misconceptualization which must underly a > | hard-to-learn language will also be manifested in one's ability to live > | with it even if mastered.
> Hm. Can the ideas behind C++ be re-expressed sanely?
If there are sane object-oriented ideas that C++ claims to follow, it does such a poor job of doing so that the claim itself is insane.
Kenny Tilton <ktil...@nyc.rr.com> writes: > Now for my money I never want to sit thru a link again, nor do I want > to work with a language that cannot do the equivalent of (list 1 :two > "three), nor could I live without lisp macros, and no matter how much > C++ I learn I still won't be able to do those things.
You can't even write a working version of EQ in the language!
> | In other words, the fundamental misconceptualization which must underly a > | hard-to-learn language will also be manifested in one's ability to live > | with it even if mastered.
> Hm. Can the ideas behind C++ be re-expressed sanely? There should be a > lot of really good ideas and good material in that language, but I tend > to believe that the sheer pain of expressing oneself in it creates a > "creative climate" that produces really weird results. It is very much > like the SGML/XML crowd, who also do amazingly stupid things because of > the sheer painfulness of working with their misconceptualization of their > core problems and solutions.
For me the largest impediment to writing a computer program is that when you start you do not know what you are doing. Ironically when you are done writing the program then (hopefully) you now know what you are doing. With languages like C++ you have to begin worrying right away about data types, since you cannot do any programming without specifying the interface. C++ created hurdes to develop programs since it added classes to C. Now people have to think that everything that they now do has to be written as a class. On top of that there is inheritence, and now (some) programmers believe to write a good C++ program you _have_ to use inheritence (no matter how contrived it is). The effect of this is to immediately get bogged down with the concern that to use a language with object oriented techniques is that you have to use them all.
With this mentality that everything is a class, that everything can be conceptualized as a hieracrchy of objects, there is an illusion that things which are similar are close enough to be _coded_ as subclasses of some higher concept. This leads some programmers to chase the golden goose.
Even using Common Lisp I find that it takes me longer (at least for smaller problems) to use CLOS instead of just whipping up structure and not letting the idea of inheritence/classes cross my mind. Lists, arrays, property lists, association lists...
From starting to code a solution in C++ to actually getting the first and primitive version to run is a long haul with very little progress to be seen. In Lisp, little things, whether they be utility functions, interface specs or conceptual frameworks of code can be quickly be written which further clarify my thoughts. So to go from an ignorant beginning to an informed end is much shorter in Lisp. It facilitates my solving the problem. Further, with its rich datatypes, memory management and the thought and care put in by the developers of Common Lisp (which seems to forsee most of my needs) I can concern myself with solving the problem and not worry about the picky details. Lisp is more than just a programming language, it is a way to develop programs.
> >>>t...@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >>>> [C++ is] a powerful, expressive language. I think a lot of > >>>> misconceptions about C++ are because people haven't > >>>>put in the absurd effort it takes to learn the language fully.
> >>>It can't be `expressive' if it takes an `absurd effort' to express > >>>things in it.
> >>Nonsense.
> >>I.e., "thanks for your absurd yet expressive effort to debunk this."
> >>;-)
> > I would have said `absurd *amount* of effort', but that would have > > been misquoting.
> <heh-heh> I thnk you /did/ misquote! Didn't he say the absurd effort > was in /learning/ C++ fully? I thought Burdick was saying that once > once had with great effort mastered C++ it was indeed easy to work > with it.
Indeed, that's exactly what I said.
> Now for my money I never want to sit thru a link again, nor do I want > to work with a language that cannot do the equivalent of (list 1 :two > "three), nor could I live without lisp macros, and no matter how much > C++ I learn I still won't be able to do those things. But getting back > to your original remark, I was thinking more along these lines, > something even stronger:
> "The Tao says no language that is hard to learn can be easy to work > with, no matter how well you learn it."
I'm a staunch materialist; I wouldn't trust the Tao as a source of wisdom farther than I can throw it, much less some pseudo-Orientalistic guide to programming that tries to get credibility through false association with Lao Tsu. (I have no idea if this was the original intent of the author, or if it was just supposed to be "cute", but certainly a lot of its proponents buy into it on an Orientalist level)
I'm sure there are plenty of difficult-to-learn languages that, once learned, aren't easy to use. Rather than a language composed of 90-degree angles, C++ seems mostly composed of 30, 60, and 45-degree angles. That is, things fit together, but you pretty much need to be an expert to know what piece to grab when. Yeah, it's gonna involve a hell of a lot more typing than Lisp, but it does aspire to allow the user to use a variety of paradigms, and, with GC (which is allowed, and might even make it into a future revision of the standard), even semi-functional style! One tip-off I've noticed that someone hasn't learned C++ well enough to be comfortable with it is if they write 2000~5000 LOC without using a single function-object. *I* sure as hell can't remember half the good things in C++, and have to constantly go to my reference book, just to remember things like, "oh yeah, I *can* make a closure-like-thing ... forgot about that", but for those who *can* remember them, they get to use them to express themselves. If you can't remember how funciton-objects work, you don't use them, and find yourself constrained in what you can do. But if you can rember how things work (the absurd effort -- both in quantity and quality), you have a lot of tools to express yourself, which is no longer an absurd amount or quality of effort.
Naturally, closures shouldn't be hard. Generic code shouldn't be hard. You shouldn't need 1000 potentially redundant typedefs just to avoid deciding type issues before you're ready to. Multiple-dispatch shouldn't require weird overloaded functions that operate syntactically differently than methods. The whole non-virtual method nonsense is a mess.
(Common) Lisp makes things easy to do, and easy to learn. It's easy to fit the parts together without having to be able to remember the entire spec. But if remembering the entire spec allows you to fit the parts together, I'd call that expressive and powerful. For those who can/will invest the effort in getting to that point. And I'd call it a mess for everyone else.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> > "The Tao says no language that is hard to learn can be easy to work > > with, no matter how well you learn it."
> I'm a staunch materialist; I wouldn't trust the Tao as a source of > wisdom farther than I can throw it...
Ah yes, Johnson, Berkeley and the rock. :) Good for you. My coding guide is:
"Learn to empty yourself and be filled by the Tao, the way a valley empties itself into a river."
Some programmers are so smart they create terrible code; their genius overcomes all consequent difficulties, so they think they are doing good work. Been there, done that. Now if I am going one way with the code and I feel resistance, I change direction. I try to be like a good dance partner when the other has the lead. Except I do not know what partner I am following, so for fun I call it the Tao.
> > Now for my money I never want to sit thru a link again, nor do I want > > to work with a language that cannot do the equivalent of (list 1 :two > > "three), nor could I live without lisp macros, and no matter how much > > C++ I learn I still won't be able to do those things.
> You can't even write a working version of EQ in the language!
You can't? I don't think I can write a *useful* version of eq, but I think I can write a working one (unless I'm missing some subtlety).
Cheers, M.
-- > I'm a little confused. That's because you're Australian! So all the blood flows to your head, away from the organ most normal guys think with. -- Mark Hammond & Tim Peters, comp.lang.python
> > > Now for my money I never want to sit thru a link again, nor do I want > > > to work with a language that cannot do the equivalent of (list 1 :two > > > "three), nor could I live without lisp macros, and no matter how much > > > C++ I learn I still won't be able to do those things.
> > You can't even write a working version of EQ in the language!
> You can't? I don't think I can write a *useful* version of eq, but I > think I can write a working one (unless I'm missing some subtlety).
Well, you can write something that compares the bit patterns in a VOID *, but this breaks down when you start using `envelope/letter' models (where the exposed interface to the object is a different class from the implementation of the object). Then you might consider making *all* your object inherit from a virtual abstract class that supports an EQ function, but now your objects will be cast to that abstract type when you want to compare them but the abstract class doesn't have a way of querying the subclass for equivalence.
I think you can provide an instance identifier that is unique for each object, but then comparing EQ involves chasing down virtual class pointers, dereferencing instance counters, etc.
And it won't work on objects that were created by library functions (unless the library had this hack in it).
