Hacker News Reader

Comment by japanman185 | Hacker News Reader

[flagged]

I prefer compiled and statically typed languages myself, but it seems a bit absurd to not consider Python a general purpose programming language. It's Turing complete, has one of the most fully-featured standard libraries in existence, and can interface with native libraries.

What does the term "scripting language" mean to you?

Not the original poster, but to me it usually refers to a language that is expressive and high-level but usually not fast or efficient enough to implement the actual heavy lifting. It seems fair to call Python a scripting language. This is not a derogatory term, rather it actually describes a great way to build software and explains Python's success.

Probably something along the lines of "something I don't like, but don't have any objective reasons to prove why it is bad".

To me, it means that the person who wrote "scripting language" probably doesn't know what they're talking about.

Can you elaborate on the issues you've seen? Was the code haphazardly thrown together, or did it follow the usual modern practices (pip-tools or Poetry, dataclasses, type checking, Pydantic, etc.) and still suffer the problems?

Python is like anything in that it rewards experience. If you know about asyncio you can write beautiful, performant code that can deal with networking, files, and other blocking resources without halting the program every time. If you know about processor executor pools -- you can easily execute CPU-intensive operations on different cores even though your main program is single-threaded. If you know a little about databases you can write highly portable and simple queries with SQLite.

You can use Python in the same way that other languages allow you to write performant servers, desktop applications, websites, and even software that runs on phone. But you need to know what the best approaches are. The thing about Python is that its a very old language. It didn't always have things like asyncio which is now arguably the best approach for dealing with concurrency and the modern challenges of blocking I/O. New libraries appear all the time, and the language and tooling continue to evolve. I think older developers who may have only dabbled in Python might have out-dated views about the language because there definitely were times in Python's history where it lagged far behind other languages.

Python is not a scripting language, it's a weakly-typed general-purpose programming language. I too dislike the lack of strong-typing, but there are dozens of good options if that's what I need in a codebase.

It sounds like your problem is with people who write Python, not Python itself. Not every person who writes code has the time or ability to learn all the nuances of strongly-typed functional languages. In my opinion, people outside of software engineering shouldn't bother with such esoteric domain knowledge. "Real" programmers like yourself are there for that reason - to rewrite their prototyped code in whatever style you see fit.

Complaining that they don't know how to program is a great way to alienate smart people in other domains. Knowledge of computer science tends to blow up people's egos in a way that I have observed in few other fields.

Python’s strongly, dynamically typed. Try adding “12”+3 and it will throw a TypeError at you.

That only works with a few built in types, like numbers. For any other type, you had better hope that the author has added such checks.

This isn't true, even if you define your own types/classes you still can't add them together willy nilly unless you (or a superclass) explicitly defined an addition operator. The Python language itself will never implicitly coerce a type for you, not even for floating point and integer addition. [0]

[0] https://www.pythonmorsels.com/type-coercion/

You're right. Classes don't even provide such operators by default:

  >>> class Foo:
  ...     ...
  ...
  >>> class Bar:
  ...     ...
  ...
  >>> a = Foo()
  >>> b = Bar()
  >>> a+b
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'Foo' and 'Bar'

If anything, the complaint is that pre-type-hinted Python was too quick to raise a TypeError without helping you know what types it was expecting. The only case I can think of where it was too lenient was where Python 2 conflated strings and bytes. That change was 90% of the pain of the Python 3 upgrade, and now they're different types.

I was speaking generally not specifically about addition. If you create new types and especially new operations on those types, then it will be up to you to add runtime "type checks" to avoid other failures. Try defining equality for a Point class for an example.

Found the rust dev

Reply on news.ycombinator.com