News for hackers. Stuff that matters.

A comment on Starlark Programming Language. Parent comment

Re:Starlark Programming Language by kccqzy on Monday December 09, 2024 @09:55AM (#42366742)
What you describe is really all large-scale Python projects look like. No types, just layers and layers of indirection, with the goal of making the interface simple and Pythonic while hiding implementation complexity. I don't think this is necessarily a fault given that this language explicitly decides to look like Python (and was in fact simplified from Python).

The worst Starlark code I've read has been written not by SREs, but by the Boq team as they have a fetish for accomplishing complicated configuration at build time. This was one of the reasons I've avoided Boq: an incomplete code base that's under development doesn't even begin to build, which is far worse than building something and seeing a real compiler error.

[ Parent | on HN ]
Re:Starlark Programming Language by yodsanklai on Monday December 09, 2024 @10:03AM (#42366829)
> No types

It's pretty easy to add types to Python nowadays. I'd consider it bad practice not to do so in a large project.

[ Parent | on HN ]
Re:Starlark Programming Language by kccqzy on Monday December 09, 2024 @11:10AM (#42367497)
That's only true for greenfield projects where people start a new project with types in mind. It's absolutely a nightmare for old projects because, without the need to write types, people write all kinds of code that cannot fit within what's possible in python's type annotations.
[ Parent | on HN ]
Re:Starlark Programming Language by poincaredisk on Monday December 09, 2024 @11:55AM (#42367890)
In my opinion it's a bad practice, and rewriting code to be typeable is a good idea for refactoring.

But I write Python for some time now, and I know what you mean. I have nightmares about codebases with dynamically generated class fields for example (though I heard ruby is even worse)

[ Parent | on HN ]
Re:Starlark Programming Language by seanmceligot on Monday December 09, 2024 @10:43AM (#42367237)
It would be nice if python would show types in the documentation. Not only do I need that all the time, it would show python was taking type safety serious.

For example, knowing the return type of a function is Union[DataFrame,Series] rather than simply DataFrame would save a lot of bad errors.

[ Parent | on HN ]
Re:Starlark Programming Language by zellyn on Monday December 09, 2024 @10:51AM (#42367328)
Starlark, unfortunately, does not really support (Python style) types yet. Facebook's version has some kind of types, but ideally Starlark would just learn to do mypy types.
[ Parent | on HN ]
Re:Starlark Programming Language by zellyn on Monday December 09, 2024 @10:50AM (#42367320)
What you describe is really what all programming languages, compilers, interpreters, etc. look like. Layers and layers of indirection, with the goal of making the interface simple while hiding implementation complexity, all the way down to assembly.
[ Parent | on HN ]