brennen
/
p1k3-wala


								<[[alan]]> i concur. as steve yegge likes to point out, the critical mistake was the decision to flatten lists. this means they can only hold scalars, never other lists, and you're stuck in flatland. in order to get out of flatland you have to somehow get a list into a scalar. the solution to this problem was to introduce references. you see by now the slippery slope we're on: now you have not only arrays, hashes, and lists, but references to arrays and hashes, and you need distinct syntax for addressing elements of each.


								it's confusing and lame to even have the option of indirection in an interpreted language. perl did a good thing for its time--garbage collected languages add a lot to programmer productivity. (i think this has been pretty well demonstrated by now.) perl's references eliminated the dangers of indirection, but not the confusion and mental bookkeeping. if anything, perl made this worse. i bet you don't have much trouble remembering what **p does, but @{$HoA{$b}} is another story.


								in the end an intrepreted language benefits a lot from having no indirection whatsoever. make everything a ref under the covers, and everything above the covers doesn't have to care. ruby has no indirection. this is a good thing assuming you trust its garbage collector.


								the thing that still amazes me about perl is that they figured out a way to evolve the language into this thing that has rich data structures, supports OO, exceptions, etc. even though that wasn't a part of the original design. i mean, for crying out loud, it was a crappy little hybrid between awk / sh / sed / C in the beginning. look at it now. i feel like some of these other languages that possibly had a "better" design from the get-go aren't evolving as well. when they were first designed people shouted "eureka! we finally got it right! unlike perl..." and went off to dance naked in the streets. well, no, you didn't get it right. your language will need to evolve too. with every passing year it looks wronger.


								so here we are with perl which is definitely not perfect. definitely. like you i dislike certain things about it. i bump into things that annoy me. but i think the healthy mode of thinking is not "i want to program in a language where nothing annoys me and everything is perfect" but "let's get stuff done and find clever ways to evolve the language in the meantime." because the former is never going to happen.


								sorry this went essay--not my original intent.


								<[[brennen]]> this is essentially my attitude, some kvetching aside. (and i don't know whether to expect that perl6 will address the more serious of these gripes, but there are signs that effort is going toward a lot of stuff that used to fall into the drink-your-kool-aid category. it used to be that you weren't supposed to want a [http://search.cpan.org/perldoc?Switch switch statement], for example, but there it is.)


								there's someting of a parallel to be drawn between perl and the linux kernel (+ its software ecosystem). both grew from improbably specific little niches into highly generalized organisms through a messy evolutionary process, and both are often enough viewed as fundamentally incorrect.


								direction and momentum, i think, count for nearly as much as "correctness".


								<[[alan]]> i've seen this "creative" perl5 switch idiom:


								SWITCH: {

								  /foo/ && do { print "got foo$/"; last SWITCH; };

								  /bar/ && do { print "got bar$/"; last SWITCH; };

								  do { print "got something else$/"; };

								};


								it just feels wrong though.


								i don't think there's much direction and momentum behind perl6, precisely because the idea is to "make the design clean." people don't care. or if they do they defect to some other language where there's more of an emphasis on that.


								p.s. i currently work with the former leader of the parrot project, so maybe you can put my cynicism down to that.


								<[[brennen]]> hmm. your cynicism is probably a lot more warranted than my vague hope for some lost annoyances. and there are certainly enough newish languages floating around with an aesthetic-as-ideology of "clean". if i knew enough to talk i'd say that the problem with this is that while not always unjustified, it gets dangerous fast confusing your stylistic preferences with moral imperatives. but of course i don't know enough to talk; practically the only code i write is perl, and my day job amounts to data entry. which i suppose i should get back to. ottawa's wheelchair-accessible restrooms and parking availability await my mad skillz.


								<[[alan]]> dude, i still don't understand how a competent hacker like yourself can stand to sit in front of a computer all day doing data entry. you're already there, face-to-face with glowing oblivion...you might as well code up some neat stuff man. before you start in with the self-deprecation, let me reassure that you're already in the upper 10th percentile. have you met the people who call themselves "programmers" these days?


								so don't be lazy. give me a good excuse so i don't think you're being lazy.


								<[[brennen]]> i have met the people who call themselves programmers these days. i'm reluctant to be one of the people who inspires that sentiment, and i harbor no delusions about where i'd fall calling myself a programmer without (at least) a few years of intense self-education. people who work primarily in old versions of microsoft access would look down their noses at me, and they ''wouldn't necessarily be wrong''.


								all right, they'd be wrong, but not by all that much. and only in ways underwritten by the relative worth of aesthetic decisions. good taste does not substitute for competence in software any more than it does in literature.


								snark aside, however, you're right. i am being a certain kind of lazy. larry wall's occasionally full of shit, but his (or whoever he stole it from's, or whoever i'm accidentally conflating him with's) good lazy | false lazy scheme is basically true, and i won't argue that my kind is the right kind.


								data entry is an accident; before this i was moving mail and pallets full of overpriced server hardware (and defunct java propaganda) through the halls of a sun microsystems campus. before that i was in christchurch spending borrowed money. now i am trying to get my girlfriend through an undercompensated intern teaching program & a master's degree while paying down stupidly accumulated debt at a rate likely to be overtaken soon by the liquifying of the polar ice caps, so i do my data entry and my cut-rate unix geeking, and i don't take too many chances because it sure would be a goddamn shame if the rent check bounced, or i couldn't pay that fucking mechanic in town who decided to run up an extra couple hundred on a car that's probably worth about what i am paying him to fix it, although on the plus side it's a car i'm borrowing from my parents because at the age of 25 i have not yet managed to have my shit anywhere near together enough, not once, to actually purchase one. none of this is an excuse, precisely, but it is a constraining circumstance. i am operating in a self-created environment of impoverished mental trajectories, desperately trying to find the reserves to spin my mind up to speed without also fucking my entire life, again, and leaving with all my shit piled in the backseat, again.


								<[[alan]]> [http://www.samag.com/documents/s=10093/sam0609j/0609j.htm perl6 demo by randal] - hash and array access look much more consistent.


								<[[Brennen]]> just read that last night. those changes, at least, look pretty decent. i think i might play around with [http://www.pugscode.org/ pugs] a little one of these days.