Re: An ignorant opinion from an amateur [was: Re: Civility, please]
Sam Vilain wrote: To me what's missing stands out like a sore thumb - that making sure a package/class definition can express all the same primitive elements used by the current emerged standard of modelling data sets - UML. The design group is currently considering the entire issue of class metadata. Jarkko has some very solid ideas on what's needed and how it would work. I suspect we'll see a set of standardized properties that encode the requisite information. Damian
Re: Civility, please.
Michael Lazzaro wrote:
Joseph F. Ryan wrote:
Perhaps in the grand scheme of things; however, anyone that is
redesigning a system should not be ignorant of how the old system
worked (even in the slightest degree), in order to know of what to
keep and what to throw away.
Oy. One more time. My objection is this: I said Cmap {...} @a and
friends are special compared to normal subroutine syntax, because there
isn't a comma after the {...}. It was then stated that Cmap itself is
not special, because the '' in the prototype allows the special case to
exist not only in map, but in anything else prototyped in the same
way. True.
My error, therefore, was to not properly define what I meant by normal
subroutine syntax, because I thought it was clear from the context what
normal meant... it meant compared to having a comma there. But it
wasn't clear.
This, however, is a Computer Science discussion. Computer Science is
one of those fields populated almost exclusively by people who consider
any statement devoid of at least three explanatory footnotes to be an
act of aggression, and who measure their own genius in large part by
their practiced lack of ability to infer meaning from any string of
words not emanating from their own head.
Thus, a possible response like I don't agree with your use of the word
'special' to describe this case, because these other cases are
identically 'special' too is transformed without any apparent irony to
since you did not use the precise wording I myself would have used in
your two-sentence explanation, that provides conclusive evidence that
you therefore don't know Perl5.
Yes, in hindsight, I should have responded I know *why* the specialness
exists, you thundering blowhards, I'm just noting that it *is* special
compared to how *most* subroutine argument lists look. Quit assuming
that every last syntactic nuance will tunnel untouched to Perl6 by the
grace of your own unassailable wisdom, and tell me *why* this particular
one should. [1] Those sorts of communications can sometimes cross the
semantic barrier.
Yes, perhaps we should all have our mail proofread by a peer jury before
we post, thus attempting universal semantic clarity... or perhaps we can
all just practice those human social skills that some of us might have
seen on television or in the movies, and Get Over Ourselves. [2]
(Note that Damian was the *only* person who, at any point in the
discussion, was able to identify the notion that not having the comma
there was different from having the comma there, and was able to
respond with an argument more structured than because Perl5 does it.
_This_ is why his ideas get implemented. Duh.) [3]
Any programmer who doesn't know that they are ignorant are almost
certainly instead arrogant.
Ignorant of what? Surely we shouldn't assume that we're all ignorant
of Perl?
What I'm trying to avoid is the apparent need for programmers to degrade
every conversation into an I'm-smarter-than-you semantic duel. In the
entire history of the Perl6 process, there has been noone here to emerge
as God's Perfect Gift to Language Design -- I think the design has been
improved repeatedly by the collective thoughts of the group. But
nobody, individually, has a very good batting average, so I think nobody
is in a position to throw stones.
MikeL [4]
[1] OK, that's definitely not civil. Which is why I didn't originally
say it.
[2] Er, that's not great either, but probably in the range of acceptable.
[3] Note to self -- remove the 'Duh', and it will be fine.
[4] And yes, the irony of needing N paragraphs to try to convince
programmers of such a profoundly simple concept is not lost on me. Nor
is the fact that it will inevitably fail...
Sorry, I hope I didn't offend you. In that last remark I was in no way
fingering you; I was simply speaking broadly.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Civility, please.
Joseph F. Ryan wrote: Sorry, I hope I didn't offend you. In that last remark I was in no way fingering you; I was simply speaking broadly. Nah, you didn't -- I know what you meant. I was just getting very worried about the direction the conversation has been heading lately. Well, that and the fact that one doesn't often get to write a near-flame with footnotes. It's really quite impossible to stop, once you're into it. :-) MikeL
An ignorant opinion from an amateur [was: Re: Civility, please]
On Sun, 19 Jan 2003 11:18, Joseph F. Ryan wrote: Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? Ignorant of the untold number of ways things could be done better. Assuming the universe has an infinite number of possibilities, we have 0% of the expressive space of programming languages covered. But that's not important right now. Now, I know that there was an extensive RFC process for Perl 6. But perhaps there are still simple ideas that have not been entered into the pot yet; after all, like minds think alike. And pot mind like I think into, hmm? To me what's missing stands out like a sore thumb - that making sure a package/class definition can express all the same primitive elements used by the current emerged standard of modelling data sets - UML. So you could say, eg two classes that have a composite, ordered, one to many relationship between each other, and have that information both accessible at run time to persistence layers and control the defaults of how the object behaves. Or an aggregate many to many relationship. Or a simple one to one relationship. You might correctly say, if you make the language flexible enough then you are free to build any number of these systems that work in any number of different ways. But if you ask me, they'll all be a hack until the underlying principles are isolated, and included as keywords, modifiers or whatever it takes to extend the act of defining a class. OO Code is; Classes, Attributes, Methods and Associations. How many of these elements does Perl deal in? And don't take offence at being called an amateur - the word literally means `for the love of it'. -- Sam Vilain, [EMAIL PROTECTED] Thesaurus: ancient reptile with an excellent vocabulary
Re: Civility, please. (was Re: L2R/R2L syntax)
On Sat, 18 Jan 2003 15:10, you wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. -- Sam Vilain, [EMAIL PROTECTED] You're either part of the solution, or part of the precipitate. - George W. Bouche, renowned chemist.
Re: Civility, please. (was Re: L2R/R2L syntax)
Sam Vilain wrote: On Sat, 18 Jan 2003 15:10, you wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Perhaps in the grand scheme of things; however, anyone that is redesigning a system should not be ignorant of how the old system worked (even in the slightest degree), in order to know of what to keep and what to throw away. Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? Joseph F. Ryan [EMAIL PROTECTED]
Re: Civility, please.
Joseph F. Ryan wrote:
Perhaps in the grand scheme of things; however, anyone that is
redesigning a system should not be ignorant of how the old system
worked (even in the slightest degree), in order to know of what to
keep and what to throw away.
Oy. One more time. My objection is this: I said Cmap {...} @a and
friends are special compared to normal subroutine syntax, because there
isn't a comma after the {...}. It was then stated that Cmap itself is
not special, because the '' in the prototype allows the special case to
exist not only in map, but in anything else prototyped in the same
way. True.
My error, therefore, was to not properly define what I meant by normal
subroutine syntax, because I thought it was clear from the context what
normal meant... it meant compared to having a comma there. But it
wasn't clear.
This, however, is a Computer Science discussion. Computer Science is
one of those fields populated almost exclusively by people who consider
any statement devoid of at least three explanatory footnotes to be an
act of aggression, and who measure their own genius in large part by
their practiced lack of ability to infer meaning from any string of
words not emanating from their own head.
Thus, a possible response like I don't agree with your use of the word
'special' to describe this case, because these other cases are
identically 'special' too is transformed without any apparent irony to
since you did not use the precise wording I myself would have used in
your two-sentence explanation, that provides conclusive evidence that
you therefore don't know Perl5.
Yes, in hindsight, I should have responded I know *why* the specialness
exists, you thundering blowhards, I'm just noting that it *is* special
compared to how *most* subroutine argument lists look. Quit assuming
that every last syntactic nuance will tunnel untouched to Perl6 by the
grace of your own unassailable wisdom, and tell me *why* this particular
one should. [1] Those sorts of communications can sometimes cross the
semantic barrier.
Yes, perhaps we should all have our mail proofread by a peer jury before
we post, thus attempting universal semantic clarity... or perhaps we can
all just practice those human social skills that some of us might have
seen on television or in the movies, and Get Over Ourselves. [2]
(Note that Damian was the *only* person who, at any point in the
discussion, was able to identify the notion that not having the comma
there was different from having the comma there, and was able to
respond with an argument more structured than because Perl5 does it.
_This_ is why his ideas get implemented. Duh.) [3]
Any programmer who doesn't know that they are ignorant are almost
certainly instead arrogant.
Ignorant of what? Surely we shouldn't assume that we're all ignorant
of Perl?
What I'm trying to avoid is the apparent need for programmers to degrade
every conversation into an I'm-smarter-than-you semantic duel. In the
entire history of the Perl6 process, there has been noone here to emerge
as God's Perfect Gift to Language Design -- I think the design has been
improved repeatedly by the collective thoughts of the group. But
nobody, individually, has a very good batting average, so I think nobody
is in a position to throw stones.
MikeL [4]
[1] OK, that's definitely not civil. Which is why I didn't originally
say it.
[2] Er, that's not great either, but probably in the range of acceptable.
[3] Note to self -- remove the 'Duh', and it will be fine.
[4] And yes, the irony of needing N paragraphs to try to convince
programmers of such a profoundly simple concept is not lost on me. Nor
is the fact that it will inevitably fail...
Re: Civility, please. (was Re: L2R/R2L syntax)
[EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: Civility, please. (was Re: L2R/R2L syntax)
Simon Cozens wrote: This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. Fortunately there is absolutely no chance of that. Perl 6 is a language being designed by exactly one person. And he's neither ignorant, nor an amateur. The rest of us are merely offering suggestions, feedback, and advice. It's important to remember that Larry loves Perl more than any of us, and that he's not about to be seduced into butchering it by the wild suggestions of so-called ignorant amateurs. Though, of course, he would never *dream* of using that term himself (except perhaps as a profound compliment). On the other hand, I know that Larry cherishes all the ignorant amateur suggestions he receives. Because they help him explore the design space. Because they spark counter-ideas. And because they so often encode -- albeit sometimes very cyptically -- truly guileless expressions of real problems that real Perl users experience. Larry is well-known for extracting the nutritional value from these encodings (i.e. the underlying needs and desires they highlight) without swallowing the unpalatable packaging they sometimes come in. It's instructive to review the PSA ratings of the RFCs covered by the first six Apocalypses and consider the fact that Larry almost always rates the problem space addressed by an individual RFC much higher than the solution it proposes. And *then* typically goes on to describe an alternate approach that solves the problem better and far more generally. Personally, I think we're in safe hands. Damian
