Hacker News Reader

Comment by brianberns | Hacker News Reader

I agree, and yet dynamic languages such as Python continue to gain popularity because they are supposedly easier for newbies to pick up. I think we (experienced software developers) have to do a better job of educating newcomers about the dangers of dynamic typing.

https://stackoverflow.blog/2017/09/06/incredible-growth-pyth...

View on HN

Why do you think static languages are easier to pick up? I have had the opposite experience. In managing people who do not aspire to be software developers, but do need to write simple programs to perform basic job functions, I’ve seen much more openness to Python than to more structured alternatives. If you have suggestions that set the bar for working code lower than we can get with Python then I would love to hear them.

I think Python is perceived as easy to pick up because it's a scripting language, not because it's dynamically typed. I wish I could recommend a statically-typed scripting language that's easy to pick up, but I'm not familiar with any mainstream ones (and I'm probably too far from the newbie stage myself to be a good judge).

It's not even the dynamic typing that makes Python easy to pick up. It's readable core language, and a well-documented and reasonably thorough standard library that doesn't ignore things that are useful specifically for teaching people (like turtle graphics - I've yet to see a better way to teach loops, recursion etc than getting someone to draw stars and spirals with a turtle).

The more TypeScript I write, the less I like Python. In a recent project that involved pulling some data from Hive via Pandas dataframes and merging it with data from a JSON REST API, then doing some calculations and stuffing that data into a different JSON REST API (with a totally different shape to the data), I kept running into little edge cases that Python forces you to handle explicitly vs Javascript just doing what you want. It also annoys me to an irrational degree that Python has "dicts" and not objects, "lists" and not arrays, KeyError everywhere, error looking up dict keys as ints (you can only look them up by str with no implicit type conversion), can't say "dict.keyname", have to do dict['keyname'] or usually dict.get('keyname') and handle things like dicts within dicts where you're not sure if keys exist even more verbosely, etc

example of something annoying that came up:

    foo = [1,2,3]
    bar = {'1': 1, '2': 2, '3': 3}
    for i in foo:
      print(bar.get(i))

What does it output? None x3. In order to get it to do the thing, I did something like this:

    foo = [1,2,3]
    bar = {'1': 1, '2': 2, '3': 3}
    for i in foo:
        str_i = str(i)  # even more fun when this throws
        print(bar.get(str_i))

I use python because most of my coworkers understand it and it has wide library + runtime support where I work, but it's definitely not my favorite thing to work with. Dynamic typing where types still matter and where the language is picky about implicit type conversions kind of sucks.

I also couldn't do:

    foo = [1,2,3]
    bar = {'1': 1, '2': 2, '3': 3}
    for str(i) in foo:
        print(bar.get(i))

Which was also eyeroll. Like, I get it, but...c'mon. Working with Pandas is also more or less learning another language, with the insanity that is df.T.whatever and df.loc[]:

    df.loc[df['shield'] > 6, ['max_speed']]

I'm sure that someone will comment about how I'm an idiot and there's a much better way to do it, but given PEP20:

    There should be one-- and preferably only one --obvious way to 
    do it. Although that way may not be obvious at first unless 
    you're Dutch.

I guess I'm not Dutch enough.

> I guess I'm not Dutch enough.

I could write an "obvious" fix for your example, but I expect that it'd be unsatisfactory, since the real problem likely has a different solution.

It looks like you might want a little utility to transform key lookups to a standard. Web frameworks do stuff like that for mapping URLs to functions, to ignore case, etc.

You might be interested in learning about the ``dict.__missing__`` magic method.

dicts are like Maps in JavaScript, so the type of a key matters. It enables usecases where your keys aren't always strings:

  >> bar = {1: "a", "1": "b"}
  >> bar[1]
  "a"
  >> bar["1"]
  "b"

So, in a discussion where most complaints about Python are that it is dynamically typed (vs statically typed eg Java, Go, Rust etc) you're complaining that it is strongly typed (eg vs weakly typed eg Javascript)?

I don't have a problem with that - it just seemed kinda incongruous in that context. I imagine the other critics would be even more unhappy about implicit type conversions.

No, the problem you had was not because of Python, but because of JavaScript, JavaScript's objects only let you put strings inside of object keys, and JSON inherited that, it would have been more sensible for bar to come from the API like this:

    bar = {1: 1, 2: 2, 3: 3}

Why should it implicitly convert a number to a string? That's a common source of bugs. Explicit is definitely better.

Why not just do the following?

    foo = [1,2,3]
    bar = {'1': 1, '2': 2, '3': 3}
    for i in foo:
        print(bar[str(i)])

I'm not familiar with Pandas but I'm guessing that its API is similar in style to numpy just by looking at the code snippet. I can't rule out that you might be an idiot, but it is not because you find that line of code confusing. The numpy API is horrific. Its abuse of operator overloading and undermining of expectations is shockingly awful. They should have just made a separate query language.

At least it's safer than newbies picking up javascript or php. ;)

Reply on news.ycombinator.com