3 ms·

> python can't be directly included in Firefox or other browsers So Python is a bad candidate, but there are better candidates out there. For example, jsofocam

by vog 12y ago

> python can't be directly included in Firefox or other browsers So Python is a bad candidate, but there are better candidates out there. For example, jsofocaml (using OCaml in the browser) looks quite promising. In the end, we need a lightweight yet properly defined and highlevel language, and the ML languages as well as the LISP languages are great candidates for that.

maximilian 12y ago
Purescript is a Haskell-like language that is designed to output to javascript. It looks quite nice and has seen a lot of attention lately. It's even in GSoC.
- magmadiver 12y ago
  Also, ClojureScript.
- arianvanp 12y ago
  plus its semantics lie pretty close to javascript. Most importantly because it's strict instead of lazy. Eventhough its strict it has a very haskelly feel. Both in syntax and type system. Also I think strict semantics is the way to go for efficient Functional Reactive Programming. Furthermore, Purescript's FFI is really nice to use and it's really easy to bind to existing javascript libraries. PureScript is community is nice and active. They are also discussing a lot with the `virtual-dom` guys to bring react/om/mercury-like functionality to purescript [0] and it's quite freakin awesome. Seriously I'd take purescript for javascript any day. I think it's great that we FP folks can finally do frontend dev :-) [0] - https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen
- akst 12y ago
  Purescript is interesting, I've been trying to build a project in it over the last few months. Since it's still pre 1.0, it has proven difficult but understandably so. It's mostly due to arcane/vague error messages (which they're in the process of dealing with), painfully long compile times, (imo) a few missing features, and incomplete young libraries. On the flip side, with the state of libraries and all, it's provided me with a real incentive to get involved in open source, by having to contribute patches to said libraries and getting actively involved in general discussion. Edit: Just so I don't come off as mostly negative, I do enjoy having purescript as another statically typed option on the client side with close semantics to javascript. It's also been nice having a some kind of parsec like library on the client side (purescript-parsing), which was the main reason I chose purescript for this project in the first place.
- dheera 12y ago
  The problem I have with "output to Javascript" languages is that debugging becomes hell. Line numbers no longer correspond to each other, for example. A slightly less-hellish but still annoying problem is that I often poke at things directly from the console when bugs happen, and this helps me a lot in debugging. However poking at the console requires using JavaScript, which is fine, but it would drive me nuts to have to code in one language (e.g. CoffeeScript, TypeScript, Python) and debug in another (JavaScript) and switch my brain back and forth every few minutes. So I've ended up largely sticking with writing code directly in JavaScript. Any good solutions to this? Are there replacements to the Chrome JavaScript console that supports those other languages?
  - Psyonic 12y ago
    Are you using source maps? If so, you can actually put breakpoints in your other source and Chrome will still break on it. I've even done this with Scalajs.
stock_toaster 12y ago
> In the end, we need a lightweight yet properly defined and highlevel language.... Even lua would be a joy!
- espadrine 12y ago
  Out of curiosity, what would make Lua valuable to add in browsers by default? It is similarly prototype-based, has the same closure design, is dynamically typed, has an object system fairly similar to JS (with the type of arrays and hashtables both mixed), and its number system is also based on floating-point numbers… I honestly don't see how we can justify the cost of adding Lua to browsers. I see the merit of Lua-to-JS compilers (existing codebases or sheer love of the syntax), but built-in?
  - trynumber9 12y ago
    Lua 5.1 (2006) has lexical scoping, tail calls, multiple return vales with assignment lists, semicolons are actually optional & most importantly: coroutines. ES6 adds some of these features. Lua 5.3 has both integer and floating-point types.
Macha 12y ago
I believe the issue is politics. I.e. browser vendor A (any vendor) can't unilaterally introduce a programming language and expect others to follow. (MS tried with VBScript, Google gave up on doing so with Dart, for example) This applies equally to any language.
vog 12y ago
Not sure why this was downvoted. Does anyone care to elaborate?
- toyg 12y ago
  I didn't downvote, but I don't think the problem has anything to do with specific language features. It's purely a political issue: you have to get at least two or three main vendors to adopt the new language at the same time, and none of them must perceive it as a threat to its own agenda. For that to happen, all of them must release compatible implementations that put everyone on an equal level at the exact same time, which is really hard to accomplish. It was very hard even to get javascript where it is now (remember the browser wars and all the incompatible extensions it spawned... ?), starting again from scratch with any new language would be extremely difficult, regardless of how "nice" the actual language is.

by vog 12y ago

maximilian 12y ago

Purescript is a Haskell-like language that is designed to output to javascript. It looks quite nice and has seen a lot of attention lately. It's even in GSoC.

magmadiver 12y ago
Also, ClojureScript.
arianvanp 12y ago
plus its semantics lie pretty close to javascript. Most importantly because it's strict instead of lazy. Eventhough its strict it has a very haskelly feel. Both in syntax and type system. Also I think strict semantics is the way to go for efficient Functional Reactive Programming. Furthermore, Purescript's FFI is really nice to use and it's really easy to bind to existing javascript libraries. PureScript is community is nice and active. They are also discussing a lot with the `virtual-dom` guys to bring react/om/mercury-like functionality to purescript [0] and it's quite freakin awesome. Seriously I'd take purescript for javascript any day. I think it's great that we FP folks can finally do frontend dev :-) [0] - https://github.com/slamdata/purescript-halogen https://github.com/slamdata/purescript-halogen
akst 12y ago
Purescript is interesting, I've been trying to build a project in it over the last few months. Since it's still pre 1.0, it has proven difficult but understandably so. It's mostly due to arcane/vague error messages (which they're in the process of dealing with), painfully long compile times, (imo) a few missing features, and incomplete young libraries. On the flip side, with the state of libraries and all, it's provided me with a real incentive to get involved in open source, by having to contribute patches to said libraries and getting actively involved in general discussion. Edit: Just so I don't come off as mostly negative, I do enjoy having purescript as another statically typed option on the client side with close semantics to javascript. It's also been nice having a some kind of parsec like library on the client side (purescript-parsing), which was the main reason I chose purescript for this project in the first place.
dheera 12y ago
The problem I have with "output to Javascript" languages is that debugging becomes hell. Line numbers no longer correspond to each other, for example. A slightly less-hellish but still annoying problem is that I often poke at things directly from the console when bugs happen, and this helps me a lot in debugging. However poking at the console requires using JavaScript, which is fine, but it would drive me nuts to have to code in one language (e.g. CoffeeScript, TypeScript, Python) and debug in another (JavaScript) and switch my brain back and forth every few minutes. So I've ended up largely sticking with writing code directly in JavaScript. Any good solutions to this? Are there replacements to the Chrome JavaScript console that supports those other languages?
- Psyonic 12y ago
  Are you using source maps? If so, you can actually put breakpoints in your other source and Chrome will still break on it. I've even done this with Scalajs.

stock_toaster 12y ago

> In the end, we need a lightweight yet properly defined and highlevel language.... Even lua would be a joy!

espadrine 12y ago
Out of curiosity, what would make Lua valuable to add in browsers by default? It is similarly prototype-based, has the same closure design, is dynamically typed, has an object system fairly similar to JS (with the type of arrays and hashtables both mixed), and its number system is also based on floating-point numbers… I honestly don't see how we can justify the cost of adding Lua to browsers. I see the merit of Lua-to-JS compilers (existing codebases or sheer love of the syntax), but built-in?
- trynumber9 12y ago
  Lua 5.1 (2006) has lexical scoping, tail calls, multiple return vales with assignment lists, semicolons are actually optional & most importantly: coroutines. ES6 adds some of these features. Lua 5.3 has both integer and floating-point types.

Macha 12y ago

I believe the issue is politics. I.e. browser vendor A (any vendor) can't unilaterally introduce a programming language and expect others to follow. (MS tried with VBScript, Google gave up on doing so with Dart, for example) This applies equally to any language.

vog 12y ago

Not sure why this was downvoted. Does anyone care to elaborate?

toyg 12y ago
I didn't downvote, but I don't think the problem has anything to do with specific language features. It's purely a political issue: you have to get at least two or three main vendors to adopt the new language at the same time, and none of them must perceive it as a threat to its own agenda. For that to happen, all of them must release compatible implementations that put everyone on an equal level at the exact same time, which is really hard to accomplish. It was very hard even to get javascript where it is now (remember the browser wars and all the incompatible extensions it spawned... ?), starting again from scratch with any new language would be extremely difficult, regardless of how "nice" the actual language is.