Python's “disappointing” superpowers • Hacker News Board

Re: Python's “disappointing” superpowers

#261

Post by sargstuff » Wed, Feb 08, 2023, 3:43 AM UTC

Goal directed-execution programming languages, such as 5th generation languages icon[0] & unicorn[1], would get the 100k (typed) / 10k(untyped) loc's down another factor of ten.

~1-2k loc around the range of being easy to get up to speed on what's going on than equivalent 100k/10k LOC program with less 'typing' issues. (compiler/interpeter & keyboard too!)

Haven't run across a uni-py language yet (python & unicorn mash up)

[0] : https://en.wikipedia.org/wiki/Icon_(programming_language)

[1] : https://en.wikipedia.org/wiki/Unicon_(programming_language)

Re: Python's “disappointing” superpowers

#262

Post by necovek » Sat, Feb 11, 2023, 9:06 PM UTC

bobbylarrybobby wrote: post #175

ReflectedImage wrote: post #100

Earlier quoted context omitted.

No programming language tells you if a program is correct at compile time. Type errors aren't a very common type of bug either.

“No programming language tells you if a program is correct at compile time” is technically true, but my experience is that about 99% of the refactors I do in rust, no matter how large, go back to working correctly as soon as the code compiles again. I don't think anything like this is possible in a language like python.

That's true, but mostly because one rarely compiles Python.

I've done significant refactors in untyped Python without much ado: as soon as your tests pass, code works too. I've done significant changes with tests passing on the first go.

Re: Python's “disappointing” superpowers

#263

Post by necovek » Sat, Feb 11, 2023, 9:32 PM UTC

cageface wrote: post #205

taeric wrote: post #194

Earlier quoted context omitted.

Amusingly, you don't know my actual stance. Which is probably closer to pro static types than to dynamic. My criticisms in this thread is that the static type brigade does not hinge on evidence. It is typically hollow claims and getting angry at dynamic languages for being obviously bad for lack of helping.

Hard evidence is hard to obtain for something as varied and unrigorous as software. After 25 years of working on all kinds of codebases I’ll take even badly engineered statically typed code over dynamic any day of the week including Sunday.

I wouldn't.

Badly designed software with terrible class structure (FooModel, FooSchema, FooSpec, FooSchemaSpec, FooSchemaSingle, FooSpecContainer with inexplicable relations between them) is way worse than a well designed non-explicitly-typed software.

Re: Python's “disappointing” superpowers

#264

Post by necovek » Sat, Feb 11, 2023, 9:43 PM UTC

Ferret7446 wrote: post #197

deshpand wrote: post #195

Earlier quoted context omitted.

A ~100k LOC project in a statically typed system with type hierarchies, interfaces, contracts and boiler plate will boil down to ~10k LOC in a dynamically typed language like Python. A 10k LOC project will be more readable than a 100k LOC project. Source: I have spent years coding in C++/Java, then Python. I have migrated Java projects into Python

Your problem is C++/Java, not static typing. Static typing does not add many extra lines of code. In most cases, it adds no extra lines of code, as declaring variable/param types is done inline. Heck, just look at static typing in Python.

Static typing is not only about declaring your arguments and variables as simple types (int, float, array of ints etc).

It means having a distinct type for any complex structure you pass around (think pre-normalization API params, post-normalization API params, slightly enriched post-processing data as separate type vs a dict of str to anything in Python), or anything you want to make compatible (think interfaces vs duck typing).