I'm already not buying Samsung devices, I'll run out of choices soon.
why not just use a big ol' monitor with a smart TV box and plain Android TV? or, even better, build a HTPC with Plasma Bigscreen or Bazzite?
Readit Newsbpavuk commented on VS Code deactivates IntelliCode in favor of the paid Copilot heise.de/en/news/VS-Code-... · Posted by u/sagischwarz
bpavuk commented on AI agents are starting to eat SaaS martinalderson.com/posts/... · Posted by u/jnord
I'm CTO at a vertical SaaS company, paired with a product-focused CEO with deep domain expertise. The thesis doesn't match my experience.
For one thing, the threat model assumes customers can build their own tools. Our end users can't. Their current "system" is Excel. The big enterprises that employ them have thousands of devs, but two of them explicitly cloned our product and tried to poach their own users onto it. One gave up. The other's users tell us it's crap. We've lost zero paying subscribers to free internal alternatives.
I believe that agents are a multiplier on existing velocity, not an equalizer. We use agents heavily and ship faster than ever. We get a lot of feedback from users as to what the internal tech teams are shipping and based on this there's little evidence of any increase in velocity from them.
The bottleneck is still knowing what to build, not building. A lot of the value in our product is in decisions users don't even know we made for them. Domain expertise + tight feedback loop with users can't be replicated by an internal developer in an afternoon.
> The bottleneck is still knowing what to build, not building.
shit, I'm stealing that quote! it's easier to seize an opportunity, (i.e. build a tool that fixes the problem X without causing annoying Y and Z side effects) but finding one is almost as hard as it was since the beginning of the world wide web.
I'm all for FP, but there's no way the mainstream is taking side-effects seriously.
Neither Kotlin nor Rust cares about effects.
Switching to Kotlin/Rust for FP reasons (and then relying on programmer discipline to track effects) is like switching to C++ for RAII reasons.
side effects are not necessarily a bad thing. unintentional side effects are. with some exceptions, such as UI frameworks, I find it harder to unintentionally create a side effect. also, UI is basically one huge side effect.
Kotlin and Rust are just a lot more practical than, say, Clojure or Haskell, but they both take lessons from those languages.
OOP is different things to different people, see e.g. [0]. Many types of OOP that were popular in the past, are, indeed, dead. Many are still alive.
I'd personally declare dead everything except 3 and 4 because, unlike the rest, polymorphism is genuinely useful (e.g. Rust traits, Kotlin interfaces)
trivia: Kotlin interfaces were initially called "traits", but with Kotlin M12 release (2015), they renamed it to interfaces because Kotlin traits basically are Java interfaces. [0]
[0]: https://blog.jetbrains.com/kotlin/2015/05/kotlin-m12-is-out/...
Having tried Kotlin in IDEA, I must admit their refactoring tools for Java are miles ahead of Kotlin.
I don't know how strong lock in is.
near-infinite until they finish Kotlin LSP alpha.
also, hot take: Kotlin simply does not need this many tools for refactoring, thanks in part to the first-class FP support. in fact, almost every non-Android Kotlin dev I have ever met would be totally happy with analysis and refactoring levels on par with Rust Analyzer.
but even with LSP, I would still need IDEA (at least Community) to perform Java -> Kotlin migration and smooth Java interoperability.
this explains virtually everything:
- that's why OOP failed - side effects, software too liquid for its complexity
- that's why functional and generic programming are on their rise - good FP implementations are natively immutable, generic programming makes FP practical.
- that's why Kotlin and Rust are in position to purge Java and C, philosophically speaking - the only things that remain are technical concerns, such as JetBrains' IDEA lock-in (that's basically the only place where you can do proper Kotlin work) as well Rust's "hostility" to other bare-metal languages, embedded performance, and compiler speed.
bpavuk commented on Ask HN: How can I get better at using AI for programming? · Posted by u/lemonlime227
Don’t!
concise answers are the best, and I agree with that one.
I am still curious, why? I have my own set of why's and want to hear yours
bpavuk commented on Ask HN: How can I get better at using AI for programming? · Posted by u/lemonlime227
first off, drop the idea of coding "agents" entirely. semi-async death valley is not worth it, you will never get into the flow state with an "agent" that takes less than an hour to spin, and we did not learn how to make true async agents that run for this long while maintaining coherence yet. OpenAI is the closest in that regard, but they are still at a 20-minute mark, so I am not dropping the quotes for now.
another argument against letting LLM do the bulk of the job is that they output code that's already legacy, and you want to avoid tech debt. for example, Gemini still thinks that Kotlin 2.2 is not out, hence misses out on context parameters and latest Swift interoperability goodies. you, a human being, are the only one who will ever have the privilege of learning "at test time", without separate training process.
replace coding "agents" with search tools. they are still non-deterministic, but hey, both Perplexity and Google AI Mode are good at quick lookup of SvelteKit idioms and whatnot. plus, good old Lighthouse can point out a11y issues - most of them stem from non-semantic HTML. but if you really want to do it without leaving a terminal, I can recommend Gemini CLI with some search-specific prompting. it's the only CLI "agent" that has access to the web search to my knowledge. it's slower than Perplexity or even ChatGPT Search, but you can attach anything as a context.
this is the true skill of "how to use AI" - only use it where it's worth it. and let's be real, if Google Search was not filled with SEO crap, we would not need LLMs.
bpavuk commented on Valve: HDMI Forum Continues to Block HDMI 2.1 for Linux heise.de/en/news/Valve-HD... · Posted by u/OsrsNeedsf2P
And what if they just do it anyway? What are they going to do, sue them? Make them scrub every git repository on the planet?
it will be easy to prove that it is not technically possible since Git is decentralized. but fines... oh, those fines could be enormous. possibly, AMD could get barred from implementing HDMI at all - all HDMI has to do is to stop selling the spec to AMD specifically.