You're kidding, right? Haskell doesn't have the support base perl does.
And Latin doesn't have the support base Chinese does. Which is easier to learn? Which teaches you more about other languages?
Haskell sounded straightforward enough, but looks can be decieving. After writing my first program without a hitch, I spent several hours trying to code a simple proof-of-concept Sieve of Erostrathenes in Haskell, and kept getting a bizare "Unification would lead to Infinite Type" error.
Wow... what were you doing? Sieve in (idiomatic) Haskell:
Your "Gentle Introduction to Haskell" is anything but.
Well, I was referring to section 8.1 of the intro (on the IO monad), which is mostly straightforward in the way it presents IO -- it could easily be dumbed down a bit so you can say, "Here's how you do basic input and output. We'll teach you what's going on under the covers a little later when you learn a bit more about the language."
Haskell, like all functional languages, is based upon the assumption that recursion is a good thing. This assumption is nearly universally false.
Recursive algorithms are complex, and hard to understand and maintain
Really? This is hard to understand (in OCaml)?:
let rec quicksort l = match l with [] -> [] | h::t -> let less,greater = List.partition (fun x -> x < h) t in (quicksort less) @ [h] @ (quicksort greater);;
Compare that to the iterative solution and the recursive solution is much cleaner and more direct (And yes, I know that this solution is less efficient that an in-place modification version of the algorithm, so spare me that old sawhorse... If you want to do that style, you're perfectly free to). There are entire classes of problems like this that are more naturally solved in a recursive fashion, like working with trees. The definition of a binary tree in Haskell:
data BinaryTree a = Empty | Node a (BinaryTree a) (BinaryTree a) deriving Show
Care to show me how the iterative definition of a tree is more clear than that? Yeah, that's what I thought...
An entire branch of mathematics is based on simplifying recurrance relations into a simple, closed form solution
Yeah, and there are people that have spent their lives working on the essentially simple concept of factoring integers. Just because a concept has a deep, dark, complex underbelly doesn't mean that it doesn't have a very simple face that is all most people need to see.
I wouldn't expect that someone who lacks programming experience would have any useful basis for intuition.
Perhaps, and after *cough* many years mucking about with computers, I have a hard time putting myself in the shoes of a beginner. However, I could see someone thinking, "Well, I can put a string in an array, and a number in an array, hell, I can put 'em both in the same array. Well, let's stuff a couple of arrays in another array... what the? Why won't this work?"
There might be a good reason for it, but it just doesn't seem "natural". It's sort of like OCaml not letting you add ints and floats (which has a good reason, but it is usually a huge stumbling block for people new to the language).
Well, its possible he's talking about something like OCaml's hashtables, where you have to supply an initial size when you create it. Or he may even be talking about its strings and arrays, which require you to specify the size at creation time (unless you create one as an array/string literal, in which case the size is implicitly supplied).
You can agree or disagree with that decision, but until you understand context in Perl and its implications, Perl will continue to confuse you.
Um, yeah... but we're talking about Perl as a first language here, and the behavior pointed out above is hardly intuitive, and is likely to be a stumbling block for someone just learning how to program. Someone like that is far more likely to understand the concept of a nested list than that of an anonymous array or an array reference.
which is a bad thing, because it means that even their typos don't show up until it actually tries to run that part of the program. So they think they've succeeded, when really they still have a buggy mess.
Well that's not necessrily a compiled vs. interpreted issue. Give 'em an interactive REPL like with Haskell, OCaml, Lisp, Scheme, etc., and that will catch any of the errors that the compiler would catch -- without having to stop and recompile all of the time. Plus, you get type inferencing goodness with the languages like ML and Haskell which make bugs easier to spot, and essentially do away with the need for explicit type annotations.
the required variable prefixes clearly allow newbies to see what's a scalar, array, etc
Yeah, but that can be ugly and nonintuitive. For example, in the Perl Cookbook, one of the very first things one reads about arrays is:
So, given this list:
@tune = ( "The", "Star-Spangled", "Banner" );
"The" is in the first position, but you'd access it as $tune[0].
Woof... that is ugly to these eyes.
And then there's the horrific typing (or lack thereof) issues... Is it really sensible that "Hello" + 2 is a valid value? And is the behavior of something like (3+2) x 4 something that should be clear to a beginner?
Nah... give me something like Haskell as a beginning language. And before anyone starts screaming about monads or I/O, it's possible to introduce them in a gentile, sensible way.
Hmmm, let's see... someone publishes a review of a service I like that points out some very real flaws backed up with a good example of these flaws. How can I get back at him? I know! I'll call him a pompous jerk and make an irrelivant point about the accuracy of the encyclopedia he used to edit (without providing an actual example of it's problems). That'll get him! (and cet me modded up to boot!)
Of courrse you seemed to have missed the points he was trying to make to the folk like you. For example, if the EB did indeed have erronious information at one time, once that information reached a state of correctness, it stayed correct unlike the wikipedia, who's correctness may always be in a state of flux (as demonstrated by the Hamilton article he cited). Yes, the wikipedia may be a great resource in five or ten years, but given the way it currently works, it might be just as flawed as it is now.
a: I'm not too familiar with doing this inside of emacs, but when I ran a similar procedure from vim, it only ran through the compile phase once, not to fixpoint, so I had to run multiple times if there were, say, undefined references. iTeXMac does this for me (unless I hit Cmd-Alt-C or click on the big "C" at the top of the window, which only compiles once then displays the result), does your Meta-x compile method?
b: It's still (slightly) less efficient than the iTeXMac method, which is one keyboard chord, and completely contained within one app. Additionally if I need to run bibtex again for the current document, I hit Cmd-Alt-B (Then Cmd-Alt-T if I want to typeset the result). What do you have to do in emacs? And what if you have to switch back and forth between compiling a metpost document to generate an image for inclusion in your original document, and the original document? I'm guessing you really lose out on efficiency in a case like that.
c: That is, of course, using an application, and not doing the work at the command line, where you at best have the aid of history or makefiles to save you time.
d: This wasn't really meant to be a pissing contest for shaving keystrokes anyway. It was more to point out that there are some applications that are better suited to a GUI than a CLI (and not just things like Photoshop). For example, browsing web pages. Yes, we have things like links (which I use an awful lot, actually), but it is a complete pain in the ass to use it on pages with screenfuls of links on them and you need to navigate to say the 43rd out of 100 -- and how about if you wanted to email a picture from a web page to someone? Not so easy in links, with Safari and Mail, it's a simple drag operation. And what is the CLI equivalent of something like Quicksilver? I suppose you could whip up something similar using curses (shudders at the thought), but you'd need to keep an extra terminal window open or use screen for it.
If you use an application for a longer period the GUI gets in the way in the long run. That's when a good CLI (or macros or similar) is more effective than clicking and clicking and clicking...
And this all depends on the situation. Take something like iTeXMac. To compile a tex project with it, I hit Cmd-Alt-T. Much faster than switching to another terminal, typing pdflatex my_proj.tex, waiting for it to finish, typing pdflatex my_proj.tex again until it reaches its fixpoint, then refreshing my view of the resulting pdf.
Even if I whipped up a script or makefile, its still going to be faster as I can do everything from within the same app.
The command line has its uses, and GUIs have their uses. One is not strictly better than the other.
First reaction: Yech! Second reaction: Yeah... that's why I put the word most in my original post. Obviously there are domains where raw speed is paramount; and C and assembly will likely always rule those domains. However, we've reached a point were most apps that people interact with just don't need to go as fast as possible.
Speed is generally overrated these days -- most programs simply don't need to go 100% hammer-down.
But if you're still concerned about speed, you can always go with something like OCaml which is just a shade behind C in speed, yet offers you true type saefty, expressiveness, and flexibility all in one package.
There's been a lot of work done in programming languages over the years, and there are a lot of good languages out there to work with, despite what a glance at the sorely lacking O'Reilly catalog might say...
I think there's mountains enough of literature, on generic programming, to say nothing of implementations, without me having to justify why I want it.
Like I said above, that's fine. I find generics tend to lead to sloppier and more confusing code at the expense of saving a couple of keystrokes -- you like 'em for whatever reasons you like 'em for. As a wise man once sang, it takes diff'rent strokes to move the world...
Presumably in Ocaml, you'd override the sort method on a subclass. Seems I have to use objects to get pervasive polymorphism in Ocaml... something I wouldn't mind, but for the fact that objects come with their own strange set of type restrictions. It's like two languages fighting each other inside Ocaml -- I'd just like one of them to win at long last.
Well yes and no. You're still not getting ad hoc polymorphism. The sort function outlined in my earlier post is still parametric polymorphic with type
(< of_list : 'b list -> 'a; to_list : 'b list;.. > as 'a) -> 'a
But it feels more like the ad hoc polymorphism you're looking for... And like I said above, you can also do it with type constructors. For example:
type 'a sortable_container = Array of 'a array | List of 'a list | String of string;;
let sort cmp (c : 'a sortable_container) = match c with Array a -> Array.sort cmp a; Array a | List l -> List (List.sort cmp l) | String s -> failwith "Haven't implemented string sort yet...";;
let a = Array [| 10; 3; 5; 1; 4; 7|];; let l = List [ 10; 3; 5; 1; 4; 7];; let b = sort compare a;; let m = sort compare l;;
val a : int sortable_container = Array [|10; 3; 5; 1; 4; 7|] # val l : int sortable_container = List [10; 3; 5; 1; 4; 7] # val b : int sortable_container = Array [|1; 3; 4; 5; 7; 10|] # val m : int sortable_container = List [1; 3; 4; 5; 7; 10]
The big difference here is that you need to rewrite both the type sortable_container and the sort function every time you add a new sortable structure, whereas with the object approach you just need to be sure your structure has the appropriate methods.
Module functors are also supposed to address the issue, but I'm still searching for any documentation of how.
I'm not sure how functors would help you out here either (have you tried asking on the OCaml mailing list there are some serious OCaml gurus there). Functors are just modules parameterized over module types, so you could use one to build, say, a sortable data structure out of one that has no sort function yet, but is a subtype of some other module, but then you would have to do something like:
module SortableDS = Sorting(UnsortableDS);;
let sds = SortableDS.some_initialization_function;; let ssds = SortableDS.sort sds;;
So you're back to where you started with the Lists and Arrays (though this would allow you to standardize the interrface to the sort function). But again, if you really want to know the answer, ask on the OCaml mailing list.
I don't ask for Haskell type families and abstractions of lists all the way down to MonadPlus; I do ask that I can define a bloody "sort" function that can take anything that implements the collection with items that support comparison! Even C++ manages to do this.
While at first blush, that sounds like a good idea, from my viewpoint I don't really see how useful or wise that really is. First of all, you could do such a thing with a little bit of work by first wrapping at least the List and Array modules up as objects (something I believe has already been done and is available at the OCaml humps) -- I suppose you might want to do the String and Buffer modules as well, but none of the other standard modules make any sense in terms of sorting. Then you can just define
let sort o = o#sort
and be done with it. Now you can sort anything, so long as it's an object of type
< sort : 'a;.. > as 'a
Or perhaps it's even better to do something like
let sort (a : 'a) : 'a = let l = a#to_list in let l' = List.sort compare l in a#of_list l';;
Which would work on any object of type
< of_list : 'b list -> 'a; to_list : 'b list;.. > as 'a
It's not really what you're asking for, and of course you have to make all of your new data structures objects of the same type, but it's got the same flavor (you can also do a similar thing with type constructors and pattern matching, but it's just as much of a pain in the ass).
The biggest problem I see with a fully generic sort is that it really just doesn't make sense. Arrays and lists are not the same things. For one thing, lists are immutable structures, arrays are not -- therefore, if you define a fully generic sort that works on both arrays and lists, you are now kept from using methods that sort arrays in place (unless you're willing to do the horribly inefficient task of tearing down and rebuilding the list every time you want to modify a value to emulate sorting in place). So now you need to define two functions: one for sorting in place (which can only be used with certain classes of types) and one for sorting externally. And of course certain data structures are more efficient to sort using "method A" than others, blah, blah, blah... (DISCLAIMER: I am not Joe Type-theory, so there is likely a better line of reasoning behind this behavior of OCaml -- go ask someone like Xavier Leroy or Benjamin Pierce if you really care.)
All of this may still be possible to graft onto OCaml (see the work that was being done on GCaml, but I only see a small portion of that really being useful to me. Apparently YMDV, and that's cool...
I don't know... the OCaml code isn't much less elegant
let rec qsort l = match l with [] -> [] | h::t -> let lt,ge = List.partition ((>) h) t in (qsort lt) @ (h::(qsort ge));;
Disclaimer: Yes, we all know it's innefficient, and subject to pathalogical behavior, etc... Still, it's pretty and it gets the job done. Of course, in the real world, we'd use List.sort to sort our lists, or Array.sort (or Array.fast_sort) to sort our arrays.
Things I've found to be invaluable to the way I program:
Strong typing: Much like pig and elephant DNA just don't splice, one should not be allowed to add characters to integers then divide by floats and expect a sensible result.
Type inference: I want a language that can figure out what I'm doing without having to specify every last detail. And I want it to be able to tell me when I'm trying to splice said pig and elephant DNA.
Higer order/first class/anonymous functions: makes life and coding so much nicer.
Pattern matching: pretty and powerful.
An interactive environment: why should I have to compile my whole freaking program to test one little function?
Paradigm neutrality: if a problem is best solved with object, let me use objects. If an algorithm is most naturally expressed functionally, gimme that. If imperative code is what I need, let me use it. If I want to mix'n'match hand me the blender
Native and byte-code compilation: choose between speed and portability depending on your needs
Thank goodness there's OCaml there to provide all this for me in one happy little package...
Yeah, after all, Albuquerque/Rio Rancho is only home to an Intel plant, a Honeywell plant, Sandia National Laboratories, The Air Force Research Laboratory (aka Phillips Labs), EMCORE West, Eclipse Aviation, and an assload of other "high-tech" operations that I can't think of offhand.
And of course it was the original home of Microsoft...
So why would a backwater town like that get something like this?
I use NovaMind for the same type of work. Create a mind map or outline of a document, attach the LaTeX text to each of the branches, rearrange as I see fit, add or delete sections, whatever. And when I'm ready to go, export and compile.
Good stuff that NovaMind
Slashdot Mirror
And Latin doesn't have the support base Chinese does. Which is easier to learn? Which teaches you more about other languages?
Haskell sounded straightforward enough, but looks can be decieving. After writing my first program without a hitch, I spent several hours trying to code a simple proof-of-concept Sieve of Erostrathenes in Haskell, and kept getting a bizare "Unification would lead to Infinite Type" error.
Wow... what were you doing? Sieve in (idiomatic) Haskell:
Your "Gentle Introduction to Haskell" is anything but.
Well, I was referring to section 8.1 of the intro (on the IO monad), which is mostly straightforward in the way it presents IO -- it could easily be dumbed down a bit so you can say, "Here's how you do basic input and output. We'll teach you what's going on under the covers a little later when you learn a bit more about the language."
Haskell, like all functional languages, is based upon the assumption that recursion is a good thing. This assumption is nearly universally false.
Recursive algorithms are complex, and hard to understand and maintain
Really? This is hard to understand (in OCaml)?:
Compare that to the iterative solution and the recursive solution is much cleaner and more direct (And yes, I know that this solution is less efficient that an in-place modification version of the algorithm, so spare me that old sawhorse... If you want to do that style, you're perfectly free to). There are entire classes of problems like this that are more naturally solved in a recursive fashion, like working with trees. The definition of a binary tree in Haskell:Care to show me how the iterative definition of a tree is more clear than that? Yeah, that's what I thought...An entire branch of mathematics is based on simplifying recurrance relations into a simple, closed form solution
Yeah, and there are people that have spent their lives working on the essentially simple concept of factoring integers. Just because a concept has a deep, dark, complex underbelly doesn't mean that it doesn't have a very simple face that is all most people need to see.
Perhaps, and after *cough* many years mucking about with computers, I have a hard time putting myself in the shoes of a beginner. However, I could see someone thinking, "Well, I can put a string in an array, and a number in an array, hell, I can put 'em both in the same array. Well, let's stuff a couple of arrays in another array... what the? Why won't this work?"
There might be a good reason for it, but it just doesn't seem "natural". It's sort of like OCaml not letting you add ints and floats (which has a good reason, but it is usually a huge stumbling block for people new to the language).
Even so, it's hardly an issue...
Um, yeah... but we're talking about Perl as a first language here, and the behavior pointed out above is hardly intuitive, and is likely to be a stumbling block for someone just learning how to program. Someone like that is far more likely to understand the concept of a nested list than that of an anonymous array or an array reference.
which is a bad thing, because it means that even their typos don't show up until it actually tries to run that part of the program. So they think they've succeeded, when really they still have a buggy mess.
Well that's not necessrily a compiled vs. interpreted issue. Give 'em an interactive REPL like with Haskell, OCaml, Lisp, Scheme, etc., and that will catch any of the errors that the compiler would catch -- without having to stop and recompile all of the time. Plus, you get type inferencing goodness with the languages like ML and Haskell which make bugs easier to spot, and essentially do away with the need for explicit type annotations.
Yeah, but that can be ugly and nonintuitive. For example, in the Perl Cookbook, one of the very first things one reads about arrays is:
Woof... that is ugly to these eyes. And then there's the horrific typing (or lack thereof) issues... Is it really sensible that "Hello" + 2 is a valid value? And is the behavior of something like (3+2) x 4 something that should be clear to a beginner?
Nah... give me something like Haskell as a beginning language. And before anyone starts screaming about monads or I/O, it's possible to introduce them in a gentile, sensible way.
What's so strange about a closure?
Of courrse you seemed to have missed the points he was trying to make to the folk like you. For example, if the EB did indeed have erronious information at one time, once that information reached a state of correctness, it stayed correct unlike the wikipedia, who's correctness may always be in a state of flux (as demonstrated by the Hamilton article he cited). Yes, the wikipedia may be a great resource in five or ten years, but given the way it currently works, it might be just as flawed as it is now.
b: It's still (slightly) less efficient than the iTeXMac method, which is one keyboard chord, and completely contained within one app. Additionally if I need to run bibtex again for the current document, I hit Cmd-Alt-B (Then Cmd-Alt-T if I want to typeset the result). What do you have to do in emacs? And what if you have to switch back and forth between compiling a metpost document to generate an image for inclusion in your original document, and the original document? I'm guessing you really lose out on efficiency in a case like that.
c: That is, of course, using an application, and not doing the work at the command line, where you at best have the aid of history or makefiles to save you time.
d: This wasn't really meant to be a pissing contest for shaving keystrokes anyway. It was more to point out that there are some applications that are better suited to a GUI than a CLI (and not just things like Photoshop). For example, browsing web pages. Yes, we have things like links (which I use an awful lot, actually), but it is a complete pain in the ass to use it on pages with screenfuls of links on them and you need to navigate to say the 43rd out of 100 -- and how about if you wanted to email a picture from a web page to someone? Not so easy in links, with Safari and Mail, it's a simple drag operation. And what is the CLI equivalent of something like Quicksilver? I suppose you could whip up something similar using curses (shudders at the thought), but you'd need to keep an extra terminal window open or use screen for it.
And this all depends on the situation. Take something like iTeXMac. To compile a tex project with it, I hit Cmd-Alt-T. Much faster than switching to another terminal, typing pdflatex my_proj.tex, waiting for it to finish, typing pdflatex my_proj.tex again until it reaches its fixpoint, then refreshing my view of the resulting pdf.
Even if I whipped up a script or makefile, its still going to be faster as I can do everything from within the same app. The command line has its uses, and GUIs have their uses. One is not strictly better than the other.
Great. Now try querying google with: word count "os x". And tell me how easy it is compared to looking through the menus...
First reaction: Yech!
Second reaction: Yeah... that's why I put the word most in my original post. Obviously there are domains where raw speed is paramount; and C and assembly will likely always rule those domains. However, we've reached a point were most apps that people interact with just don't need to go as fast as possible.
But if you're still concerned about speed, you can always go with something like OCaml which is just a shade behind C in speed, yet offers you true type saefty, expressiveness, and flexibility all in one package.
There's been a lot of work done in programming languages over the years, and there are a lot of good languages out there to work with, despite what a glance at the sorely lacking O'Reilly catalog might say...
Like I said above, that's fine. I find generics tend to lead to sloppier and more confusing code at the expense of saving a couple of keystrokes -- you like 'em for whatever reasons you like 'em for. As a wise man once sang, it takes diff'rent strokes to move the world...
Presumably in Ocaml, you'd override the sort method on a subclass. Seems I have to use objects to get pervasive polymorphism in Ocaml ... something I wouldn't mind, but for the fact that objects come with their own strange set of type restrictions. It's like two languages fighting each other inside Ocaml -- I'd just like one of them to win at long last.
Well yes and no. You're still not getting ad hoc polymorphism. The sort function outlined in my earlier post is still parametric polymorphic with type
But it feels more like the ad hoc polymorphism you're looking for... And like I said above, you can also do it with type constructors. For example:The big difference here is that you need to rewrite both the type sortable_container and the sort function every time you add a new sortable structure, whereas with the object approach you just need to be sure your structure has the appropriate methods.Module functors are also supposed to address the issue, but I'm still searching for any documentation of how.
I'm not sure how functors would help you out here either (have you tried asking on the OCaml mailing list there are some serious OCaml gurus there). Functors are just modules parameterized over module types, so you could use one to build, say, a sortable data structure out of one that has no sort function yet, but is a subtype of some other module, but then you would have to do something like:
So you're back to where you started with the Lists and Arrays (though this would allow you to standardize the interrface to the sort function). But again, if you really want to know the answer, ask on the OCaml mailing list.While at first blush, that sounds like a good idea, from my viewpoint I don't really see how useful or wise that really is. First of all, you could do such a thing with a little bit of work by first wrapping at least the List and Array modules up as objects (something I believe has already been done and is available at the OCaml humps) -- I suppose you might want to do the String and Buffer modules as well, but none of the other standard modules make any sense in terms of sorting. Then you can just define
and be done with it. Now you can sort anything, so long as it's an object of type Or perhaps it's even better to do something likeWhich would work on any object of type It's not really what you're asking for, and of course you have to make all of your new data structures objects of the same type, but it's got the same flavor (you can also do a similar thing with type constructors and pattern matching, but it's just as much of a pain in the ass).The biggest problem I see with a fully generic sort is that it really just doesn't make sense. Arrays and lists are not the same things. For one thing, lists are immutable structures, arrays are not -- therefore, if you define a fully generic sort that works on both arrays and lists, you are now kept from using methods that sort arrays in place (unless you're willing to do the horribly inefficient task of tearing down and rebuilding the list every time you want to modify a value to emulate sorting in place). So now you need to define two functions: one for sorting in place (which can only be used with certain classes of types) and one for sorting externally. And of course certain data structures are more efficient to sort using "method A" than others, blah, blah, blah... (DISCLAIMER: I am not Joe Type-theory, so there is likely a better line of reasoning behind this behavior of OCaml -- go ask someone like Xavier Leroy or Benjamin Pierce if you really care.)
All of this may still be possible to graft onto OCaml (see the work that was being done on GCaml, but I only see a small portion of that really being useful to me. Apparently YMDV, and that's cool...
- Strong typing: Much like pig and elephant DNA just don't splice, one should not be allowed to add characters to integers then divide by floats and expect a sensible result.
- Type inference: I want a language that can figure out what I'm doing without having to specify every last detail. And I want it to be able to tell me when I'm trying to splice said pig and elephant DNA.
- Higer order/first class/anonymous functions: makes life and coding so much nicer.
- Pattern matching: pretty and powerful.
- An interactive environment: why should I have to compile my whole freaking program to test one little function?
- Paradigm neutrality: if a problem is best solved with object, let me use objects. If an algorithm is most naturally expressed functionally, gimme that. If imperative code is what I need, let me use it. If I want to mix'n'match hand me the blender
- Native and byte-code compilation: choose between speed and portability depending on your needs
Thank goodness there's OCaml there to provide all this for me in one happy little package...Yeah, after all, Albuquerque/Rio Rancho is only home to an Intel plant, a Honeywell plant, Sandia National Laboratories, The Air Force Research Laboratory (aka Phillips Labs), EMCORE West, Eclipse Aviation, and an assload of other "high-tech" operations that I can't think of offhand. And of course it was the original home of Microsoft... So why would a backwater town like that get something like this?
I use NovaMind for the same type of work. Create a mind map or outline of a document, attach the LaTeX text to each of the branches, rearrange as I see fit, add or delete sections, whatever. And when I'm ready to go, export and compile. Good stuff that NovaMind
Yep. He was a roommate of my old PhD advisor when he was at Berkeley.