6 ms·

Interesting to read his description of the language, which sounds pretty much exactly like python is now. It’s a pretty good testament to why python gained and

Interesting to read his description of the language, which sounds pretty much exactly like python is now. It’s a pretty good testament to why python gained and retained popularity. Though not without fault, python is certainly one of the best-designed languages ever created, in my opinion.

kumarvvr 9y ago
It may not be the most efficient one out there, but it certainly is the most productive, atleast for me. God I love the language. The only language, that allows my thoughts to flow alongside writing code that allows my thoughts to manifest. I am well experienced with C# as well, but something about statically typed stuff (I worked with C# before the dynamic stuff wasn't added to it) breaks the flow of thoughts. With python, it's like designing systems on paper. Friction-free.
- y4mi 9y ago
  It would be great to still have static constraints as an option though. I absolutely love the free form in the prototype phase, but once I've got that one nailed and want to make it maintainable... well, I always miss it at that time.
  - kumarvvr 9y ago
    It can be done partially with type-hinting in python. However, quickly iterating through to a solution and then optimizing it in a static language is a workflow that can be adopted. However, that may be necessary for only the most critical parts of an application. With software development moving towards distributed computing, there is a lot of breathing space for languages like Python.
    - deleted 9y ago
      [deleted]
  - ageofwant 9y ago
    Yea thats what mypy is for, and that fits my workflow too: Rapidly prototype once the API has stabilised, I add the typehints. For unfammilliar codebases using MonkeyType is now a option too.
    - nicolaslem 9y ago
      I started using type hints and it greatly improves the readability and sometimes catches a mistake. But would love for it to be more. Maybe a flag to the interpreter that would raise an exception each time it detects an inconsistency at runtime. I can imaging turning this feature on in a staging environment.
      - deleted 9y ago
        [deleted]
      - ATsch 9y ago
        From my understanding, this should be possible by setting the sys.settrace hook. It would slow down every function call, but I'm surprised it looks like nobody has done it yet.
- willtim 9y ago
  C# does not in any way represent the best that static typing has to offer. Try F#, Haskell or OCaml seriously before discounting static typing. These functional languages offer much better safety (e.g. no nulls, no casts, case exhaustiveness) and are as succinct as Python. They also generalise a lot of features that are ad-hoc in C# and Python (e.g. async-await is a library in F# and Haskell). For me, using Haskell is also like "designing a system in paper, friction free". In fact, I tend to write down the types and type check them, before I attempt to fill in any implementation. Truth be told, I am not a Python fan. I am seeing it take over in my industry, because it's superficially 'easy' and it's popular. The lack of static typing only later becomes a big problem when large codebases start to appear with many contributors.
  - kumarvvr 9y ago
    Any good resources on learning how to solve problems by leveraging strong type systems?
    - willtim 9y ago
      There's "Real World OCaml" (new) and "Real World Haskell" (a bit out of date). But my favourite introductory text, which is not free, is Graham Hutton's "Programming in Haskell".
      - kumarvvr 9y ago
        Thanks for the info. Just curious, what sort of problems are strongly typed languages most suited for? In the sense that which class of problems can be solved using them leading to elegant solutions.
        willtim 9y ago
        I use Haskell professionally in the area of quantitative finance in a large team with a multi-million line codebase. Everything is built upon domain specific libraries, sometimes many layers deep. And these libraries are constantly changing to keep pace with the business. Strong types tell us early when things are broken. Others are attempting to use Python for similar projects, but it isn't fun (we have some of their alumni). Haskell's effect typing also helps us. For example, for reproducible calculations, it is critical that no data is pulled-in via a backdoor (i.e. a side effect). Even reading and using the current system datetime is something we want to prevent. This can be expressed in the types using Haskell.
- renox 9y ago
  That's funny: my python's experience is totally opposite from yours: I find that me and my colleague keep making mistakes that would have been caught by the compiler.. So we're replacing a Python based test system by a C++ one.
developer2 9y ago
There's a lot I like about Python, but there are a couple of things that they've gotten so horribly wrong. 1. The KeyboardInterrupt exception for SIGINT. Whoever came up with that idea destroyed the credibility of the entire interpreter. Python falls flat on its face to me because of this one design choice. It's impossible to write a Python script that will not dump a full debug stack trace if you send SIGINT (ie: Ctrl+C) before the first line of your script is reached. That is, even if your very first line of code is a try/except block intended to catch KeyboardInterrupt, a SIGINT early on will still fail spectacularly at some point during Python's internal startup. Python runs a lot of code before turning control over to your script and it's simply not possible to, from within Python, catch these signals. In order to provide a professional piece of software to clients that will not dump debugging gibberish to the terminal, one must wrap every single Python script with a shell script or small C binary that catches signals and proxies/rewrites SIGINT as SIGTERM, in order to avoid KeyboardInterrupt entirely. Something as fundamental as signal handling having been botched to this extent is frustrating. 2. The asyncio module. They screwed up the async implementation in the earlier phases, and the hacks that have been implemented in an attempt to improve the situation are grotesque. The state of async in Python is confusing enough as it is, but if you happen to run into one of the edge cases where the ways in which they've hacked the core of the language to make room for the async stuff affects you, you're in for quite the ride.
- eesmith 9y ago
  While it's never been a problem for me, I can see that #1 makes a lot of sense. % python -c pass ^CTraceback (most recent call last): File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 62, in <module> import os File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 400, in <module> import UserDict File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 83, in <module> import _abcoll File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_abcoll.py", line 9, in <module> """ KeyboardInterrupt There was some discussion about this at https://bugs.python.org/issue14228 https://bugs.python.org/issue14228 , with strong pushback from some of the core developers. One of the workarounds was to do: python -S to avoid importing the site module, then set your signal handlers, then import site manually. In that case the only output, if caught at the wrong time, will be the message 'KeyboardInterrupt'. This isn't quite what you want, but it's a lot closer. (Another request for this feature is at https://bugs.python.org/issue24261 https://bugs.python.org/issue24261 .) If you are still working with Python, and still want this feature, you might contribute to that second thread. The first is rather contentious.
pimmen 9y ago
It's both very expressive and readable, and it's the last part I absolutely love. I can understand Python code very quickly and I can often recognize the algorithm that's implemented. And you can do composition easily, that's the main seller for me.

kumarvvr 9y ago

It may not be the most efficient one out there, but it certainly is the most productive, atleast for me. God I love the language. The only language, that allows my thoughts to flow alongside writing code that allows my thoughts to manifest. I am well experienced with C# as well, but something about statically typed stuff (I worked with C# before the dynamic stuff wasn't added to it) breaks the flow of thoughts. With python, it's like designing systems on paper. Friction-free.

y4mi 9y ago
It would be great to still have static constraints as an option though. I absolutely love the free form in the prototype phase, but once I've got that one nailed and want to make it maintainable... well, I always miss it at that time.
- kumarvvr 9y ago
  It can be done partially with type-hinting in python. However, quickly iterating through to a solution and then optimizing it in a static language is a workflow that can be adopted. However, that may be necessary for only the most critical parts of an application. With software development moving towards distributed computing, there is a lot of breathing space for languages like Python.
  - deleted 9y ago
    [deleted]
- ageofwant 9y ago
  Yea thats what mypy is for, and that fits my workflow too: Rapidly prototype once the API has stabilised, I add the typehints. For unfammilliar codebases using MonkeyType is now a option too.
  - nicolaslem 9y ago
    I started using type hints and it greatly improves the readability and sometimes catches a mistake. But would love for it to be more. Maybe a flag to the interpreter that would raise an exception each time it detects an inconsistency at runtime. I can imaging turning this feature on in a staging environment.
    - deleted 9y ago
      [deleted]
    - ATsch 9y ago
      From my understanding, this should be possible by setting the sys.settrace hook. It would slow down every function call, but I'm surprised it looks like nobody has done it yet.
willtim 9y ago
C# does not in any way represent the best that static typing has to offer. Try F#, Haskell or OCaml seriously before discounting static typing. These functional languages offer much better safety (e.g. no nulls, no casts, case exhaustiveness) and are as succinct as Python. They also generalise a lot of features that are ad-hoc in C# and Python (e.g. async-await is a library in F# and Haskell). For me, using Haskell is also like "designing a system in paper, friction free". In fact, I tend to write down the types and type check them, before I attempt to fill in any implementation. Truth be told, I am not a Python fan. I am seeing it take over in my industry, because it's superficially 'easy' and it's popular. The lack of static typing only later becomes a big problem when large codebases start to appear with many contributors.
- kumarvvr 9y ago
  Any good resources on learning how to solve problems by leveraging strong type systems?
  - willtim 9y ago
    There's "Real World OCaml" (new) and "Real World Haskell" (a bit out of date). But my favourite introductory text, which is not free, is Graham Hutton's "Programming in Haskell".
    - kumarvvr 9y ago
      Thanks for the info. Just curious, what sort of problems are strongly typed languages most suited for? In the sense that which class of problems can be solved using them leading to elegant solutions.
      - willtim 9y ago
        I use Haskell professionally in the area of quantitative finance in a large team with a multi-million line codebase. Everything is built upon domain specific libraries, sometimes many layers deep. And these libraries are constantly changing to keep pace with the business. Strong types tell us early when things are broken. Others are attempting to use Python for similar projects, but it isn't fun (we have some of their alumni). Haskell's effect typing also helps us. For example, for reproducible calculations, it is critical that no data is pulled-in via a backdoor (i.e. a side effect). Even reading and using the current system datetime is something we want to prevent. This can be expressed in the types using Haskell.
renox 9y ago
That's funny: my python's experience is totally opposite from yours: I find that me and my colleague keep making mistakes that would have been caught by the compiler.. So we're replacing a Python based test system by a C++ one.

developer2 9y ago

There's a lot I like about Python, but there are a couple of things that they've gotten so horribly wrong. 1. The KeyboardInterrupt exception for SIGINT. Whoever came up with that idea destroyed the credibility of the entire interpreter. Python falls flat on its face to me because of this one design choice. It's impossible to write a Python script that will not dump a full debug stack trace if you send SIGINT (ie: Ctrl+C) before the first line of your script is reached. That is, even if your very first line of code is a try/except block intended to catch KeyboardInterrupt, a SIGINT early on will still fail spectacularly at some point during Python's internal startup. Python runs a lot of code before turning control over to your script and it's simply not possible to, from within Python, catch these signals. In order to provide a professional piece of software to clients that will not dump debugging gibberish to the terminal, one must wrap every single Python script with a shell script or small C binary that catches signals and proxies/rewrites SIGINT as SIGTERM, in order to avoid KeyboardInterrupt entirely. Something as fundamental as signal handling having been botched to this extent is frustrating. 2. The asyncio module. They screwed up the async implementation in the earlier phases, and the hacks that have been implemented in an attempt to improve the situation are grotesque. The state of async in Python is confusing enough as it is, but if you happen to run into one of the edge cases where the ways in which they've hacked the core of the language to make room for the async stuff affects you, you're in for quite the ride.

eesmith 9y ago
While it's never been a problem for me, I can see that #1 makes a lot of sense. % python -c pass ^CTraceback (most recent call last): File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 62, in <module> import os File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 400, in <module> import UserDict File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 83, in <module> import _abcoll File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_abcoll.py", line 9, in <module> """ KeyboardInterrupt There was some discussion about this at https://bugs.python.org/issue14228 https://bugs.python.org/issue14228 , with strong pushback from some of the core developers. One of the workarounds was to do: python -S to avoid importing the site module, then set your signal handlers, then import site manually. In that case the only output, if caught at the wrong time, will be the message 'KeyboardInterrupt'. This isn't quite what you want, but it's a lot closer. (Another request for this feature is at https://bugs.python.org/issue24261 https://bugs.python.org/issue24261 .) If you are still working with Python, and still want this feature, you might contribute to that second thread. The first is rather contentious.

pimmen 9y ago

It's both very expressive and readable, and it's the last part I absolutely love. I can understand Python code very quickly and I can often recognize the algorithm that's implemented. And you can do composition easily, that's the main seller for me.