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

91–100 of 112 posts

Re: Leaving Python for JavaScript

#91

Post by pseudalopex »

jgalvez wrote: post #42
scriptkiddy wrote: post #29

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…

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

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

Re: Leaving Python for JavaScript

#92

Post by joshmaker »

mixmastamyk wrote: post #82
joshmaker wrote: post #57

Earlier quoted context omitted.

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.

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

Re: Leaving Python for JavaScript

#93

Post by pseudalopex »

Symen wrote: post #89
pseudalopex wrote: post #71

Earlier quoted context omitted.

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

It's possible but rarely more concise or clear than just using variables.

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

Re: Leaving Python for JavaScript

#94

Post by pseudalopex »

mcluck wrote: post #80
crimsonalucard wrote: post #72

Earlier quoted context omitted.

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

I'd say that anyone who's complaining about callback hell isn't up-to-date with the JS world. Promises have fixed this problem and, as you pointed out, async/await make it even nicer. In my experience (I write mostly JS but also a lot of C# and, not as much, Rust), passing functions around is very easy to read and reason about. Functional programming "Just Makes Sense™" to me. I think it's just an exposure thing. Man…

Passing around functions is great, but it's easier to read and reason about when the functions have names. I see a lot of complex/nested anonymous functions in JavaScript code, even with promises.

Re: Leaving Python for JavaScript

#95

Post by jgalvez »

kochandy wrote: post #56

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

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

Re: Leaving Python for JavaScript

#96

Post by crimsonalucard »

mcluck wrote: post #80
crimsonalucard wrote: post #72

Earlier quoted context omitted.

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

I'd say that anyone who's complaining about callback hell isn't up-to-date with the JS world. Promises have fixed this problem and, as you pointed out, async/await make it even nicer. In my experience (I write mostly JS but also a lot of C# and, not as much, Rust), passing functions around is very easy to read and reason about. Functional programming "Just Makes Sense™" to me. I think it's just an exposure thing. Man…

First off, you aren't doing functional programming when you have first class functions or if you use HO functions like map and reduce. Those concepts can exist in imperative programs. The only concept that makes a program functional is immutability. That's it. Functional programming does not make sense to you if you don't understand this.

>I'd say that anyone who's complaining about callback hell isn't up-to-date with the JS world. Promises have fixed this problem and, as you pointed out, async/await make it even nicer.

The latest node api still uses callbacks. Promises haven't fixed this problem, it's just a bandaid on stab wound. Async/await is the proper way to deal with this problem and python supports it so there's no upside for node in this area.

Re: Leaving Python for JavaScript

#97

Post by yupyup »

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.

Re: Leaving Python for JavaScript

#98

Post by cryptica »

crimsonalucard wrote: post #68
cryptica wrote: post #31

Earlier quoted context omitted.

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

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

Well put. Good to see that Python can handle this cleanly.

You can do pretty much exactly the same with JS but I do think that there is some merit to this intermediate step of having the then() clauses for backwards-compatibility because you can't always guarantee that the caller will in be an async function.

Async/await is an all-or-nothing improvement not an incremental one.

Re: Leaving Python for JavaScript

#99

Post by Symen »

pseudalopex wrote: post #93
Symen wrote: post #89

Earlier quoted context omitted.

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

It's possible but rarely more concise or clear than just using variables. label = "Template string {thing}".format(thing=33) something(label)

I guess it is a matter of preference at some point.

Storing each step in variables has the advantage to be self-documenting and nicer when debugging. However in many cases I feel like wasting energy trying to find short and adequate variable names for each steps in a computation, especially when the steps are clear enough by themselves but difficult to describe in 1-2 short words.

You also need to keep the variable names in sync when refactoring, which may cause even more refactoring if the line gets too long with the new name.

IMO it makes sense to use both styles where they feel most adequate.

Re: Leaving Python for JavaScript

#100

Post by [deleted] »

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…

[deleted]
Post reply on HN