5 ms·

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

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-python/ https://stackoverflow.blog/2017/09/06/incredible-growth-pyth...

swalladge 8y ago
At least it's safer than newbies picking up javascript or php. ;)
stochastastic 8y ago
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.
- brianberns 8y ago
  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).
seanp2k2 8y ago
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.
- xapata 8y ago
  > 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.
- bkad 8y ago
  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"
- antod 8y ago
  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.
- Franciscouzo 8y ago
  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}
- throwaway37585 8y ago
  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)])
- sime2009 8y ago
  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.
int_19h 8y ago
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).

swalladge 8y ago

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

stochastastic 8y ago

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.

brianberns 8y ago
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).

seanp2k2 8y ago

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.

xapata 8y ago
> 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.
bkad 8y ago
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"
antod 8y ago
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.
Franciscouzo 8y ago
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}
throwaway37585 8y ago
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)])
sime2009 8y ago
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.

int_19h 8y ago

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