Hacker News Reader

Comment by __alexs | Hacker News Reader

JavaScript the language isn't even that awful anymore and TypeScript makes it actually pretty good.

In some ways I prefer javascript for lots of tasks. Easier to write functional style using filter and maps and lambdas, than python's weird itertools and list comprehensions.

Python also has filters maps and lambdas, and lots of third-party support for other functional ideas (e.g. the Toolz library).

Though personally I really like itertools and list comprehensions. (And list comprehensions are pretty functional as well, they were inspired by haskell I blieve.)

In my experience lambdas are a lot easier to write with strong types and related tooling.

Same, python is my goto language so its (minor-ish) deficiencies annoy me a lot.

- Annotating nested JSON objects is a pain in the ass. You need a bazillion intermediary classes.

- Sometimes you need a 3ish line lambda, because you have an beefy if-condition or a try-catch. Too bad multi-line lambdas aren't a thing.

- Function hoisting in JS is actually really nice, not just for the previous scenario. You can define utility functions at the bottom of a function and they'll be available to anything before that definition

- I wish python had a more succinct way to destructure dicts / objects like JS does, outside the new switch statements. (ie doesnt require imports, doesn't require typing the object name over and over.)

- Code completion doesn't work for list comprehensions because the for x in xs comes last :(

Honest question: why not name a function instead of using a multi-line lambda? I've never used a language where multi-line lambdas are common though.

Just readability for me. It's easier to read if the function is defined where it's used rather than before.

  apply(lst, () => {
     ...
     ...
  })

instead of

  def naming_is_hard():
      ...
      ...
  apply(lst, naming_is_hard)

Agreed with @richiebful1, multiliners are better as standlone funcs, and I'd say (personal opinion) that they'd be better here. I like functional a lot but I don't lambda up unless it's more or less a one-liner or a kind of control structure, where they can get large but that's the point.

I've had to deal with too much shit code where lambdas within lambdas are considered hot.

Added bonus, the names are useful (naming is hard because if you do it right you are adding valuable information).

I'm sure there are cases where doing it your way are better, but I can't think of them.

If `apply` is your own code, you could refactor it to

  @apply(lst)
  def naming_is_hard():
      ...

I came to python after working in JS fulltime for years, and used to complain about the exact same thing. After I started using decorators, I stopped complaining about the single-line lambdas.

For any non-python devs looking at my example, it's equivalent to

  def naming_is_hard():
      ...

  naming_is_hard = apply(lst)(naming_is_hard)

It's a nice way to pass functions into other functions, much like how you'd do with a lambda.

edit: s/list/lst/g because autocorrect "fixed" the variable name.

Kotlin JavaScript typescript anonymous functions in golang

List comprehensions are one of the best features! How dare you sully the great name of the list comprehensions!

In all seriousness I do like them a lot. But like all things one can abuse them and make code unreadable.

Problem with list comprehensions are that it's often not easy to see what you're trying to do. Like, I have some objects I want to group by a property, and then make a map containing the sum of some other property of those groups but only if it's value is above 5.

Take Kotlin:

    result = myList
         .filter { it.myValue > 5 }
         .groupBy { it.myKey }
         .mapValues { entry -> entry.value.sumOf { it.myValue }}

In python:

    result = {
        key: sum(el["myValue"] for el in elements)
        for key, elements in groupby(
            sorted([el for el in my_list if el["myValue"] > 5], key=lambda el: el["myKey"]),
            key=lambda el: el["myKey"],
        )
    }

to me that's incomprehensible. You have to read it the wrong way, and it's not really clear what the intention behind each step is. Like, the filter is in the middle!

Yeah ... In that case I would write a function to return this result dict in a more imperative way in python -- but perhaps that's cuz i am not that great of an engineer/python dev. But what I can see is that the syntax of Kotlin (which I've never written) you've provided is a lot cleaner.

True that. That's why I prefer R, and its built-in pipes, when I'm working with relatively clean data.

Use intermediate steps:

    keyOf = itemgetter("myKey")
    valueOf = itemgetter("myValue")
    filtered = (item for item in myList if valueOf(item) > 5)
    grouped = groupby(sorted(filtered, key=keyOf), keyOf)
    result = {key: sum(valueOf(item) for item in group) for key, group in grouped}

Ooh I like this. That’s about what I would do as well.

Could you save a line by replacing valueOf(item) with item.value?

OP wrote the code as if the list items were dictionaries, so I just made that pythonic. If they are objects whose attributes we care about then we can get rid of the two getters altogether which are mostly there to make the code more legible but also remove duplication. You could also switch them to attrgetters.

Yeah that Python would not pass my code review. Rule of thumb is don’t nest list comprehensions, and if you have to try to keep it to two. Checkpoint the results info a variable. You aren’t supposed to chain like that in Python.

From https://docs.python.org/3/tutorial/datastructures.html#id2

> You might have noticed that methods like insert, remove or sort that only modify the list have no return value printed – they return the default None. [1] This is a design principle for all mutable data structures in Python.

> Footnotes > [1] Other languages may return the mutated object, which allows method chaining, such as d->insert("a")->remove("b")->sort();.

I’m primarily a Python dev but I’ve been recently working on a React codebase. One of the things that’s been driving me insane is how the default way to import things is without a namespace, aka:

`import {foo} from ‘bar’;`

This makes reading code really really hard as I can’t tell where some symbol is coming from.

There also seems to be a general aversion against using classes to model types. Instead we have a host of functions that manipulate JSON/dataclasses, which means business logic is scattered around 10 different places!

Yeah there's a lot of weird design choices in JS code. I'm not sure all of them really make sense given the modern state of the language but old habits die hard.

> This makes reading code really really hard as I can’t tell where some symbol is coming from.

That's why you use Typescript then you can just hover something or ctrl-click it.

Anyway Python is exactly the same in my experience. Sometimes people `import numpy as np` or whatever but most of the time they `from foo import X, y, z`.

I don't like more the default exports / imports. In this case one can import using completely different name and then it is even harder. Also it won't be changed while renaming utill the developer will go in all other places and do it manually

My problem is that I find TypeScript written by another person entirely unreadable. Python written by another person? Relatively intuitive, even if it's written badly.

And this is actually a hugely important consideration in determining whether a language becomes successful, it turns out.

I agree 100%.

I love JavaScript (yes, I'm one of THOSE people) and like what TypeScript brings to the table but it quickly becomes hard to read as the code becomes more complex.

Python has always had a readability advantage... up to the point where people start doing code golf and nesting multiple comprehensions together.

For me it is other way around, untill it is something very simple

Really interested in your experience with this.

What would you say it is about TypeScript that makes the code harder to read as it becomes more complex? Just the additional type annotation syntax, extra concepts like generics and/or the accompanying more exotic features of TS, the type definitions physically adding many lines of extra code, something about TypeScript that encourages code to be written in a certain way that is different and more complex?

As I remember, the biggest thing is the tendency of TypeScript to result in deeply nested code, which is very hard to read/unwind.

Note that I haven't touched TS in about two years now, so my memory is a little fuzzy.

Would this be in a different way to the equivalent JavaScript code? Or do you just mean like physically, the layout of the code with the additional TypeScript syntax makes it appear more nested/indented and more difficult to parse?

TS doesn't really do any worse than JS in this respect; the key here is the difference between either of them and Python.

Ah, this is a facepalm moment in that I had completely misread the initial comment not as being a comparison of JS/TS to python, but of JS to TS then a further comparison to python. Now it makes much more sense!

Python beat Perl in the 90s-2010 era thanks to its readability which was always advertised as a supreme advantage. Of-course Python 3.x is more complex, but even as an occasional Python user who doesn't like Python that much, I can still dive into an OSS python project and understand what its doing with little prep or Googling needed.

Can't really say that for most programming languages with the exception of Go.

JavaScript has a clearly superior model to support any:{custom:"data"}

Reply on news.ycombinator.com