Leaving Python for JavaScript

http://hire.jonasgalvez.com.br/2017/Aug/25/Leaving-Python-for-JavaScript?

by jgalvez • 9 years ago

81 99 9 years ago

hire.jonasgalvez.com.br

dagenleg4• 9 years ago

there's no acceptable way to pass a function body to another in Python.

What. Why would you ever want a function body as a string? What kind of vile sorcery are you doing? One can use inspect.getsourcelines in python if really pressed to, but I find it horrifying that javascript developers actually seem to require this functionality often.

rhodysurf• 9 years ago

I cant figure out what he means either since he follows it up talking about map() and reduce() whcih you can use with function pointers (references? IDK what they actually are in python)

dagenleg4• 9 years ago

I edited my post, as after giving it some thought I concluded that the author wants to pass around the source code of the function. That indeed is something that python cannot provide in cases when function is already precompiled.

zeugmasyllepsis2• 9 years ago

I'm guessing, since the author used the arrow shorthand notation in Javascript as an example, that the limitations of Python's lambdas are the chief complaint

dagenleg4• 9 years ago

It's more of a feature than an arbitrary limitation I think. Python philosophy, 'explicit over implicit', and that stuff.

saurik• 9 years ago

The author did not say "as a string" and I am extremly confused as to how you read it like that... what? Essentially, the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented (and you are horribly tempted to play extremely insane tricks with decorators to build something that feels like a Frankenstein Ruby block); this is why the author then brings up arrow functions: it has nothing to do with strings.

dagenleg4• 9 years ago

Well truth be told it was hard for me to understand what the author meant. Thanks for clarification.

aaronchall• 9 years ago

the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented

You mean these critics find

    >>> map(lambda x: x**2, filter(lambda x: not x % 2, range(11)))

preferable to the "fragmented":

    def square(x):
        return x ** 2

    def is_even(x):
        return not x % 2

    >>> (square(x) for x in range(11) if is_even(x))

Both result in the same lazy iteration (to see results below - requires materialization with a constructor like list or tuple), but I find the "fragmented" approach much more readable (so long as the functions do what their name says they do - I have seen Python where they actually did the opposite...)

    >>> list((square(x) for x in range(11) if is_even(x)))
    [0, 4, 16, 36, 64, 100]
    >>> list(map(lambda x: x**2, filter(lambda x: not x % 2, range(11))))
    [0, 4, 16, 36, 64, 100]

kronos29296• 9 years ago

Higher order functions maybe? Though python has them. Spread operator can be done as unpacking a list. Destructuring assignment can also be done. Map is already there while reduce is in functools stdlib. So are all the other functional stuff. Async is in python 3.

Can't say what python lacked except being able use same language on front end and back end. Except if he still uses python 2 which hasn't any new features in years.

ojhughes• 9 years ago

Poor misguided person

crimsonalucard6• 9 years ago

I use to read hacker news and feel that all the articles were by people infinitely smarter than me. Nowadays I occasionally hit something like this. The fact that this makes it to the front page means many programmers are equally misguided...

creatonez5• 9 years ago

Then guide the OP yourself.

Posting short inflammatory comments isn't going to change how people approach the topic.

rdudekul• 9 years ago

A lot of innovation happened in JavaScript space over the past few years and yet the learning curve is high. I prefer to use Python for Data Analysis, Data Transformations & Machine Learning. For web applications, Node/Express + React/Vue seems to work better.

jgalvez6• 9 years ago

Yep, Python is still king for machine learning.

monkmartinez2• 9 years ago

I started programming in JS then moved to Python. It seems like JS has become very, very complicated. I look at his post and I am lost... I remember Knockout.js and Node in the v0.8 days.

I mean look at this:

  dotenv (lets you load the environment from an .env file), axios 
  (HTTP client library), cheerio (HTML parsing library), bcrypt 
  (password hashing), co-body (HTTP body parser), co-busboy (HTTP 
  multipart parser), jsonwebtoken (JWT generator), koa-jwt (JWT 
  middleware), koa-router, koa-sslify, vue-no-ssr and source-map.

What the hell is all that? I am not saying he is wrong... I am just saying that I don't have the capacity to play in that playground. I am also asking if any of those libraries will be around in a year?

alayek2• 9 years ago

I have been in your position about a year ago. The approached that helped me, was to not worry about all this.

Just start somewhere; and in a month or two, you would mostly know which libraries you need to add to your project.

The best way to go about it, is to check a few popular open source projects; what libraries they typically use.

I am also asking if any of those libraries will be around in a year?

You can check the download stats of these in https://npmjs.com, and activity on the GitHub repo, before adding it to your project.

If they are still around, but have published a new major version to update a few APIs; you can slowly migrate to it.

If not, you'd read some Medium post or Hackernews discussion, about what is replacing that.

There's something called Greenkeeper (https://greenkeeper.io/) that integrates a GitHub bot to your repo, and files a PR when something needs to be upgraded.

You can implement something similar on your own, if you aren't interested in using something like this.

secstate• 9 years ago

I mean no offense, but the "just use it you'll get used to it" strategy seems the antithesis of the goal of engineering as a discipline.

A materials engineer simply cannot afford to pick concrete unless she knows the specific load and weathering characteristics of it. The same should be true for software projects. You shouldn't use cheerio because everyone uses it in their project, but because you've looked through the source and considered all your options for need it fills.

Sorry for the rant, but I think it's important to encourage software developers to think before they code.

ojosilva• 9 years ago

Apparently it's just the guy's routine JS rig, not any sort of new standard you would have to follow or even care about.

batmansmk• 9 years ago

Most of the Js libs are super tiny. You integrate them, learn what you need to learn in less than 10min. Each is like learning a numpy operation :). It has its benefits and problems, but it's for the better imo.

jasonlotito• 9 years ago

What the hell is all that?

Libraries of code.

I am not saying he is wrong...

Good, because they are right.

I am just saying that I don't have the capacity to play in that playground

Good, because you are right.

I am also asking if any of those libraries will be around in a year?

Yes. Some have been around for years already.

Listen, it's fine that you are using Python. It's fine that the OP is using JavaScript. It doesn't make you wrong. It doesn't make them wrong. Just because you are confused doesn't make it wrong. Hell, Python should worry about itself; it has enough warts of it's own it doesn't need people pretending that a library like bcrypt is confusing.

DigitalJack• 9 years ago

I suspect you are being downvoted for presuming to know what the parent's capacity is.

creatonez5• 9 years ago

Koa has been here since 2013 (and some of those other libraries even longer). It is here to stay.

Do you see ancient but popular PHP frameworks going unmaintained and reach the point where they collect a significant amount of bugs and vulnerabilities? Not really...

metaphorm• 9 years ago

why is the sidebar on the left half the width of the page? I can hardly read the main content crammed into the right half.

dharness• 9 years ago

Why is all the actual content on the far right side of the page? Even more interesting given that you specialize in UI/UX.

jgalvez6• 9 years ago

Hi, it's just a blog, not a paid job. Not a lot of effort went into it. I'll take a look when I have a chance (it looks fine on my MBP and several others).

sushisource• 9 years ago

I don't think it's broken. It just looks pretty cramped and weird if you've got your browser in a portrait orientation.

jp_sc• 9 years ago

Why not? In what way this is worse than having the same column of content centered or on the left side of the page?

I find it refreshingly different.

Walkman• 9 years ago

there's no acceptable way to pass a function body to another in Python.

There are sentences which are telling a huge incompetence about the person using these.

This sounds the same story to me as "We used tech X, but X is shit/can't do something so we switched to Y, and Y is awesome and fast." Where the person switching was just incompetent with X but it would have been perfectly solvable and they just do a totally different thing with Y.

In the specific "passing a function" case, yes, it's impossible to pass only a function body, but I think it's impossible to do in JavaScript also? (correct me if I'm wrong), because you pass in function. You can do the same in Python by defining a function in the same scope and passing that in. If you don't like that, it's just one opinion, not necessarily good or bad. For example, I find it ugly and difficult to handle nesting this multiple times (defining another anonymous function inside an anonymous function) which is called "callback hell" if I understand right, but that's just my opinion also, because people seem to able to accept this hell. :)

neurotrace• 9 years ago

No one likes callback hell but I believe they meant that you can just pass a function expression directly. No need to define a named function. It's the difference between:

  let doubled = nums.map(x => x * 2)

and this:

  def double(x):
    return x * 2
  doubled = map(double, nums)

(my Python is pretty rusty so maybe there's a better way of doing that)

takeda2• 9 years ago

You can do the exact same thing in Python, and this is not any new feature:

    doubled = map(lambda x: x * 2, nums)

JS it's just not as explicit with what you're exactly doing.

scriptkiddy4• 9 years ago

(my Python is pretty rusty so maybe there's a better way of doing that)

    return [x*2 for x in nums]

bobwaycott• 9 years ago

    doubled = [x * 2 for x in nums]

crimsonalucard6• 9 years ago

It's true js is better with anonymous functions. But the design of js (node esp.) requires you to constantly pass these callbacks to do async. Critics of JS are basically claiming that a programming style that overuses anonymous functions as parameters into other functions leads to unreadable and overcomplicated code... hence why python restricts anonymous functions from being over one line long.

Typically in programming you don't often encounter the need to pass a multiline anonymous function into another function, it leads to confusing code. Async/await gets rid of this bs all together which is the pythonic way to do async.

btw pythonic code for maps or filters is to use list comprehensions so

doubled = [x2 for x in nums]

or if you want to use a anon function:

doubled = [(lambda y: y2)(x) for x in nums]

alayek2• 9 years ago

The way I see it, there are two types of callbacks - synchronous and asynchronous.

This is a synchronous callback (but callback nonetheless), that takes an array of numbers, and adds its entries:

arr.reduce(function(acc, item){ return acc + item; });

There's some boilerplate in this, so as per latest JS specs, you can remove all that and rewrite it as:

arr.reduce( (x, y) => x + y);

Then there's asynchronous callback. Most of "callback-hell" stems from these type of callbacks, because you would do "do-this-then-do-this-then-the-other-thing", and nest these one within other.

We realized that callback-hell prevents us from using return or handle errors in a clean & reliable way, so we went to promises.

Then promises turned out to be quite a pain too. Then generators, and now we have settled for async-await.

But in no way that "hell" is acceptable!

cryptica2• 9 years ago

I really like chaining Promises in JavaScript. The Python way to do this doesn't seem as powerful (what if you want to inject a parallel set of async operations at some point in the chain?): https://stackoverflow.com/questions/43325501/how-do-i-write-... - JS also supports async/await but the advantage of JS is that you can return promises (or parallel combinations of multiple promises) from inside promises so any link in the promise chain can essentially inject new links in the chain in its own place (so the chain can change dynamically based on the results of previous async operations).

You can build really complex dynamic async chains in JS very easily because of this. It's hard to explain why it's so nice until you try it.

In JS, I can do something like:

Promise.resolve().then(() => {

  let innerPromiseChain = serialOperation1()
  .then(serialOperation2);

  if (somethingIsTrue) {
    // Only inject serialOperation3 at the end of the
    // innerPromiseChain if somethingIsTrue
    return innerPromiseChain.then(serialOperation3);
  }
  // else return the inner chain without serialOperation3
  return innerPromiseChain;

}) .then((resultOfLastSerialOperation) => {

  // resultOfLastSerialOperation could be the result of
  // either serialOperation2 or serialOperation3 depending
  // on the value of somethingIsTrue

  // parallelOperation1 and parallelOperation2 will be
  // executed in parallel.
  return Promise.all(parallelOperation1(), parallelOperation2());

}) .then((parallelOp1Result, parallelOp2Result) => {

  // This will be called once the previous parallel
  // operations have both finished (therefore the
  // whole chain has been processed).

});

crimsonalucard6• 9 years ago

You realize your promise code is ugly af. All your code is nested within other functions and chained with dots. It's not clear.

For imperative code the goal is to write code that is just as clear as writing a single threaded algorithm: a simple list of steps. Promises and callbacks DO NOT ACHIEVE THIS GOAL.

That stackoverflow post showed a python solution that's infinitely cleaner than js. Python skipped callbacks and promise chains and jumped directly to the best way to do async operations... async/await.

You want to shove a parallel set in an async chain of operations? Here's the way to do serial and parallel async operations in Python:

    async def main():
        # run them sequentially (but the loop can do other stuff in the meanwhile)
        body1 = await get_body('http://httpbin.org/ip')
        print body1
        body2 = await get_body('http://httpbin.org/user-agent')
        print body2


        # run them in parallel
        task1 = get_body('http://httpbin.org/ip')
        task2 = get_body('http://httpbin.org/user-agent')
    
        for body in await asyncio.gather(task1, task2):
            print(body)

You see that code? Way more clearer way more understandable than your promise chain. Python has it's problems but your promise code is not powerful at all, it leads to over complicated code and just slightly better than callbacks.

crimsonalucard6• 9 years ago

This guy does sound incompetent. Sounds like he likes js because it's easier to use callback hell with multiline anonymous functions.

You can pass a function as a callback or something else in python. You just give the function a name then pass it. No function literals.

Also he's talking about async/await in koa... does this fool realize that async/await is built into python?

I'm proficient in both python and js and I have to tell you, python is light years ahead of js in terms of language design.

jgalvez6• 9 years ago

Sounds like he likes js because it's easier to use callback hell with multiline anonymous functions.

Sounds like you're more pissed off at the article because it contradicts your views than anything else. Sounds like you didn't even pay full attention to it.

Yes, those who assumed I meant you can't pass an anonymous multi-line function to another were obviously right -- it dazzles me people spent so much time arguing over this point. There's not much else to it.

I'll just say: that's definitely NOT the sole reason -- I point out several other factors that weighed in my decision in making JS my #1 choice. Above all, after seeing a few successful large projects deployed (and no issues in production), I just came to trust the Node.js stability and ecosystem.

pc2g4d• 9 years ago

I think he's complaining about the fact that lambdas in Python can't be multiline. The equivalent in Javascript can be as big as you want. That means in Python you have to separately define your function and then refer to it, whereas in JS you can just give it all in one go.

JS:

  doThing(function(){
    blah();
    de();
    blah();
  });

Python:

  def thing_doer():
    blah()
    de()
    blah()

  doThing(thing_doer)

freecodyx• 9 years ago

I did the move but to GOLANG instead.

I think what is more important than the language it self, is the toolings and standard library.

every now and then you hear about a new framework, a lot of hype, which is not for big projects.

I think the wise thing is to move to golang

monkmartinez2• 9 years ago

Why? I mean please elaborate.

jjnoakes2• 9 years ago

I want to like JavaScript, but the type coercion land mines and the lack of a real numeric tower make me a little queasy. When I have to use JS I stick to the transpile-to-js languages mostly for those reasons.

iffycan• 9 years ago

Is TypeScript one of your goto "transpile-to-js" languages? I'm a Python developer who is learning to love TypeScript. With TypeScript I feel like I can write maintainable, collaborateable JS.

jjnoakes2• 9 years ago

TypeScript has the same number problem that JavaScript has.

scriptkiddy4• 9 years ago

Just in case the author is present in the thread:

Your blog is extremely difficult to read on wide screen monitors. The entire left 50% is basically just blank space. My suggestion is to make the left side maybe 20% width on desktop or less.

Also, regarding the article content:

There really aren't any good reasons presented here about why you moved from Python to Javascript for back-end web development. It seems that you simply prefer Javascript semantics. There's nothing wrong with that, but the title is misleading considering that the bulk of the article is actually about which JS tools you use on recent projects and not why you moved.

Also, could you clarify what you mean by

Also, there's no acceptable way to pass a function body to another in Python.

Functions are first-class in python and can be passed as arguments to other functions. I'm not sure I understand what you mean with the above statement.

Cool to see someone else has been using Nuxt though.

haikuginger• 9 years ago

Functions are first-class in python and can be passed as arguments to other functions. I'm not sure I understand what you mean with the above statement.

I believe the author is referring to inline definition:

    setTimeout(function(){alert("Timed out!");}, 5000)

You can do something similar with lambdas in Python, but the allowed syntax is relatively limited compared to a full function definition. You could also define an inline function, but it'd be in a separate statement from the call you make with it. Unfortunately Python doesn't allow for creating and returning a first-class function in a single expression.

9t3h4r3o5w1a4w22• 9 years ago

Python has lambda but they are one liners.

There is no way to do write this in Python:

   someFunc( _ => {
       // this is 
       // a function 
       // with multiple lines
   })

Having to define a named function to use it as a callback is a pain in the ass.

Python has an excellent standard library but the language itself is pretty mediocre IMHO. Classes are an afterthought thus verboses, as so is "functional programming" in Python.

JS biggest issue is that it is not strongly typed enough. But ES2015 makes it really pleasant to use.

anentropic2• 9 years ago

the problem is callbacks as a pattern

if you have a multiline function it should be named and unit-tested instead of just stuffed anonymously into some pyramid of doom

mmmpop• 9 years ago

> Having to define a named function to use it as a callback is a pain in the ass.

Happy debugging!

joshmaker2• 9 years ago

I know the lack of multiline lambdas is a common criticism of Python, but I've never really understood it.

Typing

    someFunc( _ => {
       // this is 
       // a function 
       // with multiple lines
    })

Is only one line shorter than

    def foo ():
       // this is 
       // a function 
       // with multiple lines

    someFunc(foo)

There is a case to be made that the second version is more legible and that exposing the function foo makes unit testing it possible. I can understand why people might slightly prefer one or the other, but I honestly can't understand the intensity of opinion around this seemingly very minor syntactic difference.

I'm curious what you find verbose about Python classes as:

    class FooBar():
        text = "Hello World!"

        def hello(self):
            return self.text

feels fairly terse to me.

jgalvez6• 9 years ago

Your blog is extremely difficult to read on wide screen monitors. The entire left 50% is basically just blank space. My suggestion is to make the left side maybe 20% width on desktop or less.

Thanks, I'll take a look when I have a chance. I myself don't own a widescreen monitor, the site looks fine on my MacBook and several other computers. It's not a paid job, not a lot of effort went into it ;)

but the title is misleading considering that the bulk of the article is actually about which JS tools you use on recent projects and not why you moved.

Hm, actually, it's not. I'm surprised by this comment. I point out precisely the JavaScript features that weighed the most in my decision: "So with JavaScript you've got arrow functions, the method shorthand definition syntax, the spread operator, destructuring assignments, all functional Array methods and async functions. Combined with Vue's minimal patterns and Nuxt's conventions, I can't think of a better language to write web applications in."

Also, could you clarify what you mean by > Also, there's no acceptable way to pass a function body to another in Python.

Exactly that, a "function body", "closure", "inline function", whatever you wanna call it. In Python there are lambdas, but they're limited and not even encouraged anymore. We're left with passing function references, and that's where JavaScript comes out the winner IMHO.

CuriouslyC• 9 years ago

Python absolutely kills Javascript in the library department (particularly when it comes to doing stuff with tabular data). In my opinion the APIs for the built in data structures are also more intuitive and flexible. The __method__ protocols are also very elegant relative to what Javascript brings to the table. Of course, if you aren't doing anything fancy with data this point is partially moot.

I do admit that Javascript's object and array destructuring is extremely nice. The combination of destructuring and the spread operator makes working with heavily nested JSON much more enjoyable than in Python.

pseudalopex6• 9 years ago

"Anonymous function" is the term you're looking for. Lambdas are still encouraged for trivial functions; the only thing that's changed is that comprehensions have replaced many uses of map and filter. Python just requires you to name non-trivial functions.

IMHO, complex/nested anonymous functions are usually bad for maintainability, so I'd rather have a language that doesn't allow them (Python) than a community that overuses them (JavaScript).

scriptkiddy4• 9 years ago

Hm, actually, it's not. I'm surprised by this comment. I point out precisely the JavaScript features that weighed the most in my decision: "So with JavaScript you've got arrow functions, the method shorthand definition syntax, the spread operator, destructuring assignments, all functional Array methods and async functions. Combined with Vue's minimal patterns and Nuxt's conventions, I can't think of a better language to write web applications in."

I saw that. I guess I just expected you to go into detail about why you believe things like that are better. I use JS a lot in my day-to-day work for the front end of my web application. I also use Django and Python for my back-end. I'm well aware of the differences between Python and Javascript as they are the two languages I work with the most. I would not consider either language "better" than the other except at specific tasks. i.e. I can't really use python to build an SPA and it would be a pain to use Javascript for anything involving heavy number manipulation. I guess what I'm saying is that you should always choose the right tool for the job; sometimes that will Python and sometimes it will be JS. Other times, it might be something else. I'm always a little confused when someone decides that they're going to start writing everything in a particular language even when other languages are more suitable for the task.

Exactly that, a "function body", "closure", "inline function", whatever you wanna call it. In Python there are lambdas, but they're limited and not even encouraged anymore. We're left with passing function references, and that's where JavaScript comes out the winner IMHO.

To each their own I guess. I feel like programmers these days automatically assume that more functional == more good. There are cases where using FP techniques is definitely advantageous. However, there are also circumstances where OOP is a better choice. I find that Python is equally capable of both paradigms. The idea of anonymous callbacks is good from a productivity standpoint, but readability suffers. Anonymous functions in general cause cryptic error messages and are difficult to debug. I've found that the over use of anonymous functions can also lead to a lot of duplicate code. There are many cases when an anonymous callback would be better if refactored into a named function. I believe that having more named functions aids in creating an efficient program compostion, even when using the FP paradigm. There is one use case where Javscript is much better suited than Python: web applications front ends. This comes as no surprise as JS was designed for exactly that purpose. Asynchronous callbacks and promises cannot be beat when dealing with fetching data from an API.

ageitgey• 9 years ago

So a person who writes web apps prefers JS over Python. Cool. Pick the right tool for the job. If your job is writing client-side-heavy web apps that share code between the client and server, then JS might be a better choice than Python.

Look, writing programs that respond to HTTP requests with HTML is not rocket science. You can do it in JS, Python or Ruby and be very productive. If you hate yourself, you can do it in Java, Go or whatever else and trade server performance for development speed. If you really hate yourself (or are Amazon circa 2004), you can write your whole website as a C++ static binary.

My theory is that the endless proliferation of JS libraries, frameworks and language revisions are because lots of smart and talented developers are employed to build websites - but building websites is just not that technically interesting, so they express their creativity by creating new tools, frameworks, package managers and ES revisions. It's a symptom of boredom.

But my one bit of career advice would be don't "Leave X for Y." Don't tie your livelihood and career to a single X or Y. Learn how to use a variety of tools and pick the best one for each job. Any big project will require using a few different tools and really valuable developers are the ones who can navigate that entire landscape intelligently.

jgalvez6• 9 years ago

All very well said. I never said I was leaving Python for good, in fact, it needs to be pointed out it's still king for machine learning and I'll even integrate a Python-based solution as microservice to a Node.js project. Perhaps a clearer title would have been, "JavaScript is now my main language".

As for boredom, though, it's true, but every now and then something special emerges out of boredom, as was the case for Vue.js and most recently, Nuxt.js for me.

I hate the amount of JS frameworks and libraries available like everybody else and if anything, this article is also a short reference for myself in disguise on _how to get started_. I'll say though, knowing your way around a Node.js project can be painful, but with a little experience can become really reassuring. Code runs fast, it's easy to write (easy idioms to memorize like Python) and is generally very predictable.

rlander• 9 years ago

Right? When I read these kind of posts I always imagine a carpenter saying the equivalent "After over 10 years using a hammer as my main tool, I have moved on to the screwdriver." Which is nonsense.

creatonez5• 9 years ago

But in this case, the function of the tool is very similar. It's more like switching from one multi-tool to another. Both have a screwdriver, a knife and maybe a bottle opener. They're more than just superficially different for all tasks, but for web development they're only superficially different.

z3t4• 9 years ago

With programming languages you can both screw and hammer. I'ts not like you need to know C++ to do GUI's and D to make CLI's, or the other way around. What's the best tool for the job when all tools does basically the same thing ? I would say the tool you are best at.

holydude• 9 years ago

I am still learning to like Javascrip and its ecosystem. I do not think I would be able to invest time in transpile-to-js language (looking at you TypeScript). I really hate the evolving ecosystem, hyped libs / frameworks and tons spaghetti new paradigms.

creatonez5• 9 years ago

I really hate the evolving ecosystem, hyped libs / frameworks and tons spaghetti new paradigms.

Then don't use them. The javascript ecosystem on the backend and frontend has settled down quite a bit. Use something that's been established for a while (React, Vue on frontend or Express, Koa on backend) and you're not gonna suffer from churn too badly.

devnonymous• 9 years ago

So with JavaScript you've got arrow functions, the method shorthand definition syntax, the spread operator, destructuring assignments, all functional Array methods and async functions.

In language that pythonistas would grok:

Arrow functions: multiline lambda definitions

method shorthand definition syntax: class defined with only classmethods, or in other words a namespace

the spread operator: *args in functions

destructuring assignments: tuple unpacking... But also for creation of instances

all functional Array methods and async functions: functools and async... Plus a bit more

While most of this is good to know, I'd still stick with python for readability and maintainability purposes.

creatonez5• 9 years ago

IMO arbitrary rules like lambda expressions being limited to one expression do not directly improve readability and maintainability. Consistently using good conventions in the first place will help you more than arbitrary restrictions.

And to be clear, I would classify, say, Rust as not having many arbitrary restrictions. All the limitations that Rust has compared to C fit clearly within the language's core design. On the other hand, I don't see this same structure and consistency to some of Python's rules.

dragonwriter• 9 years ago

IMO arbitrary rules like lambda expressions being limited to one expression do not directly improve readability and maintainability.

In Python’s specific case, I've seen no alternative that isn't bad for readability; the strong line-orientation of Python's broader syntax limits the good options for inline anonymous functions.

That being said complex lambdas in general can be adverse to maintainability and Python’s single-expression limitation largely prevents that (though you can make hideously complex opaque single-expression lambdas if you try.)

wolco• 9 years ago

If you started with php instead of python you would never have left.

Vue is a great language but php can offer more in the backend

kochandy• 9 years ago

Thanks for your article. It's really helpful to hear about the technologies that have been used in actual projects/production environments. I'd love to hear more about what diminished your excitement with ElementUI vs iView

jgalvez6• 9 years ago

Mostly aesthetics in the default theme. Both are actively maintained and the APIs are super similar.

yiransheng• 9 years ago

ES6+ javaScript in absorbed many great features from python: destructuring vs. tuple unpacking, spread (...) vs *args argument unpacking and generators. Many things I enjoyed in python are now also idiomatic javaScript. Only thing missing is function decorators:

    @connect(...)
    function StateLessComponent(props) {

    }

deathanatos• 9 years ago

the spread operator

How?

JS:

  var args = [0, 1, 2];
  myFunction(...args);

Python:

  args = [0, 1, 2]
  myFunctions(*args)

A more complicated one:

JS:

  var args = [0, 1];
  myFunction(-1, ...args, 2, ...[3]);

Python:

  args = [0, 1]
  myFunction(-1, *args, 2, *[3])

As used in list building; JS:

  var parts = ['shoulders', 'knees']; 
  var lyrics = ['head', ...parts, 'and', 'toes'];

Python:

  parts = ['shoulders', 'knees']
  lyrics = ['head', *parts, 'and', 'toes']

"A better way to concatenate arrays"; JS:

  var arr1 = [0, 1, 2];
  var arr2 = [3, 4, 5];
  arr1 = [...arr1, ...arr2];

Python:

  arr1 = [0, 1, 2]
  arr2 = [3, 4, 5]
  arr1 = arr1 + arr2

(Though the star notation works here too.)

I omit JS's use of ... on objects; Python's class system works differently — and IMO, more rigorously — than JS's, making ... less sensible on Python objects. (Python focuses much less on passing around untyped key-value bags and more on strongly typed classes IMO; both are possible in both languages, but the idioms around them differ, and I think Python's idioms tend more towards having a well defined class with well defined attributes, and not having just a bag of attributes, moreso than JS at least, and I feel that direction (well defined classes) leads to more robust code. In particular, it forces you into naming your concepts, and defining their set of attributes: a simplistic type definition.)

all functional Array methods

Python has map, reduce, etc., as well as generator and list comprehensions which are often easier to use.

async functions

Python and JavaScript have practically identical syntax in this area.

there's no acceptable way to pass a function body to another in Python

I find it very acceptable that if your function body is more complicated than an expression, that you're forced to pull it out and name it, frankly. I think it does good things for fighting complexity, and this just isn't something I worry about day to day while using Python. But I will concede that Python does lack a syntax for passing a function in an expression context.

(But I would also note JS's screwed up named-function syntax; in Python:

  def foo():
    # body

is a valid statement. JS's:

  function foo() {
    // body
  }

is not a valid statement, and can only appear in certain, particular contexts. In particular, the following is not valid JavaScript, though many implementations will do The Right Thing™, I'm told:

  if(true) {
    function foo() {
      // body.
    }
  }

[2])

My code usually revolves around higher order functions, reduce(), map(), etc. I can't remember the last time I wrote a regular for loop in JavaScript.

Because JS for a long time (until ES6's for(… of …) syntax) lacked a for loop (the C style look, and for(… in …), do not count, as they do semantically different things), which is why you're using forEach().

arrow functions

The best thing about arrow functions is the sane binding of `this`, a problem notably absent in Python to begin with.

[Python's] class definition boilerplate is still hard to look at

This is sometimes true; I find the attrs[1] package helps greatly here for small, struct-like classes.

[1] https://pypi.python.org/pypi/attrs

[2] http://kangax.github.io/nfe/#expr-vs-decl

abuckenheimer• 9 years ago

So with JavaScript you've got arrow functions, the method shorthand definition syntax, the spread operator, destructuring assignments, all functional Array methods and async functions.

This confuses me quite a bit, there are nuanced differences between these ideas in the two languages but at the surface these are things that very much exist in both languages

arrow functions:

  (x,y) => { x + y }

vs.

  lambda x,y: x + y

method shorthand definition:

  MyObj = {
      foo(x,y) { return x + y }
      bar(x,y) { return x * y }
  }

vs.

  class MyObj:
      foo(self, x, y): return x + y
      bar(self, x, y): return x * y

spread operator:

  function add(x,y) {
      return x + y
  }
  add(...[1,2])

vs.

  def add(x, y):
      x + y
  add(*[1,2])

destructuring:

    [a, b, ...rest] = [10, 20, 30, 40, 50];

vs.

    a, b, *rest = [10, 20, 30, 40, 50]

functional array methods:

    forEach(["Wampeter", "Foma", "Granfalloon"], print);

vs.

    list(map(print, ["Wampeter", "Foma", "Granfalloon"]))

async methods:

    function resolveAfter2Seconds(x) {
      return new Promise(resolve => {
        setTimeout(() => {
          resolve(x);
        }, 2000);
      });
    }

    async function add1(x) {
      var a = resolveAfter2Seconds(20);
      var b = resolveAfter2Seconds(30);
      return x + await a + await b;
    }

    add1(10).then(v => {
      console.log(v);  // prints 60 after 2 seconds.
    });

vs.

    async def resolve_after_2_seconds(x):
        await asyncio.sleep(2)
        return x

    async def add1(x):
        a = resolve_after_2_seconds(20)
        b = resolve_after_2_seconds(30)
        return x + await a + await b

    loop = asyncio.get_event_loop()
    loop.run_until_complete(add1(10))

There's a lot of fun differences between the origins of these features and how they work but the sentence to me doesn't quite to the idea of "Leaving Python for JavaScript" justice

_greim_• 9 years ago

With async/await now landing in mainstream engines, Koa instead of Express, the new Turbofan+Ignition optimization pipeline "evening out" V8's performance characteristics, and ES6 enjoying reasonably broad support, I feel like JS is now crossing a threshold into being not a completely sucky programming experience, which is a sentiment this article echoes.

I'm probably being overly optimistic, but I look forward to a future where a "naked JS" movement rises up, similar to "vanilla JS", but rebelling against tooling complexity instead of jQuery bloat, in which your website's /js/ folder contains pretty much exactly what's in git.

spondyl• 9 years ago

I'm split on it myself. I like being able to go Right Click -> View Source and poke around but with more modern sites, you're given nothing but a single JS file. You can scroll through the DOM in developer tools but it's not as neat as text :(

yupyup• 9 years ago

When reading these "Leaving X for Y" I first think that maybe some people are unable to fluently use more than 1 language.

Seriously, professionality is being able to use the right tool for the job at hand.

Leaving Python for JavaScript

Related Stories