> replacing Arc-on-Racket with Clamp-on-Common-Lisp
We need a compiler for that btw (ie. the arc macro Im talking about nearby?) because 1) language designers need a compiler and 2) right now, it is missing parts of Arc; specifically:
('(1 2 3) 0)
(mylist 0)
("Yoopi" 0)
(+ "Hello" " World")
top level ssyntax
What case are missing for destructuring?
What am I forgetting? Do we have 'for'?
Doesn't work with sbcl, I'll try it with ccl later today:
$ uname -a
Linux akkartik 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686 i686 GNU/Linux
$ pwd
/home/akkartik
$ sbcl --version
SBCL 1.1.14.debian
$ ls quicklisp/local-projects
Clamp/ system-index.txt
$ rlwrap sbcl
This is SBCL 1.1.14.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (require :asdf)
("ASDF")
* (asdf:load-system :clamp)
debugger invoked on a ASDF/FIND-SYSTEM:MISSING-COMPONENT in thread
#<THREAD "main thread" RUNNING {ABFC8D1}>:
Component :CLAMP not found
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
((:METHOD ASDF/OPERATE:OPERATE (SYMBOL T)) ASDF/LISP-ACTION:LOAD-OP :CLAMP) [fast-method]
0]
*
Oh, are you using it with Quicklisp? I also tried installing quicklisp as well, but it didn't change the error.
I think we should evaluate if the Arc community want to switch to clamp as a main implementation (it's ok, we can take our time..). I gonna use it this week end to see if I find any problem.
Just made a quick test on my pet project using :clamp (not clamp experimental) and since most CL is exported, it's pretty compatible and works without much effort. So far so good. I'm gonna test the experimental part this week end.
I did find a better way to export everything. By using defpackage-plus, you can define a package definition clause that imports and exports every symbol that doesn't have a naming conflict with the current package. Exporting all of the symbols in :cl becomes just using this clause on :cl.
That's only ssyntax. a.b is rewritten as (get a b) where get is a generic function. You may be able to use set-funcallable-instance-function to get something closer to what arc supplies. Also there are a lot of edge cases with the ssyntax since you have to be within a w/ssyntax block. There is one included in def, so you can use ssyntax in function definitions, but you can't use it at the toplevel.
I wouldn't spend too much time on it. malisper truly has the right idiomatic approach with packages. I was mostly just flailing around with the little bit of Common Lisp I understand.
I've not dive into it but I actually like a lot the idea of Arc being implemented as macros into CL. Ill take some time to review this implementation I think (at least for myself :P).
I recommend the community to audit this implementation and to switch to it as a primary impl if it's any decent. Every link should be redirected to it. I can say quite confidently that CL is the best lisp out there today and the way to go forward as the other lisp dialects both sux and are stucked (even clojure; I've made a 5K+ LOC program with clojure and got tons of technical problems as the codebase got bigger).
It's not about popularity. It's about that I, as a good programmer, doesnt use Arc because it sux for a couple of reasons, which defeat the purpose of the language. In my opinion, switching to CL would fix those issues and open up a bright future.
That's fair. Reading your post, it seems like you have four points:
1. Arc is slow.
2. Arc doesn't have threads.
3. You can't make an executable out of Arc.
4. If you're dealing with extending the low layers of Arc, you need to use Racket.
We don't need to switch to CL to solve #1 and #2 -- you can make Racket-Arc faster and add threads there. I'm not sure if switching is required for #3, but #4 is definitely only solved by switching languages.
I think I prioritize popularity more than other people; perhaps because I want libraries, and other people can write more libraries than I can. For example, see my long-coming rewrite of unit-test.arc, which is going to be out any season now.
I also have a possibly unwarranted hope that there will be a new official version of arc, or pg/rtm/kogir/sctb will hang out here more.
I guess my point is that switching to CL fixes some problems; some don't need a switch. And I worry about fragmentation.
I see what you mean. I entirely agree with you. Basically, I would not want too to advocate for a switch if it was for minor reasons (even for most medium ones) that can be fixed or with which one can live. That happens a lot with software, you have to live with some shit and that's ok.
I think my point goes beyond however.
For understanding why, let's discuss one aspect of software. There is something cool about software that actually many organisation miss I think. Software is pretty predictable. Just use your stats. So, if your development team was going at that velocity this month on that system, chances are they are going to move forward with the same velocity or so the next month. If you've had 15 new bugs this week on your system, chances are you gonna have at least 10 new bugs next week. If you had important successes with your system, chances are you gonna continue to be successful with your system again.
In other words, if your team is slow this month, they won't be fast next month. Nah, they wont. If you had bugs last week but think you've made big fixes, well you gonna be disappointed this week when you will understand that you've not fixed the mother of all bugs because there is no such thing. Your codebase has that property, it has that bug stats. It can go down, but using a continuous and low varying function.
If you adopt Arc and got 5 technical problems in 2 weeks all more or less related to Racket [0], chances are, that's my point, that you gonna have technical problems all along.
So what I'm trying to do here by my call is not to fix a couple of issues. What I'm trying to do is to change the stats themselves. Arc must be smooth. If it's not smooth, hackers wont use it. Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.
Note that I'm not advocating fragmentation. I'm advocating to, if reviews and discussions tell it's right, deprecate the Racket version for a CL one.
I've very quickly tried the Clamp implementation yesterday, and already, I've felt the difference. The ffi, check. As fast as C, check. Threads, check. Not repl problem in sublime, check. Easy import from CL, check. Executable, check (I've made one with clamp, it just worked). (Chances are, Im gonna continue to check at this rate.)
I think that makes my point more clear. Before any consideration, we must have a real good implementation hackers would use, as a foundation on which to build on. I can be wrong though. I may be making a judgement mistake of course.
[0] I've also had problems importing my symbols coming from a ffi to arc. Such a pain. It's already working with clamp though...
> If you adopt Arc and got 5 technical problems in 2 weeks all more or less related to Racket [0], chances are, that's my point, that you gonna have technical problems all along.
> Right now, Arc is unusable because, as you use it, you understand that statistically, Racket gonna pose problems. So you quit.
I've had the complete opposite experience -- none of my problems with Arc are Racket-related. The things you have listed seem to fall into two categories: you prefer Common Lisp, or things that have been done in Clamp.
I think I'd be happier about switching implementations if we could update the site that most people using the language use to communicate on! The instructions still say to get a specific old version of mzscheme!
The only caveat I want to inject is to not blame Racket too strongly. Clamp showed me that I don't know enough CL to make a good Arc in it. By the same token, Pauan's https://github.com/arclanguage/arc-nu showed me how much better Arc-on-Racket can be. Racket is pretty mature, but the default Arc implementation hasn't moved much from the days of mzscheme.
Sure, obviously Racket is a great language, specially for teaching. Though, I don't find it is in the same greatness category as C and python (and some others like Ruby, Rust and Go). Those are the hacker languages. I would like to see a lisp actually in this category.
Just as a counter-point, I'm utterly unconcerned about fragmentation. This community is small, and the Arc codebase is small, in the grand scheme of things. It's tractable for one person to hold it in his/her head. We all have different strengths and weaknesses. If somebody finds it easier to work with C++ (that's me), go do it. If Common Lisp is your forte, and you find it easier to port Arc to it than to build threads into Racket-Arc, go for it. Regardless of where you are, it's tractable (though not trivial; write lots of tests!) to share code across projects.
One lament that often comes up with programmers is why software can't be as stable as a house or a bridge or whatever. Well, the reason is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because of large amounts of fragmentation, only we don't call it fragmentation because atoms are harder to copy than bits, we just call it "trying again". Since bits are easy to copy, software culture has internalized some amount of "peer-pressure copying" under the banner of "avoiding fragmentation". I think it's silly. Particularly in the context of a small-scale project where there's never going to be much demand for deploying at scale, we'll never be a massive target for black-hat folks (so quickly transmitting security fixes isn't a priority), etc. Even for a large-scale project like Android, I think the problems people attribute to "fragmentation" are symptoms of deeper issues, and not fragmenting just keeps us from better understanding the issues.
That's fair. I definitely have a bias away from creating architecture, which probably explains more of my reactions than I'm comfortable with. I normally prefer to make things work within an existing system.
But yeah, I do see that it's worthwhile to try random things; it just doesn't feel true to me. For some reason, waterfall design is what makes me more comfortable.
Arc is designed for good programmers. It gives you raw power. Like you could kill yourself with it. Arc is to programming language what unix is to OSes. It doesn't try to protect yourself from doing bad things but gives you the maximum power instead.
The advantages of the language are numerous: raw macro, short names, incredible library, awesome operators, right choice of data structures, etc.
In short, it's more beautiful and agile than racket.
Hi highCs, this is off-topic but I was thinking about you just yesterday. I updated your bugfix at http://arclanguage.com/item?id=19310. Could you pull anarki and let me know if it's still working for you on Windows? Many thanks.
We were also wondering what your setup looks like. Are you using cygwin when you run Arc on Windows?
Hi akkartik, thanks for the update. I'm not using cygwin, but raw racket for windows, sublime and terminals. But I've not run Arc since a while - december or so. Actually, I growing more and more interested by poker. It's kind of the perfect answer to the frustration I got in software - mostly due to my struggle to find a job with great programmers and also my struggle to find great co-hackers. In poker, I win money when the others are wrong; guess how I like that this days...
Programming is my life. I like to think I'm a master of it. But I'm completely alone. Also I hate my jobs, I hate big companies, I hate bullshit, I hate TDD, I hate code reviews, I hate estimations; it's a pain man.
Poker, while definitely not as deep as software, is the exact opposite. They do TDD? I take money. They do code reviews? I take money. bullshit? a fountain of money...
But there is Arc. The most beautiful language I've ever used. I could build so much with it. Wow it could be so awesome. But, let's be honest, it's now or never.
Btw, I think I have an idea to fix email. What's missing is a delivery date (of the task / answer / content) set by the sender or the receiver, which would allow to sort emails. Anyway, I'm throwing a bottle in the ocean. If you have a project you want to do using arc (or another language that would fit the task better), let me know.
I was quite addicted to poker (no-limit hold 'em) for a couple of years (2005-2008) until it became hard to play online in the US. Now I just play with play money on some mobile app every few months :) It's not true that when people play badly they always lose money. It took me a while to realize that my compass of how well I was playing had to come from within. Otherwise the worst thing that could happen to me was to play badly and win a hand. I'd then be giving away money for a long time, going on tilt, etc. But yeah you're right that in the long run the better player wins, particularly in cash games. Tournaments seem like more of a lottery (maybe I'm just not very good).
I'm constantly looking for people to hack with as well. Some ideas:
a) We could work on anarki. For example, try out the latest version sometime when you have time and let me know if mktemp broke again on Windows. Help kinnard and me expand the install instructions for Anarki to Windows. Neither of us knows how to run Arc there, so this would be very valuable. These small-ish ideas might be the start of a larger project.
