kens1


22 points by kens1 over 2 years ago | link
cached 12 days ago

17 points by kens1 over 2 years ago | link
cached about 1 year ago

7 points by kens1 over 2 years ago | link | top
cached 10 days ago
I'm finding Arc's type system to be kind of random. I'm not sure has-a vs is-a is the solution, but here are my issues:

a) Lots of operations operate on "sequences" (tables, lists, and string). Lots of other operations operate only on lists, or only on string and tables. There doesn't seem to be any real pattern. There also doesn't seem to be any fundamental "sequence" abstraction that supports implementation of more complex operations. It's more like "if list, do this. If string, do that. If table, do that."

b) Lots of string operations treat a list of characters and a string interchangeably. Lots of operations don't. Again, it seems pretty random.

c) Non-fundamental types, such as queues (http://www.arcfn.com/doc/queue.html) don't interoperate at all. That is, a sequence operation such as map will do entirely the wrong thing to a queue.

I don't know what the solution is, but it seems like there are some type abstractions struggling to escape from arc.arc..


7 points by kens1 over 2 years ago | link
cached 10 days ago

6 points by kens1 over 2 years ago | link | top
cached 22 days ago
I'd like improvements in basic usability. This includes filling in missing functionality (e.g. trig, socket connections, regular expressions) and/or an escape to Scheme to do these. Also non-brokenness on Linux, Windows, etc. Also ability to simply make a non-REPL Arc script. Picking up the Anarki stable fixes would probably cover most of this.

On the trivial side: w/bars must die.

One question: why is currying so popular? I don't see the point, so I guess I'm in blub-land with respect to currying.


6 points by kens1 over 2 years ago | link | parent | top
cached 22 days ago
The problem I ran into today was:

  arc> (apply or '(nil t nil))
  Error: "Function call on inappropriate object #3(tagged mac #) (nil t nil)"
I assume that first-class macros would let me do this.

6 points by kens1 over 2 years ago | link | top
cached 13 days ago
In my experience, the meta-issue is that there are multiple substantial barriers to Lisp adoption, and an uncertain payoff, leading to the question, "Is this really the best use of my time?"

The first substantial barrier is Emacs. Before learning Lisp, first you must learn Emacs. I've tried several times, but keep deciding it's not worth the effort. Imagine for an instant that in order to use Ruby, you need to use some strange Japanese editor, but it's really not bad once you get used to the cryptic commands and rebind your keyboard so it is usable. Do you think this might hamper the adoption of Ruby?

Next, the IDE. I'm willing to put up with Slime's 1980's styling, but I keep ending up in mysterious inferior modes that don't seem to be documented. After reading through Slime documentation, it seems I need to understand Emacs's Lisp modes first.

Then, the REPL. Sure, it's nice to be able to interact. 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.

Then there's the payoff. Will Lisp actually help me solve any of my problems? That's still extremely unclear. Perl or Python are great for random problems I have, such as "Fetch a web page, pull stuff out with regular expressions, and convert it from iso-8859-1 to UTF-8" or "Analyze a pcap dump file". This is where Lisp runs into the infamous library issues. The problems Lisp solves seem to not be the problems I want to solve.

The issue of a dialect/implementation is somewhat vexing: try reading SICP and Practical Common Lisp at the same time, and discovering that everything is different. Also, the expectation that whatever implementation you pick will be the wrong one for the libraries you want is a bit scary. But overall, I'd say this isn't a fundamental barrier.

The above is meant as an honest answer to your question; I'm not interested in starting a flame war.

I am pleased with DrScheme, by the way.


6 points by kens1 over 2 years ago | link | parent | top
cached 11 days ago
Unfortunately, compatible axioms don't guarantee compatible code on top. The big problem is the operations that use "system" (e.g. date and ensure-dir) break on different OS's. This is the root of many of the Windows problems.

For this reason, I believe that use of "system" makes a mockery of the axiomatic construction, and has no place in the Arc core.


5 points by kens1 over 2 years ago | link
cached 22 days ago

4 points by kens1 over 2 years ago | link | top
cached 12 days ago
To run Arc from a file, I think what you're looking for is the script at http://arclanguage.org/item?id=1424