* Tim Bradshaw <t...@cley.com> | I'd suggest that the minimum possible time to evaluate a language which is | not a slight variant on something you already know is about a year - see | http://www.norvig.com/21-days.html. You have to work at it, too. However | you can probably do parallel evaluations to some extent. Say, maybe, 18 | months for CL and SmallTalk. If you want to become expert in it, it will | take 5-10 years (assuming you already are a fairly fluent programmer).
This is unduly pessimistic. If you sit down with the standard and spend the time it takes to read it /in its own right/ instead of primarily trying to figure out if it is just like something you already know, it should take 18 months to become an expert. You will be an expert on the language, but not an expert user of the language. I contend that if you try to become an expert user of a language without knowing the language, /you will fail/.
I maintain that it is far better for a person to be able to read well than it is to write well. You become a good writer by reading diligently and with great interest in how and what other people write. You cannot possibly become a good writer simply by writing a lot. Nor is it the intention in advanced societies that each person should start out in life from scratch. We have public education systems to ensure that people have a really good chance of not being completely ignorant of how the world they live in works when they reach the age of suffrage and can inflict harm on society with their ignorance if they vote for, say, George W. Bush. For a person to be able to write well, they would have to read several orders of magnitude more than they write. I fail to understand how programming is any different, yet I see a lot of people who effectively argue that reading other people's code would turn them into /worse/ programmers. Few people today argue that correct spelling is optional, but it appears that some part of the compulsory education system has failed when more and more writers of English are amazingly incompetent spellers. Being /aware/ that you spell a word in a different way than other people and accepted authorities is a necessary condition for learning to spell right, however. Some people think that this is undemocratic or object to it on some ideological grounds, just like some people argue against using standards and specifications in programming.
Reading and understanding specifications is a /prerequisite/ for writing good code. Being able to subjugate one's personal desires to that of other people is a /prerequisite/ for working in a team, for other people, and is a goddamn /requirement/ to make code that works for any other person. Therefore, being able to read a specification like a standard and submitting to its requirements instead of thinking "I can do better, I in fact, I /am/ better, than this" and thus screwing up for everybody else.
If you only sit down to toy with a language until you "get it", and refuse to study it seriously, including reading specifications and other people's code, you end up writing code like some people write SMTP or NNTP servers and mail and news software in general -- and your code will rely on the ability of others to be liberal in what they accept. It is a really bad idea to believe that one can learn to get it right from doing it wrong many times.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Tim Bradshaw <t...@cley.com> writes: > Take physics, or maths. How hard do you have to work to become a > first-rate physicist? Very hard, and for 5-10 years. If you start > seriously when you are 17, you will probably be fluent by the time you > are 23-25, and you'll be really good when you're 30. What about the > prodigies? They work even harder. I've seen this at first hand: I > had a chance to be an academic physicist (well, people said so), but I > was just too lazy, and I gave up my PhD. It wasn't because I couldn't > do it, it was because I *didn't work hard enough*.
Supposedly there exists a "ten-year rule" amongst certain creativity researchers which states that an individual is incapable of making a significant contribution to a given field without at least ten years of significant preparation.
There is a discussion of this rule in an article by Carol S. Dweck entitled "Beliefs That Make Smart People Dumb" in "Why Smart People Can Be So Stupid", edited by Robert J. Sternberg, 24-41. Erik Naggum cited the larger publication's introduction in this group about two months ago. I hope other people have had a chance to pick up this book, I very much enjoyed reading a number of its chapters. Thanks, Erik.
* Erik Naggum wrote: > This is unduly pessimistic. If you sit down with the standard and > spend the time it takes to read it /in its own right/ instead of > primarily trying to figure out if it is just like something you > already know, it should take 18 months to become an expert. You > will be an expert on the language, but not an expert user of the > language. I contend that if you try to become an expert user of a > language without knowing the language, /you will fail/.
Yes, I'm sorry, I should have said `expert user of' rather than `expert in', as it's the user of part that I'm mostly interested in. I agree that becoming an expert in a language can be faster, and is a prerequisite to becoming an expert user of the language.
ilias <at_n...@pontos.net> writes: > I try to evaluate LISP and Smalltalk in the minimum possible time, > with the minimum possible influence of my thinking-processes.
>> (This article was written as a kind of business plan for a new >> ... >> 4 Hackability
>> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of >> ... >> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
>> is this limitation true?
some people here in c.l.l confirm this limitation.
if you have concrete informations about how to overcome this limitation (something that is implemented by major CL-vendors, if possible compatible across the different implementations), please let me know.
>> i found a limitation in LISP, which i'm wondering about.
> You're a troll, right? Right??
I'm not _so_ sure about that. He is a bit nasty in some words yes - but I still think that he really wants to learn Lisp. We could give him at least a chance. His posts are obviously on topic even if he is not necessarily right in any of his claims.
To the topic of iterating over structure slots. I want to emphasise that such things are much less a problem if one uses CLOS and classes instead of structures. Most (all?) CLs which support CLOS seem to support accessing the slots of a class - even if they do not support the remaining parts of the MOP. So _maybe_ this is a limitation of _structures_ in some implementations but it is not a limitation in Common Lisp qua language. Claiming that it is a limitation of the language would be the same like claiming that fixnums are cannot grow arbitrary big (as one should choose bignums to get this...).
>> > I don't want to start a flame war but if it is that lisp mastery does >> > take 5 years for strong programmers then I suggest lisp is far harder >> > to >> > learn and master than Smalltalk. Predudicially I wouldn't be surprised >> > because Smalltalk has strong pedagogical underpinnings; amongst its >> > principal design goals are explorability, readability and >> > comprehensibility.
>> There is a huge gap between a programmer who is good enough to write >> non-trivial applications and an actual language _expert_ .
> Define "huge gap"; but more to the point define "expert". IMO, mastery > "in" a language (ability to solve problems using the language) is as > valid and laudable as mastery "of" a language (ability to > maintain/extend a language). A master in a language is still an > expert. Masters "in" a language may and do use "exotic" features like > MOPs. Feels to me like you're pushing some status agenda. Does one > have to be a language lawyer to use Lisp? If so, that's a serious flaw; > any language that requires a programmer to have mastered a non-trivial > programming system to language lawyer level is too difficult to use. I > don't think Lisp *is* such a system.
No one does not have to be a language lawyer and not even a language expert to _use_ Lisp (or Smalltalk).
> So what's your point?
My point was simply that there is a difference between someone who is able to use a language in a useful and non-trivial way and someone who has a *deep* understanding of a language and all its environment. I think the claim that one needs ~5-10 years to get an expert programmer even in languages like Lisp or Smalltalk. If it would be true what you say that one reaches this level of comprehensability in several months then you actually claim that those programmers who use the language for several years (> 5 years) do not really learn anything more - I do not believe that.
And please recognize that I actually tried to fullfill your wish not to start a flame war - I simply tried to ask your question from how I understand it - so please stop that "define every word you use" flaming mode. You could have simply asked politely if you by yourself are really not interested in a flamewar.
>>>i found a limitation in LISP, which i'm wondering about.
>> You're a troll, right? Right??
>> You did _not_ "find a limitation" in lisp in your first week >> of perusal. Just take my word for it.
> i've found a limitation in LISP:
You found someone else's expression that he perceives a limitation in Lisp. That someone else has somehow, in spite of that limitation, profited greatly from the use of Lisp. By profited, I of course mean dollars. Millions of them. This is no secret; he himself has informed the word about this, and claimed that Lisp was a big ingredient in his success. You can read all about it on his website.
He is now promoting a new programming language. That new programming langauge would not be even slightly interesting if it could not claim to correct some limitations in Lisp.
Note that nearly everyone here is quite familiar with the writings at www.paulgraham.com. You are not surprising anyone with your citations from this material.
> if you have concrete informations about how to overcome this limitation > (something that is implemented by major CL-vendors, if possible > compatible across the different implementations), please let me know.
If you know of a concrete software project which apparently cannot proceed without overcoming this limitation, and is willing to pay a developer to solve the problem, please let me know.
If you know of an ISO- or ANSI-standard programming language, which is more powerful than Common Lisp, and has equally great vendor support, please let me know also.
How much other functionality are you willing to *lose* in switching to a language which has built-in reflection in the form of enumerating the slots of a structure?
Note Paul Graham's stated reasons for wanting to do that: hunting down references to objects, and finding uninitialized values. The hidden implication is that these things are important to do. But hunting down references to objects is unnecessary, because garbage collection does that. Finding uninitialized values is unnecessary because Lisp structures don't have uninitialized values. Slots which have no :initform are initialized with the value NIL.
ilias <at_n...@pontos.net> writes: > if you have concrete informations about how to overcome this > limitation (something that is implemented by major CL-vendors, if > possible compatible across the different implementations), please let > me know.
Sure, use CLOS or write your own generic struct API unifying the variations betwixt the implementations and providing a portable, internally consistent interface, perhaps contribute it to CLOCC.
The limitation is not CL, it's the replacement of your real goal with a miguided set of goals you THINK are indicative of a languages capabilities. You are choosing these goals because you do not have the experience yet to evaluate these languages on their own terms. The condition of CL not having such an interface defined is certainly a hassle if you are fixated on doing this particular task, but it is not impossible to use either of the solutions mentioned above, or perhaps one of the other suggestions, in order to accomplish your real goal.
Taking this one example as an indicator of a hackability or reflexive limitation in a programming language yeilds particular ironic results in the case of CL.
If you are in such a hurry to evaluate languages as you said you were, you are never going to be able to properly evaluate CL or SmallTalk or ML or Python or any of the possiblities, let alone operate at a sufficiently advanced level in any one of them to reach their respective hackability limitations, or perhaps even complete your goal in the allotted time.
>>I try to evaluate LISP and Smalltalk in the minimum possible time, >>with the minimum possible influence of my thinking-processes.
> I'd suggest that the minimum possible time to evaluate a language > which is not a slight variant on something you already know is about a > year - see http://www.norvig.com/21-days.html. You have to work at > it, too. However you can probably do parallel evaluations to some > extent. Say, maybe, 18 months for CL and SmallTalk. If you want to > become expert in it, it will take 5-10 years (assuming you already are > a fairly fluent programmer).
> What you are doing is roughly the equivalent of walking into a nuclear > powerstation and badgering people about whether the lino should be > white or blue.
> --tim
what are you doing there? taking one paragrah, bringing my words out of context, and the comment?
it will take me not more the one month to take my decision. And this while working fulltime on a project in C++.
"...i try to evaluate [as deep as i need]...".
for you to remember, the *full* post you answered to.
>> Take physics, or maths. How hard do you have to work to become a >> first-rate physicist? Very hard, and for 5-10 years. If you start >> seriously when you are 17, you will probably be fluent by the time you >> are 23-25, and you'll be really good when you're 30. What about the >> prodigies? They work even harder. I've seen this at first hand: I >> had a chance to be an academic physicist (well, people said so), but I >> was just too lazy, and I gave up my PhD. It wasn't because I couldn't >> do it, it was because I *didn't work hard enough*.
>Supposedly there exists a "ten-year rule" amongst certain creativity >researchers which states that an individual is incapable of making a >significant contribution to a given field without at least ten years >of significant preparation.
Herb Simon and others who study expertise have made the claim that achieving expertise requires ten years of concentrated study and practice, and have collected data to back up this claim in domains ranging from chess to pole vaulting. IIRC, Simon cites Bobby Fisher as one of the rare exceptions -- he progressed from chess beginner to grand master in just over nine years.
>>>i found a limitation in LISP, which i'm wondering about. >> You're a troll, right? Right?? >> You did _not_ "find a limitation" in lisp in your first week >> of perusal. Just take my word for it.
> i've found a limitation in LISP:
You have found a limitation in _one data structure_ in Lisp.
You would find, in C, that there isn't a straightforward way to _ensure_ that variables of type "char" can be guaranteed to be able to store ASCII text.
I'm sure you would find limitations in one thing or another in just about any software system you cared to look at. But that is apparently not nearly as interesting as trumpeting that you have found "a limitation in Lisp.'
> some people here in c.l.l confirm this limitation.
> if you have concrete informations about how to overcome this > limitation (something that is implemented by major CL-vendors, if > possible compatible across the different implementations), please > let me know.
If you don't like the way DEFSTRUCT works, then use DEFCLASS instead, as it is now widely implemented, and does not have this limitation that you are apparently so worried about.
If you persist in _demanding_ that DEFSTRUCT be "fixed" to conform with your expectations, people are likely to ask how much you are prepared to pay for the "bug fix," because you seem to be the only one around that really cares about having it changed. -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://cbbrowne.com/info/finances.html Overheard in the mall: "What's with your sister and her spitting fetish?"
Tim Bradshaw <t...@cley.com> writes: > * Erik Naggum wrote:
> > This is unduly pessimistic. If you sit down with the standard and > > spend the time it takes to read it /in its own right/ instead of > > primarily trying to figure out if it is just like something you > > already know, it should take 18 months to become an expert. You > > will be an expert on the language, but not an expert user of the > > language. I contend that if you try to become an expert user of a > > language without knowing the language, /you will fail/.
> Yes, I'm sorry, I should have said `expert user of' rather than > `expert in', as it's the user of part that I'm mostly interested in. > I agree that becoming an expert in a language can be faster, and is a > prerequisite to becoming an expert user of the language.
I've just remembered a book I read some years ago. It was "Designing and Programming Personal Expert Systems" by Carl Townsend and Dennis Feucht translated into Russian. Authors claims that an expert in a given domain differs from a nonexpert by an ability to create chunks (chanks ?) (bundles of facts and links between them, that are stored and retrieved as whole things). Average specialist remembers from 50000 to 100000 chunks. It requires 10-20 years to create such volume of data in a man memory.
* Carl Shapiro | Supposedly there exists a "ten-year rule" amongst certain creativity | researchers which states that an individual is incapable of making a | significant contribution to a given field without at least ten years of | significant preparation.
I thought that was "tenure". (Sorry.)
| Thanks, Erik.
I'm happy that the recommendation was well received.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
* Jochen Schmidt | I'm not _so_ sure about that. He is a bit nasty in some words yes - but I | still think that he really wants to learn Lisp. We could give him at least a | chance. His posts are obviously on topic even if he is not necessarily right | in any of his claims.
This is interesting. /ilias/ is "on topic"? And what about all the chances he deliberately squandered? Seriously, this is an ill-behaved runt that people should not respond to.
| I want to emphasise that such things are much less a problem if one uses CLOS | and classes instead of structures. […] Claiming that it is a limitation of | the language would be […] like claiming that fixnums […] cannot grow | arbitrary big (as one should choose bignums to get this...).
Precisely—it is a feature. Persisting in arguing that it is a limitation when people tell you otherwise is annoying and only goes to show a lack of desire to learn the language coupled with a desire to "fix" it. Structures have better optimizability because their layout is known at compile time, redefinition is not defined, and single inheritance can only append slots. Choose structures if you are willing to give up some of the flexibility in exchange for different performance. Choose classes if you want the flexibility back. Portability between structures and classes is limited to the constructor functions.
[This should double as a test of posting with UTF-8.] -- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
In article <3238601790221...@naggum.no>, Erik Naggum wrote: > * Carl Shapiro > | Supposedly there exists a "ten-year rule" amongst certain creativity > | researchers which states that an individual is incapable of making a > | significant contribution to a given field without at least ten years of > | significant preparation.
> I thought that was "tenure". (Sorry.)
> | Thanks, Erik.
> I'm happy that the recommendation was well received.
I just ordered that on, but so far I have bought: a rulebook for arguments asking the right questions choosing civility and the at of reasoning(still reading it)
So far all of them have been good and useful books.
So Erik please make more recommendations, you are a force multiplier where reading is concerned.
> (This article was written as a kind of business plan for a new > ... > 4 Hackability
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of > ... > In Common Lisp I have often wanted to iterate through the fields of a struct-- ... > I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
and i asked
> is this limitation true?
two parts of the text for Paul Graham i'd quoted imply the meaning of 'limitation':
> "being able to do what you want" > "I have often wanted to..."
limitation = *I* cannot do, what i want to do.
or we could say:
limitation = *n* % of the language users, cannot do what they want to do.
I personally 'felt' this limitation with "C" and "C++" and some others languages (see my first post to c.l.l).
Of cource, i could build an "object-model" or a "structure_model" to support this.
but i wan't the fuctionality at the lowest possible language-level.
> * Jochen Schmidt > | I'm not _so_ sure about that. He is a bit nasty in some words yes - but I > | still think that he really wants to learn Lisp. We could give him at least a > | chance. His posts are obviously on topic even if he is not necessarily right > | in any of his claims. > > This is interesting. /ilias/
my firstname is something very personal to me. you've replied not one time directly to my posts. but you quote my name.
be friendly. choose civility.
> is "on topic"?
of course i am. i start the topic. i know the exact reasons why i've done that. it looks like you don't.
> And what about all the chances he > deliberately squandered?
maybe i'm the one who's giving chances.
> Seriously, this is an ill-behaved runt that people > should not respond to.
i bet your pardon?
be friendly. choose civility.
> | I want to emphasise that such things are much less a problem if one uses CLOS > | and classes instead of structures. […] Claiming that it is a limitation of > | the language would be […] like claiming that fixnums […] cannot grow > | arbitrary big (as one should choose bignums to get this...). > > Precisely—it is a feature.
i understand your thought. you are correct. but with limits. see below.
> Persisting in arguing that it is a limitation when > people tell you otherwise is annoying
'argue'. 'tell'. sorry, if anyone feels annoyed.
> and only goes to show a lack of desire to > learn the language coupled with a desire to "fix" it.
i've generally a high tendencies to fix. see my first post in c.l.l.
> Structures have better > optimizability because their layout is known at compile time,
the layout is know at compile time. so it should be not a problem, to allow accessing the structure - by index - by name - by telephone-number of your last date. - by smell
> redefinition is > not defined, and single inheritance can only append slots. redefinition? who cares? off-topic.
> Choose structures > if you are willing to give up some of the flexibility in exchange for different > performance. Choose classes if you want the flexibility back.
this is ok.
but the implementation of structs in CL raises limitations, that are not neccessary.
(defstruct_like_ilias_wants () (....))
> Portability > between structures and classes is limited to the constructor functions.
you forgot the 'flexibility' you've stated above. you forgot the 'limitation' of the structs.
On 17 Aug 2002 03:22:58 +0000, Erik Naggum <e...@naggum.no> wrote:
> than they write. I fail to understand how programming is any different, yet > I see a lot of people who effectively argue that reading other people's code > would turn them into /worse/ programmers. Few people today argue that
Well, it depends:
"The best way to prepare [to be a programmer] is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system". -- Bill Gates
This tells something about the quality of Mr. Gates' products: garbage in, garbage out :)
By the way, do you have any suggestions for especially interesting Lisp code to read?
ilias <at_n...@pontos.net> writes: > limitation = *I* cannot do, what i want to do.
This is false. You can do what you want to do, but you're too obsessed with what name has been chosen for the types in Lisp to do it.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -X "Structure is nothing if it is all you got. Skeletons spook X- <- -> -/ people if [they] try to walk around on their own. I really \- <- -> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
