[-] FizzyOrange@programming.dev 3 points 1 week ago

Not really. It will predict more vulgar output but that is fixed by fine tuning. It's not going to "poison" it in any meaningful sense.

[-] FizzyOrange@programming.dev 3 points 2 weeks ago

Why do you say it needs more time in the oven? I've had zero issues with it as a drop-in replacement for Pip in a large commercial project, which is an extremely impressive achievement. (And it was 10x faster.)

I tried Poetry once and it failed to resolve dependencies on the first thing I tried it on. If anything Poetry needs more time in the oven. It also wasn't 10x faster.

[-] FizzyOrange@programming.dev 3 points 1 month ago

Not the kinds of bugs he is talking about. This is about spectre mitigations.

[-] FizzyOrange@programming.dev 3 points 2 months ago

Presumably you could just buy that paper size? They're pretty similar sizes; printers all support both sizes. I've never had an issue printing a US Letter sized PDF (which I assume I have done).

Kind of weird that you guys stick to US Letter when switching would be zero effort. I guess to be fair there aren't really any practical benefits either.

[-] FizzyOrange@programming.dev 3 points 2 months ago

Well that just sounds insane. Isn't the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?

[-] FizzyOrange@programming.dev 3 points 4 months ago

no need for flatpack/appimage/snap ect

No matter how large their repo is you're always going to find some software they haven't packaged. Trying to convince the entire world to use your repo isn't scalable.

[-] FizzyOrange@programming.dev 3 points 4 months ago

That's not at all the conclusion you should draw. xz was linked into systemd but that was just a convenient target. Once xz was compromised it could have targeted literally anything that loaded it. Your only real defence would have been not to install it at all.

[-] FizzyOrange@programming.dev 3 points 4 months ago

There's two things:

Deno: this is a replacement for Node and NPM and prettier and some other tools. So one aspect is that it's a more modern Node, using standard web APIs instead of Node specific stuff. And the other aspect is it is more streamlined modern tooling - no node_modules, no complicated build steps, built in Typescript support, etc. In fact you can use a single file as a script, similar to Python.. but unlike Python you can use third party dependencies, which makes it fantastic for stuff like CI scripts, etc. where you might have suffered with Bash or Python before.

Fresh: this is just a web framework targeting Deno. Honestly I haven't used it much but I really like what I've seen so far. I always found React to be confusing and overkill for most sites, which should really be rendered server side, but also I really like the way you can compose components with JSX/TSX in a real language with full type checking. Fresh gives you both!

[-] FizzyOrange@programming.dev 3 points 5 months ago

I do like the author's overall point that we should try and fix the issues rather than just pretend they don't exist.

However a lot of these seem to be things that people have obviously thought of already, and they've thought about it more than the author and found problems that he just hasn't got to yet. Incremental linking for example. Yeah obvious idea but did he think about all of these issues?

Good brainstorm anyway.

[-] FizzyOrange@programming.dev 3 points 6 months ago* (last edited 6 months ago)

You're still limited by lambda expressions though. And in general the language is still statement based, not expression based. You can't do a = if foo then x else y type things (except for the one-off and backwards x if foo else y; they were so close!).

[-] FizzyOrange@programming.dev 3 points 7 months ago

Yeah I have to second UnfortunateShort. Benchmarking papers are on average very bad, often because they're trying to push a particular idea or product and are very biased, or because they're like "my first benchmark" and done by people who don't know what they're doing.

A classic one that gets referenced a lot is "Energy Efficiency Across Programming Languages" I which the authors seriously benchmarked programs from the very heavily gamed Computer Language Benchmarks Game, and concluded among other things that JavaScript is much more energy efficient than Typescript.

The only realistic way to benchmark different languages is to take implementations that weren't written to be fast in a benchmark. For example Rosetta Code, or maybe leetcode.com solutions.

Or to do it yourself. But that requires you to be experienced in many languages.

Difficult for obvious reasons.

[-] FizzyOrange@programming.dev 3 points 7 months ago

Yes I understood that. My point is how often do you know you need to move a line exactly 17 lines? Do you count them? Clearly much slower than doing it interactively by holding down ctrl-shift-down for a bit.

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago