71–80 of 114 posts
This is from 1998, and Peter Norvig has long since switched to Python. "LISP - a Language for Internet Scripting and Programming", Timothy J. Hickey, Peter Norvig, and Ken Anderson LUGM'98: Proceedings of Lisp in the Mainstream, Nov. 1998, Berkeley, CA. As per http://www.cs.brandeis.edu/~tim/
Earlier quoted context omitted.
Once you "accept" transpilation,you can use any language in the browser and you stop asking yourself these questions. You still need to know javascript though. Dart,CoffeeScript,Typescript,ClosureScript... IT's not like people dont have the choice today.And sourcemaps work well when debugging,usually.
If we had LISP, we wouldn't really need CSS or HTML either. Everything could be represented with s-expressions and we would all reach nirvana.
Sexps are cool, but you really, really need proper tools to edit them efficiently. Without them it's very easy to make a mistake, which of course will make it to runtime, because it won't be a syntax error in most cases. That's the downside of having so little syntax.
So I think that (for CSS) we'd either build very simple sexp based DSL using macros or we'd just create a compile-to-sexps human friendly syntax. On the plus side, with Lisps, that would be one evening to implement... :)
> Simple debugging. This is an area where AI techniques could be quite helpful. Detecting and explaining common syntax and runtime errors is a crucial step in teaching a new language. Tools which provide this type of support could increase the interest in this language in the mainstream. Our current debugging support is minimal and provides only the basic commands: step, skip, and continue. I have given some thought…
For syntax errors, check out: http://research.swtch.com/yyerror It's not "AI" but I think it's a much more practical approach that any parser could implement, with enough work and feedback. I haven't used Go enough to know if this technique makes a qualitative difference on the friendliness of error messages. Interested to hear opinions.
Earlier quoted context omitted.
> Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in. That's quite a stretch. There are two browser plugins that are in broad use on the web: Flash, for fallback audio/video support and some casual games, and Silverlight, for Netflix. Both are dead technologies when you consider mobile web; even if you're only thinking about laptops/desktops, both Silverlight and Flash have essentia…
> Personally, what I'm hoping happens is that we get one, single better compile target That is a terrific idea in theory, but the last time anyone tried to do that the result was the JVM.
Incredible amounts of R&D devoted to optimizing its performance, broad hardware and os support, with lots of interesting languages to choose from running on top of it.
Earlier quoted context omitted.
> Dozens of what? Browser plugins? I don't have to imagine, that's the world we live in. That's quite a stretch. There are two browser plugins that are in broad use on the web: Flash, for fallback audio/video support and some casual games, and Silverlight, for Netflix. Both are dead technologies when you consider mobile web; even if you're only thinking about laptops/desktops, both Silverlight and Flash have essentia…
> Personally, what I'm hoping happens is that we get one, single better compile target That is a terrific idea in theory, but the last time anyone tried to do that the result was the JVM.
I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality.
That's not to say the JVM is perfect. I don't like type erasure for instance (I understand C# has 'better' generics). Nevertheless - and this idea comes up frequently - imagine if browsers ran VM bytecode instead of interpreting JavaScript. The browser would be totally language-independent. You could write in any language that compiles to the browser bytecode, and deploy the precompiled bytecode 'object' files. I mean, it is a great idea in theory, and it's exactly what the JVM has succeeded in doing, except that the JVM does it for operating systems and not browsers.
Of course, this is all a fantasy at this point. There's no possible way browser vendors would ever agree on a standardized virtual machine, much less all implement it (see DartVM).
Earlier quoted context omitted.
> Personally, what I'm hoping happens is that we get one, single better compile target That is a terrific idea in theory, but the last time anyone tried to do that the result was the JVM.
Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate? I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality. That's not to say the JVM is perfect. I don't like type erasure for instan…
No, I'm not trolling. I was responding to someone who said that the two non-dead browser plugin technologies were flash and silverlight. Java is notably absent from that list. (Can you even interact with the DOM from a Java applet?)
I agree with you that the JVM is the best part of Java, but that's not saying much IMHO.
I remember talking with him about teaching languages to kids. Like me he has three kids. I was noticing that many of the beginner languages were quite Lispy, including Logo which I had been teaching my oldest and I asked about the suitability of various lisps beyond this (I would end up going the direction of Rebol instead at this point, but plan to come back to Lisp).
His response was that for a beginner, Lisp is nice, but Common Lisp was, in his words, "too big" to be an early programming language, so one has to start small and work up.
I can't help but wonder at this. "Simplicity in the eyes of the user" is not something I have ever associated with Lisp as a whole but it seems like part of that is jumping into Common Lisp directly.
Now, none of this means one couldn't have a lisp for the web. However, we don't have one right now.
Earlier quoted context omitted.
Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate? I consider the JVM to be the best part of programming in Java. The JVM is fast, lets you write very portable code, and it gives you a great debugging experience. Plenty of other languages chose to target the JVM, like Scala and Clojure, for its quality. That's not to say the JVM is perfect. I don't like type erasure for instan…
> Are you trolling here, or are you really implying that the JVM is bad? Could you elaborate? No, I'm not trolling. I was responding to someone who said that the two non-dead browser plugin technologies were flash and silverlight. Java is notably absent from that list. (Can you even interact with the DOM from a Java applet?) I agree with you that the JVM is the best part of Java, but that's not saying much IMHO.
In an aside, the JVM has only relatively recently been an effective general-purpose compile target, and it wasn't designed as such. The JVM's failure for frontends doesn't give much indication as to where the pitfalls of targets like PNACL or asm.js might be: it died (deservedly) because of reasons that apply to neither technology — slow startup time and lack of effective sandboxing. Both PNACL and asm.js start quickly, lean on hardware-acceleration in the browser to react smoothly, are designed from the start as compile targets, and are sandboxed to the point where browser vendors don't feel the need to pop up warning boxes that scare off consumers.
Earlier quoted context omitted.
ClojureScript is a subset of Clojure that compiles to Google Closure-optimized JavaScript, so close enough, right?
Googling turned up several on just the first page of results: http://www.biwascheme.org/ http://sisc-scheme.org/sisc-online.php http://lisperator.net/slip/ http://alex.nisnevich.com/ecmachine/ But the parent is really the right answer -- ClojureScript is actually targeted at meeting modern web development challenges and has a thriving ecosystem of powerful tools for the same.
Pure Lisp, compiled for the user's browser and OS. No Javascript anywhere.
I was thinking about this too. I am somewhat of a lisp newbie, but one of the people on the LedgerSMB team also maintains Armed Bear Common Lisp (i.e. Lisp in the JVM). I remember talking with him about teaching languages to kids. Like me he has three kids. I was noticing that many of the beginner languages were quite Lispy, including Logo which I had been teaching my oldest and I asked about the suitability of vario…
We are at a point where JS is following the same path. Ideas like ECMAScript 4 were rejected because they would break compatibility and we are still working around the problems of JS. We need that clean break now rather than later. Such a clean break would be at it's best now rather than later. We could simply continue supporting the current JS compilers 'as is' for old code (or provide a JS to new language compiler) and replace the language with another which is designed correctly (we could perhaps break the DOM too).
While I would like to see a scheme r7rs used (except with support for OOP, built-in actors, and static typing), I suspect that M-expressions (more like dylan) would be necessary (though for the record, I've seen more nested parenthesis/braces in JS code than I've seen in a lot lisp code). Such a language could also be interpreted via JS (or compiled to JS) for old browsers (though I suspect telling people to upgrade or go without would promote suitable updating more akin to telling everyone to change to digital TV or go without).
We need a clean break and lisp is worthy of consideration rather than being cast to the side like last time.