Prev: The correct choice for implementation (was: A simple web clientlibrary)
Next: Solved Re: Emacs speedbar doesn't show .lisp and .asd files
From: John Bokma on 10 Mar 2010 14:20 Jürgen Exner <jurgenex(a)hotmail.com> writes: > Wasn't it the Inuit language, that has over 50 different words for > snow? http://en.wikipedia.org/wiki/Eskimo_words_for_snow -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: ccc31807 on 10 Mar 2010 15:20 On Mar 10, 1:48 pm, Jürgen Exner <jurge...(a)hotmail.com> wrote: > That code is abominable and obfuscated, but of course you can write > abominable and obfuscated code in any programming language. That code is hard read, but it's not obfuscated. The variable 'names' represent scalar values, in this case, an 'integer' used as a key. The convoluation comes from Perl's awkward syntax for multi-level data structures, in this particular case, a hash element that consists of an anonymous hash, thus $sec{$k}{'xlist'} in a foreach loop (which I omitted) like this foreach my $key (keys %sec) { ...$sec{$key}{'xlist'}... } and $fac{$sec{$key}{'id1'}}{'location'} simply references the $sec{$key}{'id1'} element in $fac{KEY}{'location'} This isn't harder than C pointers. And yes, I could have aliased the hash references to more readable variable names, but I wrote the code, I'm reading the code, and I'm maintaining the code ... why should I have to think of a redundant variable name when I have the hash assignments a few lines above this? my %fac; while (<SOME_DATA_SOURCE>) { chomp; my ($id, $site, $location, ... ) = split; $fac{$id} = { id => $id, site => $site, location => $location, ... }; } The script is a short one, about 40 lines of code excluding comments, use statements, etc., and wouldn't give a Perl programmer any problem. CC
From: J�rgen Exner on 10 Mar 2010 15:39 ccc31807 <cartercc(a)gmail.com> wrote: >On Mar 10, 1:48�pm, J�rgen Exner <jurge...(a)hotmail.com> wrote: >> That code is abominable and obfuscated, but of course you can write >> abominable and obfuscated code in any programming language. [...] >$fac{$sec{$key}{'id1'}}{'location'} Thank you for confirming my point. >This isn't harder than C pointers. Saying something isn't harder than C pointers is like saying a desease isn't worse than the Bubonic plague: it gives very little comfort to people suffering from it. Actually C pointers are probably among the worst concepts ever invented in computer science. jue
From: John Bokma on 10 Mar 2010 15:54 Jürgen Exner <jurgenex(a)hotmail.com> writes: > ccc31807 <cartercc(a)gmail.com> wrote: >>On Mar 10, 1:48 pm, Jürgen Exner <jurge...(a)hotmail.com> wrote: >>> That code is abominable and obfuscated, but of course you can write >>> abominable and obfuscated code in any programming language. > [...] >>$fac{$sec{$key}{'id1'}}{'location'} > > Thank you for confirming my point. > >>This isn't harder than C pointers. > > Saying something isn't harder than C pointers is like saying a desease > isn't worse than the Bubonic plague: it gives very little comfort to > people suffering from it. > Actually C pointers are probably among the worst concepts ever invented > in computer science. They are not "invented" they are somewhat a 1:1 mapping to assembly. I've never had problems with C pointers but that's most likely also because I had programmed in Z80 assembly [1] (and some motorola processors) for a few years before programming in C. I do agree, however, that it would've been nice if C had references like Perl, and (harder to get to) pointers as they are now. That, and a better standard library. Disclaimer: haven't programmed in C for a while. [1] including hacking a subset of Forth :-D. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: J�rgen Exner on 10 Mar 2010 16:22
John Bokma <john(a)castleamber.com> wrote: >J�rgen Exner <jurgenex(a)hotmail.com> writes: > >> ccc31807 <cartercc(a)gmail.com> wrote: >>>On Mar 10, 1:48�pm, J�rgen Exner <jurge...(a)hotmail.com> wrote: >>>> That code is abominable and obfuscated, but of course you can write >>>> abominable and obfuscated code in any programming language. >> [...] >>>$fac{$sec{$key}{'id1'}}{'location'} >> >> Thank you for confirming my point. >> >>>This isn't harder than C pointers. >> >> Saying something isn't harder than C pointers is like saying a desease >> isn't worse than the Bubonic plague: it gives very little comfort to >> people suffering from it. >> Actually C pointers are probably among the worst concepts ever invented >> in computer science. > >They are not "invented" they are somewhat a 1:1 mapping to >assembly. Exactly. You can hardly do worse than that ;-) But in all fairness, when C was developed in the early 70s it was a major step forward and Kerningham and Ritchie could not possibly have known as much as we do today. For its time it was a great concept and implementation. It's just that it is way outdated 40 years later. > I've never had problems with C pointers but that's most likely >also because I had programmed in Z80 assembly [1] (and some motorola >processors) for a few years before programming in C. Well, not much Z80 but quite a bit 6502 here in this corner. >I do agree, however, that it would've been nice if C had references like >Perl, and (harder to get to) pointers as they are now. Or even Pascal or Modula or Haskell or pick pretty much any more modern language. However you cannot blame a 40 year old language for reflecting the thinking of 40 years ago. jue |