5 ms·

Ya know, it’s funny. I like Python. We like it enough to actually use it in embedded products. It has its limits, and we use other tools where it doesn’t fit. P

Ya know, it’s funny. I like Python. We like it enough to actually use it in embedded products. It has its limits, and we use other tools where it doesn’t fit. Python in a browser seems like a keen idea. But JavaScript vs Python isn’t really the key thing for me on the web. It’s the uncanny pile of other software one uses to build a man-machine connection that flummoxes me. It’s the CSS, the DOM, the events, the browser API, the ever churning massive pile of complexity that interactive software has become with the voluminous W3C specs, expressed in near BNF form and full of edge cases and backwards compatibility, all so every thing my user does can be observed by myself a few megacorps. I honestly wouldn’t care if I could write it in Fortran. It’s such a minor wart of the whole mess. Caring about which actual language you can use in all the script tags of a jacked up text format feels like caring which font is being used in your favorite hot piece of government legislation.

__alexs 4y ago
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
  - 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.
underdeserver 4y ago
I used to read BNF forms on LCD displays.
at_a_remove 4y ago
I get it. As an Old, I have watched the web evolve, threw out my HTML 2.0 book not too long ago. Netscape floppies and Trumpet Winsock. CSS being invented by people who, I don't know, did they ever hear the four principles of Contrast, Repetition, Alignment, and Proximity? I feel like they heard one of them. A programming language for it that had a ten day deadline. Tables abused like Russian nesting dolls shellacked into layers just to serve as doorstops. Dead-end evolution that thrashed around in the tar pits for a long time, screaming before its expiration: Flash. And yet the network effect would keep this going even if you had a team of a thousand brilliant people design a rational replacements for all of this ad-hoc cruft that has traditioned its way into being something like a standard.
garfieldnate 4y ago
I agree here, Typescript is actually quite a nice language to write in, but the complexity of setting up a project and your own compiling pipeline and everything causes my head to spin.

__alexs 4y ago

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

underdeserver 4y ago

I used to read BNF forms on LCD displays.

at_a_remove 4y ago

I get it. As an Old, I have watched the web evolve, threw out my HTML 2.0 book not too long ago. Netscape floppies and Trumpet Winsock. CSS being invented by people who, I don't know, did they ever hear the four principles of Contrast, Repetition, Alignment, and Proximity? I feel like they heard one of them. A programming language for it that had a ten day deadline. Tables abused like Russian nesting dolls shellacked into layers just to serve as doorstops. Dead-end evolution that thrashed around in the tar pits for a long time, screaming before its expiration: Flash. And yet the network effect would keep this going even if you had a team of a thousand brilliant people design a rational replacements for all of this ad-hoc cruft that has traditioned its way into being something like a standard.

garfieldnate 4y ago

I agree here, Typescript is actually quite a nice language to write in, but the complexity of setting up a project and your own compiling pipeline and everything causes my head to spin.