Arc Forumnew | comments | leaders | submitlogin
Need for a practical language
5 points by stefano 5936 days ago | 7 comments
The critiques regarding Common Lisp usually concern the fact that the implementations are not practical: no straightforward way to deliver an application, a lot of little small problems to setup a working environment together with a set of libraries. If you use a language as Perl, you can get up and running in a few minutes, while with most CL implementations you need a few hours to set up SLIME, install a set of compatible libraries, etc. I think that Arc should solve these problems before improving the language itself. In other words, we should give higher priorities to the implemenation rather than to the language. This means getting a good standard FFI, a module system, useful practical libraries (BTW, I've just started a simple XML parser on Anarki), an IDE (or at least good editor support) and a simple way to install all this. I think this would be a better way to attract people to lisp rather than developing a great language that is difficult to use for practical projects because of many little problems (i.e. you need to get exactly version 352 of mzscheme to run Arc2.tar, you need to start it from the installation directory, etc.)

What do you think about this?



4 points by drcode 5936 days ago | link

> What do you think about this?

Sounds like a great recipe for creating a ten year language, like Perl.

Arc is, after all, a philosophical exercise at guessing what a hundred year language might look like (though clearly still falling well short of that goal)

Do you really think you're going to be calling a C++ function through an FFI in 100 years?

That being said, you are absolutely right that a lack of focus on libraries greatly hurts arc's chances at widespread success. I'm not sure if there is any good way to solve this dilemma, though, in the near future.

-----

6 points by stefano 5935 days ago | link

> Do you really think you're going to be calling a C++ function through an FFI in 100 years?

I think I will be dead in 100 years.

> I'm not sure if there is any good way to solve this dilemma

The only solution is to write libraries. Take some problem you think is generic enough for a library and write code to solve it. I've already written in Arc a library to download files through HTTP and a simple XML parser. They're not complete, but they're something. Talking about libraries' shortage won't solve the problem. We have to write code.

-----

2 points by andreyf 5922 days ago | link

Do you really think you're going to be calling a C++ function through an FFI in 100 years?

I don't think we can imagine how we'll be programming in 100 years - Arc is a bit too easy to imagine - and was just about imagined nearly a half-century ago.

How would you design a language if you knew that you had >2^50 the processing power you have today to compile/interpret it?

-----

4 points by Tripp 5932 days ago | link

I think one can make a 100 year old language and still package with praticality along the way. You can not avoid tangents or corrections. The distinction between a 100 year language and others is not the tangents taken, but rather the appetite to make corrections back to the 100 year evolutionary path, along the way. More usage = more appetite. Arc risks losing momentum. At this pace users will move on to other short term candy apps that are easier to use.

-----

2 points by tokipin 5936 days ago | link

i think both can be done, no need for compromising. the problem with CL is its size/complexity, which is the complete opposite of Arc. also i doubt mzscheme will be Arc's final platform

that said, i've been wondering how quick it would be to grab the source for DrScheme, shoehorn Arc into it, and release it as a single-install, works-right-outta-the-box IDE

-----

1 point by stefano 5935 days ago | link

> i doubt mzscheme will be Arc's final platform

Using mzscheme as some sort of high-level virtual machine isn't a bad idea as it may seem. In fact, I think that it could be quite practical even in the lon period. Speed is not blazingly fast, but it is quite good, and you get stability and a good portability without effort.

-----

1 point by eds 5930 days ago | link

We've already got http://github.com/nex3/arc/tree/master/arc-exe.scm which creates an exe of the interpreter. And it wouldn't be difficult to use my http://common-lisp.net/~eslaughter/darcs/blackthorn/install.... to create a Windows installer for it.

-----