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

Python's pre-declared constants are kinda weird

sebsite.pw

Post reply on HN
Print view View original

131–140 of 234 posts

Re: Python's pre-declared constants are kinda weird

#131

Post by YuechenLi »

belorn wrote: post #117
YuechenLi wrote: post #107

Python is just such a weird language in general despite its popularity that I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments. I mean, I was one of the first person to start using Python when I was in grad school almost a decade ago when everybody else in my field was still using Matlab for their lab code, for the simply reason that Nump…

Are academics who are not working in computer science interested in learning statically typed programming languages? In the past, the usual answer to people who need a programming language but did not want to learn programming was to give them a domain specific language that focused on solving the specific problem they wanted to solve.

Well, many times in my field of mechanical engineering, they have to, because CFD and FEA are very performance sensitive. The professors I had were still writing FORTRAN and C++ before, but maybe they've switched to Rust now.

Re: Python's pre-declared constants are kinda weird

#132

Post by tialaramex »

AdamH12113 wrote: post #96
Animats wrote: post #32

Earlier quoted context omitted.

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past.…

Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do. Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.

> Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do.

The thing you want is what Rust delivers in the box, &str a string slice reference type, in Rust's case the "string" is UTF-8 encoded text. On the bare metal the way to represent this type is as a "fat pointer" typically a pair of registers, one with the address of the first byte of the string and the other with a length.

C should have fat pointers, they were proposed, for IIRC C89 but the proposal was rejected. That's pretty sad, the fat pointer is expensive to the point of maybe feeling extravagant on a PDP-11, but by 1989 that's long gone.

More ridiculously C++ didn't get this type (which it eventually called std::string_view and provides in its standard library not as a built-in) until 2017, years after Rust 1.0 shipped. In the meanwhile C++ just did not have a sensible way to do this, strings are hard apparently.

The string buffer feature, allowing you to actually make strings is less important, as you say it will need an allocator and so on very bare metal you might not have this - but the string slice reference doesn't need an allocator.

I think it's worth delivering the basic "it's a growable array type, duh" implemenation of the string buffer type, which is what Rust's String type is, but C++ chooses to ship an oddly specific small-string optimized version as std::string right from the offset.

Re: Python's pre-declared constants are kinda weird

#133

Post by gucci-on-fleek »

stouset wrote: post #71
hmokiguess wrote: post #34

Python is awful. There are so many one offs in libraries, none agree on a style, it’s slow, and it’s way too easy to do the wrong thing. I often work with data scientists and have to productionize their jupyter notebooks which is pure suboptimal hell. I guess it must be a good easy learning curve for research/scratchpad

I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default. Ruby has such a nice holistic consistency to it. With a few exceptions, it feels like it was conceived of by one person with a core idea in mind. Python feels like a mess.

> I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default.

This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer [0], while Ruby's website [1] still points you to a third-party installer, which doesn't even have native support since it uses MSYS2 [2].

Most non-developers use Windows, so if you're choosing the first language to teach a large group of people, good Windows support is fairly important. Python being the "default" introductory language gave it a huge number of users, then I suspect that everything flowed down from there.

[0]: https://web.archive.org/web/20160824235759/https://www.pytho...

[1]: https://www.ruby-lang.org/en/downloads/

[2]: https://rubyinstaller.org/

Re: Python's pre-declared constants are kinda weird

#134

Post by rmunn »

Waterluvian wrote: post #125
rmunn wrote: post #114

Earlier quoted context omitted.

What is the best language for controls and embedded, in your opinion? I assume from your comment that it's not a great choice as a first language to teach newbies, but I've never done anything in the field of robotics or embedded stuff, so I'm quite ignorant in that area.

None of them. Walks away. Stops. Turns. All of them. It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun! . Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you can…

If I'm teaching you programming and you've learned Scratch, I'm going to hand you Snap! (https://snap.berkeley.edu/) next. Because it's Scratch, but with the artificial limiters removed. Snap! (the exclamation mark is part of the name) allows you to store lists in variables and pass them as inputs to functions, and it has the standard list-handling functions you'd expect, like filter and map. Moreover, it also allows you to store blocks (functions, basically) in data structures and pass them as inputs to other blocks, so you can actually learn to write code in functional-programming style.

Once you learn that Brian Harvey, one of the two main designers of Snap!, was one of the principle people behind Berkeley Logo (which itself was a variant of Lisp, though that wasn't clear to me when I was learning Logo at age eight), it all starts to become clear. Snap! is itself nearly a Lisp, just lacking macros (and Brian Harvey is trying to figure out how to add a macro system to Snap!, with the primary challenge being making it comprehensible in graphical-blocks form).

Re: Python's pre-declared constants are kinda weird

#135

Post by rmunn »

YuechenLi wrote: post #123
rmunn wrote: post #114

Earlier quoted context omitted.

What is the best language for controls and embedded, in your opinion? I assume from your comment that it's not a great choice as a first language to teach newbies, but I've never done anything in the field of robotics or embedded stuff, so I'm quite ignorant in that area.

If I'm not allowed to toot my own horn, I think for controls, you probably should not start with choosing a programming language, the first step is learning control theory and automata theory, you kinda have to understand feedback control/PID/steady state/jitter/hysteresis and the like. Python has never had great control libraries to begin with as far as I can remember (my info could be a bit outdated though), so the…

Please do toot your own horn. I assume you're referring to https://github.com/yuechen-li-dev/oct — tell us why it's good.

Re: Python's pre-declared constants are kinda weird

#136

Post by YuechenLi »

Chinjut wrote: post #122
YuechenLi wrote: post #107

Python is just such a weird language in general despite its popularity that I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments. I mean, I was one of the first person to start using Python when I was in grad school almost a decade ago when everybody else in my field was still using Matlab for their lab code, for the simply reason that Nump…

I hate Python and I'm onboard with putting it down in many ways, but significant whitespace isn't weird in a first programming language. It's only weird if you've absorbed from some other language the convention that whitespace shouldn't be significant.

Oh, by "significant whitespace" I meant whitespace sensitive indentation, which I think Python and YAML are the only languages that has that feature.

Re: Python's pre-declared constants are kinda weird

#137

Post by Waterluvian »

rmunn wrote: post #134
Waterluvian wrote: post #125

Earlier quoted context omitted.

None of them. Walks away. Stops. Turns. All of them. It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun! . Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you can…

If I'm teaching you programming and you've learned Scratch, I'm going to hand you Snap! ( https://snap.berkeley.edu/ ) next. Because it's Scratch, but with the artificial limiters removed. Snap! (the exclamation mark is part of the name) allows you to store lists in variables and pass them as inputs to functions, and it has the standard list-handling functions you'd expect, like filter and map. Moreover, it also allo…

We’re spoiled with great options. My kid jumped right from Scratch to JavaScript for game dev because he loves how he can put his games on the Web easily. Huge props to Microsoft Make Code Arcade for allowing you to port your Scratch to JS. It gave him a powerful way to see what he knows and how it looks like in JS.

Re: Python's pre-declared constants are kinda weird

#138

Post by rmunn »

mixmastamyk wrote: post #105
rmunn wrote: post #39

Earlier quoted context omitted.

Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it. But to describe the Python community as "spen[ding] the…

You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.

Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment.

But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.

Re: Python's pre-declared constants are kinda weird

#139

Post by tialaramex »

Animats wrote: post #32
neillyons wrote: post #19

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true! True, False = False, True Python 3 you could no longer reassign them.

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past.…

You list a few absences but absences aren't the end of the world, I say it's worse when designers make a booboo where the language semantics are wrong. In C++ there are so many of these it's not sporting but a recurring example from the garbage collected languages would be the for-each loop mistake.

Several times now†, people make a language where the way a for-each loop (for each Goose in Geese ...) works is that there's a single variable Goose and each time around the loop we change which value is referred to by the Goose variable. This seems intuitively like a reasonable way to do this. But it's wrong and eventually your programmers will get nasty surprises. What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.

† At least Go and C#, I think there are others

Re: Python's pre-declared constants are kinda weird

#140

Post by JodieBenitez »

jherskovic wrote: post #81

Python has some absolutely kick-ass libraries, even without C. It has Django, for those of us who like developing web apps but never could fall in love with Ruby on Rails. And Django is amazing. I've also yet to see a better language for writing quick ETL scripts and pipelines. Also, an 'I need a script for $SYSADMIN_TASK but I want to be able to read it later.' Anything dominated by external latencies (web, database…

> Also, an 'I need a script for $SYSADMIN_TASK but I want to be able to read it later

uv + PEP723 make this even better.

Post reply on HN