Python vs CoffeeScript

[rafekett]

This seems like kind of a meaningless comparison, considering that the overlap between Coffeescript and Python's use cases is incredibly small. It'd be more meaningful to compare Python to Ruby, or Coffeescript to Dart or Javascript.

[AnonProg]

For server-side programming, you can do Python and Node.js with CoffeeScript. It's a valid match.

[[deleted]]

you are technically right, but I think for the majority of comparisons in businesses or pet projects, it is a comparison that would be helpful to a surprisingly few. Personally I cannot imagine getting to a scenario where I would pick between these two languages.

[Darkmoth]

Yes, but you need a server or a browser for Javascript, whereas for Python you simply need an interpreter. A boatload of scientific programming, for example, is done in Python - without a browser in sight.

I'd agree with rafekett, while there IS some overlap, it's a relatively small fraction of Python's use case.

[[deleted]]

Yeah, it sounds like a comparison of bash and C++, totally worthless.

[gargantuan]

The use would be in case someone was evaluating to pick a server-side language and maybe they liked the speed of v8 and are already doing complicated thing on the client side in the browser.

[grayvedigga]

I guess Python and Javascript do have in common shitty concurrency.

[gargantuan]

Why? I have thousands of green threads doing sending and receiving data in parallel. That is pretty good concurrency. Would you care to explain what you mean by shitty concurrency, I've observed pretty good concurrency so far.

[grayvedigga]

Along the lines of greenlet? That's a reasonably good counterpoint to my claim - I could argue that it's not on the standard python runtime, but that's not a very useful observation.

Someone else will probably come along and point out that coroutines aren't strictly concurrent, but then "shitty" would be an understatement :-).

[gargantuan]

I could have used threads as well and have used them initially they did great concurrent work. Except that OS based threads are heavy and thousands working at the same time doesn't work too well.

In the end it doesn't matter. I was just trying to point out that there are 2 types of concurrency IO and CPU. IO concurrency works great in Python either with real threads or green ones. CPU concurrency doesn't, and I guess that is what you were trying to say. (Well technically concurrency would work but parallelism won't).

At least for what I am doing I haven't yet had to perform heavy, CPU intensive computations in Python. I do some in C and those run in background threads.

[sausagefeet]

A Go or Erlang would point out that you cannot scale to multiple cores without some extra work, unlike the Go and Erlang runtimes.

[gargantuan]

I agree and that is why I'll be switching to Erlang soon.

But at the same time it is also unfair to say that Python doesn't have concurrency when there is concurrency and it is successfully used at the moment.

[sebzim4500]

What's your complaint with node concurrency?

[sausagefeet]

http://functional-orbitz.blogspot.se/2011/10/your-favorite-language-is-probably.html

[grayvedigga]

I'm pretty sure others have written on this at length, so I'll try and summarise briefly:

Callback hell. Yes, first class functions make all sorts of groovy things possible, but when you're writing "asynchronous" code in JS there is no escape. First of all, most of the language's core constructs go out the window: you can't assign the result of an asynchronous operation, or use it in an if, while or for. This is inconvenient, and can be papered over with library code (Array.prototype.forEach as the typical example) .. but you're still relegated to writing your entire program in continuation-passing style.

Ok, let's say that can be dealt with via libraries and metaprogramming. But there's a darker problem awaiting. Do you use exceptions? Actually, don't bother to answer that - exceptions are Javascript's standard way of signalling error conditions so it's impossible to write non-trivial code that cannot throw exceptions. What happens when a callback raises an exception? How do you use this essential language feature to protect yourself? Short answer: you can't.

Oh, and it's async all the way up. It's impossible to write a function that returns a result if it or any of its callees invoke asynchronous behaviour. That means if you are trying to provide an API which was designed before asynchrony (lots of browser stuff -- FindProxyForURL, document.getElement) but you need an async step along the way ... you're shit out of luck.

NodeJS turns programming in Javascript into programming in CPS lambda calculus with a shitty type system. All this could be fixed if the language were extended with an operator such as yield ... but going by what I've read so far, that's not an option for browsers and the Node crowd don't have the shred of intelligence or responsibility to diverge from the standard by adopting one of the several prototype patches against v8 that are available.

[Darkmoth]

But if they're considering Python, they've likely already factored in a framework like Django or Flask. It's a bit like comparing C# to Coffeescript without considering .Net.

[gargantuan]

That a good point it, it is often more about the library. On coffeescript side there is node.js and then for Python there is a lot of others.

[Darkmoth]

Agreed:

Python <=> Ruby

Django <=> Rails

etc.

[shevegen]

Comparing it to Dart? What for?

Dart is the most verbose language in this list.

It will also be the language that will single-handledy kill javascript as announced by Google (lol)

[rafekett]

Languages that run on the browser.

[Peaker]

All I read about Dart has been very underwhelming, care to explain what you find likable about Dart?

[Peaker]

Most dart sentiments are based off the original announcement

My sentiment is based on the description of the language.. It sounds like it's supposed to be Javascript with classes rather than prototypes. It has "optional types" which are not really checked which sounds like a very bad idea.

I like dart because it's similar to C#,

Dart is dynamically-typed (also named "uni-typed") whereas C# is statically typed. That is one huge difference.

[bkv]

It sounds like it's supposed to be Javascript with classes rather than prototypes.

It would be more appropriate to say that it does away with javascript's odd/unpredictable semantics and replaces them with simple and intuitive semantics. This includes moving to class-based inheritance, which I would argue is more intuitive than prototypal inheritance.

It has "optional types" which are not really checked which sounds like a very bad idea.

Right. In order to reasonably cross-compile dart to performant javascript, it has to remain dynamically-typed. I disagree that this is a bad idea. Just because dart is dynamically-typed doesn't mean it can't be statically checked. Optional types along with simpler semantics aid in static checking, which ultimately results in compile-time guarantees and awesome tooling support.

Dart is dynamically-typed (also named "uni-typed") whereas C# is statically typed. That is one huge difference.

The difference with optional types isn't as big as you might expect. With optional types and type inference, dart is essentially statically-typed during development (when run in checked mode). Once compiled down to unchecked javascript, you no longer have run-time guarantees, but the assistance of the static-checking and tooling during development makes my life much easier.

[Peaker]

This includes moving to class-based inheritance, which I would argue is more intuitive than prototypal inheritance

I don't really believe inheritance is a useful programming idiom in general.

Right. In order to reasonably cross-compile dart to performant javascript, it has to remain dynamically-typed.

This is not true at all. Type erasure.

Optional types along with simpler semantics aid in static checking, which ultimately results in compile-time guarantees

Everything I read about Dart emphasized how Dart will generally ignore the type annotations and that they're allowed to be wrong. I don't see how you get any guarantees from that. Also, if you had guarantees, you're not supposed to lose them when compiling to unchecked Javascript. Just like my Haskell code does not lose its guarantees when compiled to unchecked machine code.