I actually made a brave effort to use Prolog for serious development, and Paul pretty much nailed it on the head: it just does not scale, mostly because its all logic programming all the time. That can make normally direct things rather painful. OTOH, I am using PAIP Prolog embedded in my big CL application and getting huge mileage out of it -- for a tightly defined problem that does indeed benefit from Prolog's strengths. Basically Prolog's mistake (iff it wanted to be an all-porpoise language) was not offering other paradigms.
Well, yes, that is the beauty of macros. What is holding you back from the Arc example is that it makes you nervous -- how can it work?! I do not see all the moving parts! But then when we are programming heads down do we really want to see all the plumbing? Macrology is all about hiding the boilerplate so we are looking at just what matters. But yes again: make sure your macros (or the ones in the library you choose to adopt) work. :) Once you have satisfied yourself of that, as a developer you are in a much better place. My 2, anywho.
Nice. Call me crazy, but I think the squares should get smaller towards the top, just as in a real arch. I would hate for the logo for a hot new language to be architecturally unsound. Also, I like the proportions of the St Louis Gateway arch: 1:1 base to height. Neat since it looks taller than it is wide. (530 ft both) Oh, and I like 9 thing daniel mentioned.
I have tried that but five is the minimal amount of pixels to form an arch and minimalism is one goal of pg, isn't it?
The proportions are derived from the underlying pixel grid. I wanted the logo to be scalable without blurring by just multiplying the pixel number.
uvl 8-)
There cannot be a problem with unhygienic macros. I have 527 of them across 103 Common Lisp source files (I like small source files) and have not once ever had a problem with unintended capture, Not even when I was new to macros. QED.
Hygiene is a solution without a problem. Bad solution, bad!
btw, 2800 defuns and 800 defmethods (OO defuns, in brief) in the same source.
Regarding number two, after I started using syntax coloring editors for my Common Lisp I noticed that the blue stuff (the language keywords) was surprisingly scant. ie, Most of the text consisted of my own variables and operator names. This (I guess) is especially true of functional languages and maybe also because I never miss achance to hide boilerplate with macros. So in conclusion my fellow Archers, I think real world code you write will be as long as you want it to be. No one forces you to pick short names or use the chaining:thing.
I am puzzled by how (let (t (cdr v))...) could work for you in vec-get when it should be (let tbl (cdr v)...) -- note that as an aside I am avoiding rebinding t just from long CL experience. Also, it seems unusable because no one wants to rebind some local variable holding the vector just because they added an element. And it is unworkable because you make a new cons of count and hash but you keep the same hash, so anyone with a binding with a lower count who now goes to add will be writing over values added by other code working on the same vector (say if I pass the vector to a subroutine for further work and then resume work on it myself). My final concern is finding a hashtable inside something called "vector". :) Anyway, the fix is to modify the car of the "vector" when changing the count instead of consing up a new count-hash pair. But really I would mush rather see a size declared when creating the vector and then requiring an index on the add (in which case it is more of a set).
