Save yourself the 7$, here's Tufte's essay in a nutshell:
Slide presentations are bad because:
The fonts are big and there's a lot of wasted space. Therefore information density is low.
People are too stupid to deal with the low bandwidth, so they either overcram stuff on their slides or end up with notes that are useless to others afterwards.
The fonts are big and there's a lot of wasted space. Therefore information density is low. (he repeats this like 87 times)
Powerpoint is bad because I said so, and you have to believe me because I'm famous for this kind of stuff.
I'm not going to give you any hints as to how to use slides effectively.
Thanks for the seven bucks, sucker.
It's been a while since I wasted my time reading that overhyped essay, so I probably forgot something, but that's the meat of it... low information density. Big farking whoop...
Yeah, I had to shake my head at that one too. I also liked this particular exchange:
Reason: Can you give an example of that?
Powell: There's Standard Oil.
Reason: Most of the revisionist histories of Standard Oil show that by the time it had its maximum market penetration, it was actually charging less for oil.
Powell: You may know more about the specifics of Standard Oil than I. But I do believe in the cases and the theories that show that at a certain level of monopolistic control people can extract monopoly rents and affect output in a way that harms the American consumer.
Umm... dude? If you don't know the details of the issue, why would you bring it up as an example? I guess he just expected the interviewer to know nothing about the Standard Oil situation (like me, but at least I admit that I'm a dumbass).
But there's a huge difference between working long hours when you want to, and doing it when you're forced to. I worked for a while at Rockwell Automation, and I had one winter where I was working 16 hour days for a month, and I didn't mind because it was my decision to do that so we could help get our guys home from Korea in time for Christmas (they were upgrading the control systems at a steel plant).
Now if I was forced to do that to get some rod mill in PA up and running on short notice because management screwed up and set a poor schedule, I'd be pretty pissed about it, and those hours would get mighty long mighty fast.
These guys wer working out of love (or insanity, you decide). That makes the long hours a lot more palatable...
What I'm looking for is a CS (not necessarily just programming) equivalent to Shirley O. Corriher's excellent Cookwise or Alton Brown's I'm Just Here for the Food: Food + Heat = Cooking, a couple of books that teach you about the chemistry of cooking at a very accessible level, in order to teach you how cooking works so you can successfully modify or create your own recipes, and not just giving you a list of recipes to follow.
I suppose that SICP is sort of close, but it's not nearly as accessible as Cookwise (and much more boring)
Consider a situation in which the transmission of encrypted messages is intercepted by an adversary who can later ask the sender to reveal the random choices (and also the secret key, if one exists) used in generating the ciphertext, thereby exposing the cleartext. An encryption scheme is deniable if the sender can generate `fake random choices' that will make the ciphertext `look like' an encryption of a different cleartext, thus keeping the real cleartext private. Analogous requirements can be formulated with respect to attacking the receiver and with respect to attacking both parties.
Deniable encryption has several applications: It can be incorporated in current protocols for incoercible ("receipt-free") voting, in a way that eliminates the need for physically secure communication channels. It also underlies recent protocols for general incoercible multiparty computation (with no physical security assumptions). Deniable encryption also provides a simplified and elegant construction of an adaptively secure multiparty protocol.
In this paper we introduce and define deniable encryption and propose constructions of such schemes. Our constructions, while demonstrating that deniability is obtainable in principle, achieve only a limited level of it. Whether they can be improved is an interesting open problem.
Why are you assuming this is a joke? As the prof in my heuristics class said, "your boss isn't going to give a damn if the problem you need to solve is NP-Complete... you're still going to have to write the code." And of course there's the issue of average case hardness vs. worst case hardness, plus just the size of the problem being worked. A lot of TSP instances don't take that long to solve.
There are plenty of algorithms out there for solving NP-Complete (and harder) problems. It's just that they won't work too fast for large, hard case problems...
Thanks for the info, but I've got to say... Holy crap is that horriffic. It just strikes me as one of the things wrong with C, (there's plenty right with it, but that's just bad). For example, in C I can do:
int main () {
float a = 1.234; float b = 5.678; float f = 100.001;
int c = 13; char * s = "hubba bubba";
Plus, if I were to have screwed up and written that last printf statement as printf "f: %f, s: %s\n" f s;;, the type conflict is detected at compile time...
Of course that's how they do it. And of course you can swap the contents of variables that hold pointers to the other types. But how many people here on slashdot bothered to take that into account?
This is especially true if you want to really get pedantic. The problem said numbers and people are throwing up int based solutions. Try throwing them at floats, or arbitrary precision integers. But "everybody knows" that
The solution is canonically written in C/C++ as:
a ^= b ^= a ^= b;
or
#define SWAP(a,b) (a^=b^=a^=b);
Which only swaps two ints, not two numbers, for that you have to add the code to take the addresses, cast them to ints, yadda, yadda, yadda... I stand by my assertion that these are sad little solutions...
Well, you can use copy and paste (Cmd-C and Cmd-V) to copy and paste files. There's just no cut (and Cmd-C followed by Cmd-Del doesn't work either, as you can't paste after you move the original to the trash).
Reliance on the mouse is a big issue to me. I really loathe having to pause reach for the mouse every two seconds to move the cursor to the button, click then go back to my keyboard.
So get yourself one of these. I did, and it's one of the best purchases I ever made. Shiny.
ML!?!!! But that's yet another functional language I don't know!
Sigh... you may or may not have been joking here, but I want to make it clear that I said ML instead of OCaml is because it's common across the ML family of languages, just as some concept may be common to *nix or *TeX.
Yes, of course it makes sense, and no thanks for the slur on my education
Hey, you're the one who said you only had a minimal introduction to recursion. And since you said that the horrific example of recursion you gave came straight from that introduction, I'd have to surmise that it was a very poor introduction. You've certainly given me no evidence to the contrary... Especially when you say things like:
So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results.
I'm not sure I'm interpeting your example correctly, but this is what I think it does, and the minimal mental operations required to process it:
Close-ish, but not quite right. It's more like:
(1) Define a function map that takes f and lst as parameters (2) Define a function map_helper, local to map that takes three parameters, f, lst, and acc. This function does the following:
(3) Pattern match on lst. If lstis an empty list
(4) Reverse acc
(5) Return it
(6) Otherwise split lst into its first element and a list of the remaining elemets, call these head and tail.
(7) Apply f to head
(8) Cons the result onto acc.
(9) Overwrite the current stack frame with a new one where f is the same as it was before, lst is replaced with tail, and acc is replaced with the value computed in (8) -- Goto (3) (10) Call the function defined in (2) passing it f as f, lst as lst and an empty list as acc. (11) Return whatever value this hands back to you.
Note that there is no stack growth (well, there is one new frame appended for the first call to map_helper [I think... the compiler may optimize this call away as a tail call as well -- I'll have to see if that's the case]), and then for every additional call to map_helper, the current stack frame is just reused. And so we have the following concepts to handle: Define a function, apply a function, add and remove elements to/from the head of a list, return a value. That's all...
Of course there are a few neat things that go on under the hood here. For example, the compiler is able to determine the following things about map: map_helper's f must be a function that takes something of unknown type 'a and return a value of unknown type 'b ('a -> 'b). It knows this because we apply it to head in step (7). map_helper's lst must have type ('a list). It knows this because f (of type 'a -> 'b) is applied to head in step (7), so head must be of type 'a, and the list it came from must be an 'a list (as OCaml lists are homogeneous). acc must have type 'b list, because we stick (f head) in it, and f returns values of type 'b. map_helper is a function of type (('a -> 'b) -> 'a list -> 'b list -> 'b list) because it takes f, lst, and acc of the first three types and returns the reversed acc, which has the same type as acc map's f and lst are of type ('a -> 'b) and 'a list respectively, because that's what it passes into map_helper's f and lst, and it
Assembly Language (imperitive style) is the latin of programming. Functional programming is, what, esperanto? Useful in some limited circles, but generally unpopular?
Well, assembly is more like the Latin of the von Neumann architecture (and thus very important to learn), while a functional language like Haskell is more along the lines of the Latin of the mathematics of computation, and thus also important to learn.
Showing off your mastery of OCaml doesn't help anyone understand Haskell better
a) I switched to OCaml, because I am more familiar with it (and able to write proper code off the top of my head in it) and for an example like quicksort, it's very close to Haskell (without the list comprehensions). b) As for showing off my "mastery" of the language, as I pointed out, the definition of rec is in section 1.1 of the OCaml manual. It is the sixth line of OCaml code that someone looking in the manual would see. And if you care, here's quicksort in Haskell (from Haskell.org):
qsort [] = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x where elts_lt_x = [y | y <- xs, y < x] elts_greq_x = [y | y <- xs, y >= x]
And basic programming in an imperative style requires that you document the names of your variables and choose meaningful names
Yes. And I suppose I should have used lst or theList for l, head for h, and tail for t. But h, t, and l are so common in ML literature and code (much like i and j as throwaway loop counters, and foo, bar, and baz in pseudocode), that a brief amount of exposure to the language would make them instantly familiar. Besides, my use of less and greater didn't seem to help...
BTW: Imperative programming requires that? Since when? Why is it that Perl has its reputation for looking like line noise? Have you looked at the IOCCC entries lately? Crap variable names and lack of documentation are available in all languages...
In a programming language, "+" could be string concatenation, for example, so that "hello" + 3 yields "hello3".
Yeah, in a language with horrible typing properties, but that's a rant for a different time.
Yes, I'm sure it is, somewhere.
Yeah, right at the spot I linked to. In the OCaml manual, under the section that documents the List module.
Actually, the example I gave was straight from the (minimal) introduction to functional programming I got in school. Which re-enforces my point that functional programming isn't so simple, if I got it wrong.
So you got a minimal (and apparently pretty damn poor) education in recursion and FP, and you're using that experience to damn a whole class of programming languages? Does that really make sense to you?
My point was that recursion is usually more complicated than an imperative alternative.
And my point was that you pulled a contrived example of recursion out of a hat and used it to damn FP. As I said, that's akin to my using Duff's device or this example of printing some strings to damn C. The oddball cases don't tell you anything about the average ones...
Doesn't the recursive version need to put n -1 lists on the stack, (until it unwinds to the empty list), each of size one smaller? I get n-1(n-2)/2 space usage for an operation that should take 2*n space. Am I wrong? Is this a bad example?
Well, depending on how you implement it, yes. As a pure recursive process, it will consume linear space instead of constant space (in terms of stack frames). However, you can use an iterative (tail-recursive) process (with a recursive procedure) to use constant stack space. Ex:
let tr_map f lst = let rec map_helper f lst acc = match lst with [] -> List.rev acc | head::tail -> map_helper f tail ((f head)::acc) in map_helper f lst [];;
Chinese teaches more about eastern languages, latin, about western.
Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)
What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.
rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual). l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h. If you have trouble telling what a variable is, it's no wonder Haskell befuddled you (Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?"). By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.
Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.
Well that certainly depends on whether you mean recursive in the sense of the process or in the sense of the procedure (see SICP if you don't know the difference. The difference in performance between a for loop and something like:
let fib n = let rec fib_h a b n = if n = 0 then b else fib_h (a + b) a (pred n) in fib_h 1 0 n;;
Tree manipulation is a toy problem? Last time I checked, trees (and heaps and treaps, and all sorts of other recursive data structures) are all over programming.
What's more, I can write recursive solutions in perl if I really have to.
And I can do imperative programming in OCaml if I really have to. Your point was what again?
We're programmers. We do need to understand that complex underbelly.
So you know all about the properties of the semiconductors making up your machine? You can tell me how to build a J/K filp-flop and a shift register? You know all about circuit layout optimization? The inner workings of a DVD burner? See, that's one of the nice things about programming. You only need to strip off a certain number of layers of abstraction to do your job well -- sometimes you need to go deeper, sometimes you don't need to go deep at all.
We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible.
And so you're advocating Perl?!? It's nigh impossible to reason at all about imperative programs and prove them correct, but when you've got a language that essentially encourages willy-nilly programming styles (yes, I know you can code clean Perl, but it takes a lot more effort than other languages) and highly mutable state like Perl than pretty much all hope i
Well I was complaining more about the horrible way of referencing the elements of the array. It's especially confusing when you learn that even though $tune[0] refers to the array @tune in some way, the variable $tune doesn't.
Slashdot Mirror
Slide presentations are bad because:
It's been a while since I wasted my time reading that overhyped essay, so I probably forgot something, but that's the meat of it... low information density. Big farking whoop...
Meh, what do I care? I live in Albuquerque...
Bring on the tidal waves, bitches!
Umm... dude? If you don't know the details of the issue, why would you bring it up as an example? I guess he just expected the interviewer to know nothing about the Standard Oil situation (like me, but at least I admit that I'm a dumbass).
But there's a huge difference between working long hours when you want to, and doing it when you're forced to. I worked for a while at Rockwell Automation, and I had one winter where I was working 16 hour days for a month, and I didn't mind because it was my decision to do that so we could help get our guys home from Korea in time for Christmas (they were upgrading the control systems at a steel plant).
Now if I was forced to do that to get some rod mill in PA up and running on short notice because management screwed up and set a poor schedule, I'd be pretty pissed about it, and those hours would get mighty long mighty fast.
These guys wer working out of love (or insanity, you decide). That makes the long hours a lot more palatable...
Well, they did add that Help button. And they were also able to make it all blocky and cheap looking...
Yeah, that would be great if O'Reilly hadn't started resting on their laurels and let their collection stagnate.
Oh look honey... another 400 "Hacks" books. Oooohhh... "Grits 'n' Gravy Hacks"! And "1974 Ford Pinto Hacks"!
What I'm looking for is a CS (not necessarily just programming) equivalent to Shirley O. Corriher's excellent Cookwise or Alton Brown's I'm Just Here for the Food: Food + Heat = Cooking, a couple of books that teach you about the chemistry of cooking at a very accessible level, in order to teach you how cooking works so you can successfully modify or create your own recipes, and not just giving you a list of recipes to follow.
I suppose that SICP is sort of close, but it's not nearly as accessible as Cookwise (and much more boring)
Really?
Psycho appears to be closer to old slow Python than to C++.
I know that these benchmarks aren't the end all/be all of the issue, but where there's smoke...
Abstract:
Why are you assuming this is a joke? As the prof in my heuristics class said, "your boss isn't going to give a damn if the problem you need to solve is NP-Complete... you're still going to have to write the code." And of course there's the issue of average case hardness vs. worst case hardness, plus just the size of the problem being worked. A lot of TSP instances don't take that long to solve.
There are plenty of algorithms out there for solving NP-Complete (and harder) problems. It's just that they won't work too fast for large, hard case problems...
Eeeets got Sony guts!!!
You like, you buy. Is no big deal...
Of course that's how they do it. And of course you can swap the contents of variables that hold pointers to the other types. But how many people here on slashdot bothered to take that into account?
This is especially true if you want to really get pedantic. The problem said numbers and people are throwing up int based solutions. Try throwing them at floats, or arbitrary precision integers. But "everybody knows" that
The solution is canonically written in C/C++ as:
a ^= b ^= a ^= b;
or
#define SWAP(a,b) (a^=b^=a^=b);
Which only swaps two ints, not two numbers, for that you have to add the code to take the addresses, cast them to ints, yadda, yadda, yadda... I stand by my assertion that these are sad little solutions...
Simple, make a rubber stamp with the appropriate shape on it, dip stamp in pile of ground up pencil lead, stamp image on paper.
Now then... where's my goddamn profit?
Yep. Works in OCaml (let a,b = b,a) and a few other languages as well.
And unlike the sad little C/C++ solutions people are tossing around, this works for *any* type, not just ints & chars...
More about quines than you ever wanted to know.
So someone's finally doing something with Dorothy Denning's Geo-Encryption and location based authentication ideas from a couple of years ago.
Wake me when Woz has an original, interesting idea...
Snagglepuss, perhaps?
Heavens to Murgatroyd. It's a dual G5, even...
Well, you can use copy and paste (Cmd-C and Cmd-V) to copy and paste files. There's just no cut (and Cmd-C followed by Cmd-Del doesn't work either, as you can't paste after you move the original to the trash).
Reliance on the mouse is a big issue to me. I really loathe having to pause reach for the mouse every two seconds to move the cursor to the button, click then go back to my keyboard.
So get yourself one of these. I did, and it's one of the best purchases I ever made. Shiny.
ML!?!!! But that's yet another functional language I don't know!
Sigh... you may or may not have been joking here, but I want to make it clear that I said ML instead of OCaml is because it's common across the ML family of languages, just as some concept may be common to *nix or *TeX.
Yes, of course it makes sense, and no thanks for the slur on my education
Hey, you're the one who said you only had a minimal introduction to recursion. And since you said that the horrific example of recursion you gave came straight from that introduction, I'd have to surmise that it was a very poor introduction. You've certainly given me no evidence to the contrary... Especially when you say things like:
So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results.
Memoization and tail recursion are hardly FP specific.
I'm not sure I'm interpeting your example correctly, but this is what I think it does, and the minimal mental operations required to process it:
Close-ish, but not quite right. It's more like:
(1) Define a function map that takes f and lst as parameters
(2) Define a function map_helper, local to map that takes three parameters, f, lst, and acc. This function does the following:
(3) Pattern match on lst. If lstis an empty list
(4) Reverse acc
(5) Return it
(6) Otherwise split lst into its first element and a list of the remaining elemets, call these head and tail.
(7) Apply f to head
(8) Cons the result onto acc.
(9) Overwrite the current stack frame with a new one where f is the same as it was before, lst is replaced with tail, and acc is replaced with the value computed in (8) -- Goto (3)
(10) Call the function defined in (2) passing it f as f, lst as lst and an empty list as acc.
(11) Return whatever value this hands back to you.
Note that there is no stack growth (well, there is one new frame appended for the first call to map_helper [I think... the compiler may optimize this call away as a tail call as well -- I'll have to see if that's the case]), and then for every additional call to map_helper, the current stack frame is just reused. And so we have the following concepts to handle: Define a function, apply a function, add and remove elements to/from the head of a list, return a value. That's all...
Of course there are a few neat things that go on under the hood here. For example, the compiler is able to determine the following things about map:
map_helper's f must be a function that takes something of unknown type 'a and return a value of unknown type 'b ('a -> 'b). It knows this because we apply it to head in step (7).
map_helper's lst must have type ('a list). It knows this because f (of type 'a -> 'b) is applied to head in step (7), so head must be of type 'a, and the list it came from must be an 'a list (as OCaml lists are homogeneous).
acc must have type 'b list, because we stick (f head) in it, and f returns values of type 'b.
map_helper is a function of type (('a -> 'b) -> 'a list -> 'b list -> 'b list) because it takes f, lst, and acc of the first three types and returns the reversed acc, which has the same type as acc
map's f and lst are of type ('a -> 'b) and 'a list respectively, because that's what it passes into map_helper's f and lst, and it
Well, assembly is more like the Latin of the von Neumann architecture (and thus very important to learn), while a functional language like Haskell is more along the lines of the Latin of the mathematics of computation, and thus also important to learn.
Showing off your mastery of OCaml doesn't help anyone understand Haskell better
a) I switched to OCaml, because I am more familiar with it (and able to write proper code off the top of my head in it) and for an example like quicksort, it's very close to Haskell (without the list comprehensions). b) As for showing off my "mastery" of the language, as I pointed out, the definition of rec is in section 1.1 of the OCaml manual. It is the sixth line of OCaml code that someone looking in the manual would see. And if you care, here's quicksort in Haskell (from Haskell.org):
And basic programming in an imperative style requires that you document the names of your variables and choose meaningful namesYes. And I suppose I should have used lst or theList for l, head for h, and tail for t. But h, t, and l are so common in ML literature and code (much like i and j as throwaway loop counters, and foo, bar, and baz in pseudocode), that a brief amount of exposure to the language would make them instantly familiar. Besides, my use of less and greater didn't seem to help...
BTW: Imperative programming requires that? Since when? Why is it that Perl has its reputation for looking like line noise? Have you looked at the IOCCC entries lately? Crap variable names and lack of documentation are available in all languages...
In a programming language, "+" could be string concatenation, for example, so that "hello" + 3 yields "hello3".
Yeah, in a language with horrible typing properties, but that's a rant for a different time.
Yes, I'm sure it is, somewhere.
Yeah, right at the spot I linked to. In the OCaml manual, under the section that documents the List module.
Actually, the example I gave was straight from the (minimal) introduction to functional programming I got in school. Which re-enforces my point that functional programming isn't so simple, if I got it wrong.
So you got a minimal (and apparently pretty damn poor) education in recursion and FP, and you're using that experience to damn a whole class of programming languages? Does that really make sense to you?
My point was that recursion is usually more complicated than an imperative alternative.
And my point was that you pulled a contrived example of recursion out of a hat and used it to damn FP. As I said, that's akin to my using Duff's device or this example of printing some strings to damn C. The oddball cases don't tell you anything about the average ones...
Doesn't the recursive version need to put n -1 lists on the stack, (until it unwinds to the empty list), each of size one smaller? I get n-1(n-2)/2 space usage for an operation that should take 2*n space. Am I wrong? Is this a bad example?
Well, depending on how you implement it, yes. As a pure recursive process, it will consume linear space instead of constant space (in terms of stack frames). However, you can use an iterative (tail-recursive) process (with a recursive procedure) to use constant stack space. Ex:
Chinese teaches you about whatever dialect of Chinese you learned, and I believe a bit about Korean. Latin gives insight into French, Spanish, Italian, and a lot of English, plus a leg up in understanding legal terms, medical terminology, etc. (Although I'm sure some linguist could come around now and point out all of my errors...)
What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.
rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual). l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h. If you have trouble telling what a variable is, it's no wonder Haskell befuddled you (Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?"). By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.
Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.
Well that certainly depends on whether you mean recursive in the sense of the process or in the sense of the procedure (see SICP if you don't know the difference. The difference in performance between a for loop and something like:
Unless, of course we're talking about a memoized version. But if you want one, it's actually pretty damn easy to wrap a recursive function with a memoizing wrapper. By the way, do you really want to be talking about speed and efficiency in a thread about Perl?
Tree manipulation is generally a toy problem.
Tree manipulation is a toy problem? Last time I checked, trees (and heaps and treaps, and all sorts of other recursive data structures) are all over programming.
What's more, I can write recursive solutions in perl if I really have to.
And I can do imperative programming in OCaml if I really have to. Your point was what again?
We're programmers. We do need to understand that complex underbelly.
So you know all about the properties of the semiconductors making up your machine? You can tell me how to build a J/K filp-flop and a shift register? You know all about circuit layout optimization? The inner workings of a DVD burner? See, that's one of the nice things about programming. You only need to strip off a certain number of layers of abstraction to do your job well -- sometimes you need to go deeper, sometimes you don't need to go deep at all.
We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible.
And so you're advocating Perl?!? It's nigh impossible to reason at all about imperative programs and prove them correct, but when you've got a language that essentially encourages willy-nilly programming styles (yes, I know you can code clean Perl, but it takes a lot more effort than other languages) and highly mutable state like Perl than pretty much all hope i
Well I was complaining more about the horrible way of referencing the elements of the array. It's especially confusing when you learn that even though $tune[0] refers to the array @tune in some way, the variable $tune doesn't.