Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm betting on HTML

catskull.net

Post reply on HN
Print view View original

261–270 of 458 posts

Re: I'm betting on HTML

#261

Post by vidarh »

reichstein wrote: post #137
KronisLV wrote: post #119

Earlier quoted context omitted.

> The LLM will look at any .exe and determine if it halts. At that point you'd need an AGI that can figure out something we can't. Edit: but yeah, sarcasm. Nowadays I can't even tell sometimes.

I think KronisLV's point, presented ironically, is that not even an AI superior to human reasoning, which can figure out things we cannot, can decide the undecidable. Being undecidable is a hard limit, not something that requires better algorithms. Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.) If an AI is its…

> Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.)

The complexity of the program trying to decide is not really the issue. An "infinite program" could add an infinite number of extra rules to try to cut down on the time taken to determine if a decidable program halts, but the issue with the halting problem is that there is an infinite set of undecidable programs where the size of your detector will make no difference to your ability to decide them.

E.g. "while next_symbol() == some_arbitrary_symbol {}" is undecidable unless you add constraints on the length or contents of the input.

Even if you haven infinite-sized program you can't decide whether or not the unconstrained version of that halts, because deciding it is equivalent to being able to determine if an infinite tape contains a given symbol, and no matter how long you scan the tape the symbol can always be the next one on the tape after the last symbol you scan.

> And _any_ non-trivial property of programs is undecidable

I don't think I agree with this without adding the qualifier "in general". There are a whole lot of useful properties we can decide, but often the properties will have constraints. E.g. for a whole lot of programs where we can't decide whether or not they will halt, we can still decide whether or not they will halt assuming certain properties of their inputs. E.g. we can decide the property of my pseudo-code above that it will halt IF "some_arbitrary_symbol" is in the input. We can also decide the property that whether or not it will halt in general is undecidable, and that is itself useful to know, because for many programs knowing what makes them undecidable is useful in order to suggest e.g. adding timeouts, or ensuring there are ways to bail early from certain actions without restarting the machine or killing the program.

For a whole lot of problems we also do not really care whether or not a given property is decidable. We care whether they're decidable often enough within certain time constraints, and that's a very different ballgame.

Re: I'm betting on HTML

#262

Post by boredumb »

Spivak wrote: post #258
boredumb wrote: post #255

Earlier quoted context omitted.

I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.

But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.

Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build.

I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times brittle) javascript involved to juggle client state. I don't think we're better off as users or developers because of this.

Re: I'm betting on HTML

#263

Post by Technotroll »

chickenfeed wrote: post #260

I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of da…

Part of this is the ever increasing amount of tags and elements in HTML files. Instead of being a document markup, it's a page markup, and it's difficult to discern where one stops and the other begins, although the W3C has tried with the addition of article and section elements. But then I suppose the raw HTML code was never meant to be read by other than devs in the first place, so there's that.

Re: I'm betting on HTML

#264

Post by omgmajk »

I've been meaning to build some utility websites like a simple forum and a simple pastebin and the like for a while just entirely without javascript, kind of like the old days. I want a simpler web with less bloat.

Re: I'm betting on HTML

#266

Post by idoubtit »

cassepipe wrote: post #206

I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case. The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is jus…

> I have to think about labeling a input (why is this not an attribute ?)

If input labels were html attributes, forms would be much less versatile. It would merge 2 visual elements into one, which would make it hard to adjust the display (think of inputs with right-aligned labels to their left, or checkboxes with labels to their right). And a "label" attribute would mean a plain text content... Seems awfully restrictive to me.

Granted, HTML has a complex history and several layers, like anything that's been in use for decades. But it hasn't changed much recently, and (thanks, MDN) it's easy to learn learn enough to identify what is possible with HTML5 and dig later if necessary.

Re: I'm betting on HTML

#267

Post by boredumb »

omgmajk wrote: post #264

I've been meaning to build some utility websites like a simple forum and a simple pastebin and the like for a while just entirely without javascript, kind of like the old days. I want a simpler web with less bloat.

I'm not javascript free, but i've been actively pursueing building useful things with as little if any javascript and have been impressed with what I can get done with forms and html templating.

A few years ago moving to a new area I was trying to find a CPA and saw simple brochure sites are loading 10+ mb of resources and 10+ JS snippets and realized how bad things have really gotten, even with an adblocker on these days a 3g network is hardly enough to browse a massive portion of the web.

Re: I'm betting on HTML

#268

Post by jcpst »

berkes wrote: post #235
merdaverse wrote: post #222

The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of , etc.), very little sites use it properly. Even the fancy professional sites wrap all the page co…

> simple element can't be used properly, I have no hope for all the others. The first solution that comes to mind, is stricter validation. Where the browser would just refuse to render a properly unless it's structure is correct. But we had that. Anything before HTML4 really. And it sucked even more. So maybe browser dev-tooling that throws warning or errors when devs are Doing It Wrong?

I would love to just flip a switch in the browser dev tools and see html validation errors.

Re: I'm betting on HTML

#270

Post by berkes »

speedgoose wrote: post #250
berkes wrote: post #243

Earlier quoted context omitted.

> ...place the user in American-style MM/DD... > No ability to force date style by design. There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc. The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve. > L…

But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.

WRT dates, there's no "metric" standard. Not really. E.g. Belgium commonly uses DD/MM/YYYY whereas the Netherlands uses DD-MM-YYYY. Both use "metric standard" for lengths, weights etc. Same with currencies: "13,37 €" vs "€ 13,37" vs "€13,37", all depending on where in Belgium you are from, vs Dutch in the Netherlands. It's an utter mess.

Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".

Post reply on HN