samiskin (u/samiskin)

samiskin commented on Try and ygdp.yale.edu/phenomena/t... · Posted by u/treetalker

raldi · 7 months ago

I think most of the mysteries in this piece can be explained if “try and stop me” just an abbreviation for “try to stop me and see if you can”.

samiskin · 7 months ago

I think this capture’s the essence better than anything else, “try and” simply behaving as “try and see if I can” (or whatever fits instead of “I” here)

samiskin commented on Training LLMs to Reason in a Continuous Latent Space arxiv.org/abs/2412.06769... · Posted by u/omarsar

ekianjo · a year ago

> We don't think in plain English

That's debatable. Language shapes thoughts much more than you might think. Because you learn concepts from language that you could not imagine by yourself until you learned/read about them, so they are in effect very linked to language.

samiskin · a year ago

Language is definitely a significant part of thinking, but when I remember how cold it was outside yesterday to figure out if it was colder than today, I'm not bringing words to mind. I'm bringing up some other non-discrete information that I could never precisely encode into words and then factoring that in with the other non-discrete information I'm currently taking in through my senses. Its only after that processing that I encode it as a lossy "It was colder yesterday" statement.

samiskin commented on Language models can explain neurons in language models openai.com/research/langu... · Posted by u/mfiguiere

ryandvm · 3 years ago

Funny that we never quite understood how intelligence worked and yet it appears that we're pretty damn close to recreating it - still without knowing how it works.

I wonder how often this happens in the universe...

samiskin · 3 years ago

Evolution created intelligence without even being intelligent itself

samiskin commented on Programming breakthroughs we need yoyo-code.com/programming... · Posted by u/panstromek

jaredcwhite · 4 years ago

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs).

What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. Static typing everywhere. It's utterly baffling to me.

"Why are you using Ruby? You should use…Rust! (Go! Zig! Fill-in-the-blank nerd hype!)"

Lol.

What I actually want is a new programming language/environment which makes Ruby look like programming pointer arithmetic in C by comparison. Something so advanced, so high level, that much of the time you're really just describing patterns and flows and data models and extensions, and then letting the computer determine the most efficient way to develop those code paths and execute them.

Unfortunately, I'm a bit cynical on this front. I believe the reason this doesn't exist is because it's at cross-purposes with programmer nerd culture. Many programmers enjoy the nitty-gritty of low-level coding. They fear abstraction. They fear "magic". They fear things like "implicit imports" or "duck typing" or "many ways to express the same method/function/algorithm" etc. because it's all nebulous and fuzzy compared to the safe confines of deterministic math & logic. "If I declare that this variable MUST BE AN INTEGER, then it MUST BE AN INTEGER. The idea you could pass me a string instead? UNACCEPTABLE !!!#%@!"

In other words, I don't have high hopes that great UX for forward-looking developers will come from present-day programming culture. For a quantum leap in DX, we probably need people who aren't die-hard programmers to engage in blue sky thinking. We need to talk to artists, philosophers, linguists, psychologists, and other experts in social & historical cultural dynamics. They can provide the insight we lack. Because for every "this is an integer, damnit!" type out there, there are probably many, many more who would see 123 and "123" and think THAT'S THE SAME THING. :-D

samiskin · 4 years ago

This all makes sense given "for the contexts I care about (small web applications largely written by solo devs)". Unfortunately for you most software (and therefore what most developers work with) isn't for those contexts, but rather for larger projects written by multiple devs, where being lower level and compiled (runtime speed) and having static typing (more explicit and easily understood by other devs) become much more valued.

You'll probably always be in the minority with your preferences because of this.

samiskin commented on Functional programming jargon in plain English github.com/hemanth/functi... · Posted by u/mgliwka

pdpi · 4 years ago

This is one of those things where looking at the type signature hard enough eventually gives the game away, but most writing on it sucks:

    bind :: m a -> (a -> m b) -> m b

Because that function in the middle takes an `a`, your implementation of `bind` needs to be able to take an `m a` and pull an `a` out of it, which means it also has to evaluate however much of `m` is needed to actually get to that `a`.

Because that function in the middle returns an `m b`, binding again with a function `b -> m c` requires you to pull `b` out of `m b`, which in turn forces pulling an `a` out of `m a` to make progress. This is where you force sequentiality — you can only evaluate the `m` in `m b` after you've evaluated the `m` in `m a`

samiskin · 4 years ago

This makes a lot more sense than anything I've read about this in the past, thanks for the explanation!

samiskin commented on State machine replication, and why you should care signalsandthreads.com/sta... · Posted by u/yminsky

lbhdc · 4 years ago

This was an interesting episode. However, I thought this pattern was called actors. Did anyone else get that sense? I have never heard that called a state machine.

samiskin · 4 years ago

This seems like a more restrictive version where the "Actors" must also be entirely deterministic and single threaded without really blocking in the middle of processing something.