Why Arc is bad for exploratory programming

http://arcfn.com/2008/05/why-arc-is-bad-for-exploratory.html

by mqt • 18 years ago

28 73 18 years ago

zach• 18 years ago

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

mqt• 18 years ago

What's the status of Arc?

Interest on arclanguage.org seems to be fading.

pg8• 18 years ago

What do you mean by "status?"

EliAndrewC• 18 years ago

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

skenney262• 18 years ago

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?

sacado5• 18 years ago

You mean, pg's interest ? Sure, he doesn't seem to be very involved anymore... :)

garethm• 18 years ago

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.

Tichy2• 18 years ago

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.

rsheridan62• 18 years ago

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.

Tichy2• 18 years ago

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.

rms• 18 years ago

>Arc is unfinished. It's missing things you'd need to solve some types of problems. But it works well for basic web apps.

tokipin2• 18 years ago

from: http://www.arclanguage.org/

pg8• 18 years ago

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.

Husafan4• 18 years ago

Why is speed not important?

Edit: How is speed not important?

pg8• 18 years ago

Why isn't the shirt I'm wearing blue?

tokipin2• 18 years ago

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

bOR_• 18 years ago

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

hugh4• 18 years ago

Surely whether speed is important depends on what corner of program space you happen to be exploring?

henning2• 18 years ago

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.

nostrademons2• 18 years ago

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.

pg8• 18 years ago

it lacks floating point speed

How much slower are floating point operation in Arc than OCaml?

sacado5• 18 years ago

Arc has a lot of bottlenecks when speed matters, but I never felt floats were one of them...

mnemonicsloth• 18 years ago

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.

sacado5• 18 years ago

In ac.scm, add :

  (xdef 'cos 'cos)
  (xdef 'sin 'sin)
  (xdef 'exp 'exp)

And you're done.

rkts• 18 years ago

I think that should be

  (xdef 'cos cos)

etc.

utx00• 18 years ago

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)

jcl2• 18 years ago

Apps take time. IIRC, for a long time the big Python applications were Grim Fandango and some research software at LLNL.

LogicHoleFlaw• 18 years ago

Actually, large chunks of Grim Fandango were written in Lua.

http://www.grimfandango.net/?page=articles&pagenumber=2

sacado5• 18 years ago

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

nostrademons2• 18 years ago

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.

xirium• 18 years ago

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?

Husafan4• 18 years ago

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

gruseom• 18 years ago

I'm tired of this incessant chatter about libraries, libraries, libraries in discussions about language. Of course libraries matter; I don't want to write code to convert a bitmap to jpeg. But the "libraries are the new language" belief is a gross exaggeration that has become way too commonplace. If it were true, we'd all be programming in C.

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.

lacker3• 18 years ago

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.

Hexstream• 18 years ago

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.

jimbokun3• 18 years ago

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

radu_floricica4• 18 years ago

Speaking of, anybody has any practical experience with ABCL (Armed Bear Common Lisp)?

aaronblohowiak• 18 years ago

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?

lacker3• 18 years ago

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.

skenney262• 18 years ago

I guess the title "Arc could use more libraries" isn't as attention-getting as "Why Arc is bad for exploratory programming."

jmatt• 18 years ago

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

tx• 18 years ago

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.

Why Arc is bad for exploratory programming

Related Stories