Hacker News Reader

> 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.

> 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.

"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).

I couldn't agree with you more. I think that Python's lack of complex anonymous functions actually forces the programmer to compose their code in a more efficient manner.

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.

> 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.

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.

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.

The problem with python class definition is the need to write instance vars 3x:

    def __init__(self, foo)
        self.foo = foo

There is an attrs package and new proposal (https://github.com/ericvsmith/dataclasses/blob/master/pep-xx...) to remedy that.

Yeah, I guess I normally don't deal with enough properties like that for it to be a big deal in my workflow. When it's come up I've generally done something like:

    class Foo:
        bar = 42

        def __init__(self, **kwargs):
            self.__dict__.update(**kwargs)

But I agree that's not a super robust solution

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

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

It's like saying all data should be declared as variable, in the functional programming paradigm, functions are data. That's why closures are useful. And it has absolutely nothing to do with unit-testing, that's beside the point. Javascript is not harder to unit test because it has fully featured anonymous functions.

what does functional programming have to do with it? you still unit test functions in functional programming surely?

> It's like saying all data should be declared as variable, in the functional programming paradigm, functions are data. That's why closures are useful.

I don't think you understand what you're talking about. We were already talking about using 'functions as data', and closures and anonymous functions aren't the same thing.

But anyway, how do you unit test an anonymous function?

I assume you mean that you don't, you just test the bigger context around it. But that was my point, once your anonymous function starts becoming much bigger than a one-liner it ought to be tested itself.

> Javascript is not harder to unit test because it has fully featured anonymous functions.

It is if you actually use them. ;)

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

Happy debugging!