15% improvements are usually called “fixing a mistake in the code” or “getting to that task in the backlog for optimizing that code we had to ship on a deadline”. They’re more likely the bigger the company: more contributors working in disparate areas means more low hanging fruit is probably lying around.
> I don’t really like AI but let’s stop kidding ourselves
If I had to create a tagline to describe my opinions about AI in a single sentence, that’d be it.
It’s possible to both hate AI and be impressed by it at the same time. Lying to ourselves about its capabilities does us no good. It’s emotionally difficult to do, but people need to come to grips with what’s happening and shake themselves out of a state of denial.
Indeed, the internet is absolutely gonna be with us forever, but I’d hate to be the guy who bought Cisco stock in August of 2000. (It took 25 years to recover.)
Although at its peak, CSCO was up ~2500% in a 5-year period, whereas NVDA is “only” up ~1000% in a similar timeframe.
Copying it. Because they clearly believe that they’re allowed to do so.
For physical books, they believe they’re not allowed to, hence the destruction.
It’s abhorrent, I agree… maybe if your world domination plan involves destroying rare books, you should change the plan rather than saying “well our hands our tied, the law says we have to”
I mean they used to have a different plan, which involved not destroying the books, and then they got sued for not destroying the books, by us, so now they are destroying the books. What did you think would happen?
They got sued for violating copyright in general, not for “not destroying books” in particular. Destroying the books was a legal trick they used to continue scanning them without breaking the law.
If I were running the AI company and my lawyers came back with “teeeechnically we can still scan them if we burn them after”, I would reply with “I guess we’re not scanning them”, but I lack the sociopathic instincts required to be a tech CEO I guess.
Indeed, won’t someone please think of the poor AI company CEO’s, we should be ashamed of ourselves for criticizing their perfectly acceptable destruction of our creative works. Thank god you’re here to swoop in and defend them at every turn.
I think it’s pretty clear in GP’s first sentence that they believe artists should get compensation during the first 10 years. I personally would change it to something more like 20 years but I share the idea.
Reminds me of when Apple finally moved the iPhone to USB-C… they defended lightning for the longest time, but then when when they finally did the switch, all I could think was “the last N years [0] of lightning accessories I’ve bought are now ewaste”… once it became clear USB-C was going to be the future, every year they weren’t using it was another year of future ewaste building up.
Every year go didn’t have generics was another year of workarounds and tech debt building up that would have otherwise been able to be written the right way from the start. Unlike ewaste though, it’s probably impossible to quantify.
[0] I’d probably peg N as the years between when they gave MacBooks USB-C ports for charging, up until the iPhone got them. It’s clear Apple knew they were gonna need to move to it eventually… every year in that period represents a year of lightning cables people bought that could have been still-useful USB-C cables today.
Technical debt, sure. But you could argue the same for any new feature added to a programming language, without having X you will need to workaround with Y, generating technical debt.
To be clear, I was one of those people that only started to use Go after generics. But for most of my projects, generics is less than 1% of the code base, so it is not like lack of generics was a huge issue. I think it is more of a problem for libraries in general.
IMO it depends on the language… to me, map/collect/etc are useful in languages that have the concept of immutable data, because you can initialize an array with a single call chain, and be sure that nothing after that can modify it.
What I’ve seen in the “for loop” approach that I can’t stand, are things like (pseudo code)
var a = []
for x in coll1 {
a.push(foo(x))
}
do_stuff_with(a)
// … further down the function
for y in coll2 {
a.push(bar(y))
}
do_other_stuff_with(a)
Reading code like that, is the first call to do_stuff_with(a) a bug, because it’s not fully built from both coll1 and coll2 yet? Or is the second call to do_other_stuff_with(a) a bug because a now contains more stuff than the developer probably thought? Can I safely move both loops next to each other, or does that break something subtle? If I need to pass a to a new function, where can I safely do this? Before or after I add from coll2? (In my actual times seeing this, a is really a map of cached key/values or something, and it’s kinda ok that the contents were different each time it was used, but subtle bugs emerged…)
IMO the sane way to do it is to just not incrementally mutate things like that, and stick with giving things a single place where they’re defined and initialized. Go doesn’t really help you here because there’s no such thing as immutable data. So just adding Map/collect or whatever doesn’t really buy you much.
Often the mutation might have performance benefits.
Of course if you're Rust the stdlib and compiler might conspire to optimise an operation you wrote which reads as non-mutating into an actual mutation which was faster.
This is another benefit of the "destructive move". If I consume X and spit out Y, the X is gone, so it's OK if secretly I just mutate X and tell you that's Y now.
Except you don't need a multiplexer for that. Essentially all modern terminals have tabs. Many have split-screen. Even windows ships with a half-decent terminal with tabs and multiple panes by default now!
A multiplexer's job is to do the whole multiple tabs/panes/windows thing independently of the terminal itself, but (a) the UX for eg. tmux is so much worse than that of a good terminal UI, and (b) you only need that if you plan on connecting remotely (see my other comment https://news.ycombinator.com/item?id=49108483).
Tmux only makes sense if you’re connecting remotely in some form or another. Otherwise, it’s just terminal windows/tabs with extra steps. Even if your terminal integrates with tmux like iterm2 does (where local tabs become tmux tabs, local windows become tmux windows, etc), it doesn’t really mean much if it’s all local anyway.
The usual arguments make no sense if you’re only on your local machine:
- You can detach the session: well yeah, I can minimize the terminal window too.
- You can have multiple tabs/windows in a session: yup, same with my window manager
- You can keep multiple sessions and attach/detach from them whenever: I can do that with multiple desktops in my window manager
And so on.
But, once you want to do all of this on a remote server, it all makes sense: putting my laptop to sleep shouldn’t end the session on the server. If I get disconnected for some reason, I should be able to reattach and resume it if I reconnect. So then you have the session run on the server and you only “attach” to it when you connect, and if your terminal has good integration, new tabs become new tmux tabs etc… it’s all transparent.
It’s also useful if you’re running a session locally but anticipate wanting to attach to it from somewhere else: if your terminal session is tmux from the start, you can transparently attach to it from another machine too.
But, if you’re just dealing with one machine, who cares, just skip the multiplexer. (It’s literally not “multi” plexing if there’s only one client!)
Another thing worth mentioning is that if your terminal doesnt have good tmux integration, and you’re only running locally anyway, your life is strictly worse off with tmux: scrolling is a horribly broken hack, buffer search sucks, copy/paste never works, switching open terminals is an awkward ctrl+b contortion, etc. No amount of fiddling with your tmux config is going to make the UX as good as a decent terminal has, and I will die on this hill. :-)
reply