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

[flyingmoose]

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*.