Comment by ralmidani | Hacker News Reader

Comment by ralmidani | Hacker News Reader

Personally, I like CoffeeScript syntax combined with JavaScript's "a hash is an object" better than Python's object syntax (too much unnecessary use of "self" and class method decorators could be better achieved with the @ sigil).

What I would really find interesting is a CoffeeScript-like language that can compile to both Python and JS (with snake_case for Python and camelCase for JS). Couple it with a JS client-side library that mimics Django's Model and Field APIs, while keeping the best parts from Ember.js (Handlebars/Emblem templates, Components with Actions for template events, Router, and Routes), plus glue code to make the whole thing seamless, real-time, and with an isomorphic feel.

If nobody does it, I plan to study compilers with the express goal of attempting it myself.

Edit: To clarify, I already know a decent amount of Python and JS/CoffeeScript. The problem is not in learning multiple languages, but in the amount of duplicated logic (especially in the model layer) that could be eliminated via shared code when you write in a single language.

Speaking of coffeescript, there's a python/coffeescript inspired language that I stumbled upon recently: http://breuleux.github.io/earl-grey/ Basically es6-ified coffeescript it looks like.

Wow. Definitely a language to check out.

Thanks for the link!

What about nim (http://nim-lang.org/) ?

It's more python-like than CoffeeScript-like, but still looks lighter than Python, without the overuse of 'self'. It can compile to C for the server part and to Javascript for the client part. The obvious difference with your project is that it targets nim, not python, and thus cannot reuse any of the python libraries. Being so close to C it can use whatever is written in it though.

Check out this page for a good feel of it:

http://hookrace.net/blog/what-is-special-about-nim/

CoffeeScript feels for me like more flexible Python. Only thing I was missing until ES6 were generators.

I simply love how I can wrap line from csv file in custom CoffeeScript object just by declaring class like:

    class Entry
      constructor: ([@id, @description, @amount]) ->

and doing new Entry(line.split(','))

An equivalent in Python is

>>> Entry = namedtuple("Entry", "id description amount")

>>> Entry(*line.split(','))

Entry(id='1', description='an entry', amount='99')

Neat, but can I add few methods to my Entry touple?

Can it inherit from something else?

Can something else inherit from Entry?

Won't named touple have some of its own methods that my methods could have collided with?

You can use a `namedtuple` class as a base class, e.g. like this:

    class Entry(namedtuple('Entry', ('id', 'description', 'amount')), SomethingElse):
        def more_methods(self):
            pass

Thank you for this example. It's exactly the thing I had with CoffeeScript

>Neat, but can I add few methods to my Entry touple?

Yes, if you subclass it.

> Can something else inherit from Entry?

Yes, it can be subclassed.

>Won't named touple have some of its own methods that my methods could have collided with

Yes and no, it has the "index" and "count" methods any tuple should have, which can easily be overridden by specifying them as attributes in the second argument to the contructor, through reassignment during initialization or method overriding.

I like your idea of a language that can compile to Python or JavaScript. I wish there were a straightforward & proven business model that could be applied to programming languages. I have a feeling we would see much more interesting development in this area if there were bigger rewards for coming up with something better than the status quo.

Haxe can target both JS and Python (as well as many other things). It doesn't seem to be very well known, probably because it originally came about for developing Flash content.

90% of the duplicate logic is data validation.

How about using PyV8 to run javascript on the server, so you can share validation logic between the frontend and backend?

Routing could also be shared; you could declare endpoints in one place, but the implementations for client and server would be different.

At the risk of oversimplifying: on the server, routed actions are concerned with getting data from a database, serializing it, and sending it to the client. On the client, routed actions get data from the server and use it to render a template.

I don't understand why this is such a controversial view. I agree in full. I hope that you are successful.

> It is questionable.

> I don't mean to talk a bunch of trash about the idea, because it is a cool one and undoubtedly would be a great learning project. However, in trying to compile down to both Python and JS, you'll end up with a lowest common denominator language. Aside from libraries, it isn't obvious what compiling down to Python gives you; just use Coffeescript or something similar for your entire stack if for some reason ES6 is not an option.

> Truthfully you are just better off biting the bullet and getting good at multiple languages which are the best fit to their domains. The best tool for the job and all. Python is a good language, but not great enough to warrant hanging onto if/where it has been eclipsed.

My motivation isn't a love for Python (although I do confess one), but contempt for javascript.

I do like coffeescript just fine, so my solution is to "just Coffeescript" most of the time.

However - and I know I'm not alone here - I end up having to not only repeat but re-represent crucial pieces of logic in both Python (in a model method) and Coffeescript (in a scope method) in order to have complete coherence over my app.

In 2015, it doesn’t need to be this way.

> but contempt for javascript

Opinions like this make me very sad. And not because I love JavaScript: I love all the languages (take a look if you want to see the list: https://klibert.pl/articles/programming_langs.html). It's sad, because we have now more languages than ever before, yet almost no one uses them, because they all "contempt" some of them, "dislike" others and are "not interested" in the rest. "Using the best tool for the job" was never that easy, yet nobody wants to do it, choosing to try and translate completely incompatible semantics and features of one tool on top of another. It's really disappointing.

This presentation sums up my dreams about how development should look like pretty nicely: https://www.youtube.com/watch?v=qluiQgbXZBQ

> It's sad, because we have now more languages than ever before, yet almost no one uses them, because they all "contempt" some of them, "dislike" others and are "not interested" in the rest. "Using the best tool for the job" was never that easy, yet nobody wants to do it, choosing to try and translate completely incompatible semantics and features of one tool on top of another. It's really disappointing.

JS is used to develop client-side web applications not because it's the best language for the job, but because it's the only language supported by all browsers.

Those who like the philosophy and/or reach of the Web but don't want to use JS have no alternative to using languages like CoffeeScript.

> Those who like the philosophy and/or reach of the Web but don't want to use JS have no alternative to using languages like CoffeeScript.

Could you explain what you mean by "languages like CoffeeScript"? If you mean it as "languages compiled to JS" then many of them are completely unlike Coffee in both syntax and semantics. There's a great many of them to choose from, too.

But I think you completely missed my point, which is that you have an alternative for JS (in the form of compile to JS languages, but why should it matter if a language is compiled to JVM bytecode of JS code? It's an implementation detail!). You have an alternative for every single language out there, and a wide array of languages optimized for different use cases. Yet, instead of embracing this diversity, people try to push their favorite[1] language everywhere. Yeah, it's easier to write something that way, but until we have "sufficiently smart compilers" the effect is going to be worse than if you just used a best-suited language for each component of your system.

[1] Maybe because it's the only one they know?

I do have reservation about Python to be the language to be cross-compiled to anything, then there is NodeJS on server side as well, so what the hell :(

Whenever a new stack popup, I always wonder 1) who us it 2) why they use it 3) what they use it for

Hopefully more people share their stacks on http://www.stackbus.com/ (FYI, I build it) so that it help others to decide better.

i'm going to write my next web app in python on the front end and nodejs on the server just because fuck it.

What stack did you use to build stackbus.com?

Flask, Python, Brunch, Backbone, Google App Engine http://www.stackbus.com/@d_luaz

Reply on news.ycombinator.com