Not necessarily. Here's a rough example (it's not what's going on here, just a representative idea):
There are words/tokens that are heavily correlated to the prompt (a yes or a no, for example), and then there are others that are going to be less so (adjectives with a lot of synonyms for example).
Given a text, you can identify what the "load bearing" and auxiliary words/chunks are. Then, looking only at the auxiliary words/chunks, you should, in principle, be able to determine what other wordings could have gone there instead. From this, you can, very roughly, recreate the token probability distribution that was in effect when those tokens were generated. With the probability distribution in hand for enough chunks of text, you can start inferring properties about the RNG process that was used to sample from those distributions.
But then, this notion of "load bearing" vs "auxiliary" can be expressed directly in the probability distributions. A load bearing token just has a very high probability, and thus any RNG bias that may have been in effect will likely be swallowed in the distribution. So the parts of the text that are highly dependant on the prompt will naturally not be contributing much information about he RNG in the first place.
Humanoid robots can be dropped in wherever human labor is currently used.
That makes them extremely easy to sell to industry. This unlocks, in principle, a large chunk of the potential untapped industrial automation market that still relies on human labor because the ROI of redesigning production lines didn't make sense.
These humanoid robots would cost $10-100k to make and would require costly maintenance for them to do the job people in poor countries do for a dollar. I don't say we won't come to it eventually, but not in near future
More realistically it seems that llms in several years could help dramatically decrease costs of automation and make it available for more industries
I don't think it's the dream, I think it's the cynical market-driven logic.
Automation has been rolling out for a long while now, and most of the low-hanging fruit of things that can easily be redesigned in a cost-effective way has been dealt with already. The role of these robots is to address all of the stuff that would have been automated by now if they could have.
I almost entirely agree with this. However, after coding quite a few large projects with LLM assistance, I can say with certainty that there is some form of "art" at play with regards to structuring requests for LLMs.
However, this "art" is not so much about how to present a given request to the LLM, but rather guestimating what the scope of the next chunk of work should be to balance getting as much out of the model as possible while avoiding the machine going off the rails.
Obviously, this is a moving target and different models perform differently for various chunk/scope of work. I look at my successful sessions with LLMs and I'm not sure I'd be able to articulate a clear set of rules to apply here. You just... gradually build a intuition for how much you can throw at the LLM at once.
That being said, I'm pretty convinced at this point that this is a property of the coding assistants as they exist today, and what "working well with LLM assistance" means will keep on changing.
Hello HN. There's still a long road ahead for the project, but since I've recently closed the loop on bootstrapping the language's core within itself, I thought now's as good a time as any to throw it out there and start getting other people's takes on it.
Chirp is my attempt at engineering a programing language from the ground up that packs together all my favorite bits and pieces into one tight and consistent package. It's got a bit of Rust, a bit of Zig, a LOT of TypeScript, and a lot more LISP than I initially expected.
What sets it apart is its treatment of sets as a trait, and how they are used to express constraints on variables while keeping the code as boring and straightforward as possible.
Here's a taste:
let fizz = { x:int | x % 3 == 0 };
let buzz = { x:int | x % 5 == 0 };
let fb_range = 0 ..= 100;
let eval(v: fb_range) = match v {
fizz ∩ buzz => "fizzbuzz",
fizz => "fizz",
buzz => "buzz",
`any => f"{v}"
};
for (v ∈ fb_range) `print(eval(v));
To manage expectations: Code emission isn't ready yet. As things stand, it's effectively a scripting language with an intuitive set-centric syntax and runtime constraint checking. But, especially since scripting a compiler is what it's meant to do, I think it's still enough to show around a bit.
> and to avoid the warning (error) the code is decorated with compiler pacifiers, which makes no sense!
How is that a bad thing, exactly?
Think of it this way: The pacifiers don't just prevent the warnings. They embed the warnings within the code itself in a way where they are acknowledged by the developer.
Sure, just throwing in compiler pacifiers willy-nilly to squelch the warnings is terrible.
However, making developers explicitly write in the code "Yes, this block of code triggers a warning, and yes it's what I want to do because xyz" seems not only perfectly fine, but straight up desirable. Preventing them from pushing the code to the repo before doing so by enabling warnings-as-errors is a great way to get that done.
The only place where I've seen warnings-as-errors become a huge pain is when dealing with multiple platforms and multiple compilers that have different settings. This was a big issue in Gen7 game dev because getting the PS3's gcc, the Wii's CodeWarrior and the XBox360's MSVC to align on warnings was like herding cats, and not every dev had every devkit for obvious reason. And even then, warnings as errors was still very much worth it in the long run.
IMHO readability is the absolute maximum paramount priority. Having the code interrupted by pacifiers makes the code more difficult to read. The warning is very visible when compiling. Let me argue, much more visible. Why? well, independent if my last change had something directly to do with that piece of code, I will see the warning. If I use some preprocessor magic, I will only see that if I directly work in that part of the code.
Again, IMHO the big problem is people think "warnings are ok, just warnings, can be ignored".
And just as anecdotal point "Sure, just throwing in compiler pacifiers willy-nilly to squelch the warnings is terrible." this is exactly what I have seen in real life, 100% of the time.
For some reason people stop thinking when it comes to warnings. Often it is the warning which gets one to rethink and refactor the code properly. If for whatever reason you want to live with the warning, comment the code appropriately, do not squelch blindly.
Please remember we are coming from "set warnings to errors", which I interpret as: I know better than the people doing the compiler. There is a good reason for the two. If not, there could be no warnings at all, all would be an error.
My rationale: if you do set warn->error, then there are 2 ways around it: change the code to eliminate the warning, or pacify the compiler. Note, the measure to set it to error, is to instigate lazy programmers to deal with it. If the lazy person is really lazy, then they will deal with it with a pacifier. You won nothing.
There is no one recipe for everything. That is why, even if I do not like to treat warnings as errors, sometimes may be a possible solution.
I think you should deal with warnings, you should have as few as possible, if any at all. So if you have just a couple, is not a problem to document them clearly. Developers building the project should be informed anyway of many other things.
In some projects I worked, we saw warnings as technical debt. So hiding them with a pacifier would make us forget. But we saw them in every build, so we were reminded constantly, we should rework that code. Again, it depends on the setup you have in the project. I know people now are working with this new trend "ci/cd" and never get to the see the compilation. So depending on the setup one thing or another may be better.
> My rationale: if you do set warn->error, then there are 2 ways around it: change the code to eliminate the warning, or pacify the compiler. Note, the measure to set it to error, is to instigate lazy programmers to deal with it. If the lazy person is really lazy, then they will deal with it with a pacifier. You won nothing.
> You won nothing.
No, you won that you can distinguish between intended and not intended warnings. Specifying in the code, which warnings are expected makes all warnings that the compiler outputs something you want to get fixed. When you do not do that, than it is easy to miss a new warning or that the warning changed. So you essentially say that you should not distinguish between intended and non-intended warnings?
Having no warnings is a worthwhile goal, but often not possible, since you want to be warned for some things, so you need that warning level, but you don't want to be warned about that in a specific line.
> So you essentially say that you should not distinguish between intended and non-intended warnings?
No, I pretty clearly said the opposite. Please read what I wrote:
"[...] is not a problem to document them clearly. Developers building the project should be informed anyway of many other things"
I also stated "warnings, you should have as few as possible, if any at all" in the projects I worked we hardly had any in the final delivery, but we had many in-between, which I find ok. If there are only 2 warnings, I do not see a big risk of not seeing a 3rd. I expect developers to look the compiler output, carefully, as if it was a review from a coworker.
Last but not least you ignore my last paragraph, where I say warnings are typically technical debt. There should be in the long run no "expected" warnings. My whole point is that they are just no error, so you should allow the program to compile and keep working in other things. I do not think is ok to have warnings. Also (specially) I think is a bad idea to silence the compiler.
Anyway, a good compiler will end with a nile lime “N warnings detected“ so there is that. You can just compare an integer to know if there are more warnings… not so difficult, is it?
If you read my comments it should be clear. If not, I cannot help with that.
If you want to disagree, as long as you don't work in my code, is ok. This is just my 2ct opinion.
It's not just a pure matter of law, and looking at it from that perspective is naive.
Legacy publishers in general (and a few big ones in particular, like der Spiegel) have been lobbying hard for legislatures to redirect big tech revenue to their failing businesses.
The focus on AI here is really just the continuation of that ongoing fight that has been raging for over a decade now. If it wasn't that, it would be some other wedge.
I'm not saying Google is squeaky-clean here, far from it. However, it's important to keep in mind that the main drive here is to get publishers paid, not to force Google to be accountable to some specific standards.
In the grand scheme of things, we've only had about a quarter century where you needed a *very* specific kind of problem where prosumer hardware wasn't adequate across computer science as a whole.
It's kind of amazing we got that at all for a while.
There is a HUGE difference in that the combined short length with the fact that the video starts playing before you even have a chance to make a decision on whether to watch it or not leads you to a "heh! I'm here already, might as well just watch the thing".
This is a response to you and the other Y people that confuse short videos with autoplay and user engagement techniques.
There are people that autoplay long videos, in fact people stream random Simpson’s (or other favorite tv show, podcast, music, books on tape, etc) episodes in the background while they work. Classic TV has autoplay with no opportunity to decide. Autoplay is not an exclusive short form video feature. I can make a short video on my computer and it will not autoplay other content.
There's no confusion here. It's pretty easy to make the argument that the combination of auto play and short form is orders of magnitude more problematic than the sum of their parts.
Yes but then we’re not talking about short form video being addictive but rather the hunt for a good short form video is addictive. This same idea can be applied to long form and any other medium you enjoy, finish, and immediately want more of. Now if you have only 30 mins before your next task to watch a long form video then you may skip starting the video, but that doesn’t mean there is anything inherently bad about short form video but rather the tools for viewing it. So yes you are confusing and you’re intentionally confusing the two so that your point stands about short form video, but it doesn’t because your points are about the viewing tools.
If you continue to push this point, people will only think that short videos under 3 minutes are some how the devil and TikTok et al will continue on making whatever length of video is next in line, more addictive.
Honestly, I don't mind the format in principle, and the process that goes from YT's homepage to watching a single one of them is not that bad to me. As long as I get to make a decision that I want to watch something, consciously go "I will click on this thing and watch it" and only then proceed to watch it, then it's _fine_.
It's the algorithmic loop that starts the moment you scroll to the next video that starts playing before you even have a chance to decide whether or not it's something that you want to watch that's abhorrent to me.
There are words/tokens that are heavily correlated to the prompt (a yes or a no, for example), and then there are others that are going to be less so (adjectives with a lot of synonyms for example).
Given a text, you can identify what the "load bearing" and auxiliary words/chunks are. Then, looking only at the auxiliary words/chunks, you should, in principle, be able to determine what other wordings could have gone there instead. From this, you can, very roughly, recreate the token probability distribution that was in effect when those tokens were generated. With the probability distribution in hand for enough chunks of text, you can start inferring properties about the RNG process that was used to sample from those distributions.
But then, this notion of "load bearing" vs "auxiliary" can be expressed directly in the probability distributions. A load bearing token just has a very high probability, and thus any RNG bias that may have been in effect will likely be swallowed in the distribution. So the parts of the text that are highly dependant on the prompt will naturally not be contributing much information about he RNG in the first place.