5 ms·

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

matsemann 4y ago
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.
- edanm 4y ago
  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.)
  - xnorswap 4y ago
    In my experience lambdas are a lot easier to write with strong types and related tooling.
- Frotag 4y ago
  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 :(
  - richiebful1 4y ago
    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.
    - Frotag 4y ago
      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)
      - zasdffaa 4y ago
        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.
      - rjmill 4y ago
        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.
    - zaphirplane 4y ago
      Kotlin JavaScript typescript anonymous functions in golang
- gigatexal 4y ago
  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.
  - matsemann 4y ago
    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!
    - gigatexal 4y ago
      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.
    - jgalt212 4y ago
      True that. That's why I prefer R, and its built-in pipes, when I'm working with relatively clean data.
    - js2 4y ago
      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}
xrisk 4y ago
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!
- __alexs 4y ago
  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.
- IshKebab 4y ago
  > 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`.
- vasergen 4y ago
  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
singularity2001 4y ago
JavaScript has a clearly superior model to support any:{custom:"data"}
banannaise 4y ago
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.
- akhmatova 4y ago
  And this is actually a hugely important consideration in determining whether a language becomes successful, it turns out.
- marlowe221 4y ago
  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.
  - vasergen 4y ago
    For me it is other way around, untill it is something very simple
  - davnicwil 4y ago
    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?
    - banannaise 4y ago
      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.

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.

edanm 4y ago
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.)
- xnorswap 4y ago
  In my experience lambdas are a lot easier to write with strong types and related tooling.
Frotag 4y ago
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 :(
- richiebful1 4y ago
  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.
  - Frotag 4y ago
    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)
    - zasdffaa 4y ago
      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.
    - rjmill 4y ago
      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.
  - zaphirplane 4y ago
    Kotlin JavaScript typescript anonymous functions in golang
gigatexal 4y ago
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.
- matsemann 4y ago
  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!
  - gigatexal 4y ago
    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.
  - jgalt212 4y ago
    True that. That's why I prefer R, and its built-in pipes, when I'm working with relatively clean data.
  - js2 4y ago
    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}

xrisk 4y ago

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!

__alexs 4y ago
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.
IshKebab 4y ago
> 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`.
vasergen 4y ago
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

singularity2001 4y ago

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

banannaise 4y ago

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.

akhmatova 4y ago
And this is actually a hugely important consideration in determining whether a language becomes successful, it turns out.
marlowe221 4y ago
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.
- vasergen 4y ago
  For me it is other way around, untill it is something very simple
- davnicwil 4y ago
  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?
  - banannaise 4y ago
    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.