People aren't going to want their parcels to take more time to be delivered
Ask HN: What is not going to change in future?
81–90 of 99 posts
Re: Ask HN: What is not going to change in future?
#82Earlier quoted context omitted.
Disclaimer: I didn't know about universal search until I read stephencanon's comment. I just thought it was fun to think about and I think the answer is what follows, but it could be wrong! Imagine your problem is to write Hamlet by Shakespeare. One way to write Hamlet by Shakespeare is to enlist many monkeys who then type at random (but with the property that no two monkeys type the same thing). Each monkey also has…
> If P = NP, that enumeration process can happen in P time. Keep in mind that all problems in NP have polynomial time verifiers. So you can always check a solution (i.e., checking if the monkey actually wrote Hamlet) in polynomial time. I understand why verifying can happen in time P for each machine, but I'm still confused on how you're sure that you hit on the right machine in P time. For writing Hamlet, you have w…
> I understand why verifying can happen in time P for each machine, but I'm still confused on how you're sure that you hit on the right machine in P time.
My monkey stuff was a bit wrong; the enumeration stuff actually goes like this: let every binary string be a Turing machine. So TM 0 is the string 0, TM 1 is the string 1, TM 2 is 10, and so on. Every possible TM machine can be encoded in this way.
For half your time steps, run TM 0. For half of the remaining time steps, run TM 1. For half of those, run TM 2. So the sequence of execution actually looks like this:
0, 1, 0, 2, 0, 1, 0, 3, ...
This means that every 2^(n+1) steps, the nth TM does 1 step of computation. Say that the kth TM is the smallest TM that solves your problem. Then it takes 2^(k+1) * O(m^c) steps to solve your problem, where O(m^c) is a polynomial bound. (I've ignored accounting for the time for verification, but that's polynomial too, so it doesn't matter.) That O(m^c) comes from the fact that we know that a polynomial time algorithm exists for our problem (but we don't know what it is), since P = NP.
But 2^(k+1) is a constant; it doesn't depend on the input size. The smallest program that solves our problem (in general) will always be the kth program. (Technically on some inputs there will be smaller programs that solve the input just by getting lucky, but TM k is the smallest program that solves our problem for all inputs.) So 2^(k+1) * O(m^c) is a polynomial number of steps, just with an absurdly huge constant of 2^(k+1).
I found [1] to be helpful and it probably explains it better than I just did.
[1] https://steemit.com/steemstem/@markgritter/leonid-levin-s-un...
Re: Ask HN: What is not going to change in future?
#83Theoretical CS fundamentals are not going to change. Practically, that means among other things: - Unless somebody finds a polynomial algorithm for an NP-complete problem (which is a taller order than just proving P=NP), several interesting problems will continue to be infeasible to solve exactly in the general case with large data. - If, in addition, quantum computers don't prove to be viable, commonly used cryptosy…
> - Rice's theorem, that it is impossible to determine computational properties of arbitrary programs, will still apply, making static analysis (including antivirus programs, security scans, etc.) heuristic rather than exact. I think this is misleading. There are many exact static analyses---proof-checking in theorem provers like Coq is an exact static analysis. More generally, type checking can be an exact static an…
I was very careful to specify "computational properties" (as opposed to things like program length or side effects) and "arbitrary programs" (with "arbitrary" meaning that it doesn't suffice to prove individual programs correct, and "program" meaning that I'm not talking about single functions).
I should probably have been more specific by writing "decide" instead of "determine", because you can absolutely 'determine' a computational property as long as you're willing to ignore false negatives. For example, it's easy enough to write a termination checker by just checking for loops and equivalent constructs (or e.g. in Idris, by requiring that all functions are total), but that will of course reject a large number of programs that do in fact terminate.
Coq is not a Turing Complete language, so Rice's theorem doesn't apply. But almost all people are not writing programs in Coq.
I think static types are great, but they don't contradict any of this.
Re: Ask HN: What is not going to change in future?
#84Phones will probably look the same in 10 years. Not the exact same, but it'll still have a touchscreen and fit in your pocket.
I hope not. Pocket phones are as annoying as pocket watches. I want something on my wrist or on my face (in my glasses).
Re: Ask HN: What is not going to change in future?
#85Earlier quoted context omitted.
> - Rice's theorem, that it is impossible to determine computational properties of arbitrary programs, will still apply, making static analysis (including antivirus programs, security scans, etc.) heuristic rather than exact. I think this is misleading. There are many exact static analyses---proof-checking in theorem provers like Coq is an exact static analysis. More generally, type checking can be an exact static an…
I was very careful to specify "computational properties" (as opposed to things like program length or side effects) and "arbitrary programs" (with "arbitrary" meaning that it doesn't suffice to prove individual programs correct, and "program" meaning that I'm not talking about single functions). I should probably have been more specific by writing "decide" instead of "determine", because you can absolutely 'determine…
> but they don't contradict any of this.
Sure, and I agree with what you've said. But as you pointed out, you have to be very particular/exact with language with these things. I just wanted to emphasize that there are many constrained settings (but still practical) where Rice's theorem doesn't apply.
Re: Ask HN: What is not going to change in future?
#86Earlier quoted context omitted.
You're probably right in that LaTeX won't change, but I am beyond happy having left and picking up typst for a recent project. Despite existing limitations and beta-ness, it's already fantastic, and most importantly promising (has financial backing by now). Instant preview and precise as well as legible error messages alone make it so. I had an initial document and development environment running within twenty minute…
> That's impossible with LaTeX. Certainly not impossible. I don't find LaTeX hard to install, at least on a modern Linux distribution such as Ubuntu (and if memory serves, it wasn't hard on macOS either). I agree that setting up a basic template from scratch can be tedious and I wish this was better, but the common approach for newbies is to copy a template from somewhere, and for more advanced users, they probably h…
A base install isn't too hard, correct. The main downside there is that a full LaTeX distribution is gigabytes in size, but that's manageable. Just takes time. Leaving out docs or using a distribution with on-the-fly package installation can solve this.
Trouble arises when you're looking to use latexmk (requires Perl), bib2gls (requires a Java runtime), minted (requires Python), latexindent (requires specific Perl libraries), including SVG (requires InkScape, and I believe ImageMagick), ...
Any notion of a powerful, sane, batteries-included development environment (think Rust and Go) requires jumping through insane hoops, resulting in bespoke setups, always on the brink of breakage. I really don't want to manage Python venvs!
The LaTeX crowd is very old school and tooling isn't natively available or built with containerization in mind. I've grown to like single-binary approaches (Caddy, typst, ...). I find vanilla LaTeX documents (the type that will compile in 20 years to come) very weak. UTF-8 still isn't standard in "vanilla LaTeX" (pdflatex)!
Re: Ask HN: What is not going to change in future?
#87Earlier quoted context omitted.
> That's impossible with LaTeX. Certainly not impossible. I don't find LaTeX hard to install, at least on a modern Linux distribution such as Ubuntu (and if memory serves, it wasn't hard on macOS either). I agree that setting up a basic template from scratch can be tedious and I wish this was better, but the common approach for newbies is to copy a template from somewhere, and for more advanced users, they probably h…
A base install isn't too hard, correct. The main downside there is that a full LaTeX distribution is gigabytes in size, but that's manageable. Just takes time. Leaving out docs or using a distribution with on-the-fly package installation can solve this. Trouble arises when you're looking to use latexmk (requires Perl), bib2gls (requires a Java runtime), minted (requires Python), latexindent (requires specific Perl li…
UTF-8 works with xetex, and both it and latexmk are easily installable from package sources on Ubuntu (and probably other distros).
You do raise some valid points, but most people don't really use those programs you've mentioned (I've only ever used minted), and you have to consider the insane breadth of things (often very specific to particular scientific disciplines) that LaTeX and its ecosystem are dealing with. Plus, IMHO it's a bad choice to abandon LaTeX's maths notation (despite its obvious weaknesses) entirely because the institutional inertia here is incredibly high; it's used basically everywhere even outside LaTeX itself (MathJax, Discord bots, several online forums, etc.). Mathematicians (and students / researchers from adjacent disciplines) have become _really_ used to it. And unlike programmers, researchers don't usually need or want paradigm shifts every few years.
Re: Ask HN: What is not going to change in future?
#88Most of having a job is people skills. Whether we’re writing jQuery by hand or prompting ChatGPT 9.5 to output our work, your most important job skills will still be collaboration, communication, and in some cases just being a good hang.
After a few years of the tech nerds being on top, now the Saul Goodmans of the world are back w/ all the tools.
Re: Ask HN: What is not going to change in future?
#89Human nature won't change. How companies work, how humans interact, how users behave -- I don't see how that'll change anytime soon at all.
> how humans interact, how users behave
I've seen pretty dramatic changes in both of those in the last 5 years. Human interaction seems to have become a lot shittier. Users' behaviour seems more entitled. How people behave and interact also differs quite a lot based on culture/geographic location.
Sure, at the end of the day we're all human with more or less the same wants and needs, but how we express them is neither uniform nor fixed.
Re: Ask HN: What is not going to change in future?
#90Phones will probably look the same in 10 years. Not the exact same, but it'll still have a touchscreen and fit in your pocket.
That's a funny example. Because prior to around 2007 phones looked very different than they do today. And prior to that, I think it was difficult for people to imagine a phone would fit in your pocket, and more importantly, what that would mean for follow on effects, like instagram or tik tok unless you were being sarcastic.
2014 to 2024 phones have hardly changed. Better performance, bigger screens, but the same concept. There will be changes in 10 years but I think it will look mostly the same.