Hacker Newsnew | past | comments | ask | show | jobs | submit | steego's commentslogin

After watching a bunch of people use the live chat, I am not discouraged by live chat anymore.

I actually think one can make it work, one simply needs to account for moderation and flooding upfront.

The first feature you need is a way to instantly ignore people who are ruining the collective experience. I would think when a person is ignored by a certain threshold of people, their content should automatically be moderated.

The second feature that’s needed is some sort of flood protection or detection. If a user is pasting or trying to flood the chat with characters, they should be instantly hidden and their content be subject to moderation. Being able to distinguish between copying and pasting on occasion and flooding goes a long way.


The recently sunsetted Reddit public chat was a good example. They were tied to a subreddit, so only people with some shared interest came together. And the moderators could set an entry barrier based on karma. And you stood to lose your reddit account if you misbehaved in a public chat

I understand and appreciate Reddit’s approach.

On the other hand, I think there might be a way to solve this problem for live anonymous chat in a way that doesn’t rely on threats of “punishment” or “banning”.

I think most people looking at this problem don’t appreciate how much realtime information can be calculated from the event stream and how that information can be leveraged toward solving it in near realtime.


Why does people care if their Reddit account is banned? I've never understood this. Can't you just open a new one?

Replace “reddit” with “google” in your sentence. Now how does it sound?

Like you're talking about something completely different in function and purpose.

Not for quite a lot of people it isn’t, no.

I’m guessing you’re over 35 (as I am).

I know plenty of people in their 20s whose entire online life is centered on Reddit.

They make hundreds of comments a day. It’s where all of their social interaction is. it’s where they coordinate activities with people. It’s where they chat with people. it’s how they communicate with everyone.Losing that handle would be disastrous. You can’t just change it.


> The first feature you need is a way to instantly ignore people who are ruining the collective experience. I

Yeah, and we all know you're talking about Anon Pond Heron, lets be honest.


I am.

While I’m not the kind of person who races to test the most triggering racial slurs, I’m actually glad Anon Pond Heron did because I thought his behavior was informative, especially as you could watch him slowly type out the beginnings of a slur.

I actually think these types of CRDTs can be enhanced with a handful of simple mechanisms to ensure a higher quality chat experience.


Aren’t we being a little sensitive?

The OP didn’t say all of the reasons for male related injuries were needless, but if you look at the list, it’s dominated by activities that are inherently voluntary and risky.


aren't you being a little naive by calling dangerous activities men have to take to survive "inherently voluntary"? go to a 3° world country or works as an immigrant somewhere rich to check your options. transportation included. it's easy to say one shouldn't use a cheap motorcycle and go for the one way sardine packed 2 hours bus ride across the city to reach work, everyday

Only 3 out of 18 reasons on that list are work-related, 2 maybe can be work related (lawnmowing and powered tools/household machinery?). I think cycling accidents (5 positions on the list) are in part normal cycling (like when riding to work) without rider's fault, and in a larger part taking unnecessary risks while riding, or riding for sport. And I'd guess motorcycle accidents (4 on the list) are mostly taking risks and riding too fast. 3 reasons are "assault". And that leaves only 1 reason from the list, sports equipment.

So out of 18 reasons on the list, only a small part is "activities men have to take to survive", but many of the others aren't "inherently voluntary and risky" or cannot be blamed on the hospitalized person. The list is too short to be really interesting, when half of that list is the same thing with small variations (cycling/motorcycling), and the same for women (mostly pregnancy).


This data reflects the UK, not a 3rd world country and my comments are restricted to this dataset.

Included in that same dataset are assaults and sports related injuries, which are additional risky activities.

You might argue assaults aren’t voluntary. My personal experience suggests most assaults are the result of voluntary activity rather than involuntary activity, YMMV.

I’m not being naive. I have lived in a 3rd world country where it wasn’t uncommon to see a family of 5 on a motorcycle.

I would note that you will tend to see, proportionately speaking, more women on motorcycles in those countries for the reasons you suggested.


Honestly, if you build transit, developers will build.

I wouldn't call it "building a city", but if you look at Northern Virginia today, you'll find that vertical districts are popping up along the Silver Line metro that now extends past Dulles airport.

At the end of the metro, there is literally a "town center" residential area on one side with buildings around 5 stories tall. On the other side of the tracks is literally fields, but the roads have been laid out like Sim City with empty plots and developers are now beginning to construct buildings starting from the outside perimeter first, working their way toward the metro station.

Throughout the DC suburbs, you will find densely populated areas with relatively tall vertical buildings (15-20 stories) that simply were not there 20 years ago. Reston is a good example. I've watched 4-6 buildings (over 10 stories) get built in Reston alone. They mostly started when the the metro line was finished.


tysons is a good example as well. I always think the development of the DC metro is some of the most impressive in the sense of 'cities' popping up along the train lines.

I haven't travelled the entire country but I've never seen anything quite like Silver Spring, Bethesda, or as you say, Reston. Super interesting.


If I had Musk or Bezos levels of wealth my middle-age retirement project would be buying a million acres somewhere and playing real life SimCity.

The Github user doesn't even exist.

Who writes Lean code in the actual paper but doesn't create a repo or even a username?


Nihilism is one response to disillusionment.

Another response is to come to terms with a possibly meaningless and Sisyphean reality and to keep pushing the boulder (that you care about) up the hill anyway.

I’m glad the poster is concerned and/or disillusioned about the hype, hyperbole and deception associated with this type of research.

It suggests he still cares.


Are you saying that you’re unable to read a fluent syntax that’s been supported by most mainstream programming languages for the past 10 years?

Or are you suggesting that the majority of programmers struggle to read and understand fluent method chaining?

I don’t have a dog in this fight because this blog post is very novice oriented. I’m just genuinely confused why you think it’s unreadable or “clunky”. What is it about the fluent example that you find clunky?


Why?

Writing your own LINQ provider is a very niche activity done by people who want to translate or “transpile” C# expression trees into something else.

It is fundamentally a difficult endeavor because you’re trying to construct a mapping between two languages AND you’re trying to do it in a way that produces efficient target code/query AND you’re trying to do that in a way that has reasonable runtime efficiency.

Granted, on top of that, I’m sure LINQ provider SDKs probably add their own complexity, but this isn’t an activity that C# developers typically encourage.


Isn't TLA+ is more like Alloy insofar as they're thinking tools optimized for the design phase?

I'm more familiar with Alloy, which is a great tool for exploring a specification and looking for counter-examples that violate your specification.

AFAIK, none of the languages you listed above work well in conceptualization phase. Are any of them capable of synthesizing counter-examples out of the box? (Aside: I feel like Lean's meta capabilities could be leveraged to do this.)


I only listed Dafny, although I do agree with the list on the reply to me.

Never looked into Alloy, I guess have to get an understanding of it.

How can you validate that the beautiful design phase actually maps to e.g. C code, writing data via ODBC to a SQL database, with stored procedures written in PL/SQL?

Neither the semantics of the toolchains nor the semantics of the commercial products ar part of the TLA+ model as such.

Additionally it requires someone to meticulously compare the mathematical model with the implementation code, to validate that what is written actually maps to what was designed.

Although it wouldn't work for my contrieved example, at least tools like Dafny have more viability by going through "formal model => generate library for consumption", so that we can get an automated model to code validation, without human intervention.


> Additionally it requires someone to meticulously compare the mathematical model with the implementation code, to validate that what is written actually maps to what was designed.

This is a deficiency in TLA+ (and many other systems), but it's not a good enough reason to discard or dismiss it. The industry alternative to TLA+ is not something that traces fully and easily from spec to code, but mostly to use informal, largely prose, documents as their specification (if they specify anything at all). TLA+ is a massive improvement on that even if it's not a perfect tool. Same for Alloy and other systems. It's better if people model and specify at least portions of their system formally even if it still takes effort to verify the code correctly implements that specification, effort they have to expend anyways but with greater difficulty lacking any thing approaching a formal specification.


Approximately speaking, what do you want to see put up?

I ask this because it reads like you have a specific challenge in mind when it comes to generative AI and it sounds like anything short of "proof of the unlimited powers" will fall short of being deemed "useful".

Here's the deal: Reasonable people aren't claiming this stuff is a silver bullet or a panacea. They're not even suggesting it should be used without supervision. It's useful when used by people who understand its limitations and leverage its strengths.

If you want to see how it's been used by someone who was happy with the results, and is willing to share their results, you can scroll down a few stories on the front-page and check the commit history of this project:

https://github.com/cloudflare/workers-oauth-provider/commits...

Now here's the deal: These people aren't trying to prove anything to you. They're just sharing the results of an experiment where a very talented developer used these tools to build something useful.

So let me ask you this: Can we at least agree that these tools can be of some use to talented developers?


Yes sure I’ve checked in code generated by AI myself. I’ve not experienced the excitement this article exudes though and it seems very limited in usefulness due to the by now well-documented downsides. Frankly I haven’t bothered using it much recently, it’s just not there yet IME and I’m not sure LLMs ever will be.

What I’m interested in really is just case studies with prompts and code - that’s a lot more interesting for hackers IMO than hype.


It's useful, but the promise of every AI company is very explicitly that they will burn the seed corn and choke off the pipeline that created those "very talented" developers who reviewed it!


I’m less worried about this as the best way to learn to code is to read as well as write it IMO.

If capabilities don’t improve it’s not replacing anyone, if they do improve and it can write good code, people can learn from reading that.

I don’t see a pathway to improvement though given how these models work.


> Here's the deal: Reasonable people aren't claiming this stuff is a silver bullet or a panacea

This article and vocal supporters are not being reasonable at all, they make a not so between-the-lines separation between skeptics (which are nuts) and supporters ("My smartest friends are blowing it off." in a smug "I'm smarter than my smarter friends").

I mean, come on.


You are absolutely correct. This article and vocal supporters are often not reasonable and I should have made that point.

I honestly found the article to be an insufferably glib and swaggering piece that was written to maximize engagement rather than to engage the subject seriously.

The author clearly values maximizing perceived value with the least amount of effort.

Frankly, I’m tired of reading articles by people who can’t be bothered to present the arguments of the people they’re disagreeing with honestly and I just gave up halfway reading it because it was so grating.


> Reasonable people aren't claiming this stuff is a silver bullet or a panacea.

Are you saying the CEO of Anthropic isn't reasonable? or Klarna?


The CEO of Anthropic is the least reasonable person in this discussion.

Surely you can see how insanely biased all of their statements would be. They are literally selling the shovels in this gold rush.

Anything they say will be in service of promoting AI, even the bad/cautionary stuff because they know there's an audience who will take it the other way (or will choose to jump in to not be left behind), and also news is news, it keeps people talking about AI.


For the record, as the author of this piece, I do not think anybody should factor what the CEO of Anthropic thinks into their decisions. There is in fact a section on this argument in the post. It's short, so it's easy to miss.


Of course not. CEOs are Chief Narrative Officers, one of their main functions is to craft and push a message (which is different than collating and reporting facts). Reason doesn’t not factor in.


I think that experiment was very cool, but I will say that the OAuth2.0/OIDC protocol is very well documented and there are tons of tools already built around it in multiple languages.

I implemented the OAuth2.0 protocol in 3 different languages without a 3rd party library - entire spec implemented by hand. This was like ~2015 when many of the libraries that exist today didn't back then. I did this as a junior developer for multiple enterprise applications. At the end of the day it's not really that impressive.


Three weeks ago I did basically the same thing as the author of the Cloudflare story, but I did it with my own open source tool. I went into the experiment treating Claude Code as a junior engineer and guiding it on a feature I wanted implemented.

In a single Saturday the LLM delivered the feature to my spec, passing my initial test cases, adding more tests, etc…

I went to bed that night feeling viscerally in my bones I was pairing with and guiding a senior engineer not a junior. The feature was delivered in one day and would have taken me a week to do myself.

I think stories like the Cloudflare story are happening all over right now. Staff level engineers are testing hypotheses and being surprised at the results.

Oauth 2.0 doesn’t really matter. If you can guide the model and clearly express requirements, boundaries, and context, then it’s likely to be very useful and valuable in its current form.


This is a great example of how no example provided is ever good enough. There’s always an argument that it doesn’t really count. Yet you just said the computer is doing what you did as a junior developer.


It's not supposed to be impressive. It's a faster way to do the unimpressive stuff. Which is the bulk of real-world software work at most companies.

Maybe you just have that dream job where you only have to think hard thoughts. But that's just not the norm, even at a bleeding edge startup.


Exactly how long did it take you? And now how much actual time was spent in the comparison prompting and code review by Cloudflare?


I think this proposal ultimately introduces more complexity than it solves. By automatically inserting migrations (whether at compile time or via “migration files”), you end up with a form of hidden control flow that’s arguably worse than traditional overloading or type coercion. In normal type coercion, the transformation is explicit and visible in the language syntax, whereas these “migrations” happen magically behind the scenes.

Second, database migrations are notoriously tricky for developers to manage correctly. They often require significant domain knowledge to avoid breaking assumptions further down the line. Applying that paradigm directly to compiler-managed code changes feels like it would amplify the same problems—especially in languages that rely on strong type inference. The slightest mismatch in inferred types could ripple through a large codebase in ways that are far from obvious.

While it’s an interesting idea in theory, I think the “fix your old code with a macro-like script” approach just shifts maintenance costs elsewhere. We’d still be chasing edge cases, except now they’re tucked away behind code-generation layers and elaborate type transformations. It may reduce immediate breakage, but at the expense of clarity and predictable behavior in the long run.


> In normal type coercion, the transformation is explicit and visible in the language syntax, whereas these “migrations” happen magically behind the scenes.

I was assuming that the migration would actually alter the call site in a way that is reviewable and committable, not implicitly do it every time it's needed at compile time. If that's the idea, it doesn't alter anything behind the scenes, it does so explicitly and visibly one time to change everything to meet the new requirements.

The larger problem I see is that the applications for this would be extremely limited. There's a reason why they used a simple s/a/Some a/ as an illustration—once you get beyond that the migrations will become a pain to write, a pain to validate, and likely to break tons of code in subtle ways. And since most library code changes aren't this simple kind, it's likely that it's not worth the effort of building and maintaining this migration syntax for something with so narrow an application.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: