Edit: Ontopic: "So while Arc is not the perfect Lisp, it seems to be better for at least some kinds of programming than either of the leading alternatives." What kinds did you have in mind?
Offtopic, but what exactly is that a picture of? I see chairs, and a face in the background (looks like a reflection) - is it a picture taken through a window? Why is it there?
The new picture on the frontpage of pg.com is a self-portrait shot in/through a window at the Grand Trianon, in the grounds of Versailles. I noticed that if I held my head in the right place I could line up my eyes with the wallpaper pattern.
"Which is why, incidentally, Arc only supports Ascii."
Is this why unicode is absolutely broken on ycnews? :( Seems a shame not to be even to use characters like pi in comments/titles IMHO Does a pound sign work? GBP
edit: no it doesn't. Seriously, if done right unicode support doesn't have to take that long. Especially if you're building something without the need for backward compatibility.
What??? I kinda like being able to talk about things as fundamental as money, without having to use (GBP). I'd like to use currency symbols for a start, what about math? I'd like to use pi occasionally.
How about I want to add a nice 'tm' or (c) sign.
People care if a website is using correct unicode characters or not.
Perhaps they don't know/care because the majority of websites now are unicode, and just work.
Users care if their name is zoe (with an accent on the e), or if they want to discuss prices of things in euros or GBP.
I wrote a php forum a while back. You wouldn't believe the number of emails telling me that the gbp sign doesn't show up properly when they post a comment.
Even if the users don't care (although they very much do when their characters all show up jumbled), the conversation here in this thread _is_ very much about the coders. Saying unicode is irrelevant is pretty strong in this context and IMHO, pretty bizarre.
Yah, I can see how it sucks but unfortunately that's the way it will have to be for Arc given PG's disinclination to spend time over it. If you end up contributing a unicode fix, who knows, it might even get incorporated and others will thank you as well :)
PG just released an entirely new dialect of lisp for web programming, he's mentoring about 20 startups right now, and runs Hacker News... "Oh, and can you add Unicode support, it would only take 2 or 3 days..."
I know that not having Unicode supported in your web language is inconvenient, and at times is a show-stopper. But really. Give the guy a break. If PG doesn't want to "spend a single day on character sets". Don't ask him to spend a day on character sets.
If you want Unicode support in Arc, code it up and submit it.
IMHO, it's not an issue of implementation. It's an issue of design.
If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my idea is that a string is a sequence of characters, regardless of how a 'character' is represented", then somebody can go ahead to change Arc Unicode-clean (it won't be much work assuming MzScheme has support of Unicode).
If PG says "the language Arc (not mere an implementation) doesn't support beyond Ascii", then I feel that PG reserves that part of design (e.g. it may conflate byte-array and multibyte strings, or it may use richer character representation than unicode codepoint, such as a character object that holds the sequence of base char + modifiers, or it may hold raw byte array plus encoding info). In that case I hesitate to change Arc code without understanding PG's intention.
By the same logic, commenters should be able to put arbitrary HTML in their comments. Very large font sizes. Blink tags. After all, HTML support does not have to take that long: just pass the HTML straight through to the browser. If commenters could use very large fonts and blink tags here, do you not believe that some of them would?
The freedom of the citizen of Hacker News to express himself is being suppressed! Paul Graham, add support for blink tags now!
I was talking about this place, news.yc, not about Arc programs in general. Of course a place for Spanish speakers or Chinese speakers is going to support the charset for that language. I _hope_ we can agree that we do not want comments in languages other than English in this place.
If you look at Arc's source, it certainly seems like PG prefers short names everywhere - it's more like what I've seen from Haskell people. I generally prefer medium-long names. Scheme's call-with-current-continuation is too long. Arc's ccc is too short. Ruby's callcc is just right.
You could ask on comp.lang.lisp if you wanted some really well-informed opinions wrt the impact of Arc on CL, but I wouldn't advise it unless your skin is thick and flame-resistant.
You probably missed the thread here on YC News he is mostly like responding to... I would link you to it, but it was honestly pointless to begin with... and I'm lazy.
Just read the first half, very good explanations in minimal verbiage. Arc looks beautiful here even if only for the de-parenning of so many CL operators (i.e. let). In fact I'm a little sad to still see so many parens in the code... I guess my whitespace-significant dreams were overreaching.
Huh. I would have said just the opposite about HTML; seems to me that slapping down some structural divisions and worrying about layout later is much more exploratory than starting with the layout.
His point is that it is more "exploratory" not to use semantic markup, since you might not know the semantics of the document structure while you are developing.
It seems backwards to me though, surely the most "semantic-free" approach is to default to divs rather than tables to structure the markup.
It's all meaningless unless you intend it to have meaning. But tables are probably easier to work with.
(That may change in future, but right now I don't think any mainstream tools assume markup is semantic. And in any case, tables aren't much moreso than divs.)
> right now I don't think any mainstream tools assume markup is semantic.
Depends on what you're talking about; anything that uses microformats does, for example.
Tools generally can't assume that tables are semantic, because they've been so heavily abused. That's not going to change though. Perhaps the best solution is a <yes-this-is-really-a-table> element.
> tables aren't much moreso than divs.
Would you say that a table in a relational database isn't much more semantic than a string of bytes?
GWT also uses tables for layout extensively in its compiled output. I dont think its an ugly hack, as long as you can learn and work around ambiguities with table cell height between browsers.
But then I guess that is all part of exploratory programming.
Tables for layout is awful in terms accessibility and semantics, among other things.
Tables are meant for tabular data, and when you use them for layout it breaks those semantics, which in turn makes it much harder for screen readers to make sense out of it.
Most screen readers handle both. The problem is that screen readers will attempt to read the contents of tables as if they were tabular data. (Surprise, surprise. :P)
This turns out to be a relatively poor user experience.
It is a trade off. If you want to support Internet Explorer, some kinds of layout are not easily achievable without using tables. W3C cannot be blamed for the deficiencies of IE though, so I'm not sure if this is what PG is alluding to.
Agreed, in fact if everyone used tables for tabular data only, we could have nice browser-supplied column-reordering and row resorting, I think.
Right now that kind of thing is intractable because there's no easy way to distinguish a table-for-data from a table-for-layout. I think it could be cool to have some way of putting something in your page HEAD that means: "In this page, tables are used exclusively for tabular data: you can activate your reordering features".
"We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."
Are you hoping to build a user community for Arc? If so, and why would you release Arc if you weren't, then why are you not interested in keeping track of changes that break things users might design/code against? Am I being stupid and missing something here?
Edit: I forgot to mention something else. Congratulations and thanks for sharing Arc with the rest of us :)
I remember reading this in "Arc at 3 Weeks" and being quite excited about it:
The Scheme language sneakily increased the scope of the language designer's powers. From very early, maybe from the begining, the Scheme spec said that conforming implementations must do tail call elimination. The first time I read this, I thought "wait, can you require this in a spec?" Arc will see this increase, and raise it by some standards for profiling.
I thought that was a great idea. Too few languages have good support for profiling. Did the idea get dropped? I don't see anything obviously related in arc.arc or in the tutorial.
I'm sure the idea didn't get dropped cause it's pretty darn important -- and it'd be a major back peddle for PG. It certainly might have been postponed, though.
I wonder if PLT Scheme's profiling tools are good enough on Arc programs (or useful at all?). I hear they have pretty good ones, but haven't used them myself. Arc might be different enough from MzScheme that the information that the PLT profiler returns on Arc programs isn't so useful.
Going to try it out now, but one thing really struck me in the announcement:
"We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."
Is that really wise? What's wrong with doing a simple changelog with every modification? Since you'd expect only experienced programmers to be using Arc, you don't have to hold our hand explaining the implications of the changes - but making us diff the source would probably be a bit much.
I mean it doesn't have to be verbose even. Or even tidy. This would be better than nothing:
* Added a global weak reference hash map to treat any object like a hash using {} syntax, ie, (= {someobj hashindexobj} 5).
129 comments
[ 4.0 ms ] story [ 191 ms ] threadI forgot my news.yc password and wonder if resetting password in news.yc propagates to the arc forum.
Offtopic, but what exactly is that a picture of? I see chairs, and a face in the background (looks like a reflection) - is it a picture taken through a window? Why is it there?
The new picture on the frontpage of pg.com is a self-portrait shot in/through a window at the Grand Trianon, in the grounds of Versailles. I noticed that if I held my head in the right place I could line up my eyes with the wallpaper pattern.
Is this why unicode is absolutely broken on ycnews? :( Seems a shame not to be even to use characters like pi in comments/titles IMHO Does a pound sign work? GBP
edit: no it doesn't. Seriously, if done right unicode support doesn't have to take that long. Especially if you're building something without the need for backward compatibility.
Just my 2c.
Maybe I'm being harsh :) I'm sure it's great really, but these days people expect unicode support on websites.
People care if a website is using correct unicode characters or not.
Perhaps they don't know/care because the majority of websites now are unicode, and just work.
I wrote a php forum a while back. You wouldn't believe the number of emails telling me that the gbp sign doesn't show up properly when they post a comment.
http://iolanguage.com/scm/git/checkout/Io/docs/guide.html#TO...
Perhaps arc could use the same approach.
> In Io, symbols, strings, and vectors are unified into a single Sequence prototype which is an array of any available hardware data type
> A String is just a Sequence with a text encoding, a Symbol is an immutable String and a Vector is a Sequence with a number encoding.
Pretty cool. Thanks for the link.
PG just released an entirely new dialect of lisp for web programming, he's mentoring about 20 startups right now, and runs Hacker News... "Oh, and can you add Unicode support, it would only take 2 or 3 days..."
I know that not having Unicode supported in your web language is inconvenient, and at times is a show-stopper. But really. Give the guy a break. If PG doesn't want to "spend a single day on character sets". Don't ask him to spend a day on character sets.
If you want Unicode support in Arc, code it up and submit it.
If PG explicitly says "ok, I don't have time to do Unicode stuff now, but my idea is that a string is a sequence of characters, regardless of how a 'character' is represented", then somebody can go ahead to change Arc Unicode-clean (it won't be much work assuming MzScheme has support of Unicode).
If PG says "the language Arc (not mere an implementation) doesn't support beyond Ascii", then I feel that PG reserves that part of design (e.g. it may conflate byte-array and multibyte strings, or it may use richer character representation than unicode codepoint, such as a character object that holds the sequence of base char + modifiers, or it may hold raw byte array plus encoding info). In that case I hesitate to change Arc code without understanding PG's intention.
The freedom of the citizen of Hacker News to express himself is being suppressed! Paul Graham, add support for blink tags now!
I thought representative Lisp hackers liked long descriptive names over short cryptic ones? ;P
PS: I feel my karma's going to hell in 3, 2, 1...
edit: It wasn't a challenge. It wasn't "oh, I'll pretend to think my karma will go down to look like a cool rebel". Hope that clears things up.
What's the license, by the way?
As well, any bets on who writes the first book?
You could ask on comp.lang.lisp if you wanted some really well-informed opinions wrt the impact of Arc on CL, but I wouldn't advise it unless your skin is thick and flame-resistant.
http://groups.google.com/group/comp.lang.lisp/browse_thread/...
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?
P.S. Do you have a personal vendetta against the W3C, or something?
Nobody said I was going to be a highly efficient Arc programmer. :)
I see merits in standards compliance, but making my life easier is not necessarily one of them.
It seems backwards to me though, surely the most "semantic-free" approach is to default to divs rather than tables to structure the markup.
(That may change in future, but right now I don't think any mainstream tools assume markup is semantic. And in any case, tables aren't much moreso than divs.)
Depends on what you're talking about; anything that uses microformats does, for example.
Tools generally can't assume that tables are semantic, because they've been so heavily abused. That's not going to change though. Perhaps the best solution is a <yes-this-is-really-a-table> element.
> tables aren't much moreso than divs.
Would you say that a table in a relational database isn't much more semantic than a string of bytes?
But then I guess that is all part of exploratory programming.
Tables are meant for tabular data, and when you use them for layout it breaks those semantics, which in turn makes it much harder for screen readers to make sense out of it.
It's also just ugly, in my opinion.
This turns out to be a relatively poor user experience.
Right now that kind of thing is intractable because there's no easy way to distinguish a table-for-data from a table-for-layout. I think it could be cool to have some way of putting something in your page HEAD that means: "In this page, tables are used exclusively for tabular data: you can activate your reordering features".
Are you hoping to build a user community for Arc? If so, and why would you release Arc if you weren't, then why are you not interested in keeping track of changes that break things users might design/code against? Am I being stupid and missing something here?
Edit: I forgot to mention something else. Congratulations and thanks for sharing Arc with the rest of us :)
But, why should Arc libraries generate HTML at all, instead of a list?
So a hardwired table-HTML output isn't good.
The Scheme language sneakily increased the scope of the language designer's powers. From very early, maybe from the begining, the Scheme spec said that conforming implementations must do tail call elimination. The first time I read this, I thought "wait, can you require this in a spec?" Arc will see this increase, and raise it by some standards for profiling.
I thought that was a great idea. Too few languages have good support for profiling. Did the idea get dropped? I don't see anything obviously related in arc.arc or in the tutorial.
I wonder if PLT Scheme's profiling tools are good enough on Arc programs (or useful at all?). I hear they have pretty good ones, but haven't used them myself. Arc might be different enough from MzScheme that the information that the PLT profiler returns on Arc programs isn't so useful.
"We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."
Is that really wise? What's wrong with doing a simple changelog with every modification? Since you'd expect only experienced programmers to be using Arc, you don't have to hold our hand explaining the implications of the changes - but making us diff the source would probably be a bit much.
I mean it doesn't have to be verbose even. Or even tidy. This would be better than nothing:
* Added a global weak reference hash map to treat any object like a hash using {} syntax, ie, (= {someobj hashindexobj} 5).
* Hash idea sucked. Removed.