To play devil's advocate, wouldn't the exact same thing be possible with the above alternatives and Armed Bear Common Lisp? You can write full-stack in Common Lisp, it's just that different parts need to go through different compilers/interpreters/transformers/what-have-you. Just as it is with Clojure.
No, I think the thing to note here is that Clojure--for reasons I can only guess at--has a lot more sex appeal than CL.
I think if Parenscript were just announced today it would get a big reaction as well. Just like there's a big reaction any time a language comes out and says it can compile down to Javascript. There was a big reaction when a guy did it for C# / XNA, for example.
Just because people are excited about developments in the Clojure ecosystem doesn't mean they aren't excited you can do this elsewhere. It's interesting right now because it's new, and it opens up some new ways of development for people who enjoy writing software in Clojure.
I could be wrong, but I think this is different. Are there any other languages that are both hosted on the JVM and also in Javascript VMs? Beyond that, there almost certainly isn't a lisp that is.
Parenscript doesn't have a runtime beyond what the JS implementation provides, so it's not really a Common Lisp running on JS, more like a way to compile Common Lisp-based DSLs to JavaScript. Red Daly's PSOS (https://github.com/gonzojive/paren-psos) library provides most of the runtime stuff, and I guess counts as a sort of implementation of CL. I've been toying with the idea of extending PSOS to a full CL in JavaScript.
x86 emulation is the wrong solution to this problem because of the difficulty of interop. Compiling to bytecode at least lets you treat JS functions as FFI calls. The first project to do this was Clue in 2008 (http://cluecc.sourceforge.net/), now all the hype is about emscripten (https://github.com/kripken/emscripten) LLVM bytecode to JS compiler.
Doing compilation GWT/Clojurescript style is going to reduce integration overhead. So far I haven't seen anything that integrates as well as Parenscript.
This is probably missing the point, but JavaScript is hosted on both the JVM and JavaScript VMs (thanks to Rhino). By extension, everything that compiles to JS is hosted on both.
possible with the above alternatives and
Armed Bear Common Lisp?
Yes it is. I wish being possible was all that it took for it to be done. In the absence of ClojureScript I would love to write my web client code in Common Lisp. I love Common Lisp.
In addition to sparing me from System.out.println verbosity, it's really useful in situations like the above where the value you want to print isn't bound to a variable.
What's to stop me from a) Submitting multiple requests b) Using a bot to submit a LOT of requests to bug the heck out of someone c) Using a bot to submit a LOT of requests and DOS betannoyer.com ?
Internal Server Error the first time I tried to load comments. (And every time afterwards.)
And it's kind of a bummer not to be able to log in and comment, upvote, etc. I understand it's a MVP though, so presumably that's coming. I'd offer to help a little, but I know Python, Lisp, and Java--not PHP, JS, and CSS, so sorry.
Also: I take it that you have to be in the top 10 to get something? Or is it that the top 3 get something, and 10 others are randomly selected to win a book? The award system is not explained too clearly...
Ah, I'll mention this could be cleared up. It's the top 3 people get the 1/2/3 prizes mentioned. The raffle is run amongst everyone who plays at all. So even if you just tweet or like the thing, or take the minimal amount of time to enter, you are elegible for the raffle. So you don't have to be anywhere near the top 10 to win a javascript ebook.
...and I was feeling reasonably good about reaching #18 efficiently. But don't really have the time to burn to claw my way up another 15 places. I was hoping that the raffle would be weighted by the number of points you have...oh well. Time to just hope I'm lucky.
By the way--thanks for babysitting this thread and responding to everyone.
Ah, yes, weighted raffles. We'd love to have weighted raffles. We were fooling with that awhile ago, but there's a sticky legal point. The whole no purchase necessary clause. If we had weighted raffles it sounds like we'd need a way for people to send us a postcard and have equal treatment as the highest person on the leader board with the raffle. That didn't sound fair. We'd love to figure out a way to do it though.
public class Singleton {
private static Singleton self = null;
private Singleton() {
//...
}
public static Singleton getInstance() {
if(self == null) {
self = new Singleton();
}
return self;
}
...
}
So at any point in your code you can call Singleton.getInstance() to have access to the same Singleton object. So it's effectively the same thing as a global variable.
Edit: the class version of the singleton example should also be made final, or I could just extend your class and therefore bypass your singleton restriction.
What are the advantages of instantiating the Singleton object in multiple different locations rather than, for example, using the Singleton class itself as an object with various static attributes and methods?
Thread safety is the same whether you use a static instance or plain static methods. In fact with all static members you don't have to worry about synchronizing initialization of the singleton object which is often done wrong.
The only reason to use a singleton over static members is that it feels like OO. I suppose it also makes it easier to replace the singleton with a 'multiton' at some point in the future which somewhat justifies it.
There isn't a clean way to initialize all of your static properties doing it that way. If you're using a language that has accessors you can call a private init method, but you have to do it for all of the properties. Or you can just use methods, but again you have to remember to call init at the beginning of them all. Or you could have a public init() and just remember to call it when your application first launches. Using a singleton is a natural way to have an entry point towards initialization. You can also have the best of both worlds by using static properties/methods that point to the singleton version.
In Java/C# you can use a nested class to ensure thread safety and cheat towards having your static methods. For example:
private int Foo() { }
public static int Foo() { return _instance.Foo(); }
As a big CLI fan, I mostly agree, especially with respect to launching programs. But as far as I see there's two big obstacles: 1) Many names are somewhat-obscure in the interest of shortness. But are therefore a bit harder to remember. Compare "ls" with "list-files". 2) Many programs (especially interactive programs)--text editors, office programs, file managers, web browsers--are, I think, more intuitive with a mouse. Want to open that link or edit that textbox? Click it. Want to move that file? Drag it.
Both with essays and coding, there've been times when I was very grateful that there was a fixed moment in the document's life that I could easily go back to. Sometimes I start making changes and then think better of it[1]. Sometimes I edit something accidentally, and am very relieved that I'm asked whether I want to save my changes upon exiting the program. A possible solution is to have both normal saving and continuous autosaving to a backup file (as Word, Vim, etc. all do), but in practice that's a bit clunky.
[1] - Yes, I could hit the undo button repeatedly, since any editor worth its salt will have a virtually-unlimited undo. But it's reassuring to know that you've undo-ed to exactly the right point--in Vim, at least, the "+" indicating a modified file disappears once you've undone all your changes.
Yeah, working with code is interesting because a source file is rarely in a “stable” state when it is being edited. The save button in this case serves as a checkpoint marker: “this here is good.” It's like doing mini-commits.
If we were to do away with the save button, the rest of the “working with files” story would have to be thoroughly rethought.
Many icon sets (on Linux, at least) use a picture of a hard drive instead of a floppy [1]. Which, though more correct, still worries me. Anybody who recognizes the icon as a picture of a hard drive isn't going to be confused by the concept of saving...do we need a similar icon that uses a picture of an entire computer instead? Should it be a laptop or desktop?
Save-as also provides the function of being able to save to different media/locations. Furthermore, it is easy. Power users already have their more powerful alternatives and non-power users are used to what they know.
How many times have you heard someone complain they failed to save their work? It just shouldn't happen - the computer knows exactly what was inputed - why should it ever lose track of it.
The "Save" function is a carry-over from the time when storage was expensive and slow, and humans had to make decisions about what was worth saving. Now, computers generate a lot more useless logfiles that are saved forever than a human can possibly generate using a word processor, and yet we are asked to make a decision about if we really meant to put out inputs into a computer.
That shouldn't happen any more, and with good software it doesn't.
In Google Docs - for example - there is no "Save" function - it happens everytime you press a button. There is no "Save As"; instead there is "Rename..", "Make a Copy.." and "Download As.." which perform the distinct functions rather than overloading "Save As.."
I have no idea what point you are attempting to make. Non-power users don't need full-blown version control, there are plenty of more straight-forward ways of making sure users don't lose their data than that. Save-as is not mutually exclusive with automated backup systems, or undo systems.
Furthermore, nobody is forbidding them from using the tools "power-users" use. The only difference between power users and regular users is what tools they choose to use.
I have no idea what point you are attempting to make.
Do you believe the solutions we have today are decent enough and cannot be improved further? I wish handling files was so simple that even those you call “non power-users” (i.e. pretty much everyone) could work with versioned files.
"I wish handling files was so simple that even those you call “non power-users” (i.e. pretty much everyone) could work with versioned files."
We have that already, it's called persistent undo and/or save as. Stunningly, a versioning system designed for the technologically illiterate doesn't measure up to one designed for coders.
Auto-save is a separate issue, but we have that as well...
No, I think the thing to note here is that Clojure--for reasons I can only guess at--has a lot more sex appeal than CL.