In a year, a woman goes from being virtually unknown to a core member of the Perl 6 design team, president of the Perl Foundation, a speaker at several conferences, and an author.
This news goes public, and the first thing a few people want to talk about is her breasts. When confronted about this, the excuses are "Oh, you're just being too sensitive", "Women like being noticed", and "If she doesn't like it, she shouldn't hang around here."
I'm sorry, but I really don't see any appreciation for Allison's abilities or for her as a person in those comments.
OOP hasn't been decided yet. That's the next Apocalypse the design team is considering. Just about everything known about Perl syntax is in chapter 4.
There are also plenty of people who'll program Parrot or IMCC bytecodes. We're the people who are implementing Perl 6, Ruby, Python, Lua, BASIC, BF, Befunge, Scheme, Jako, Cola, Perl 5, and Perl 1 on Parrot.
If you're expecting this to be a new verison of the Camel or the Llama, you'll be disappointed. It's not. It's aimed at early adopters, people who are curious about the state of the project, and people who are interested in developing Perl 6, Parrot, or another language on top of Parrot.
Re:Full text:
on
Palmtop NetBSD
·
· Score: 2, Interesting
Every article has a copyright notice. Would adding a note about reprint requests make it clearer?
I appreciate that you're trying to help people read the article, but we've quite a bit of bandwidth and processor power and we've survived Slashdotting before. Pre-emptive cutting and pasting just seems a little silly.
Re:Full text:
on
Palmtop NetBSD
·
· Score: 5, Insightful
If you'd asked permission to reprint the article, I'd have given it to you. That wasn't very nice.
Sorry, your comment about O'Reilly, IBM, and Merrill Lynch is wrong. All three companies support open source development financially, among other ways. All three companies also employ system administrators and programmers who work with open source software.
I don't personally know anyone at Merrill Lynch who's contributed to an open source project while on the clock. People at O'Reilly and IBM who do so regularly.
I quite agree. By pointing out mostly syntactic quibbles, I hoped to make it clear that they're much less important than the language philosophy. Some of the things I mentioned could be changed without affecting the underlying language structure. Some cannot.
You've described the best approach I know of in Java.
I think there's an important difference between asking "can this item support the message I'm about to send it" and "does this item fit into a type hierarchy"? Unfortunately, languages with static typing tend to care far more about the latter.
There are lots of ways to achieve code re-use: inheritance, aggregation, delegation, and mixins. Those are all good ways for one item to be able to support various messages. It's unfortunate that inheritance is the way to mark that it can handle that message.
Java's interfaces are one way to mark that, but they don't quite go far enough, since you don't get any code re-use with them. (Maybe it's possible, but I've never seen an example.)
Maybe I'm really overthinking things, but it seems like an important distinction to make.
You're right about the strong typing (I meant "static" but didn't get rid of "strong") and the standard library bits.
I also agree that understanding a language well is important to program in it well the really good programmers can sling around all sorts of idioms and work around implementation issues. A buddy just discovered that bitshift widths in C are done modulo 32. Sure enough, it's in Appendix C of K&R. No one in his office (including the brilliant lead engineer) knew it.
On the other hand, I've learned more things more quickly about programming from seeing how different languages do things than by delving deeply into any one language.
It's nice to be able to delve deeply into the guts sometimes, too. The point isn't to have to exert that level of control all the time. The point is that it's there when you need it.
I phrased the exceptions bit rather poorly. I should have said "deal with" instead of "catch". I'd prefer not to have to declare throws lists explicitly. It's just personal taste.
My interface gripe is specifically that it feels like inheritance (and I lump interfaces in here, whether anyone else agrees) is the one true way to say "this object can handle the method I'm about to call on it". Is there an easy way to retain type checking when using a proxy or a delegate without using an interface?
I was a pretty new Java coder at the time, but it did far more than just checking date stamps on web pages. My biggest problem in those days (Java 1.1 had just come out) was finding a good SMTP library, though it took quite a lot more work parsing a simple text file of e-mail addresses in Java than it did in my shell script.
In retrospect, "several hundred" is probably an exaggeration, though it was at least two hundred. I do count whitespace, inline comments, and javadoc, though.
I didn't list specific gripes about the languages you describe because I don't really have enough practical experience with them to analyze them well. I do discuss languages such as Lisp and Smalltalk in the analysis section though, just as you mention.
Just to be fair, though, one of my gripes with Lisp is the idea that reducing all syntax to a Lambda form makes up for moving all the remaining complexity to built-ins and extensions. I certainly don't think in trees -- a little syntactic sugar is tasty. That doesn't make Lisp wrong; it just doesn't fit my brain as well.
Slashdot Mirror
Not yet, sorry. By the time I talked to Larry, all of the producers were out of the office for the weekend. Please check back on Monday or Tuesday.
We might end up transcribing the remainder of the talks, but I intend to put them online as soon as possible.
Good detective work! You're exactly right; the name was chosen (in part) to please London.pm.
I'll try to get the State of the Onion talk up on Perl.com or the O'Reilly Network tomorrow.
In a year, a woman goes from being virtually unknown to a core member of the Perl 6 design team, president of the Perl Foundation, a speaker at several conferences, and an author.
This news goes public, and the first thing a few people want to talk about is her breasts. When confronted about this, the excuses are "Oh, you're just being too sensitive", "Women like being noticed", and "If she doesn't like it, she shouldn't hang around here."
I'm sorry, but I really don't see any appreciation for Allison's abilities or for her as a person in those comments.
Maybe there'd be more women around if you showed them a little respect.
OOP hasn't been decided yet. That's the next Apocalypse the design team is considering. Just about everything known about Perl syntax is in chapter 4.
There are also plenty of people who'll program Parrot or IMCC bytecodes. We're the people who are implementing Perl 6, Ruby, Python, Lua, BASIC, BF, Befunge, Scheme, Jako, Cola, Perl 5, and Perl 1 on Parrot.
If you're expecting this to be a new verison of the Camel or the Llama, you'll be disappointed. It's not. It's aimed at early adopters, people who are curious about the state of the project, and people who are interested in developing Perl 6, Parrot, or another language on top of Parrot.
Every article has a copyright notice. Would adding a note about reprint requests make it clearer?
Thanks for understanding.
I appreciate that you're trying to help people read the article, but we've quite a bit of bandwidth and processor power and we've survived Slashdotting before. Pre-emptive cutting and pasting just seems a little silly.
If you'd asked permission to reprint the article, I'd have given it to you. That wasn't very nice.
Sorry, your comment about O'Reilly, IBM, and Merrill Lynch is wrong. All three companies support open source development financially, among other ways. All three companies also employ system administrators and programmers who work with open source software.
I don't personally know anyone at Merrill Lynch who's contributed to an open source project while on the clock. People at O'Reilly and IBM who do so regularly.
That may have been true when the book was first written, but it's not true now. The code (a CV) is shared. Only the associated lexical pad differs.
I quite agree. By pointing out mostly syntactic quibbles, I hoped to make it clear that they're much less important than the language philosophy. Some of the things I mentioned could be changed without affecting the underlying language structure. Some cannot.
You've described the best approach I know of in Java.
I think there's an important difference between asking "can this item support the message I'm about to send it" and "does this item fit into a type hierarchy"? Unfortunately, languages with static typing tend to care far more about the latter.
There are lots of ways to achieve code re-use: inheritance, aggregation, delegation, and mixins. Those are all good ways for one item to be able to support various messages. It's unfortunate that inheritance is the way to mark that it can handle that message.
Java's interfaces are one way to mark that, but they don't quite go far enough, since you don't get any code re-use with them. (Maybe it's possible, but I've never seen an example.)
Maybe I'm really overthinking things, but it seems like an important distinction to make.
Saying "s-expression" would have been much more accurate, thanks!
You're right about the strong typing (I meant "static" but didn't get rid of "strong") and the standard library bits.
I also agree that understanding a language well is important to program in it well the really good programmers can sling around all sorts of idioms and work around implementation issues. A buddy just discovered that bitshift widths in C are done modulo 32. Sure enough, it's in Appendix C of K&R. No one in his office (including the brilliant lead engineer) knew it.
On the other hand, I've learned more things more quickly about programming from seeing how different languages do things than by delving deeply into any one language.
It's nice to be able to delve deeply into the guts sometimes, too. The point isn't to have to exert that level of control all the time. The point is that it's there when you need it.
Thanks. You understood what I tried to say.
I phrased the exceptions bit rather poorly. I should have said "deal with" instead of "catch". I'd prefer not to have to declare throws lists explicitly. It's just personal taste.
My interface gripe is specifically that it feels like inheritance (and I lump interfaces in here, whether anyone else agrees) is the one true way to say "this object can handle the method I'm about to call on it". Is there an easy way to retain type checking when using a proxy or a delegate without using an interface?
I was a pretty new Java coder at the time, but it did far more than just checking date stamps on web pages. My biggest problem in those days (Java 1.1 had just come out) was finding a good SMTP library, though it took quite a lot more work parsing a simple text file of e-mail addresses in Java than it did in my shell script.
In retrospect, "several hundred" is probably an exaggeration, though it was at least two hundred. I do count whitespace, inline comments, and javadoc, though.
Have a look at Bruce Eckel's weblog on the subject which points to Bob Martin's thoughts. (Artima seems to be down at the moment, unfortunately.)
Yes! That's exactly the point. Those are minor issues, but arguing over them has wasted a great deal of time and energy.
Granted, I want to use a language that fits my brain (just as you do), but I'm much more interested in useful features than syntax.
Indeed, that's exactly what I did. I was really impressed to discover that JavaScript supports niceties such as closures and Self-ish prototypes.
You mean use constant HACKERS => 1; :).
I've used it to great effect. It does what it says it does. Combined with XPath, the syntax makes my eyes hurt, but it's stunningly effective.
I think I'd rather see s-exps or even Python's indentations than a sea of angle brackets, but the choice of XML for syntax actually makes sense.
I didn't list specific gripes about the languages you describe because I don't really have enough practical experience with them to analyze them well. I do discuss languages such as Lisp and Smalltalk in the analysis section though, just as you mention.
Just to be fair, though, one of my gripes with Lisp is the idea that reducing all syntax to a Lambda form makes up for moving all the remaining complexity to built-ins and extensions. I certainly don't think in trees -- a little syntactic sugar is tasty. That doesn't make Lisp wrong; it just doesn't fit my brain as well.
Actually, I think that's backwards. I've never seen his business interests override his principles.
You know how to disable every installation of a previous version of software? That could be very handy.