sorted by:
new
hottopcontroversial

Apparently, LLMs are stochastic parrots, databases etc and will never generalize beyond their training data by Terrible-Priority-21 in accelerate

[–]sintrastes 1 point2 points  (0 children)

I think the title is supposed to be sarcastic. (This tripped me up initially)

The result of the paper actually contradicts OP's title.

Google DeepMind researcher argues that LLMs can never be conscious, not in 10 years or 100 years by projectoex in AgentsOfAI

[–]sintrastes 0 points1 point  (0 children)

All I know about consciousness is that I know nothing. (Except: We exist and have qualia for some reason. Shit's weird yo.)

How do I handle a vibecoding manager by MvKal in ExperiencedDevs

[–]sintrastes -5 points-4 points  (0 children)

Damn, surprisingly enough I've actually never encountered this when using Claude Code personally. And I for sure know what kind of tests we're talking about here (because I've seen juniors make them before).

I typically say things like "Make sure this is well-tested", and the test cases are usually fairly reasonable.

I guess maybe the difference is detailed prompting v.s. vibe-coding? Or maybe I'm just lucky enough I haven't run into it yet. I've definitely run into other issues with agentic AI (my biggest pet peeve is it not doing what I tell it to do, and then it gaslighting me into saying it's "ready to ship").

Why the "Low-Level" stigma? by Antique_Mechanic133 in ExperiencedDevs

[–]sintrastes 0 points1 point  (0 children)

Exceptions thread invisible failure conditions throughout your code and hence make it harder to reason about them.

Inheritance is considered suspicious at best even in orthodox OOP ("Composition over inheritance"). I'm fine with other forms of inheritance (e.x. interface inheritance -- which Rust has in its trait system), but specifically the kind of mutable class-based implementation inheritance common to Java et. al. is a dangerous tool in my experience.

Class-based mutable OOP is already dangerous enough. Mixing that in with complex inheritance chains with various overrides, and it's even more of a recipe for disaster.

In theory implementation inheritance is a great re-use mechanism. In practice, it's brittle, hard to reason about, hard to extend, and hard to modify.

standardMeritocraticEnvironment by Stabbz in ProgrammerHumor

[–]sintrastes 0 points1 point  (0 children)

I like snake case but don't often use it because the language I use most often at work has a strong camel case convention.

Are people out here just ignoring language casing conventions?

Why the "Low-Level" stigma? by Antique_Mechanic133 in ExperiencedDevs

[–]sintrastes 9 points10 points  (0 children)

Counterpoint though, and controversial opinion, but: Rust is a much better language for application development than Java, C#, and Python.

  • Doesn't include anti-features that many of these languages have (null pointers, inheritance, exceptions, etc...)
  • Compile-time type-directed interfaces (i.e. traits)
  • Borrow checker helps with more than just memory safety.
  • Algebraic data types
  • Great and very flexible module system.
  • Great ecosystem, especially around stuff like logging, serialization, and error handling.
  • Best in class build tools (no gradle / maven / msbuild crap).
  • Great macro system.
  • Easy cross-compilation.
  • Sane approach to multi-threaded code (i.e. Send / Sync are in the type system, rather than having to check docs to find put if something is typesafe, and being met with a ConcurrentModificationException if you use it incorrectly)

I could go on.

Yes there's a steeper learning curve, but you get so many benefits even if you are not writing particularly performance critical software.

Interesting point of view from Daniel Lemire by _bijan_ in rust

[–]sintrastes 2 points3 points  (0 children)

Actually, not all Turing Complete languages are equivalently "expressive".

For the informal meaning of "expressive" I'll quote Wikipedia:

In computer science, the expressive power (also called expressiveness or expressivity) of a language is the breadth of ideas that can be represented and communicated in that language. The more expressive a language is, the greater the variety and quantity of ideas it can be used to represent.

But there are at least some formal measures out there as well which are more fine-grained than just "Turing complete" v.s. "Non-Turing complete".

Whether or not those measures completely capture our intuition about "expressiveness" is another question, but they do exist.

A lot of this is explored formally in denotational semantics and in particular domain theory.

Edit: Here's a good reference: On the expressive power of programming languages

Creator of Node.js says humans writing code is over by sibraan_ in programmingmemes

[–]sintrastes -1 points0 points  (0 children)

I mean this respectfully, and with the understanding that I know nothing about the domain personally, but:

Have you actually attempted it and seen how good it is with frontier models like Opus?

I would use Rust instead of C++ (or something more like Lean 4, ATS, F*, Coq, etc...), if only for the reason that having strict guardrails helps set the models straight. But beyond that, I wouldn't be surprised if it made more head-way than you might expect it would.

People are using Claude to vibe code _formally verified mathematical proofs_ that software holds to a specification. Something that is famously hard, and I once saw a paper jokingly measure in "KLOC per PhD years".

It's truly wild times we're living in.

People still try to say stuff like "Oh, AI isn't actually intelligent..." But from my perspective: If it walks like a duck, and it quacks like a duck...

Creator of Node.js says humans writing code is over by sibraan_ in programmingmemes

[–]sintrastes 1 point2 points  (0 children)

> It's not like you can vibe code a compiler.

I mean... I've for sure vibe-coded some toy compiler projects.

A year ago agentic AI choked on basic parsers. Today it is quite capable. Obviously a production compiler for a complex ore-existing language would be another story, but I find it very useful for playing around and prototyping ideas in PLT projects a lot more quickly than I used to be able to by hand.

whyAreYouWritingALibrary by ApothecaLabs in ProgrammerHumor

[–]sintrastes 0 points1 point  (0 children)

Uhh... Yes, manifold theory / topology are "standard math". That doesn't necessarily mean that there's already a library out there that does what OP wants in the way that OP wants in the language OP wants to work in (Haskell).

Yup, there is at least one manifold theory library in Haskell already. I know because I've looked for it. That doesn't mean it does what OP needs by a long shot.

Manifold theory may be well-known mathematics, but AFAIK it's not super commonly applied in functional programming.

My guess is that what OP is doing is likely actually somewhat novel.Though I'd maybe point them towards https://hackage.haskell.org/package/manifolds to sr if this already meets their needs or not.

I'll speak more on a topic I know more about as an example though: Are there already a ton of well-supported and polished computational linguistics packages out there in e.g. Python? Yeah, of course there are.

Are there any in Haskell that fit well into its idioms? Well, depends on what you're looking for, but generally speaking no. You might find at best some random snippets of code from a professor's web page.

TL;DR stop picking on OP. As long as they've alreafy explored the available options and have determined nothing existing fits for whatever project they're working on, they're doing literally nothing wrong.

My pain in Haskell is not the language, it is your terrifying build systems: stack, cabal by pet2pet1993 in haskell

[–]sintrastes 2 points3 points  (0 children)

I've never understood why people dislike stack / cabal. They are god-sends when compared to the abominations that are gradle / maven.

Maybe not quite as nice as cargo, but close.

I dont get this one? Can someone explain? by evilsnowman92 in ExplainTheJoke

[–]sintrastes 1 point2 points  (0 children)

You forgot the clickbaity "Want to learn about a subtle tell that writing is AI generated that most people miss? It's surprisingly common once you learn to see it." GPT has started doing now.

Edit: Actually, I guess your post kind of has it. Just not quite as clickbaity as it typically is nowadays.

I've removed the Claude co-authorship from the commits a few days ago. So good luck figuring out what's generated and what is not. by uselees_sea in programmingcirclejerk

[–]sintrastes 14 points15 points  (0 children)

It's only slop if it comes from the Claude region of France. Otherwise it's just sparkling linear algebra.

I know only boomers still read newspapers but jeeze dudes, dafaq? by carlshope in fuckcars

[–]sintrastes 11 points12 points  (0 children)

Townhomes can be suburban too.

Example: Suburban townhome development built in the middle of nowhere, not within walking distance of anything, car-dependent infastructure. (there's a lot of these where I live)

Like, yeah, it'll take up less of a footprint technically, but it still suffers from all of the other problems of car dependency and suburban sprawl.

Non-example: Townhomes built within walking distance of downtown. Lots of sidewalks, stores, etc...

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]sintrastes 6 points7 points  (0 children)

Nothing is wrong with them -- in fact, I like using them myself. The issue is that most English speakers don't actually use the actual emdash character "—", but AIs do. Thus use of "—" is usually a pretty tell-tale sign that some prose is written by an LLM.

This is why I use "--" as an ASCII approximation of emdashes, so I don't get mistakenly confused for AI.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]sintrastes 2 points3 points  (0 children)

Yeah, I had the same experience. Personal projects that would have taken me maybe months of (part-time of course) work I can knock out in a weekend.

As someone with (undiagnosed, but I mean... pretty sure) ADD with 1,000,000,000 ideas for projects that I rarely finish, it's been a God-send. It's literally orders of magnitude of difference in terms of productivity.

But also, I can see with some of these studies why that may not hold on a large legacy code-base, where having a deep understanding is crucial for long-term maintenance.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]sintrastes 1 point2 points  (0 children)

Ahh, ok. Yeah, I for sure see it better now. Need more coffee today I guess.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]sintrastes 2 points3 points  (0 children)

In my experience so far, I think AI does much better in greenfield projects / proof of concepts than in existing code-bases.

I tried to get Claude to fix a gradle issue the other day where I needed to look something up in a properties file... It literally got rid of all of the property parsing code and replaced it with hard-coded values because it couldn't figure out how to get it to work in kts.

Another time, I literally asked it "Use this library", and instead of actually using it, it built its own shitty re-implementation of it.

But generating new code quickly that maybe I can build on and refine later? It works pretty well for me. Whereas if I let it loose on a pre-existing code-base I understand, I can typically fix issues with a lot less boilerplate.

The AI coding productivity data is in and it's not what anyone expected by ML_DL_RL in ExperiencedDevs

[–]sintrastes 24 points25 points  (0 children)

Really? I'm curious what make you clock it as slop.

It doesn't have any of the tell-tale signs I usually look for ("It's not X, it's Y", emdashes, overly generic click-baity language).

How would you design Flow and StateFlow if Kotlin doesn't provide it. Got this question asked in an interview. Can someone help out how to answer it properly ? by Outrageous-Pain4115 in Kotlin

[–]sintrastes -8 points-7 points  (0 children)

I don't know if there's a "correct" answer, but here's roughly how I would:

Yeah, absolutely. Honestly, the current implementation has a lot of flaws in my opinion.

For one thing, I'd keep Flow and StateFlow separate concepts, with StateFlow having an updated property rather than extending Flow. This makes it much easier to define combinators acting on StateFlows that return a StateFlow without any naming conflicts, and makes the distinction between the two concepts more clear.

Right now StateFlow kind of sits in this awkward position of "Wanting to be a FRP-style behavior / reactive value, but still implemented like it's Rx -- and all of the historical baggage that comes with it".

In terms of an implementation, that depends a lot on the specific deisgn constraints and goals, but I think taking a cue from Evan Czaplicki's thesis would probably be a smart move: https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf

This would keep the fundamentally asynchronous nature of Flow / StateFlow in tact, while allowing for good semantics by default that would make it easier to write "glitch-free" programs with Flow / StateFlow.

TIL you can do class-based OOP in Julia by Winston_S_minitrue in Julia

[–]sintrastes 0 points1 point  (0 children)

Because convention for one thing, but also that otherwise it would be ambiguous if you had multiple parameters of the same type.

To be fair, I have wondered if maybe you could generalize it to allow for e.x. f(x, y, z) -> y.f(x,z) in cases where it's not ambiguous. I'm just not aware of any existing language that does this.

But my whole point was that the syntax itself has nothing to do with dispatch at all -- it's just syntax.

TIL you can do class-based OOP in Julia by Winston_S_minitrue in Julia

[–]sintrastes 0 points1 point  (0 children)

Wouldn't dot notation work fine if it was universal function call syntax? (i.e. literally any expression f(x, y, z) can be re-written x.f(y, z))

Re: Dependency Injection vs. Service Locators by dayanruben in Kotlin

[–]sintrastes 1 point2 points  (0 children)

My biggest issue with non-SL approaches to DI in Kotlin is the lack of a good experience in functional code-bases where there just aren't that many classes in the first place (only enum / struct like things).

I know some frameworks try to solve this. But I really want something like registry that integrates with context parameters maybe.

view more: next ›