Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyre: A performant type-checker for Python 3

pyre-check.org

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Pyre: A performant type-checker for Python 3

#111

Post by zelphirkalt »

oblio wrote: post #109
zelphirkalt wrote: post #99

Earlier quoted context omitted.

It is actually more precisely a Scheme dialect. I used Racket for some time and then moved to Guile. I do not find it weird, having used other lispy languages before. Guile has many useful tools, like OS level threads and also a fibers library, community projects, a good manual, albeit sometimes lacking a few examples, an active community and mailing list and more. Since it is a Scheme, it adheres to a Scheme standar…

Lisp has been around for 60 years. Its adoption is lower than Cobol's or Fortran's and definitely lower than that of modern languages. Despite multiple commercial pushes over the decades. That's what's weird.

Wait, now we are switchting targets? What is this talk about Lisp? What Lisp? Or are you referring to the LISP? And what does it have to do with GNU Guile being perceived as weird by someone else? Right now it looks like you are talking about something unrelated.

Usually when someone claims, that something is "weird", I want to know, why they think so. When it is about programming languages, I would like to know what it is exactly, that they think is weird about that specific language and that is what my question entailed.

Re: Pyre: A performant type-checker for Python 3

#112

Post by oblio »

zelphirkalt wrote: post #111
oblio wrote: post #109

Earlier quoted context omitted.

Lisp has been around for 60 years. Its adoption is lower than Cobol's or Fortran's and definitely lower than that of modern languages. Despite multiple commercial pushes over the decades. That's what's weird.

Wait, now we are switchting targets? What is this talk about Lisp? What Lisp? Or are you referring to the LISP? And what does it have to do with GNU Guile being perceived as weird by someone else? Right now it looks like you are talking about something unrelated. Usually when someone claims, that something is "weird", I want to know, why they think so. When it is about programming languages, I would like to know what…

Guile suffers from the same problems any Lisp does: parantheses everywhere, the code all looks the same. Lisp devs love it (Yay! Homoiconicity! Code is data and data is code!), average devs hate it, it's hard for them to figure at a glance what's what.

Then, macros and DSLs are awesome for solo cowboy coders writing code, not so great for professional programmers working in large teams and reading code 10-100 times more than they write code. This also leads to fragmentation and half finished solutions since the solo devs generally scratch the itch but don't do the hard work required by the last 20% of the project (which as we know, takes 80% of the time).

Then, adoption. It's not there. There are no IDEs except for Emacs (not a popular editor/IDE) or commercial ones which are super expensive. Libraries are in much lower quantity and variety and frequently not as good as those of mainstream languages. Etc, etc.

Re: Pyre: A performant type-checker for Python 3

#113

Post by zelphirkalt »

oblio wrote: post #112
zelphirkalt wrote: post #111

Earlier quoted context omitted.

Wait, now we are switchting targets? What is this talk about Lisp? What Lisp? Or are you referring to the LISP? And what does it have to do with GNU Guile being perceived as weird by someone else? Right now it looks like you are talking about something unrelated. Usually when someone claims, that something is "weird", I want to know, why they think so. When it is about programming languages, I would like to know what…

Guile suffers from the same problems any Lisp does: parantheses everywhere, the code all looks the same. Lisp devs love it (Yay! Homoiconicity! Code is data and data is code!), average devs hate it, it's hard for them to figure at a glance what's what. Then, macros and DSLs are awesome for solo cowboy coders writing code, not so great for professional programmers working in large teams and reading code 10-100 times m…

The average dev has never taken a look at a lispy language and so cannot hate it. For the ones being hesitant to dip their toes in it, how can they really hate, what they do not know? It seems more like not being interest, than "hating" it, where "it" is the essence of such a language.

Macros, DSLs, well, of course you can abuse then, like anything else in computer programming. However, there are many examples of how they can be used in a great way. Look at some Racket macro things like typed Racket for example. Or look at pipelining operators. Or timing. Or memoization. All these are very well usable and there is no problem with using them in a team. Well written macros allow taking cool features from other languages to your Scheme dialect of choice.

Emacs is still well liked. I recommend you get on the mailing list and read a few weeks about how varied its usage is. Very active mailing list.

Libraries of lower quality? Even "much lower"? Where is your source for that? Not sure which specific ecosystem you have looked at, but that experience is completely different from mine.

Aside from the fact, that I can usually solve the problems by just using Guile features, Scheme and SRFIs, not even needing an external library, there are very clever people active in the ecosystems of lispy languages (including GNU Guile) and FP languages, outputting high quality code, often going beyond what some mainstream language library does, while using good abstractions to do so.

It is important, that languages like GNU Guile, which implement interesting and powerful concepts, continue to attract people, who want to learn more than the mainstream fad and improve the status quo. It is a great journey of learning, which I recommend to any software developer looking to widen their horizon and to improve their skill.

Re: Pyre: A performant type-checker for Python 3

#114

Post by nickm12 »

mumblemumble wrote: post #108
nickm12 wrote: post #105

Earlier quoted context omitted.

I don't like the term "type hints" because typecheckers like mypy are genuinely proving type correctness. Yes, if you don't annotate part of your program then you can get a type error in that part of the program, likewise, if you pass a value of the wrong type, you can get a type error. But if you are using a typechecker, you are guaranteed that if your inputs are well-typed, then you won't have a type error, which i…

I like the term "type hint" because that really is exactly what they are. Typecheckers like mypy are (1) optional, and (2) are only as good as the type hints themselves. Unlike with a language that's actually statically typed, the relation of the type annotations to the actual types of the data operates largely on the honor system, so the type checking is more a validation of internal consistency than full-on static…

It's really not the honor system. If you verify with a type checker, you are proving that various type errors are impossible, provided that the caller respects the type system. The rigor is exactly the same, it's just that the type system allows for "gradual typing" so that it doesn't need to be strict as in a fully-typed language.

Re: Pyre: A performant type-checker for Python 3

#115

Post by dunefox »

oblio wrote: post #112
zelphirkalt wrote: post #111

Earlier quoted context omitted.

Wait, now we are switchting targets? What is this talk about Lisp? What Lisp? Or are you referring to the LISP? And what does it have to do with GNU Guile being perceived as weird by someone else? Right now it looks like you are talking about something unrelated. Usually when someone claims, that something is "weird", I want to know, why they think so. When it is about programming languages, I would like to know what…

Guile suffers from the same problems any Lisp does: parantheses everywhere, the code all looks the same. Lisp devs love it (Yay! Homoiconicity! Code is data and data is code!), average devs hate it, it's hard for them to figure at a glance what's what. Then, macros and DSLs are awesome for solo cowboy coders writing code, not so great for professional programmers working in large teams and reading code 10-100 times m…

Guile suffers from being a great language then?

Re: Pyre: A performant type-checker for Python 3

#116

Post by nickm12 »

globular-toast wrote: post #68
nickm12 wrote: post #54

Earlier quoted context omitted.

I've been on teams at multiple companies that have used type annotations for Python. Developers have generally loved adopting type annotations because it (1) makes the code easier to understand (2) makes the code easier to refactor (3) improves integration with IDEs and (4) catches real bugs. I disagree that type errors "aren't practically a problem". NoneType errors and AttributeErrors turn up all the time in Python…

Clearly didn't watch the talk then. He found that about 1-2% of errors in real world projects were type-related errors.

I got around to watching the entire talk. It's not convincing to me. The presentation tacitly assumes that the only benefit to type systems is catching type errors and ignores the benefits to code readability and tooling. It also assumes that time spend developing and time spend debugging are fungible and I find that a bit simplistic; I would gladly trade debugging time for development time, even if the ratio is uneven. Finally, it doesn't even talk about the runtime performance penalty that dynamic languages typically incur.

Aside: It's worth commenting more on "code readability" because it cuts both ways. It can absolutely be the case that a complex, manifest type system can be a hindrance to understandably and productivity due to the "noise" of all the types that need to be written. I think struggling with C++ and (to a lesser extent) Java typing is part of the reason the industry really embraced dynamic languages in the 2000s. Python and Ruby were like a breath of fresh air. But eventually we built large systems with these languages and discovered the pain that comes from having no type-safety.

The trend I've seen in the last decade is to embrace type inference, with explicit type declarations on function signatures and otherwise only when needed for disambiguation. To me, this is the sweet spot, giving the benefits of static typing with much of the cleanliness and concision of dynamic languages.

Re: Pyre: A performant type-checker for Python 3

#118

Post by scrollaway »

lacker wrote: post #67
short_sells_poo wrote: post #32

Earlier quoted context omitted.

It's starting to look like the huge embarrassment that is python packaging and environment management. I work with the language every day, and I still have no idea what am I supposed to use between conda, pip, setuptools/setup.py, pyproject, meta.yml, poetry, pipenv, etc... Conda is so slow that I sometimes wonder if we are being trolled by some cruel God of programming. Pip is faster, but version resolution is iffy.…

I feel like the problem is that pip is clearly the most popular, but philosophically the pip developers do not want to build a solution to all packaging and environment management into pip. If I were pip dictator, I would try to make pip the one tool to handle all python packaging and environment management. In particular, that means pip would handle the management of different Python versions, different Python envir…

You're kind of describing poetry. I think Python has a real future with solved packaging if Poetry can get the backing it needs at the language level.
Post reply on HN