Stdout munging looks like the easiest option, really. :-p
---
"Also, arc currently uses sha1, and I updated anarki to switch to sha512. This will break existing passwords."
A way to fix this is to annotate each hash with information about which algorithm was used to make it. As users log in, hash their input both ways, and replace the stored hash on success. All of PHP's hashing functions automatically prepend algorithm information to the result, and PHP has a corresponding feature to verify that a hash (annotated with algorithm information) matches a document. PHP's format isn't very elegant, but it's the closest I've seen to a standard. (Not that I've actually seen it implemented anywhere but PHP, but that PHP developers who want to migrate to another language will end up having to parse this format from their databases and either migrate it or code to it.)
It's worth noting that one pass of sha512 isn't very secure, since the speed of the algorithm makes it easy to reverse a compromised hash by comparing it to the hash of every possible password. I'm not sure what the state of the art is, but one very common recommendation is bcrypt: http://codahale.com/how-to-safely-store-a-password/
"I think it’s important to attract the programmers who Graham says are “the masses” or non-hackers. Without them, the real hackers won’t come to your language en masse either."
I'm not so sure about this conclusion. World-class hackers may be so preoccupied with deeper breakthroughs that one particular fledgling language isn't on their radar, sure. But the masses probably won't adopt a language unless their relatively nerdy friends, those who are willing to bend and break social norms to find better alternatives, have already used the language and recommend it.
First, you need people who want to buy a pain reliever. While it's a huge market, it's not for everyone. Once you find people who buy pain relievers, then you need people who want to buy a new kind of pain reliever. After all, plenty of people want the "original" kind, the kind they grew up with. Finally, you need to find the people who are willing to listen to what you have to say about your new pain reliever. The vast majority of folks are just too busy and will ignore you, regardless of how many ads you buy. So you just went from an audience of everyone to an audience a fraction of that size. Not only are these folks hard to find, they're picky as well.
[...]
The old rule was this: Create safe products and combine them with great marketing. Average products for average people. That's broken. The new rule is: Create remarkable products that the right people seek out.
[...]
Differentiate your customers. Find the group that's most profitable. Find the group that's most likely to influence other customers. Figure out how to develop for, advertise to, or reward either group. Ignore the rest. Cater to the customers you would choose if you could choose your customers.
[...]
Think small. One vestige of the TV-industrial complex is a need to think mass. If it doesn't appeal to everyone, the thinking goes, it's not worth it. No longer. Think of the smallest conceivable market and describe a product that overwhelms it with its remarkability. Go from there.
) ; end excerpt
There isn't much hard substance in this excerpt, just some philosophy and an appeal to authority. Nevertheless, it's at least as good as what I could have said. :-p
---
"Another problem for Lisp is that the rest of the world doesn’t think or work like Lisp."
Actually, when I look at how programmers of non-lisp languages get things done, I'm regularly surprised to see how much they behave like lisp programmers.
Programmers often make EDSLs and custom parsers and preprocessors to model their problem space. Just look at Ruby on Rails, C's Yacc, and Template Haskell.
Programmers often represent their code using ad hoc structured data instead of flat text. Just look at Ant's use of XML for build scripts and MongoDB's use of JSON for database queries.
---
"It’s not hard to realise that people expect [...] to be able to call fork and have a new operating-system–level process appear."
This is a case where I'm personally oblivious and might not know what I'm missing. :)
"This also means Lisps should have an object system."
That came out of left field. Based on the context, it sounds like the point of having an object system is to communicate with standard object-based APIs. But object-based APIs don't all use the same object system, so which one(s) should lisps have?
---
"This also means Lisps should have an object system. I think a basic Lisp on its own provides enough functionality to implement a good-enough object system, in much the same way that Perl’s bless gave way to frameworks like Moose. With lexical closures, a native symbol kind, and cons pairs, we can do everything any other language’s object system can do."
How does that justify adding an object system? If basic lisps already have all they need, that seems more like an argument against.
---
"[other factors] + following the Unix way = success"
I would suggest replacing that with "following the client-side Web way," but I'm afraid the result would be "success + ball of mud" either way. ;)
The rest of the world may have "pretty good reason[s] for doing things the way it does," but if a language designer fails to understand those reasons and blindly goes for standards-compliance, they won't just reap the benefits; they'll also propagate and entrench the existing defects. Admittedly, the benefits will often be worth the risk.
> "I would say Racket is exactly the language the article is begging for"
Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date. So I don't believe racket meets this criteria highlighted in the article.
> "This also means Lisps should have an object system."
I'm guessing here, but I believe he's referring to an object system that incorporates high level features such as objects + instances with inheritance etc etc. He should probably read pg's Common Lisp book where I believe pg suggests that a oo-system is a great architecture that is well suited to a small set of projects and unfortunately programmers have learned to apply that system to everything they do simply because the oo-languages force them to do so (what they learn is what they know). He goes on to suggest that most projects would be more aligned with FP language paradigms (ie don't force extra layers of complexity where it's not required). And additionally that these oo features are easily implemented in FP languages should you want them ... Don't quote me on all this...I'm going off memory from reading his book over 5 years ago.
It also could be that he sees other FP languages having oo-systems ... I.e. Doesn't racket have the cobra or corba? for an oo-system? Never used it; so again I'm just going off memory here.
"Racket does not provide any real depth for libraries. There's a lot of promoting for library depth, but as soon as you attempt to do anything practical you soon realize the available libraries are either really rough drafts or are largely out of date."
I've gotten the same impression of Racket libraries, but going by the article, mass-marketing of Racket would be a good way to end up with active libraries: "In other words, if you have people who need libraries, hackers will write them. When you have more libraries, your language looks more attractive to people who need them, so hackers write more of them[...]"
This rings true for me. I think Arc has experienced this phenomenon firsthand.
Anyway, although Racket lacks a variety of libraries, it has an impressive selection of features out of the box.
---
"Doesn't racket have the cobra or corba? for an oo-system?"
Racket has at least a few systems for stateful values with user-defined fields:
I haven't used any of these systems (aside from hash tables, I guess). I rarely use Racket, and when I do, I'm still getting the hang of its module system, lol....
"if a language designer fails to understand those reasons and blindly goes for standards-compliance, they won't just reap the benefits; they'll also propagate and entrench the existing defects."
Replace 'language designer' with 'programmer' and that's my whole philosophy in a nutshell.
In fact, I'd like to even generalize this past software. I was in London over the break and found this really cool looking chair everywhere with a pocket in the seat back: http://i.imgur.com/rTO8O.jpg. It looks quaint, and it's everywhere, and I kept wondering, what's the use case? What misfits[1] did the designer consider in building it? I could try to think up a few scenarios, but it's deeply unsatisfying to me to not know.
I'd love to live in a world where I can query objects I interact with for their creators, their antecedents, the design process they went through. What was the designer optimizing for? I have no idea how to do this for the real world, but perhaps one can take a stab at this for software? I think if we were better at communicating and managing the design choices made by our various software 'abstractions' we wouldn't need them to be abstractions anymore[2].
To answer your question about the chair - it's seating for a church or chapel. Prayer books and hymnals are kept in the pocket on the back for the use of the people in the row behind.
Ah, many thanks! I now imagine one of the many ancient, stark, beautiful churches that dot London getting rid of their ancient chairs somehow, to be eventually purchased at discount by hipster coffee shops, resulting in unbelievers like me being able to enjoy them. This mental image connects up several memories of my trip, and immeasurably enriches my world.
"This process allows [many] continuations captured by your servlet to be serialized. This means they may be stored on the client’s browser or the server’s disk."
Oh, I was particularly responding to "It also turns out that there's at least one company trying to scale continuation-based servers," which you said afterward. Guess you chose the example you chose, no worries. ^_^
Ah, good point! I didn't think of it then (I think I even had the racket link in the textarea in a different context before I ended up dropping it to the floor.)
It was about a year and a half ago that I started thinking about the ethics of creating computational people, even if that isn't near on the horizon. I've now come up with a sketch of a computational model that I believe will help steer the world in a peaceful, fulfilling direction, and I describe it in this blog post.
RKN (Reactive Knowledge Networking) isn't going to be practical for a while, and by the time it is, it may be not very much like what I describe today. However, this is now the kind of programming I'm working toward.
I hope I get around to finishing some of my vague language ideas someday, rather than pushing them ever further out of reach. :-p
"..indentation is not affected by the lengths of identifiers. It’s silly to format code in such a way that you need to re-indent just because you renamed a function."
That silliness is hard to avoid. If we don't use word wrap, we have to re-indent code when an identifier changes just so things stay on the screen. To avoid that re-indentation, we should probably redesign our text editors, diff tools, and languages so word wrap isn't a pain to work with. I think I'd rather do a little re-indentation for now.
---
It's not quite the same topic, but for a long time,[1] I've considered indentation an enemy to brevity. All that wasted whitespace! :) Arc's a:b ssyntax is great at eliminating levels of indentation.
I don't quite know why, but I like to be pretty strict. I keep every line at 70 spaces long or less, with tab stops every 4 spaces, except for the following scenarios:
- Commented-out lines of code.
- A line of code that just can't be broken up any further. But first I try to move this line to a less indented part of the code, and then I remove other indentation on the line until it fits the best it can.
- Code that someone else has already made too long by my judgment. I try not to change someone else's style if my cosmetic change would obscure the meaningful changes I'm making, or if it would introduce inconsistency in the codebase. In this case the codebase includes any part of the revision history, branches, forks, and related projects that might be reintegrated.
In college I used 80 spaces, but that turned out to be too long to fit on my Wordpress layout without scrolling.
---
I thought it was also too long for Arc Forum, but it seems that's not true. Looks like Arc Forum supports 83 characters, at least on my user agent.
When I switch from Chrome to Firefox, it looks like the 84-character line doesn't scroll anymore. In general, I bet it depends on the browser's default fonts and such.
"Either way I think Arc would be a great fit for creating iOS apps as Arc has much simpler language constructs and mutability/concurrency wouldn't be as big of an issue given the localized nature of mobile code."
Sorry, I think I'm not catching all the context of this sentence. What language's "language constructs" are you comparing with Arc's? (Objective-C? Gambit Scheme? Racket?) What environment with "mutability/concurrency" issues are you contrasting with "mobile code"? (Server programming?)
I've only barely done any iOS programming, but I've done a bit of work on Android apps, and Android organizes rendering and event handling onto different threads.
Arc has fewer data types and consequently there are less methods/means required to interact with them. For example clojure has at least a dozen collection types (sets, various types of maps, vectors, seqs, lists, cons, etc, etc...) while at the same time having a variety of methods used to access them (atoms, refs etc).
This variety creates depth to the language, but it also makes the language more complex (even if appropriate). For example even the terms overlap creating confusion... I.e what's an 'atom' ? what's a 'map'? ifn? vs fn?, why does a vector get treated as a function?
So each of these "constructs" serve a purpose, some of which are to deal with state and time, or shall I say concurrency and mutability which often have to do with parallel computing or managing concurrent threads which all operate on the same object or data structure.
Currently Arc is limited to a very small set of data structures and methods to interact with. I believe arc still deals in mutability only, relying heavily on queues to manage state and time. Either way Arcs minimal set of constructs are probably well suited for many mobile code applications given you only need to manage interaction from a single user.
I pasted your DOM demo code twice, and then I was able to access both window.x and window.x2 from within Nulan. Is this intentional?
I also appended some DOM elements to the parent frame using "window.parent.document.append-child x", and they didn't get cleared on each update, but that's my own fault I guess. :-p
"I pasted your DOM demo code twice, and then I was able to access both window.x and window.x2 from within Nulan. Is this intentional?"
Yes, absolutely. It's how Nulan ensures that every variable is bound to a single "box". This also has the nice property that all the different "versions" of a variable can be accessed from the JavaScript side.
Ordinarily you can't access the different versions from within Nulan, but "window" is one of the ways you can do so. Another way would be the "&" macro which bypasses the Nulan compiler.
---
"I also appended some DOM elements to the parent frame using "window.parent.document.append-child x", and they didn't get cleared on each update, but that's my own fault I guess. :-p"
Yeah, only the <iframe> is sandboxed. Of course you can refresh the page to clear it out. Don't worry, it'll save the text you typed in the textarea.
Good luck with your project. :) I don't know how far you'll get unless you do some coding, but it's great to see you were able to complete the installation.
---
"If you have free time, please instruct me how to customize the default color top bar (gray, not yellow like ARC forum or Hacker News)."
I'll tell you my step-by-step progress:
In Chrome, I right-click on the top bar and select "Inspect element." This causes the developer tools pane to appear. I fiddle with a bunch of colors, all "#b2b2b2" and "grey," but they're all text colors and border colors, not background colors. Finally, I find the tag that says <td bgcolor="#B4B4B4">, and modifying that color seems to work.
I search the Arc code for "B4", but I find nothing. So I convert B4 from hexadecimal to decimal and get 180. When I search for 180, I find two lines in news.arc that use this color:
Looks like the top of news.arc is a good place to configure the look and feel of the site. Arc Forum uses #ffbb33 = (color 255 187 51), and Hacker News uses #ff6600 = (color 255 102 0), so these might be the changes you're looking for. :)
---
"I re-configured httpd.conf file inside the apache2 folder but I did not work. I used command line to restart apache2 and the server responded that the was a syntax error on the file."
Can you show us what you changed? What's the exact error message?
On this forum, if you put two spaces in front of each line, it will
be formatted as code:
On this forum, if you put two spaces in front of each line, it will
be formatted as code:
On this forum, if you put two spaces in front of each line, it will
be formatted as code:
---
"BTW, I can only run ARC on my VPS by connect via VNC with a simple GUI to "activate" it."
Well, I had a VPS briefly, and I couldn't figure out how to access it with anything but PuTTY. It was pretty frustrating. Having a GUI must be nice. :-p I'll have to give VNC a try someday.
Are you looking for an even better alternative of some sort?
Thanks for your help rocketia :-P. Here are some of my thoughts and experiences after following your guide.
1/ I often use WinSCP instead of PuTTY on Windows to control VPS. Of course, we can only interact/manage the virtual private server via commands line, but in the case WinSCP helps me to upload the files easily. I tried to use fluxbox (a lightweight GUI for Ubuntu) and VNC to remote connect the server and use the "original" terminal to run racket and ARC forum. As far as I tested, whenever I turn off terminator/SSH window on Windows, the ARC forum will turn off as well. So there is no other choice for me to run source code.
2. Thanks for your investigation, however, the color on the front page does not change from grey to yellow/orange like Hacker News or ARCforum. I found out that the <tag> is "bgcolor", not "border-color", so it will not run even you tweak the code on the top of news.arc file. I believe that we need to change the color of the forum by "dealing" with html.arc file. I got the tag bgcolor (line 86) in that file but not sure how to change.
3. One of the most problem with me right now is how to "forward" the default port on racket server from 8080 to 80 which is default port of Apache. When I tried to configure my httpd file inside apache2 according to this instruction
http://nicholasblee.com/blog/hacker-news-clone-on-a-free-aws...
but it does not work. So that is the reason why I have to access the ARC forum by typing the port 8080, otherwise the apache will run the 80 port with a blank page.
Here is what I add to /etc/apache2/httpd.conf
<VirtualHost :80>
3b. You don't forward racket to port 80, rather you're supposed to forward incoming requests that come to apache/nginx (which comes in via port 80) over to port 8080 or whatever port you choose to run the arc server on. This is called proxy or gateway passing.
Assuming you stick with apache, I'm still not familiar with your proxy passing implementation. It looks more like a hack using a load balancing mechanism for proxy passing and unless you're load balancing I wouldn't use it. When I used apache in the past I would load the mod_proxy module then do a normal 'ProxyPass'. You should configure according to the docs: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
Finally it works. I have decided to switch to nginx and with only few tweaks, I can now run on 80 port, the default port of nginx.
Here is the simple code to do that on etc/nginx/nginx.conf
server {
listen 80;
server_name bloggervietnam.com www.bloggervietnam.com;
location / {
proxy_pass http://127.0.0.1:8080;
}
Remember to put this code inside http tag otherwise it will cause error. You can check nginx configuration by typing : nginx -t and then restart nginx. It works!
1. I just install screen and fortunately it works well. I just hit F6 button to detach my terminal session. That is why I removed fluxbox GUI for saving RAM and resource.
2. I follow the help above and now I can chance the color of the forum.
3. I have not solved the matter yet since apache did not work despite that I already installed necessary modules as you mentioned.
I may switch to nginx for a try. Thanks for your care again :-)
"I like how in PHP, variable references always have dollar signs attached. If you bring the mindset of a computer scientist only, you might say, well, the dollar signs are obviously to simplify the tokenization; if you can solve this engineering problem, you should get rid of them. But I think it probably makes a difference in helping your brain's "tokenizer.""
PHP took sigils from Perl, where Larry Wall said "Things that are different should look different" and used different sigils for different types. However, sigils in PHP, Perl, and shell syntax all make string interpolation possible, which is more of a tokenization issue. So I think sigils probably exist in PHP for both reasons.
As a side note, Groovy uses $foo or ${foo} to mark string-interpolated expressions, but that $ isn't used in other circumstances. It uses the sigil only where the tokenization really demands it.
Personally, I consider "different things should look different" to be a good justification for lisp syntax. If macros are really going to give programmers the power to make the language syntax their own, then language-imposed irregularity is at cross purposes with that open-endedness. I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things.
---
"The author goes on to describe how these things determine where your eyes land and then move over the page, which consequently determines how easy or hard it is to make sense of; remarkably, it was true, as you can see from the examples."
Does the author just describe and demonstrate these things qualitatively, or are there also references to quantitative studies?
This is Arc Forum, where the regulars already know how to read lisp syntax. We may try to look at our culture with fresh eyes, but it isn't easy. And as I hope you can see, I justify lisp syntax for qualitative reasons similar to the ones you use against it, without really disagreeing with you.
Hard numbers are the kind of thing that would clarify which of these arguments should win, so that's what I hope to find in a thread about "concrete, objective reasons." I'm not surprised or offended that this discussion hasn't focused on the numbers, but I am a bit disappointed.
From the article: "Bonnie Meyer and others tried to use organization as a measure of reading ease. While this did not result in a formula, they showed that people read faster and retain more when the text is organized in topics. She found that a visible plan for presenting content greatly helps readers in to assess a text. A hierarchical plan shows how the parts of the text are related. It also aids the reader in blending new information into existing knowledge structures."
There's one point potentially in favor of object-oriented programming, where some of the inheritance and data-and-behavior bundling may be formally unhelpful, but (I feel) it does establish an informally organized structure over the code. On the other hand, it's almost never exactly the organization I feel is ideal for conveying my own program. Grr, subjectivity again. x_x
"If macros are really going to give programmers the power to make the language syntax their own, then language-imposed irregularity is at cross purposes with that open-endedness. I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things."
That's the beauty of Nulan's syntax system: it is almost completely customizable, feels very "Lispish", and plays very well with macros. You can now have your short syntax and the benefits of "code is data is code".
Even wart's system works pretty damn well, despite being much less powerful, because it has very simple rules for how to handle things.
I think the key to making syntax play well with Lisp is to make sure the syntax has a certain amount of simplicity and consistency, and is customizable. Basically, the syntax needs to follow the list structure. Beyond that, you can make it as crazy as you want.
>> PHP took sigils from Perl, where Larry Wall said "Things that are different should look different"
I didn't know that. Perl seems to me like a monstrosity. But I'm sure there are worthwhile aspects to it.
>> language-imposed irregularity is at cross purposes with that open-endedness
I agree. There seems to be a trade-off between flexibility and readability.
>> Does the author just describe and demonstrate these things qualitatively, or are there also references to quantitative studies?
It's not that kind of a book.
>> I justify lisp syntax for qualitative reasons similar to the ones you use against it
I'm not trying to argue against Lisp. I've proposed that there may be a trade-off between flexibility and readability, and Lisp sits at one end of that spectrum.
>> Bonnie Meyer and others tried to use organization as a measure of reading ease. While this did not result in a formula, they showed that people read faster and retain more when the text is organized in topics.
The kind of readability I'm talking about is at a much smaller scale, like being able to recognize a function call or a loop.
>> There's one point potentially in favor of object-oriented programming, where some of the inheritance and data-and-behavior bundling may be formally unhelpful, but (I feel) it does establish an informally organized structure over the code. On the other hand, it's almost never exactly the organization I feel is ideal for conveying my own program. Grr, subjectivity again. x_x
I agree. I think one of the problems with OOP is that it tries to organize everything into hierarchies. Most things in the real world don't fit into neat hierarchies.
Think of the problem of finding things on the web. Before it morphed into something else, Yahoo was about organizing the web into a hierarchy. Search engines, in contrast, are not hierarchical. It's clear that the search engine approach has won out over the Yahoo approach.
rocketnia: ..Larry Wall said "Things that are different should look different"..
In the beginning, Perl was a simple language. It generalized awk with user-defined functions[1], explicit file handles (STDIN, FILE) and array variables. With the idea that different things should look different, you got sigils to namespace arrays and scalars away from keywords and the standard library[2].
Over time, however, it got more line-noise. % for hashes. & and -> for references. Constants like $_ got added, positional arguments. When you consider all the primitives and capabilities in the language today, do array/scalar variables really deserve their sigils? It feels a little like hungarian notation now that the standard library includes so much more than just functions on strings and arrays.
It's all very well to say "different things should look different", but "different" isn't some absolute property. Programming languages are human things, and subject to human limitations. Our visual and frontal cortex gets swamped by too much "difference". So we need to pick carefully what to make salient. And, above all, not paint ourselves into a corner with our early decisions.
rocketnia: "I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things."
nburns: "The kind of readability I'm talking about is at a much smaller scale, like being able to recognize a function call or a loop."
The advantage of lisp isn't necessarily that it forces you to do without syntax entirely. Perhaps it is that it allows syntax to be tuned by project/codebase, to make decisions in the small based on the characteristics of the whole.
For several months now I've been sporadically mulling this rambling paper: http://davewest.us/pdfs/ducks.pdf. I'm not sure what it's trying to say, but the lesson that sticks to my mind is that of the Tibetan Thangka, arranging a number of stories spatially for maximum memetic power. A program doesn't have to be just a list of functions, macros, symbols and calls. Or indeed a long list of user stories. I'm starting to believe that it matters how things are arranged in the small, because it can help grasp how things are arranged in the large, help the program to get into my head, ensure I understand how it is organized in the large, keep me from messing up the architecture with my changes, and thereby help preserve the program's coherence over longer periods of time.
[1] nawk -- the first version of awk with user-defined functions -- was released in 1988 (http://en.wikipedia.org/wiki/AWK). Larry Wall had already released Perl in 1987.
Wow... thanks for the awk history lesson. I didn't learn awk until about 10 years ago, but now it's one of my favorite programming languages. It's a fine example of a domain specific language.
My experience with lisp is basically limited to scheme, which is a major bias, I'm sure. I get the feeling that common lisp is a bit friendlier, and makes things like user-defined macros a bit easier. The scheme documentation on the web is not all that user-friendly, and I'm forced to confess that I've never created a macro.
