Arc Forumnew | comments | leaders | submit | jimbokun's commentslogin
8 points by jimbokun 3703 days ago | link | parent | on: Where are we going?

Perl, Python, and Ruby are successively closer approximations of Common Lisp.

I admire the ideas behind Clojure because it makes a different set of design decisions from Common Lisp. This seems to have even gotten the attention of Common Lisp developers, and those guys are pretty hard to impress.

The focus on immutability, literals for data structures other than lists that share a common "seq" interface, first class functions and closures, multi-methods without OO, lazy sequences, and full fledged macros hit an interesting sweet spot that is not touched by any other language I know. Mr. Hickey has managed to put all of those things together in a way that strengthen, reinforce, and complement one another. That is an impressive feat of language design.

My point is that Clojure is not "just" popular. By making unique decisions about the semantics of the language, and not just improving the syntax over the semantics of an existing language, Clojure may very well be one of those languages whose ideas remain influential long after it stops being popular.

(I'm curious, does Arc innovate in terms of its semantics being significantly different than its predecessors? It seems to have the goal of taking existing Lisp paradigms and making it possible to express them more succinctly. But I might be missing something important.)

So, even by the criteria you put forth, Clojure might be a language worth watching.

-----

5 points by stefano 3703 days ago | link

Clojure has already taken many things from Arc (there is also 'prn !)

-----

3 points by jimbokun 3703 days ago | link | parent | on: Where are we going?

Isn't Google (and others) already answering that question today?

-----

3 points by andreyf 3702 days ago | link

OK, so let's rephrase it practically - how do you design a programming language if the IDE is running on Google's infrastructure?

-----

9 points by jimbokun 3704 days ago | link | parent | on: Where are we going?

Your mantra in your role running Y-Combinator is "make something people want."

Is Arc exempt from that?

-----

17 points by pg 3704 days ago | link

You're forgetting two things.

1. The time scale. I don't want to make what people think they want right now. Following that recipe earlier would have got me Perl, which lost its lead to the language I would have gotten a little later, Python, which lost its lead to the language I would have gotten a little later, Ruby, which... See the pattern?

2. The audience. "Make something people want" is a recipe for companies. Their goal is to make a lot of money, which means aiming for a wide audience. That shouldn't necessarily be one's goal in every kind of work. It's ok to want to be Jane Austen instead of Perez Hilton, even though Perez Hilton is what most people want.

-----

10 points by jimbokun 3704 days ago | link

"I don't want to make what people think they want right now."

Fair enough. I think this sentence pretty succinctly answers the questions in the original post of this discussion.

-----

5 points by john_amendall 3704 days ago | link

Actually, it might be! PG doesn't need to make a living off of Arc.

-----

3 points by cronin1024 3704 days ago | link

Yes and no - he may not be selling Arc itself, but his reputation as a Lisp expert is indeed on the line.

-----

7 points by horia314 3704 days ago | link

hardly. I don't think anybody will thing less of him if Arc somehow fails. It was an ambitious project to begin with.

-----

1 point by jimbokun 3890 days ago | link | parent | on: OOP in Arc

http://arclanguage.com/item?id=1648

-----

7 points by jimbokun 3939 days ago | link | parent | on: Issues Regarding Lisp Adoption

"But sometimes I need to write a self-contained script that can take part in the whole Unix environment: things like being part of a pipeline, running as a cron job, running through CGI, running as a command. Python makes this trivial; Lisp makes this difficult or impossible."

This is hugely under-estimated as a reason for lack of Lisp adoption. I would put this way ahead of lack of IDEs.

-----

5 points by jimbokun 3939 days ago | link | parent | on: Issues Regarding Lisp Adoption

"I don't think there is a better candidate for an IDE target than Eclipse. It is very pretty."

Eclipse is ugly as sin.

Eclipse belongs to that school of UI design that further divides and subdivides the available space into smaller and smaller little tiles and panes until you are squinting at your code through a keyhole and distracted by all the stuff surrounding it. Yes, there are ways around this, but you have to fight the default paradigm. Most other IDEs adopt the same paradigm (to varying degrees).

Also, your whole point about IDEs does not account for the growing popularity of Python and Ruby. I know you point to an online Ruby interpreter, but these languages rose to popularity with most noobies first experiencing them through a text editor + shell/REPL environment. Stop and think about being a noobie downloading Eclipse and firing it up for the first time. What is the first step? How many steps will it take to see a useful result of your labor?

Versus an intro tutorial of:

    python
    >>> print "Hello world"
    Hello World
Congratulations! You're now a Python programmer! (Hope I didn't mess that up.)

Sorry for the rant, but I think many IDEs are largely a cargo cult phenomenon. pg has a quote somewhere about finally figuring out what an IDE is for; something like "it generates all the code that your Lisp macros generate for you!" IDEs are largely band aids to make bad languages not hurt quite as much.

-----

3 points by kennytilton 3939 days ago | link

No, tell us what you really think. :)

I think you are right about one thing, I freaked when I realized Python did not have quality IDEs.

otoh, clearly you have never used a quality IDE. Or you never get beyond about a hundred lines of code in your projects. Or ________? :)

-----

3 points by lojic 3939 days ago | link

I've used Visual Studio, JBuilder, Eclipse, etc., and for the languages I used them for (C++, C#, Java), I felt the IDEs were essential. When I switched to Ruby, the same quality of IDEs weren't available, but I found I was much more productive in Ruby with a simple editor than I had been with other languages plus an IDE, and I actually enjoyed the lighter weight environment quite a bit.

Would I be even more productive in Ruby with an IDE? Possibly. But it's possible that more powerful languages lessen the need for an IDE. Your love of ACL for Common Lisp would be a counter data point, but it's only one data point. Well, Avi Bryant would tout the Squeak IDE as a great advantage in using Smalltalk. In my case, it's somewhat moot given the lack of IDEs for Ruby. As I develop more in Lisp, I'll be better able to judge the effectiveness of the available IDEs.

Tens of thousands of lines of Ruby haven't been a problem for me with just vim, and now Emacs, and I don't think hundreds of thousands of lines would be a problem either if designed well.

-----

5 points by kennytilton 3939 days ago | link

"I found I was much more productive in Ruby with a simple editor than I had been with other languages plus an IDE"

Bingo, and that is why we do not see fancy IDEs for agile languages. The corollary being horrid languages have great IDEs because lawdy we need something!

One thing going on here is reflection. If my language has that I can toss off my own rough IDE-ish hacks in minutes and then they do exactly what I want, too, so the demand just never develops for off-the-shelf IDEs.

I work with tens of KLOC of Common Lisp at a time. I like sitting in a backtrace and using a keychord to jump to a functions definition, or sitting in the inspector and jumping to a class definition in source or with a diffeent keychord to the class in a graphical class browser. ACL integrates everything (except, strangely "who calls?", tho that is available via an unexported function), so I just sail all over my big code bases as fast as I can think, click, and keychord. Some folks, btw, feel the same about Lispworks and Slime, we need an IDE smackdown some day to comapre. :)

-----

2 points by jimbokun 3958 days ago | link | parent | on: Using Arc at work

"It needed a login/password system and the ability to compress and transfer files (that was the hard part)."

So how did you manage it? Calls to "system"?

-----

1 point by sacado 3958 days ago | link

Yes. "system" was my best friend here. Not for the login part, Arc already has it built in, but when dealing with files.

-----

2 points by jimbokun 3964 days ago | link | parent | on: Object Oriented Arc

"Personally I prefer the approach in SICP ( http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html.... )."

I was negligent in citing prior work. I had SICP in mind when I wrote my code.

The main differences are I wrapped it all up in a macro, I supported inheritance, and "method invocations" require one less set of parentheses:

    (define acc (make-account 100))
    ((acc 'withdraw) 50)
    50
    ((acc 'withdraw) 60)
    "Insufficient funds"
    ((acc 'deposit) 40)
    90
    ((acc 'withdraw) 60)
    30
I also didn't allow for initial arguments (yet). And you need to say "(vars 'varname)" to get values in method bodies instead of just "varname." I could probably fix both those things together.

But, generally speaking, the goal was to provide a macro for creating SICP style "objects."

-----

1 point by NickSmith 3964 days ago | link

Be interested to read your code Jim with your 'fixes'.

-----

1 point by jimbokun 3965 days ago | link | parent | on: Object Oriented Arc

Excellent question. I think it deserves at least a blog-length answer which I hope to get to soon but first a couple thoughts here.

First, how many comments do you count in my code?

Second, I think my class definitions are pretty concise, as class definitions go.

Third, Paul said somewhere he doesn't use objects but does use hash tables filled with closures. That is precisely what my objects are. It just provides a brief syntax for defining them. If there is a way to define hash tables filled with closures with even greater brevity I'm all for it.

Fourth, Arc has opened the door to data in functional position and I find that a huge win over other Lisps. I think this should be available to those hacking with Arc, not just the language designer. Maybe another way of saying this is give hackers the ability to create new types and define what they do in functional position and defining "setters" that work with =. Objects are one paradigm for doing that but if there's a better, more Arc-ish way that would be awesome, too.

Fifth, I think this can be a pedagogically useful example to someone coming from, say, Python or Ruby to Arc. I believe that it can help bridge the understanding gap between objects on the one hand and first-class-functions + anonymous functions + closures on the other.

Well, that turned out longer than I meant to type right now, but I appreciate hearing others' thoughts.

-----

1 point by jimbokun 3967 days ago | link | parent | on: "." not allowed in quasiquote?

Thanks! I think this will work best for me for now. But the suggested change to ac.scm is probably the best fix long term.

-----

More