Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
No such thing as a small change
 
PerlMonks  

Re: Re: Re: Re: Re: Perl Internals: Hashes

by flyingmoose (Priest)
on Apr 15, 2004 at 01:01 UTC ( #345267=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: Re: Perl Internals: Hashes
in thread Perl Internals: Hashes

You are preaching to the choir here in terms of what to use in real-life projects. I was discussing not jumping to Perl in a datastructures class, where the goal is to attain the intracy and Zen. Ah well, we might as well agree that we aren't communicating on this point.

An example I often feel held back in Perl is that only offers hashes, lists, and scalars. Yes, it has objects, but it lacks structures, and hence that keeps one from implementing many data structures in their natural form. I also find it's rather broken when implementing things that feel like tables. Why? Again, the lack of records and the need to use objects.

The case for not having C-like structs is defintely an area where efficiency will burn you. While Huffman-trees, LZW encoding, and simple graphs can do nicely, you start to lose edge when passing lots of data around, and you also lose the grasp on having to "rewire" graphs due to the seeming niceness of memory management. Yeah, references and objects are ok, but still ugly and less pure, IMHO, especially when learning what a datastructures class is meant to teach you.

So that's really the crux of it. Datastructures is in part about datastructures, but as a student of programming, it's also an EXCELLENT time to assess how well you can manipulate pointers. C is unforgiving, but that builds vast discipline. Screwing up and getting a seg fault builds programmer disciple far more than just getting a GIGO error. Sort of like how the appreciation assembler gave me for not confusing int 13h with int 33h (yes, kids, you can make your printer go haywire in the middle of the night while trying to code a silly maze program!).

Keep in mind I am talking about *learning* and *datastructures*, not neccessarily *using* and *algorithms*.


Comment on Re: Re: Re: Re: Re: Perl Internals: Hashes
Re: Re: Re: Re: Re: Re: Perl Internals: Hashes
by chromatic (Archbishop) on Apr 15, 2004 at 05:31 UTC

    Funny you mention the discipline of using C. I recently spent a few minutes trying to find the best way of generating a cross-platform segfault in C for a small piece on core dumps. It took a bit to settle on something short and clear.

Re: Re: Re: Re: Re: Re: Perl Internals: Hashes
by demerphq (Chancellor) on Apr 15, 2004 at 09:10 UTC

    Well, flyingmoose i dont think our views are that dischordant. But I would like to point out and inconsistancy in what you are saying: You are preaching to the choir here in terms of what to use in real-life projects. and you start to lose edge when passing lots of data around, and you also lose the grasp on having to "rewire" graphs due to the seeming niceness of memory management.. To me the latter is about real-life projects. An algorithms and data structures class, unless it is specifically addressing the issue of large scale data processing shouldn't be dealing with huge amounts of data. Nor should it be dealing with distracting machine and OS specific issues like memory management (unless the course is directly looking at memory allocation algorithms).

    With regards to your comments about pointers, Im sorry but I have to say that now you are talking about doing algorithms in C, which is indeed a good thing to know, but is entirely seperate from the issue of teaching algorithms and datastructures. A classic example is Knuth's AofP books and the fact the code is in an assembly for a computer that has never existed. And anyway, outside of pointer arithmetic what can one do with pointers that one cant do in Perl with references or with straight forward base variables?

    I have to say while I agree with most of what you are saying, you arent in my eyes talking about a datastructures and algorithms class but really a whole mixture of general programming and more specifically C programming skils. Which I never commented on. I only said that in my mind teching algorithms and datastructures is just as easy if not easier in perl than in other languages. It seems that most of what you mention as positive from using other languages has actually nothing to do with learning the algorithms at hand but rather the broader set of programming skills. I agree the latter is necessary, but I dont know that it is necessary to occur simultaneously with learning complex algorithms. :-)

    Anyway, I think that a course that explained algorithms in perl, and then required a reimplementation in an another language would be very useful. Perl to get the ideas crystallized in your head without other nonsense distracting from the issues, and the other language to show how drammatically an algorithm can change in appearance because of a different set of operating constraints.

    Anyway, i suspect we are a bit at cross purposes here, so lets just have a beer. ;-)


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


      Yup, we're just nibbling around semantics...

      Anyway, i suspect we are a bit at cross purposes here, so lets just have a beer. ;-)

      What style of beer do you propose? I could go for a Harpoon IPA or maybe a Newcastle. Please discuss your views on the subject. This thread could continue for like eighty billion pages at least. ;)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://345267]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2014-04-20 15:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls