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

> a genuinely good tool that enriches your thinking

A smartphone is also a genuinely good all-around tool. Even social media is a genuinely good tool for connecting people.

Yet, I feel like we've been overly optimistic about the impact of said tools on us and our societies in the past two decades.

Smartphones are so good, in fact, in some societies, half of us are addicted to them. Billions of people world-wide.

I ask myself: Will LLMs enrich my thinking in the long run, or will they ruin it?

And what about most people? Will half of us outsource most of our thinking in a decade from now?

Given the speed and global scale that we're running these experiments with, it's fair, I think, to be a bit sceptical of the conclusion that, in the long run, LLMs will enrich our thinking.


I agree with this. Tools are good, betting the farm on a single tool is bad.

Example, cars are good. Betting the farm on cars to the detriment of bikes, buses, and trains is clearly bad. The tool of an llm is clearly handy. Betting trillions of dollars and linking the future of the nation and globe to this tool is clearly bad.


Yes instead of investing everything in AI the USA should invest in electric versions of their vehicles and in trains that can safely carry them because of their lack of range.


You're being sarcastic, but literally every other developed country invests in trains and tens of millions of people drive EV's daily with no issues.

If you want to argue that LLMs are 100x more useful than a functioning railroad system I've a bridge for you to subscribe to.


There's a saying that the intelligence of an average prehistoric cave man should be, in general, higher than a modern day human simply because the lack of technology required stone age humans to be far more intelligent then we are today. Now you can survive by working as a clerk in McDs, but in the stone age you needed to be on your toes and smart af.

LLMs are just continuing the trend humanity has long been traveling down.


> There's a saying that the intelligence of an average prehistoric cave man should be, in general, higher than a modern day human simply because the lack of technology required stone age humans to be far more intelligent then we are today. Now you can survive by working as a clerk in McDs, but in the stone age you needed to be on your toes and smart af.

This is a funny twist on the glorification of the past.

Modern humans have been getting smarter even over the relatively short time periods that we’ve been measuring.

It’s called the Flynn effect: https://en.wikipedia.org/wiki/Flynn_effect

Modern day humans still can and do survive in the wild if they so desire. It’s not some lost intelligence that was only achievable by past ancient humans.



1. No IQ tests for prehistoric humans. 2. IQ is going down in the US.


> 2. IQ is going down in the US.

Flynn effect research says otherwise.

If you think prehistoric humans were geniuses because They could survive in the wild, by that measure monkeys and gorillas must be geniuses too.


>Flynn effect research says otherwise.

Flynn effect is just a trend for the past century or so and it's an international measure. For the past decade there's been a trend for the US exclusively that is not aligned with the flynn effect.

https://news.northwestern.edu/stories/2023/03/americans-iq-s...


That doesn't pass the sniff test, or chimpanzees would be smarter than humans.


No, the CHLCA (Chimpanzee–Human Last Common Ancestor) would be smarter than humans. It could be that chimpanzee intelligence declined faster than human intelligence. Unlikely, but I want to clarify that we did not evolve from chimpanzees. We share a common ancestor.


Stone age humans. Not pre hominids.


How do you know that? What do you know about prehistory? Nothing. You might as well be picturing the Flintstones in your head.

You're using broadly shared but totally unsubstantiated about past humans just to argue that things are good right now.


So you're claim is prehistoric humans are stupider? Also unsubstantiated. And insulting to prehistoric humans. That kind of behavior isn't allowed on HN. Don't disparage a group.


> Now you can survive by working as a clerk in McDs, but in the stone age you needed to be on your toes and smart af.

In stone age, you had to focus on other things than thinking to have enough food for the next day. And to survive otherwise.


"Flynn effect" claimed that intelligence has been increasing over time. At least we can sort of measure things in the modern era, while objectively assessing the intelligence of the long-dead is turning into skull-measuring territory.



Technically, yes. Markdown was always intended to be used for creating HTML and thus allows you to use HTML inline (with some minor caveats, see: https://daringfireball.net/projects/markdown/syntax#html).

If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.


What do you mean by corrupted?

Been using Deno happily for many years now.

Did I miss anything?


Nothing, Deno raised capital back in 22

https://deno.com/blog/series-a


Their fetch handler [1] is not a web standard.

[1] https://developers.cloudflare.com/workers/runtime-apis/handl...


but not to lock people in but to avoid the context overhead of service worker api, which they tried first and which still works btw.


Sorry, what? I never mentioned lock-in.

I assume by Service Worker API, you mean FetchEvent? [1] As in:

self.addEventListener("fetch", (event) => {});

That is a web standard indeed, but not one that was designed for use as a general-purpose HTTP handler, but rather for use in a Service Worker proxy.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent


Maybe i misunderstood what you were going for. Just saying: Yes, their web fetch handler is not a web standard but the only standard there is to accomplish something like that had a few issues and they picked something that looks as generic as possible. vs import {pretendToStartServer} from ('our:global-injected-pseudo-sdk')

I really loved the idea of using service worker sdk and having something that works in browsers too so the conceptual model of edge functions are spanning backends, edge POPs and browser runtimes.


AFAIC, WinterTC doesn't specify how to start an HTTP server. Their minimum common API requires, among other things, that the Request and Response interfaces from the fetch specification are present. Unfortunately, it does not specify any sort of serve function.


Because an edge runtime should not directly start servers in the first place. You provide handlers that fulfil requests from the system. Edge runtimes that pretend to start the servers in the edge worker context are flawed and ugly from the very start. APIs like that leak implementation details and increase vendor lock-in for no added benefit.


> > I don't understand how none of the alternatives really embrace WinterTC

> You provide handlers that fulfil requests from the system.

As I said previously, though I wish they were, such handlers are not part of WinterTC.

And then again, how those handlers are registered is also not part of WinterTC, which I also wish it were.

> APIs like that leak implementation details

How?

Almost all runtimes, like Bunny Edge Scripting, Cloudflare Workers, Deno, Bun, etc. use the same basic signature for the handler:

(request: Request) => Promise<Response>

Only how you register said handler is, unfortunately, different for each runtime.


As a German, I gotta ask: Is this a reference to Martin Niemöller's "First They Came"?

https://en.wikipedia.org/wiki/First_They_Came


Almost certainly


Natürlich.


XHTML (or the XML syntax for HTML) wasn't removed (see: https://html.spec.whatwg.org/multipage/introduction.html#htm...). You may be thinking of XSLT, which may be removed in future.


So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C.

Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers?

Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.


> So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C.

XSLT is a W3C standard:

https://www.w3.org/TR/xslt/


> Is there still a real-world use case for XHTML

If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean.

With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.


Switching to Deno might help. It's sandboxed by default and offers granular escape hatches. So if a script needs access to a specific environment variable or read or write specific files, it's simple to configure that only those accesses are allowed.


From my experience, most simple websites are fine with XSLT 1.0 and don't experience any performance problems.


Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.


> My favorite testing framework, AVA, still isn’t supported.

Have you checked recently? The docs (https://docs.deno.com/runtime/fundamentals/testing/) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework.

> The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter.

Again, have you checked recently? According to the docs this is supported: "Deno's built-in linter, `deno lint`, supports recommended set of rules from ESLint to provide comprehensive feedback on your code. (...) You can specify custom rules, plugins, and settings to tailor the linting process to your needs." (https://docs.deno.com/runtime/fundamentals/linting_and_forma...)

I've been using Deno for 6 years now. And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.


> And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.

I feel similarly. The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.

I've started using Deno in my spare time for various projects - and it just _feels_ more productive. I go from idea to testing TypeScript in minutes - which never happened in Node land.


> The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.

And that's great for greenfield projects - although there's competition with Biome and Vite / Vitest for a lot of those - but the vast majority of Node use today is existing projects, and at least at one point Deno (and Bun, maybe others) were marketed (I think?) as a drop-in replacement for NodeJS. But maybe I'm misremembering.


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

Search: