You mention verisign, so I assume that you're talking about using HTTPS to access your web site securely. (See http://en.wikipedia.org/wiki/Https for details).
Using HTTPS does two things: it encrypts the data being sent between the browser and the web server so that no one can listen in, and it verifies that you're actually connecting to your web server (that someone hasn't manipulated DNS so that you think you're getting your web server but you're actually getting an evil server that wants to steal your passwords or whatever).
When you pay a registrar for a certificate, you're paying for the second purpose, so that when a user connects to your web site foo.com they know, by virtue of the registrar's certificate, that they're getting your foo.com, not someone pretending to be foo.com.
However, if all you want is for you to be able to connect to your web site securely, you don't need to pay for a certificate. You can create your own certificate (this is called a "self signed certificate", because you sign it yourself, instead of having a registrar sign it). When you connect to your web site which has a self signed certificate, your browser will put up a big warning message saying that it can't verify the certificate itself, and so doesn't know if you have connected to the right server. However, you can look at the certificate and check that it's your certificate, even though the browser doesn't know if the certificate is valid. And the data between the browser and the web site will be encrypted just the same.
On the other hand, I've heard that you can get a certificate from a cheap registrar for a little at $15/year, so if you want other people to be able to connect to your site using HTTPS without getting the browser warning, that's no big deal.
Arc doesn't have HTTPS support built in, so if this is the kind of security you want, what you'd do is set up a web server (such as lighttpd or Apache) which does support HTTPS, and have it forward requests to your Arc server.
I see.... Thanks. I will forward an Apache server to the Arc server.
I am in the process of buying a "slice" from slicehost and setting up real website (my first time). Local8080 is getting dry as I can't show anyone the awesome things I am doing in arc!
I'm also thinking that having Arc make things atomic for us may be a bad idea, though perhaps for different reasons than you enumerate.
1) As a general principle, IMO, it should be the programmer's responsibility
I myself am quite happy to have responsibility taken off my hands, if the resulting code actually works. However...
2) Adding the overhead of 'atomic
If it worked, I wouldn't mind the overhead. (I haven't measured it, so I don't know if things being made atomic by Arc adds 10% to my program's execution time or 0.01% or 0.00001%) But the way to make a program fast is to profile it and fix the parts that are slow, not to leave out useful features in order to do global, unmeasured optimizations.
However...
I don't think it does work, which is probably part of what you're saying as well. Consider
(readfile "foo.txt")
Reading a file might happen instantaneously if the operating system already has the file cached in memory; it might be slow if we're waiting for the hard disk to rotate into place to read it off of disk; it might take forever if the file is on a network filesystem.
Should I have the misfortune to say
(obj a (readfile "foo.txt"))
this will work fine most of the time when reading the file is fast, but if the reading the file happens to be slow then I'll bring my entire web server to a halt waiting for the file to be read.
Yeah, it's reasons like that that lead me to point (1). When stuff is done for the programmer for nonobvious reasons, it leads to problems like this - there's nothing in the conceptual mechanics of (obj ...) that would make you think "oh, it's wrapped in a global mutex", and yet it is because assignment itself uses a global mutex. It's not so much that the language is "doing it for me" that's the issue with (1); that's fine. It's "explicitness" that's the problem: I want to know when I'm using a concurrency-controlling form like 'atomic. Otherwise, it's hard to reason about how my program is going to behave.
Also, this stuff about profiling to fix hotspots is mostly true, but hotspots come in many forms: tough algorithmic problems, folding or mapping some operation over a large data structure, etc. One form of hotspot is a common operation that isn't particularly localized in use. For example, some people have experimented with adding infix math to arc by having numbers cause infix parsing when they're called; they found this caused a slowdown of ~10%. I strongly suspect assignment falls into this category: it's used everywhere, it's a fundamental language feature, and making it faster will reap noticeable (albeit not overwhelming) benefits. However, I must admit I haven't tested this, so feel free to prove me wrong.
For the second, well, I wouldn't be surprised if someone who worked at optimizing Arc could make it run twice or maybe even ten times as fast, while still implementing the full specification. So if a particular language feature is actually useful, and happens to cause a 10% slowdown, I mostly don't worry about it myself... I suspect greater gains would be found from a systematic optimization approach.
Besides, most of the programs I write already run fast enough, so I wouldn't mind a 10% slowdown for a feature that was actually useful. Which, unless I'm presented with new information that changes my mind, I agree with you that Arc's implicit locking is not.
Nothing too complicated or high volume. Our church website and a realtor's website, currently in php. We've been working on a design for a quasi-framework, and were hoping to do it in lisp. Currently my host is dreamhost, which pretty much permits anything, and has shell access. If I could use an fcgi interface, I'm pretty sure it would work. Which lisp / web framework do you recommend?
How much are you paying for DreamHost? The cheapest Linode (http://www.linode.com/) plan is $20/month. Download and unpack MzScheme, fire up Arc, and you're up and running. Sounds to me quicker and easier than messing around with fcgi, unless there's something about your situation that I'm not realizing.
If you want your two web sites to be running with different domain names (www.mychurch.org, www.terrificrealtor.com), you have a couple options: you can run Apache (or any other HTTP server that can forward requests) in front of Arc, and be running two Arc processes, one for each site. Or you could hack Arc (or ask a hacker here to hack Arc for you) to look at the "Host" header.
Which lisp / web framework do you recommend?
Well, I use Arc myself, simply because I can use any language I want, and I like Arc. What I'd recommend for you would depend on what your goal was. If you want a powerful programming environment that will enable you to implement your two sites quickly and easily without having to do any Linux system administration, I'd recommend taking a look at AppJet (http://appjet.com/).
All of the previous comments presumed virtual private servers, as far as I could tell. I am basically wondering if arc (or another lisp) could be run on a host such as DreamHost via fastcgi, or a similar method. Since python and ruby are run on DreamHost this way, it seems feasible, and I was wondering if anyone else had done this with arc or another lisp.
Poking around the DreamHost support wiki and terms of service, I can't see anything stopping you. You can run an Arc interpreter in the background, so long as it doesn't eat too many resources, and I can't see anything stopping you from forwarding requests to it.
However, it will not be officially supported in the same way that Ruby and Python are, so you'll be on your own when it comes to fixing problems. It might be better to use their private hosting service so that they don't complain about your Arc process (which they may do if a bug causes it to behave badly). Although this means it runs on a private virtual server, you still get all the same support and software as with the shared service.
Another option is if your provider will forward web requests that come in on the standard HTTP port 80 for your domain to your Arc process listening on a port such as 8080.
I would assume so. I've used Apache's ProxyPass frequently and haven't had a problem. There's no technical reason that I know of that it would be either faster or slower than fastcgi. In both cases Apache is passing on the request to a persistent process. I haven't measured it though.
You'd need to find a provider who allowed you to install executables, so that you could install MzScheme. Then, I haven't heard that anyone has implemented the fastcgi protocol for Arc, so you'd need to implement that.
I haven't tried it, so I don't know, but in general I've found it easy to call MzScheme code from inside of Arc.
You can add xdef's to ac.scm; Anarki has a $ macro to call into MzScheme if you use Anarki; and I describe my favorite way to call into MzScheme here: http://arclanguage.org/item?id=8719
calling the table using any table function that return all entries, does not return the order as it was stored, but rather it seems to return them randomly
Yes, if you need to keep track of things in a particular order (such as the order you added them), you should put them in a list.
Note that you can put the same data in both a list and in a table, if that is what you need for your application.
hence the storing of the table names as symbols in a table
If you want to have a mapping of table names to tables, you can store that in its own table:
By that I mean if you define a table library, you should be able to write code that allows the data of a table appear like a table, with a grid and everything, right within your code editor. That's what I would mean with "fully programmable"
When you say you want "characters to be fully programmable" does this mean that if you had "fully programmable characters" you'd be able to edit tables in your code editor as you describe, or are you making an analogy saying that you'd want characters to be fully programmable like these tables are fully programmable?
The former- I'm saying that if you're going to allow more characters, I'd want to go all the way and have an editor that is part of the "language definition" that supports arbitrary graphics and ui elements that is controllable through the language in a "lisp like" way and would allow code appearance to be 100% customizable right inside the code.
No, I think what people are getting at is... why does program source have to be represented by only ASCII text? After all, if code is data, an IDE is just a data editor, where that data happens to be code.
I think it has been shown many times throughout history that notation matters. In fact, the entire concept of Arc is based on this principle. Otherwise, Common Lisp would be suitable.
Why does it have to be ASCII? No reason, The simplest answer may just be that the language writer feels that adding UTF-8, or UTF-16, support would be a waste of their time, or is below them. As for programming IN the language, it becomes a matter of what is easy for the programmer to type. In a way, this whole thing is a matter of deciding what is the lowest common denominator that one wants to support.