6 ms·

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 allow

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.

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.