151–160 of 220 posts
Earlier quoted context omitted.
With writing code in english now, why have it use a slow weak language? ML still has a depth of libraries that can't be replicated easily but ML work is decreasing by the day with LLMs.
Because the English to code translation step is fallible
Earlier quoted context omitted.
It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…
This is even worse because you attempt to try to sell why types SOMETIMES make sense. But you aim with this for a language that did not have nor need types to begin with. People don't seem to understand that this is an issue. The library-situation is really not different from having types everywhere, and some people will do that too. > catch bugs that you might otherwise miss. People repeat this a lot. In about 22 ye…
Earlier quoted context omitted.
ML is basically the one use case for Python anymore. And that even shrinks by the day
How so?
AI/ML: interfacing with C++ libraries directly (or in Rust) is now a real option. For everything else, even 5 years ago I wouldn't have used Python, now there are even fewer reasons to do so. As far as I'm concerned the remaining use cases are notebooks and one-shot scripts.
Earlier quoted context omitted.
Well, that's the curse of machine learning: since everyone uses Python you have to deal with Python. Even though Python isn't very nice when things start to get serious and you don't want to spend your time fiddling with noise just to make something work at scale. I'd wish the ML/AI/LLM crowd would see that it is in their interest to get better developer ergonomics at scale. (I don't want to have to turn to C++)
Anything performance sensitive ends up being an extension in compiled code anyway Python is mostly just glue
The ML/AI ecosystem is a minefield, and pure Rust rewrites (Candle, Burn, ...) are still immature and incomplete. But I'm pretty sure we're eventually going to see the same uptake that's already happening in the data processing world.
Earlier quoted context omitted.
Elementwise equality! Given two dataframe columns or ndarrays, users often expect `==` to give out a column or ndarrays of bools (like `+`, ` `, `*, `&`, and just about every other binary operator).
What I love about operator overloading is that now you can't use operators without looking at their definition, in which case.. you could have done numpy.equals(a, b) anyway. Does a == b true, if all elements are the same? Does it return an array of booleans? It's anyone's guess!
Consider using Shamir secret sharing to share a secret, D, among several people with two people required to recover the secret. D is a positive integer, such as a randomly generated 128 bit AES key you are using to encrypt your launch codes or credit card database.
For anyone not familiar with Shamir secret sharing what you do is pick a prime number, p, that is larger than D and another random positive integer A, that is less than p. Then give each person a pair of numbers, (i, (Ai + D) % p), where each person gets a different i (which should be a positive integer less than p...it is OK to simply use 1, 2, 3, ...). Let's let Di = (Ai + D) % p.
(This is for the case where you want any two people to be able to launch your missiles or decrypt your database. If you wanted 3 required instead of giving out (i, (Ai + D) % p) you would give out (i, (Bi^2 + Ai + D) % p) where B is a randomly chosen positive integer less than p. For 4 required add on a Ci^3 term, and so on).
Given (i, Di) and (j, Dj) and p it is possible to recover A and D.
Here's what that looks like in a language where the big int library uses an accumulator style, i.e., operations are of the form X = X op Y, where the ops are methods on the big int objects. Assume Bi and Bj are big int objects initialized from i and j, and Di and Dj are already big into objects, as is p. This particular example is using Perl. (This is very old code. Since 2002 you can add a "use bigint" pragma to Perl code and then it would look a lot more like the second Python example below).
my $A = $Dj->copy()->bsub($Di); # Dj-Di
$Di->bmul($Bj); # j*Di
$Dj->bmul($Bi); # i*Dj
$Di->bsub($Dj); # j*Di-i*Dj
$Bj->bsub($Bi); # j-i
$Bj->bmodinv($p); # (j-i)'
$Di->bmul($Bj); # (j*Di-i*Dj)*(j-i)'
$Di->bmod($p); # (j*Di-i*Dj)*(j-i)' mod p
$A->bmul($Bj); # (Dj-Di)*(j-i)'
$A->bmod($P); # (Dj-Di)*(j-i)' mod p
Here's what it looks like in a language with the ops as function calls taking the big int objects as arguments. This example is Python without using operator overloading.
import operator as op
def recover(i, j, Di, Dj, p):
j_i_inv = pow(op.sub(j, i), -1, p)
A = op.mod(op.mul(op.sub(Dj, Di), j_i_inv), p)
D = op.mod(op.mul(op.sub(mul(j, Di), op.mul(i, Dj)), j_i_inv), p)
return A, D
def recover(i, j, Di, Dj, p):
j_i_inv = pow(j-i, -1, p)
A = ((Dj - Di) * j-i_inv ) % p
D = ((j*Di - i*Dj) * j_i_inv) % p
return A, D
OT: this reminds me of something I started to do once but never finished. I was going to write for each language we used at work that had a big int library but that did not support operator overloading a class that implemented a big int RPN calculator. Java, for example. Then recover would look something like this:
calc = new BigRPNCalc();
calc.do(j, i, "-", p, "modinv dup");
calc.do(Dj, Di, "- *", p, "mod swap");
calc.do(j, Di, "*", i, Dj. "* - *", p, "mod");
D = calc.pop();
A = calc.pop();
If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
For vectorizable problems there also won't be huge performance gains from switching to a compiled language because all the hard stuff is already done in highly optimized native code. The only time it really makes a difference is if you have to write a custom for loop or traversal.
Earlier quoted context omitted.
In practice, inertia is stopping me. For personal projects, I don't want to learn Rust just so I can do `def add(a: int, b: int) -> int`. For work, I don't really get a choice. I work on brownfield projects. We do use TypeScript, thankfully, for all the browser bits. But nobody is going to stop to refactor a 5 year old production code base from Python to Go just for better types. And -- pepega -- definitely not our c…
Meh, the amount of effort required to keep up to date with the python ecosystem churn is around the same as learning rust. More so if you are starting from scratch. I quit python after realizing the amount of effort it required to just implement the tooling for a project… when all of that comes included with rust. I have spent maybe an hour in the last year thinking about tooling. Glorious. But yeah, I feel for you.…
Earlier quoted context omitted.
Personally I like having my TypeScript cake and eating it. I also truly believe those who design type systems would benefit from taking a look what kind of code people programming in dynamically-typed languages produce.
I do too, but I feel like TypeScript stands alone as an unusually effective and pleasant to use bolted-on type system. I've not seen any other approach come close. (My sample size is Python, Ruby and Elixir)
Flow for Javascript was okay but Typescript I've found to be much nicer (last used flow years ago but occasionally I'd encounter bugs in Flow).
Python's is okay but it feels clunky.
Dynamically typed languages are going to decline with the rise of AI coding. Statically typed languages provide the determinism necessary to efficiently anchor probabalistic coding agents. You can throw as much type checking at dynamic languages after the fact, but youre just going to burn energy (and tokens) doing what another language gets 'for free'.
Yeah, in the age of AI where the whole goal is to not have to think, type as fast as you can with misspellings, and copy paste stuff without thinking, its TOTALLY a better system to worry about the types of whatever you are feeding into llms.