←back to thread

620 points tambourine_man | 1 comments | | HN request time: 0.222s | source
Show context
serbuvlad ◴[] No.43750075[source]
All things considered, this is pretty cool. Basically, this replaces

    db.execute("QUERY WHERE name = ?", (name,))
with

    db.execute(t"QUERY WHERE name = {name}")
Does the benefit from this syntactic sugar outweigh the added complexity of a new language feature? I think it does in this case for two reasons:

1. Allowing library developers to do whatever they want with {} expansions is a good thing, and will probably spawn some good uses.

2. Generalizing template syntax across a language, so that all libraries solve this problem in the same way, is probably a good thing.

replies(12): >>43750226 #>>43750250 #>>43750260 #>>43750279 #>>43750513 #>>43750750 #>>43752117 #>>43752173 #>>43752293 #>>43754738 #>>43756560 #>>43763190 #
rwmj ◴[] No.43750513[source]
I did a safe OCaml implementation of this about 20 years ago, the latest version being here:

https://github.com/darioteixeira/pgocaml

Note that the variables are safely and correctly interpolated at compile time. And it's type checked across the boundary too, by checking (at compile time) the column types with the live database.

replies(1): >>43750774 #
tasuki ◴[] No.43750774[source]
Yes, what you did is strictly more powerful than what the Python people did. And you did it 20 years ago. Well done, have an upvote. And yet, here we are in 2025 with Python popularity growing unstoppably and (approximately) no one caring about OCaml (and all the other languages better than Python). It makes me sad.
replies(3): >>43751186 #>>43751601 #>>43755054 #
skeledrew ◴[] No.43755054[source]
It's interesting how the majority has explicitly chosen NOT to use the "better" languages. Is the majority really that bad in their judgment? Or is it that "better" is actually defined by adoption over time?
replies(3): >>43755431 #>>43756148 #>>43757638 #
daedrdev ◴[] No.43755431[source]
It's clearly better in their opinion, they just aren't optimizing for the same metrics that you are. Python is better because it's easy for people to learn, imo.
replies(1): >>43755740 #
throwawaymaths ◴[] No.43755740[source]
its not easy to learn. its a challenge even getting it installed and running. what even is a venv? how do you explain that to a beginner?

python is popular because its what teachers teach.

replies(6): >>43756172 #>>43756692 #>>43756781 #>>43756970 #>>43757280 #>>43758584 #
zahlman ◴[] No.43756692[source]
On modern Linux you can type `python` at the command prompt and get a REPL. On Windows you download an installer from the official website (just like one usually does to install anything on Windows), then use `py` at the command prompt.

You don't need to `import` anything to start teaching Python. Even then you can do quite a lot with the standard library. Even then, unless you're using 3.11 or later on Linux you can let Pip install with `--user` until you actually need to isolate things between projects. (And even with new Python on Linux, the instructor can typically avert this by just installing a separate Python in `/usr/local/bin` for example. Yes, that's "cheating", depending on the classroom environment. But that's part of the point: installation hurdles are hurdles for self-learners, not for students.)

You only need to learn about virtual environments once you have projects with mutually conflicting dependencies, and/or once you're at a point where you're ready to publish your own software and should be learning proper testing and development practices. (Which will be largely orthogonal to programming, and not trivial, in any language.)

And when your students do get to that point, you can give them a link such as https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... .

Teachers teach Python because it's easy to teach while still being relevant to the real world, in particular because boilerplate is minimized. You don't have to explain jargon-y keywords like "public" or "static" up front. You don't have to use classes for quite some time (if ever, really). You can express iteration naturally. Types are naturally thought of in terms of capabilities.

In my mind, Python has all the pedagogical advantages of Lisp, plus enough syntactic cues to prevent getting "lost in a sea of parentheses". (Of course, it lacks plenty of other nice Lisp-family features.)

replies(3): >>43757779 #>>43759118 #>>43761005 #
throwawaymaths ◴[] No.43759118[source]
> You don't have to explain jargon-y keywords like "public" or "static" up front.

patently not true. you dont get too far into python -- especially if you are reading (or copypastaing) other People's code -- before you see if __name__ == "__main__" and any potential future programmer will rightfully ask "what the absolute fuck is this"

even "def" is kind of a weird fucking keyword.

Don't get me started about teaching beginners which datatypes are pass by reference and which are pass by value.

try explaining to an elementary school student why

    def foo(a):
       a = a + 1
doesn't change the caller's variable but

    def bar(a):
       a.append(1)
does.
replies(2): >>43763638 #>>43770561 #
1. zahlman ◴[] No.43770561[source]
> you dont get too far into python -- especially if you are reading (or copypastaing) other People's code -- before you see if __name__ == "__main__"

First off, if you are teaching someone, you are showing that person the code, and not allowing copy-and-paste.

Second, no, that comes up much less often than you'd expect.

Third, it's the same as `if value == 'example':`. Underscores are not jargon.

Fourth, it's trivially searchable. That's the part where you can copy and paste - into a search engine, which will immediately find you several competent explanations such as https://stackoverflow.com/questions/419163 .

> even "def" is kind of a weird fucking keyword.

Admittedly a poor choice, but not a deal breaker. You need the concept of functions to do programming. But you don't need the concept of data hiding, nor do you need any of the multiple, barely-related concepts described by the term "static".

> Don't get me started about teaching beginners which datatypes are pass by reference and which are pass by value.

There's nothing to explain. They are all pass by value, per the strict meaning of those terms.

Those terms have been widely seen as less than ideal for decades, however, because they fail to account for variables with reference semantics (i.e., what Python uses - which are sometimes called "names"). A more modern term is "pass by assignment", which correctly describes all variable passing in Python: passing an argument to a parameter is a form of assignment, and works the same way as assigning a value to a name.

This is far less complex than C#, in which user-defined types may have either value semantics or reference semantics, and which supports both pass by assignment and two separate, true forms of pass by reference (for initialization and for modifying an existing object). And certainly it's less complex than whatever C++ is doing (see e.g. https://langdev.stackexchange.com/questions/3798 ).

> try explaining to an elementary school student why

First: if someone gives you a bag with three apples in it, you can put another apple in the bag and give it back, and the other person will have a bag with four apples in it. But if you add 3 + 1, that doesn't change the meaning of 3. These are simple ideas that an elementary school student already understands.

Second: from extensive experience teaching beginners (never mind that you are moving the goalposts now), it makes no sense to get into the theory. It's not helpful. A student who can ask about this has already lost the plot, because the two examples use completely different syntax (a method call versus an assignment) so they shouldn't be expected to work similarly. You avoid this problem by using more precise language early on. "Change" is not an appropriate word here.

Third: you give this example because you think that `bar` (and you imply by your naming that a list is being passed) demonstrates pass by reference. This is simply incorrect. Please read https://nedbatchelder.com/text/names1.html.

Fourth: your use of profanity and the overall tone of your writing suggests that you simply don't like the fact that Python works the way that it does. This is not a good look IMO.

Just for the record, I've been in variations of this discussion countless times. I know what I'm talking about. All links above are in my bookmarks.