Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Python for JavaScript

hire.jonasgalvez.com.br

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Leaving Python for JavaScript

#81

Post by mixmastamyk »

9t3h4r3o5w1a4w2 wrote: post #50
anentropic wrote: post #43

Earlier quoted context omitted.

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…

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

It is if you actually use them. ;)

Re: Leaving Python for JavaScript

#82

Post by mixmastamyk »

joshmaker wrote: post #57
9t3h4r3o5w1a4w2 wrote: post #39

Earlier quoted context omitted.

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 bigg…

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

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.

Re: Leaving Python for JavaScript

#83

Post by creatonez »

rlander wrote: post #76
ageitgey wrote: post #45

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…

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.

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.

Re: Leaving Python for JavaScript

#84

Post by creatonez »

monkmartinez wrote: post #15

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), js…

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

Re: Leaving Python for JavaScript

#85

Post by creatonez »

devnonymous wrote: post #53

> 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 de…

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.

Re: Leaving Python for JavaScript

#86

Post by creatonez »

holydude wrote: post #51

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.

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

Re: Leaving Python for JavaScript

#88

Post by dragonwriter »

creatonez wrote: post #85
devnonymous wrote: post #53

> 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 de…

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

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

Re: Leaving Python for JavaScript

#89

Post by Symen »

pseudalopex wrote: post #71
Symen wrote: post #47

Earlier quoted context omitted.

But your lambda example would be more clear if collections functions supported chaining. You can add a small comment if you want to be explicit. This way the code reads linearly, you don't have to wonder why a "square" function and "is_even" function are defined before you see how they are used. # square even numbers range(11) .filter(lambda x: not x % 2) .map(lambda x: x ** 2) However such a chaining API is not prac…

Long method chains are impractical in Python because of the line continuation rules. That's orthogonal to the question of whether complex functions should be required to have names.

There are a few gotchas but you can do it. Mostly you need to put you multi-line chain call inside parentheses if it is not already inside a function call or data structure (similarly to generator expressions).

For example I often end up doing:

    something(
        "Template string {thing}"
        .format(thing=33)
    )

Re: Leaving Python for JavaScript

#90

Post by z3t4 »

rlander wrote: post #76
ageitgey wrote: post #45

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…

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.

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.
Post reply on HN