Live data from Hacker News

Python 1.0.0 is out (1994)

groups.google.com

41–50 of 150 posts

Re: Python 1.0.0 is out (1994)

#41
post #18

Earlier quoted context omitted.

Maybe one day, when CPython guys start taking JIT seriously and finally get rid of GIL.

Isn't multiprocessing + caching like Redis a good enough workaround? I know that it works well for web applications. Not sure about other domains.

Multiprocessing is not a free launch neither. I rediscovered recently many issues related to fork.

Luckily I mostly write IO bound code, so sticking with GILed threads is an option for me.

Re: Python 1.0.0 is out (1994)

#42
post #38

Earlier quoted context omitted.

Any good resources on learning how to solve problems by leveraging strong type systems?

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

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.

Re: Python 1.0.0 is out (1994)

#43
Want to play with it?

  conda create -n py1 python=1.0
  source activate py1
  python

  Python 1.0.1 (Mar 26 2014)
  Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
  >>>
Sorry Windows, only on macOS and Linux.

Re: Python 1.0.0 is out (1994)

#44
post #27

Earlier quoted context omitted.

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.

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.

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.

Re: Python 1.0.0 is out (1994)

#45
I think it's interesting to note the primary usecases / benefits mentioned: more readable than perl, better syntax than bash, easy to follow stacktraces. In short: an object-oriented scripting language. In that respect I think python has succeeded, probably beyond even the author's wildest dreams. And I love python, it's a language I use almost every day. The areas where it falls short are those which it was never designed for, as this announcement reminds us.

Re: Python 1.0.0 is out (1994)

#46

The most successful language in the last twenty years.

Arguably, that would be Java, which was introduced in 1995. For whatever hey are worth, most language popularity indexes (TIOBE, LangPop) place Java above Python with quite a large margin. Java may not get much exposure here or in startups, but if you go out in the real world of 'boring' business applications, Java is pretty much the defacto language (together with C#).

According to [this](https://stackoverflow.blog/2017/09/06/incredible-growth-pyth...) Stack Overflow study: "Python stands alone as a tag that is both large and growing rapidly; the next-largest tag that shows similar growth is R."

Re: Python 1.0.0 is out (1994)

#48
post #22

Earlier quoted context omitted.

Java's tooling support blows Python's tooling support right out of the water. The static type system of Java allows faster refactoring and IMHO makes development of large applications easier and less error prone. I use Python for simple scripts and often for data transformation. But e.g. at work we have a few million lines of C# that I would never ever want to manage if it was written in Python.

I always find it peculiar that people seem to defend a million line code base, like that is something to be proud off. The days I walk out of the office with less code in some mature project's repo are the days I know I accomplished the most.

Sometimes it's not possible to do it in another way. Hacker News' web-focused world doesn't apply to most of the software world where software is deployed on customers hardware for the customer to work with by themselves as much as possible.

If I had to deploy 10 microservices with 2 level caches and internal network routing on a whole server rack or in "the cloud", our customers would laugh in our face and choose one of our competitors that deploys on one or two on-site servers that can sit somewhere in the office and require minimal, if any, maintenance besides security updates.

Re: Python 1.0.0 is out (1994)

#49
post #38

Earlier quoted context omitted.

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

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.

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.

Re: Python 1.0.0 is out (1994)

#50

Earlier quoted context omitted.

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.

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]
Post reply on HN