Why Arc is bad for exploratory programming(arcfn.com)
arcfn.com
Why Arc is bad for exploratory programming
http://arcfn.com/2008/05/why-arc-is-bad-for-exploratory.html
14 comments
New code is extremely important, but if you're missing a key library - say, html parsing - a 10-second task can expand to take a day. That makes "exploratory programming" hard. You can have both a well-designed language and a great selection of libraries, in Python or Ruby.
Not that it's Arc's fault; Arc just isn't at the point in its lifecycle where the libraries are at Python level. It's more like Python 0.5. It's a good goal to have though.
Not that it's Arc's fault; Arc just isn't at the point in its lifecycle where the libraries are at Python level. It's more like Python 0.5. It's a good goal to have though.
86400 / 10 = 8640. You're telling me it's 8640x faster to use an HTML parsing library than building one from scratch? That's way overexaggerated, even for a big exaggeration.
You have to factor in the cost of finding the library, evaluating it (possibly rejecting it), reading its documentation (if it exists and is accurate and up-to-date), and living up with most of its warts because you can't be bothered to learn the innards of the library to make those few changes that would simplify your work. Or you could contact the maintainers and hope they will maybe honor your feature request/bugfix at some point. Libraries do have overhead.
edit: In the specific case of HTML parsing libraries those caveats probably don't really apply because it's a well-known problem with a well-known solution. But in the general case those are valid considerations.
You have to factor in the cost of finding the library, evaluating it (possibly rejecting it), reading its documentation (if it exists and is accurate and up-to-date), and living up with most of its warts because you can't be bothered to learn the innards of the library to make those few changes that would simplify your work. Or you could contact the maintainers and hope they will maybe honor your feature request/bugfix at some point. Libraries do have overhead.
edit: In the specific case of HTML parsing libraries those caveats probably don't really apply because it's a well-known problem with a well-known solution. But in the general case those are valid considerations.
I am not exaggerating.
There are many library functions that would take a day to write. If you need one, and you are missing it, then you will spend a day when you could spend 10 seconds. It's that simple.
There are many library functions that would take a day to write. If you need one, and you are missing it, then you will spend a day when you could spend 10 seconds. It's that simple.
In mature platforms most specific problems have official solutions either in the core libraries or in the extended standard library set (for java, which I currently use, that would be Sun + Apache).
Also from building a first draft (could take less than a day) to a professional solution you have to pass two big hurdles: feature set and performance. Each of them done properly can take easily more then a week.
I do like the idea of using the libraries of different platforms. Wrappers are much easy to write, and a mechanism for using java classes from arc/lisp would solve a world of problems. Unfortunately I can't imagine it being done without a big performance hit.
Also from building a first draft (could take less than a day) to a professional solution you have to pass two big hurdles: feature set and performance. Each of them done properly can take easily more then a week.
I do like the idea of using the libraries of different platforms. Wrappers are much easy to write, and a mechanism for using java classes from arc/lisp would solve a world of problems. Unfortunately I can't imagine it being done without a big performance hit.
[deleted]
"Edit: Another common thing about these discussions is otherwise intelligent people ignoring the fact that it is possible for a program written in one language to call a library written in another."
And this is a huge differentiator among languages.
Scala and Clojure have immediate access to the vast expanse of Java libraries. Python has a very good mechanism for wrapping and calling C/C++ libraries.
As far as I know, Arc does not yet particularly shine in this area, although I believe some arc hackers are working on it.
And this is a huge differentiator among languages.
Scala and Clojure have immediate access to the vast expanse of Java libraries. Python has a very good mechanism for wrapping and calling C/C++ libraries.
As far as I know, Arc does not yet particularly shine in this area, although I believe some arc hackers are working on it.
Glue! As perl was, so ruby is becoming (a nice glue.)
I like JRuby, cause it lets me use the gynormous amount of java libs in terse, "powerful", ruby without jumping through hoops.
Why are so many people afraid/resistant to this paradigm?
I like JRuby, cause it lets me use the gynormous amount of java libs in terse, "powerful", ruby without jumping through hoops.
Why are so many people afraid/resistant to this paradigm?
Speaking of, anybody has any practical experience with ABCL (Armed Bear Common Lisp)?
I'll paraphrase the argument as "Blub doesn't include an XML parser therefore Blub is rubbish."
Open source used to have a similar issue regarding Microsoft Word documents: "Open source operating systems were rubbish because there wasn't any software to read and write Word documents." Now that such functionality is available, the argument moves to another feature such as boot time or support for native applications.
Let's imagine that we have an open source operating system that runs all games, boots in 10 seconds, works with 6000 random devices and comes installed with a terse language which fetches web pages, parses XML, talks to 20 databases and Java applications. How much of this functionality will be of any consequence in 10 years?
Open source used to have a similar issue regarding Microsoft Word documents: "Open source operating systems were rubbish because there wasn't any software to read and write Word documents." Now that such functionality is available, the argument moves to another feature such as boot time or support for native applications.
Let's imagine that we have an open source operating system that runs all games, boots in 10 seconds, works with 6000 random devices and comes installed with a terse language which fetches web pages, parses XML, talks to 20 databases and Java applications. How much of this functionality will be of any consequence in 10 years?
I think your paraphrasing is incomplete. It would be truer to the op's point to say, "Blub does not include an XML parser, therefore Blub is rubbish for exploratory programming with XML documents."
Obviously what I meant is that the core language is tuned for exploratory programming.
Also, I disagree with his criteria. Speed isn't really important for it. And dynamic typing, which he omits, is very important.
Also, I disagree with his criteria. Speed isn't really important for it. And dynamic typing, which he omits, is very important.
Why is dynamic typing important?
I had an enjoyable time prototyping optimization heuristics in OCaml, where Arc would have been completely inadequate because it lacks floating point speed.
I had an enjoyable time prototyping optimization heuristics in OCaml, where Arc would have been completely inadequate because it lacks floating point speed.
It's more that "latent" typing (types do not appear in source code) and "structural" typing (types are determined by their structures, not by their names) are very important. Haskell and Ocaml fit both criteria, despite being strongly statically typed.
The reason for both is that you don't know the data types you'll be using when you start programming. It's very common to switch from a string to a hash to a structured record to an ADT, and if you have to change type declarations in every place that datum is passed to, you'll be spending most of your time changing type declarations.
The reason for both is that you don't know the data types you'll be using when you start programming. It's very common to switch from a string to a hash to a structured record to an ADT, and if you have to change type declarations in every place that datum is passed to, you'll be spending most of your time changing type declarations.
it lacks floating point speed
How much slower are floating point operation in Arc than OCaml?
How much slower are floating point operation in Arc than OCaml?
Have a look at http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... - instead of twiddling your thumbs for 20 seconds the way I did, you go and get a cup of coffee or check email/blogs or something else that takes your mind off the task at hand.
The reason I mention this niche (where C libraries you could call do you little or no good) is because things like optimization heuristics and machine learning are the most common form of exploratory computing and programming I know of. The biggest symptom of this is that there are dozens of "machine learning" toolkits, environments, libraries, etc all intended to provide a situation that frees you from worrying about extraneous details (like how to get data out of crappy HTML in order to do some kind of data analysis project), but a lot of people just code everything from scratch in vanilla Java/C/Python/whatever.
The way I write programs, generally, is I do the simplest possible test that still embodies the essential idea behind what I want to do and grow it from there. Thus a language supporting that has to be flexible, and I don't see why dynamic typing is necessary or sufficient for that.
The type system has little or nothing to do with also supporting essential features that support the way I think: closures, combinators, metaprogramming, and other things that often make life a lot easier.
The reason I mention this niche (where C libraries you could call do you little or no good) is because things like optimization heuristics and machine learning are the most common form of exploratory computing and programming I know of. The biggest symptom of this is that there are dozens of "machine learning" toolkits, environments, libraries, etc all intended to provide a situation that frees you from worrying about extraneous details (like how to get data out of crappy HTML in order to do some kind of data analysis project), but a lot of people just code everything from scratch in vanilla Java/C/Python/whatever.
The way I write programs, generally, is I do the simplest possible test that still embodies the essential idea behind what I want to do and grow it from there. Thus a language supporting that has to be flexible, and I don't see why dynamic typing is necessary or sufficient for that.
The type system has little or nothing to do with also supporting essential features that support the way I think: closures, combinators, metaprogramming, and other things that often make life a lot easier.
Arc has a lot of bottlenecks when speed matters, but I never felt floats were one of them...
Surely whether speed is important depends on what corner of program space you happen to be exploring?
Why is speed not important?
Edit: How is speed not important?
Edit: How is speed not important?
There is people working on having an arc-2-c translation, which I guess would bring the speed you are craving for ;)
See http://arclanguage.org/item?id=6605
See http://arclanguage.org/item?id=6605
the article itself points out Python isn't that fast either
i can only see speed being an issue in these heavy data type things, for which you should probably be using an APL language (as they are quite exploratory-friendly -- and fast -- for these types of problems)
i've been using Arc for a while and the speed has never been an issue. most of your time developing a program is spent writing it, not watching it run. about the only thing that annoys me is that it currently requires mzscheme
i can only see speed being an issue in these heavy data type things, for which you should probably be using an APL language (as they are quite exploratory-friendly -- and fast -- for these types of problems)
i've been using Arc for a while and the speed has never been an issue. most of your time developing a program is spent writing it, not watching it run. about the only thing that annoys me is that it currently requires mzscheme
"most of your time developing a program is spent writing it, not watching it run."
This totally depends on the kind of program you are writing.
I just completed a class on Information Retrieval, the exact same kind of tasks and algorithms in the Collecting Intelligence books. One assignment, I spent most of the time allocated trying to get the program reasonably fast enough in Python to finish in less than a day. If a mistake was not apparent until the program had run for a couple of hours, it totally killed all of the exploratory programming advantages that Python has.
I finally gave up and rewrote the entire thing in Java a day before the assignment was due. I got my algorithm to converge in under 2 hours (had left the Python version running much longer with than this with no converging in sight), and was able to get some decent results to turn in.
Maybe I'm just greedy. I want it all. Speed, exploratory programming, lots of libraries. Common Lisp offers the first two, the last, not so much. Java offers 1 and 3, Python 2 and 3.
My next languages to learn are Scala and/or Clojure. Potentially the speed and libraries of Java, with many of the features that make Common Lisp and Python great at exploratory programming.
I do not see Arc on a path that will give it all 3 of these attributes in the foreseeable future.
This totally depends on the kind of program you are writing.
I just completed a class on Information Retrieval, the exact same kind of tasks and algorithms in the Collecting Intelligence books. One assignment, I spent most of the time allocated trying to get the program reasonably fast enough in Python to finish in less than a day. If a mistake was not apparent until the program had run for a couple of hours, it totally killed all of the exploratory programming advantages that Python has.
I finally gave up and rewrote the entire thing in Java a day before the assignment was due. I got my algorithm to converge in under 2 hours (had left the Python version running much longer with than this with no converging in sight), and was able to get some decent results to turn in.
Maybe I'm just greedy. I want it all. Speed, exploratory programming, lots of libraries. Common Lisp offers the first two, the last, not so much. Java offers 1 and 3, Python 2 and 3.
My next languages to learn are Scala and/or Clojure. Potentially the speed and libraries of Java, with many of the features that make Common Lisp and Python great at exploratory programming.
I do not see Arc on a path that will give it all 3 of these attributes in the foreseeable future.
[deleted]
Why isn't the shirt I'm wearing blue?
Well you can always connect a false statement to another simpler false statement to make your idea easier to understand. Or you can show how if something were true, it would contradict with some obvious truth, and so on. This is not a cause, but it helps for your argument.
Otherwise, we could all go pointing random ideas as false, anyway we haven't to explain why they are false, couldn't we?
Edit: also, maybe you don't like blue after all :)
Otherwise, we could all go pointing random ideas as false, anyway we haven't to explain why they are false, couldn't we?
Edit: also, maybe you don't like blue after all :)
Try to honestly answer the question: "Why is the color of the programmer's shirt not important for his productivity?"
It's hard, because it _could_ be. The only way to properly answer is to take a random sample of programmers and show that there is no statistical difference.
This doesn't say anything about weather speed is important or not, of course. But it does give an idea that statistics (or practical experience) might be involved. Just remember, random sample = good, anecdotal evidence = bad.
It's hard, because it _could_ be. The only way to properly answer is to take a random sample of programmers and show that there is no statistical difference.
This doesn't say anything about weather speed is important or not, of course. But it does give an idea that statistics (or practical experience) might be involved. Just remember, random sample = good, anecdotal evidence = bad.
I don't see how this relates to the original argument. It doesn't help explain you can or can't say why something isn't true. And anyway, it wouldn't be easier to respond "why is the color of the programmer's shirt important ...?" than its negation.
I think that's kindof the point... it's easier to ask the affirmative form then the negative, ie it's easier to prove then disprove.
Anyways, this meta-discussion has gone long enough anyways. I'm having too hard a time following it. Can't we go back arc and exploratory languages, please? :)
Anyways, this meta-discussion has gone long enough anyways. I'm having too hard a time following it. Can't we go back arc and exploratory languages, please? :)
You are right, we are very off topic now :) back to Arc.
The point is, there's never an explanation for why something isn't true.
I don't agree. You can explain why something is true, right? (at least in some cases, not for all cases, you know, Gödel and all that). In such cases you can actually explain, it follows that if X is true, !X isn't true, and you have an obvious explaination for that.
Example: why is my shirt red? Because I only have red shirts on my house. Why isn't my shirt blue? Please refer to the previous explaination of why it's red, then it follows it can't be at the same time red and blue, etc etc.
And it's great it's like this, because otherwise we could be saying a lot of random predicates are false and no one could argue with us. So I think asking someone "why x is false" isn't illogical, after all if there is a reason to say "x is false", surely there is a way to prove it's false indeed.
Edit: part of the problem with this discussion, of course, is that there is not a fixed meaning for "why". "Why" is a very ambiguous question, it doesn't specify whether we want to know the intention, the proof, the cause, etc. And even, what is a cause? If you are talking about historic events indeed you can't explain why X didn't happen, but from the same pov you couldn't ever explain why Y did happen at all, if you see history as something deterministic & linear. So whether you're right or wrong actually depends on what you see on the word why...
Example: why is my shirt red? Because I only have red shirts on my house. Why isn't my shirt blue? Please refer to the previous explaination of why it's red, then it follows it can't be at the same time red and blue, etc etc.
And it's great it's like this, because otherwise we could be saying a lot of random predicates are false and no one could argue with us. So I think asking someone "why x is false" isn't illogical, after all if there is a reason to say "x is false", surely there is a way to prove it's false indeed.
Edit: part of the problem with this discussion, of course, is that there is not a fixed meaning for "why". "Why" is a very ambiguous question, it doesn't specify whether we want to know the intention, the proof, the cause, etc. And even, what is a cause? If you are talking about historic events indeed you can't explain why X didn't happen, but from the same pov you couldn't ever explain why Y did happen at all, if you see history as something deterministic & linear. So whether you're right or wrong actually depends on what you see on the word why...
My thesis for this essay is that the Great Gatsby is not an allegory for animal beastiality. First of all, Gatsby contains no animal characters. Because of this, the likelihood that F. Scott Fitzgerald's work was a veiled reference to man-on-animal love is very low. Second, there is no evidence than any of the characters are attracted to animals. While Gatsby does have an attraction to Daisy, there is nothing in the text to indicate that her character metaphorically embodies animalistic qualities. In conclusion, there is no possible way that the Great Gatsby represents an attempt to introduce zoophilia to mainstream American society. After examining all of the evidence one can clearly see that this simply cannot be the case.
I disagree.
First of all, Gatsby contains no animal characters.
The Great Gatsby contains two dogs and a cat. While none are given names, one of the dogs (an Airedale bought by Myrtle Wilson) appears several times and has some identifiable characteristics.
Second, there is no evidence than any of the characters are attracted to animals.
In fact, it contains this scene:
"She looked at me and laughed pointlessly. Then she flounced over to the dog, kissed it with ecstasy and swept into the kitchen, implying that a dozen chefs awaited her orders there."
In conclusion, although bestiality is not one of the novel's primary themes, there is evidence that at least one character makes out with a dog at some point.
Please note: the only reason I have time to go and grep -iw gatsby.txt for "dog" is that I'm waiting for the program I'm writing to finish executing. This is why speed is important in exploratory programming.
First of all, Gatsby contains no animal characters.
The Great Gatsby contains two dogs and a cat. While none are given names, one of the dogs (an Airedale bought by Myrtle Wilson) appears several times and has some identifiable characteristics.
Second, there is no evidence than any of the characters are attracted to animals.
In fact, it contains this scene:
"She looked at me and laughed pointlessly. Then she flounced over to the dog, kissed it with ecstasy and swept into the kitchen, implying that a dozen chefs awaited her orders there."
In conclusion, although bestiality is not one of the novel's primary themes, there is evidence that at least one character makes out with a dog at some point.
Please note: the only reason I have time to go and grep -iw gatsby.txt for "dog" is that I'm waiting for the program I'm writing to finish executing. This is why speed is important in exploratory programming.
I don't understand this argument. When someone says "Why don't you... X?" are you going to enumerate all the things you'd rather do than X, and then explain that the effort involved in doing those things precludes X? Or are you just going to say "That's a stupid question. Tell me why I should."
Well, enumerating a finite list of things is not something you wouldn't do in a math proof. Now if I say: X="primes are all multiples of three", "why isn't X true?", there are many obvious answers to that. For starters, because there's at least an element of primes (7), that is not a multiple of three.
That should be enough to disprove: "there's never an explanation for why something isn't true", and that's the point. I would have preferred a simple explaination of why PG thinks X isn't true than the assertion that such a thing can't be explained (actually I suspect he was being humourous or something like that, obviously he has to have a reason to think like he thinks).
Also, you can always reply: "because I don't want to!", or "because I have other things to do", or "because I don't see a reason to" (it's like asking "why should I..?"), to "why don't you ... X?" :)
That should be enough to disprove: "there's never an explanation for why something isn't true", and that's the point. I would have preferred a simple explaination of why PG thinks X isn't true than the assertion that such a thing can't be explained (actually I suspect he was being humourous or something like that, obviously he has to have a reason to think like he thinks).
Also, you can always reply: "because I don't want to!", or "because I have other things to do", or "because I don't see a reason to" (it's like asking "why should I..?"), to "why don't you ... X?" :)
You can sometimes prove that something is not the case, but you can't explain why it is not the case.
E.g. it's fairly easy to prove that Boston is not in Oklahoma, but there's no explanation for why it's not.
E.g. it's fairly easy to prove that Boston is not in Oklahoma, but there's no explanation for why it's not.
I agree that "why is Boston not in Oklahoma?" is a question without a sensible answer, but that has nothing to do with the fact that it is of the form "why does X not have property Y?" You will notice that "Why is Boston in Massachussetts?" is not a question with a sensible answer either.
Similarly, "why is your shirt not blue" is a silly question, unless there's any reason to suppose that it might be. For instance, if you show up to my "blue shirts only" party wearing a non-blue shirt, it's a perfectly valid question.
Now, as for questions about "Why is X not important for Y?", these can have sensible answers. Why is aerodynamics not important for a lunar lander? Because it never flies through air. Why is peanut butter not important for a lunar lander? Now that is a silly question, because nobody would suppose it might be.
So a question like "Why is speed not important in exploratory programming?" should really have a sensible answer. You could, for instance, say something like "Because in exploratory programming you typically only need to run short tests which don't take a lot of time anyway". To which I'd reply "Oh, I don't know about that, I typically run tests which take quite a long time". To which you could say "Oh, well I'm sure there are some cases where it is, but for most people most of the time it isn't". And I'd say "Yes, I agree with that statement".
Similarly, "why is your shirt not blue" is a silly question, unless there's any reason to suppose that it might be. For instance, if you show up to my "blue shirts only" party wearing a non-blue shirt, it's a perfectly valid question.
Now, as for questions about "Why is X not important for Y?", these can have sensible answers. Why is aerodynamics not important for a lunar lander? Because it never flies through air. Why is peanut butter not important for a lunar lander? Now that is a silly question, because nobody would suppose it might be.
So a question like "Why is speed not important in exploratory programming?" should really have a sensible answer. You could, for instance, say something like "Because in exploratory programming you typically only need to run short tests which don't take a lot of time anyway". To which I'd reply "Oh, I don't know about that, I typically run tests which take quite a long time". To which you could say "Oh, well I'm sure there are some cases where it is, but for most people most of the time it isn't". And I'd say "Yes, I agree with that statement".
No, there's really no answer to the question of why aerodynamics isn't important for a lunar lander.
The answer you give to that, as you imply in a later paragraph, is really an answer to the question "if a typical person thought aerodynamics was important for a lunar lander, why would they be mistaken?" It's fairly easy to answer that, at least with respect to our peers; we're used to vehicles designed with wind resistance in mind. But this is not the answer to the question of why it's not the case that aerodynamics is necessary for a lunar lander.
Similarly, though there is no answer to the question of why it's not the case that speed is necessary in exploratory programming, I could, if I knew why the OP mistakenly thought it was, have explained why he was wrong. But while I could guess why one of my peers might mistakenly think aerodynamics mattered for a lunar lander, I have no idea why the OP might think speed mattered for exploratory programming.
Sigh. What a huge waste of time this thread has been. I feel like I've just spent an hour trying to convince someone that the Monte Carlo fallacy was false.
The answer you give to that, as you imply in a later paragraph, is really an answer to the question "if a typical person thought aerodynamics was important for a lunar lander, why would they be mistaken?" It's fairly easy to answer that, at least with respect to our peers; we're used to vehicles designed with wind resistance in mind. But this is not the answer to the question of why it's not the case that aerodynamics is necessary for a lunar lander.
Similarly, though there is no answer to the question of why it's not the case that speed is necessary in exploratory programming, I could, if I knew why the OP mistakenly thought it was, have explained why he was wrong. But while I could guess why one of my peers might mistakenly think aerodynamics mattered for a lunar lander, I have no idea why the OP might think speed mattered for exploratory programming.
Sigh. What a huge waste of time this thread has been. I feel like I've just spent an hour trying to convince someone that the Monte Carlo fallacy was false.
OK, I accept that if we're going to be pedantic (and honestly, being pedantic is one of my favourite hobbies too) then the question would really be "if a typical person thought aerodynamics was important for a lunar lander, why would they be mistaken?"
In fact, one could clarify the question a little for the benefit of somebody who couldn't see why anybody would be so confused as to think that aerodynamics had anything to do with the moon, by saying: "Given that aerodynamics are important for many [though not all] vehicles, what properties of a lunar lander distinguishes it from those other vehicles in such a way as to make aerodynamics irrelevant?"
So ahem, bearing that in mind, given that speed is important in many [though not all] programming tasks, what properties distinguish exploratory programming from those other types of programming in such a way as to make speed irrelevant?
In fact, one could clarify the question a little for the benefit of somebody who couldn't see why anybody would be so confused as to think that aerodynamics had anything to do with the moon, by saying: "Given that aerodynamics are important for many [though not all] vehicles, what properties of a lunar lander distinguishes it from those other vehicles in such a way as to make aerodynamics irrelevant?"
So ahem, bearing that in mind, given that speed is important in many [though not all] programming tasks, what properties distinguish exploratory programming from those other types of programming in such a way as to make speed irrelevant?
I'm not convinced yet, but I don't want to make this argument longer. It wasn't my intention to make you or anybody lose time (sorry if I did, truly!), I just thought you were pointing something that failed to be true and that I could correct you in a friendly manneer. Your comment is interesting and I'll think about it, but as far as I could see it seems to work only in particular cases and not in all negative cases, as you had pointed before. But I need to think more about it to be sure. Thanks for your time and for your explainations.
Why isn't the Monte Carlo fallacy true?
;~)
;~)
Once, in college, I visited one of my professors and his wife. In the middle of a conversation the wife asked, "Why isn't this ink refill small enough to fit in this pen?" His answer was an amused, "What kind of existential question is that?"
This may be true of facts, but there is no problem with explaining why your opinion is one way and not the other.
Unless you are asserting that speed not being important is a fact of exploratory programming, rather than PG's opinion, I see no problem with answering my initial question.
If it makes you feel better though, I can rephrase:
Why is speed not important to you, PG?
Unless you are asserting that speed not being important is a fact of exploratory programming, rather than PG's opinion, I see no problem with answering my initial question.
If it makes you feel better though, I can rephrase:
Why is speed not important to you, PG?
There's still no answer to that question. If I needed speed, I could explain why. But there's no answer to the question of why you don't need speed.
I need a bottle opener to get the lid off a bottle. I need it because I need to bend the lid. I don't need a scarf to get the lid off a bottle. Why not? There's no reason you don't need a scarf to get the lid off a bottle; it's just not that useful.
I need a bottle opener to get the lid off a bottle. I need it because I need to bend the lid. I don't need a scarf to get the lid off a bottle. Why not? There's no reason you don't need a scarf to get the lid off a bottle; it's just not that useful.
Fair enough. I see your point and thank you for your patience.
If I may give this one last shot:
Why is slowness acceptable in a language tuned towards exploratory programming, and therefore an unimportant criteria when judging Arc?
If I may give this one last shot:
Why is slowness acceptable in a language tuned towards exploratory programming, and therefore an unimportant criteria when judging Arc?
This is semantics, it depends on what meaning you give the word "why"... you are talking about why as in causes here, but I don't think that was what you were asked about when somebody said "why isn't speed important?"
"Boston is not in Oklahoma because it's in Massachusetts, and Oklahoma and Massachusetts are two separate states and no city can belong to two states at once (afaik)." Doesn't that sound like an explaination?
Now, an explaination of "why isn't speed important", could be, for example, that it's not important because it doesn't affect your final productivity at all, or at least not in a considerable way compared to some N other factors.
Now, what's the cause of such a difference in the final users' productivity, maybe that can't be answered. But I don't think you were asked about it.
Sorry for wasting your time with this discussion, but I don't really see your point. Maybe I'm wrong after all but until now I don't see how that could be.
"Boston is not in Oklahoma because it's in Massachusetts, and Oklahoma and Massachusetts are two separate states and no city can belong to two states at once (afaik)." Doesn't that sound like an explaination?
Now, an explaination of "why isn't speed important", could be, for example, that it's not important because it doesn't affect your final productivity at all, or at least not in a considerable way compared to some N other factors.
Now, what's the cause of such a difference in the final users' productivity, maybe that can't be answered. But I don't think you were asked about it.
Sorry for wasting your time with this discussion, but I don't really see your point. Maybe I'm wrong after all but until now I don't see how that could be.
As far as I can tell, the problem here is to some degree one of conflicting generalisations. The article is trying to explore a different space to the space for which Arc was designed to be used for exploring.
Just like flippers, scuba gear, and a diving mask might be suboptimal for exploring a jungle or the moon, but great for exploring underwater, choosing an appropriate environment for the space you want to explore is something worth thinking about.
Just like flippers, scuba gear, and a diving mask might be suboptimal for exploring a jungle or the moon, but great for exploring underwater, choosing an appropriate environment for the space you want to explore is something worth thinking about.
I am not very deep into it yet, but my impression is that it is often surprisingly simple to provide lacking libraries for LISP.
As an example, this is an interface to the Cairo graphics library for MzScheme: http://planet.plt-scheme.org/package-source/samth/cairo.plt/...
I haven't tried it out yet, but I sure had expected a lot more code. Now that is just a connector to an existing C library, but in other cases I was also surprised by the brevity of the code.
Actually I was surprised by the brevity of the code in "Programming Collective Intelligence", too. For the time being, I consider that kind of stuff part of my fun projects, so I decided to do them in Scheme. The upside is that if a library is missing, you get a chance to actually provide it yourself and make a name for yourself in the Open Source world.
Also, I like implementing those algorithms. With another language, there might not be an excuse for implementing the algorithms from the book by yourself, because libraries already exists. With Scheme, I have a justification to implement them myself.
Interfaces to web services might also not be so important, and easy to implement by yourself.
As an example, this is an interface to the Cairo graphics library for MzScheme: http://planet.plt-scheme.org/package-source/samth/cairo.plt/...
I haven't tried it out yet, but I sure had expected a lot more code. Now that is just a connector to an existing C library, but in other cases I was also surprised by the brevity of the code.
Actually I was surprised by the brevity of the code in "Programming Collective Intelligence", too. For the time being, I consider that kind of stuff part of my fun projects, so I decided to do them in Scheme. The upside is that if a library is missing, you get a chance to actually provide it yourself and make a name for yourself in the Open Source world.
Also, I like implementing those algorithms. With another language, there might not be an excuse for implementing the algorithms from the book by yourself, because libraries already exists. With Scheme, I have a justification to implement them myself.
Interfaces to web services might also not be so important, and easy to implement by yourself.
It's not always about algorithms. If you need, say, something that can parse rfc 822 messages, you have to read the rfc, implement it, find out which applications you need to talk to have implemented it incorrectly, and then work around those bugs. Even if you could write the implementation in 2 minutes, you've still got a time consuming task on your hands. Worse, you will probably need to implement more than one library for a medium sized application if you're using an unpopular language, so multipy the time it takes to finish the task above by x.
Sure, but somebody has to make a start, or we will be stuck with Java forever. Maybe you can often use libraries from other languages, too, as in the example of the Cairo lib.
>Sure, but somebody has to make a start, or we will be stuck with Java forever.
True. It's just better to go into it with open eyes.
> Maybe you can often use libraries from other languages, too, as in the example of the Cairo
That helps, but it's still a time consuming task to understand a standard and a C (or whatever) API, design your own API in the 100 year language of your choice, and implement it (and document it if you're really being good). I spent a fair amount binding C libraries for Chicken Scheme (which has a good C FFI) and Scheme48, so I know this from experience.
True. It's just better to go into it with open eyes.
> Maybe you can often use libraries from other languages, too, as in the example of the Cairo
That helps, but it's still a time consuming task to understand a standard and a C (or whatever) API, design your own API in the 100 year language of your choice, and implement it (and document it if you're really being good). I spent a fair amount binding C libraries for Chicken Scheme (which has a good C FFI) and Scheme48, so I know this from experience.
"or we will be stuck with Java forever"
The Scala/Clojure approach makes this a blessing, rather than a curse.
Interesting language, with all the benefits of the JVM and Java libraries. (Which is why these languages are next on my list of languages to learn.)
The Scala/Clojure approach makes this a blessing, rather than a curse.
Interesting language, with all the benefits of the JVM and Java libraries. (Which is why these languages are next on my list of languages to learn.)
I guess the title "Arc could use more libraries" isn't as attention-getting as "Why Arc is bad for exploratory programming."
If arc could seamlessly access PLT scheme's libraries that would be a good start. I know from first hand experience that there are a number of ways to access PLT scheme from arkani and arc. But, there are two big issues. First there are type differences between fundamental types (lists gah). This means there can be a lot of work to convert between PLT scheme and arc, not impossible but time consuming. Secondly, there is no nice way to pull in a PLT library and just use it in arc. Of course this could be implemented - it's just not there yet.
There are two choices I see going forward immediately. Arc and the arc community starts implementing their own libraries or we find a way to use PLT scheme's libraries (ok maybe sbcl if you are using arkani).
There are two choices I see going forward immediately. Arc and the arc community starts implementing their own libraries or we find a way to use PLT scheme's libraries (ok maybe sbcl if you are using arkani).
Arc is inexplicably lacking trig, exp, and log
Okay, I haven't used Arc in a while -- existing Scheme codebase -- but Arc is built on PLT, which is compliant with R5RS, which does include basic math functions:
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/r5rs-9.html
(search for sin, cos, etc).
Did Arc forget how to talk to the numerics library? Rebind "cos" "sin" and "exp"? Is this guy just being stupid?
'splain me please.
Okay, I haven't used Arc in a while -- existing Scheme codebase -- but Arc is built on PLT, which is compliant with R5RS, which does include basic math functions:
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/r5rs-9.html
(search for sin, cos, etc).
Did Arc forget how to talk to the numerics library? Rebind "cos" "sin" and "exp"? Is this guy just being stupid?
'splain me please.
I think it might help to have an official statement, like, "We plan to add all these libraries, in time. You can help somehow." One issue in the Arc community is there's no clear way to contribute. A lot of this angst about lacking libraries could be turned into a polite suggestion to help build the language.
Perhaps there should be AEP = Arc Enhancement Proposals a la Python's PEPs.
Perhaps there should be AEP = Arc Enhancement Proposals a la Python's PEPs.
What's the status of Arc?
Interest on arclanguage.org seems to be fading.
Interest on arclanguage.org seems to be fading.
You mean, pg's interest ? Sure, he doesn't seem to be very involved anymore... :)
What do you mean by "status?"
I don't know precisely what the grandparent was asking, but many of us are curious about two things. First, when the next release will happen, since the previous release was 80 days ago. Second, what new features/functions/libraries are being added to the language; presumably some of the things from your poll at http://arclanguage.org/item?id=4070
In "Being Popular" you mention that the Dream Language has a "thin" manual with "lots of good examples to learn from." Can we look forward to a book on Arc?
>Arc is unfinished. It's missing things you'd need to solve some types of problems. But it works well for basic web apps.
Throwing together a bunch of libraries and gluing them together with "surprisingly few" lines of Python code isn't exploratory programming.
It's hardly programming at all.
It's hardly programming at all.
what's being explored? is c++ better than arc for this "exploring" ... it has more libraries ;)
i wonder why people are not writing more apps in arc. there seems to be a lot of activity porting it to different environemnts, writing compilers, optimizers, creating a repository .... but no app. (other than hacker news)
i wonder why people are not writing more apps in arc. there seems to be a lot of activity porting it to different environemnts, writing compilers, optimizers, creating a repository .... but no app. (other than hacker news)
I've used Arc professionally twice. Once as a web interface to an rsync system (http://my-arc-stuff.blogspot.com/2008/02/i-needed-web-app-fo...), the other one as a database for our local library (basic stuff : which book do we own, who borrowed it, ...)
These are real apps. I must admit Arc is really great (even as it is now) for these small, basic but usually time-consuming webapps. It doesn't prevent me for writing a compiler for Arc :) (which is itself written in Arc and is actually the biggest piece of code I've written in this language).
These are real apps. I must admit Arc is really great (even as it is now) for these small, basic but usually time-consuming webapps. It doesn't prevent me for writing a compiler for Arc :) (which is itself written in Arc and is actually the biggest piece of code I've written in this language).
Enhancing Arc is fun, writing practical apps in it is not. Open source developers go where the fun is.
As for your next question ("Why is enhancing Arc fun?"), it's because Arc provides many tools for manipulating Arc code (macros, code-is-data), and few tools for writing applications (libraries). The implementation is also fairly simple, vs. trying to hack on Java or Python or C++ compilers. Path of most impressiveness per unit effort seems to go through porting it to another language, rather than writing another webapp that'd be more impressive if done in Rails or Django.
As for your next question ("Why is enhancing Arc fun?"), it's because Arc provides many tools for manipulating Arc code (macros, code-is-data), and few tools for writing applications (libraries). The implementation is also fairly simple, vs. trying to hack on Java or Python or C++ compilers. Path of most impressiveness per unit effort seems to go through porting it to another language, rather than writing another webapp that'd be more impressive if done in Rails or Django.
Apps take time. IIRC, for a long time the big Python applications were Grim Fandango and some research software at LLNL.
Actually, large chunks of Grim Fandango were written in Lua.
http://www.grimfandango.net/?page=articles&pagenumber=2
http://www.grimfandango.net/?page=articles&pagenumber=2
You're absolutely correct... I'd somehow conflated the two in my mind. I guess the first big Python game was actually Eve Online. I can't recall any big, early Python applications outside of the LLNL work... which, I suppose, says even more about applications being a poor indicator of early language uptake.
Good point. Using a good language with great libraries is like prototyping at TechShop. http://techshop.ws/
There's a place for great languages with less-comprehensive libraries, no doubt. But if you want to make something that works today...
There's a place for great languages with less-comprehensive libraries, no doubt. But if you want to make something that works today...
[deleted]
Programmers are not welders. Programming means writing new code. Language is the medium of that code, it is hugely important, and it gets more important as the complexity of one's problem increases. The only way that libraries would become more important than language is if programmers stopped working on complex problems or new problems.
Ultimately, this overemphasis on libraries is a variation of the discredited "code reuse" meme, in which programs are imagined to be strung out of components, so all you need is enough components.
Edit: Another common thing about these discussions is otherwise intelligent people ignoring the fact that it is possible for a program written in one language to call a library written in another.