Kwantuum
Kwantuum on Hacker News
> The structure is identically to all of that, big title, graphic, list with icons
You're complaining about posters being structured like posters?
But also the structure is particularly similar between these posters themselves across styles because they use the same prompt to describe the desired content and that's on purpose. The model is not asked to rework or reword any of the content, this lets you compare the styles.
I think that's unfair. Many local community fairs happen to have a graphic designer or someone with some of the same chops who's willing to lend a hand to design a decent poster.
If you already know the bug is caused by a race between writing and checkpointing then it's easy. I'm unsure how the linked article makes your point at all though.
I don't think the people who opposed those things look foolish even today. Most of those things, in their early days, were implemented haphazardly and with an incredible lack of regulatory oversight, and the reason they were not quite as disastrous as they could have been is that people opposed them.
And people opposing data centers today who are opposing unfettered data center creations will not look any *more* foolish than those who opposed the things you cite.
The fact that this can happen at all without the security team's knowledge is telling.
I trust openAI's marketing team 100%
Interestingly, in the company I currently work for, if an employee encounters a problem with the product, the expected way to report the issue is to open a ticket. Not in an different system with different people responsible for handling it, in the same ticketing system that customers use.
Hackintosh refers to doing things the other way around: running MacOS on non-apple hardware. So no, this is not a hackintosh.
Both of the things you quoted are basically gone in practice, you just always use const/let and always use triple-equals for equality comparisons and that's that. Most people that write JavaScript regularly will lint these out in the first place.
OTOH I think JS has great ergonomics especially wrt closures which a number of popular languages get wrong. Arrow functions provide a syntactically pleasant way to write lambdas, let/const having per iteration binding in loops to avoid nasty surprises when capturing variables, and a good number of standard methods that exploit them (eg map/filter on arrays). I also think, though a lot of people would disagree because of function coloring, that built-in async is a great boon for a scripting languages, you can do long operations like IO without having to worry about threading or locking up a thread, so you get to work with a single threaded mental model with a good few sharp edges removed.
I've had to stop using FF as my development browser because it chokes on large source maps. I used to find lots of issues in our web app that were only ever tested on chromium browsers. I don't anymore because the devtools are unusable past a certain point.
> I guess you can attach a debugger for unit tests, but that's not very useful.
That is in fact incredibly useful
Surely this was meant to be cnt += a[i] > 0
The most egregious problem caused by this that I've encountered is an almost complete inability to use email 2FA on websites because my phone will kill the browser as soon as I switch to my inbox, and when I go back to the browser I'm back on the login screen which will generate a new one-time-password and make the one I have in my clipboard worthless. I've also encountered the exact same problem with 2FA using an authenticator app, though since the codes are valid for ~30 seconds or so, if I manage to enter my credentials fast enough or they auto-fill, at least the code I copied is still valid.
There are several points in the article which are just plain wrong:
- no private properties (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
- no readonly properties: You can use a getter. Or define the property as non-writable, the syntax isn't nice but in my opinion it's still much nicer than what the article proposes.
Some of the points are just a matter of taste ("this" is awkward)
There's the implementation itself which forces you to use non-idiomatic code for no good reason or benefit (Class.init instead of new, just why? You can absolutely return a constructor function there while preserving everything else)
Doing what the article proposes also destroys the ability to do instanceof checks because the prototype of instances is not set (can be fixed), and inheritance is severely limited if you want to preserve any of the purported benefits. You might say that inheritance is actually not a good thing and so it's a feature, not a bug, but if that's your opinion why are you trying to mimic a class?
There was not. There is now but for the better part of a decade it was just... Something you were supposed to have learned from a youtube video or a friend or something.
Pretty sure they're just replying specifically to
> you still have guilty parties going free anyways since the wrong person is convicted
which is a non sequitur.
Now you impose sanctions in your jurisdiction to violators and nobody cares because you're not the EU and your sanctions have no weight.
A lot of the comments seem to talk about the inevitable AI event horizon but unless I'm misreading this article the results are flat out bad. Even the 6 billion parameters model barely scratches a 50% success rate on a tiny problem that is trivial to fix for any human with basic knowledge of programming. Note the log scale of the graph.
> (damnit, of course calculating the permutations of a list is n-squared, but this is an interrogation of the random trivia I can manage to recall and I feel like a deer in the headlights)
With this statement I'm inclined to believe the title. Last I checked there are (n-1)! permutations for a list of length n. Not knowing this off the top of your head is fine, but making this kind of comment is an unforced error and it doesn't reflect well on the author.
Website is completely broken in firefox when javascript is enabled.
You are missing the point completely.
The IKEA effect is not "self assembly", the IKEA effect is "I think of this piece of furniture more highly because I assembled it myself". The IKEA effect compares how people feel about the same piece of furniture when they've assembled it themselves vs when someone else did it.
That's a lot of words to say "to make fraud harder you have to make buying from you harder, the optimal amount of fraud is the amount of fraud you get when any additional measure you could take against fraud would lower your revenue more from lost business than it would lower your costs from people committing less fraud"
from the linked PTC proposal in the article (
https://github.com/tc39/proposal-ptc-syntax):
> Unfortunately, the TC39 process at this time did not require heavy implementation involvement and so while many implementers were skeptical, the feature was included and standardized as part of ES6.
> the type of fetch() can't be inferred by static analysis
That is preposterous.
It really isn't, most native/standard APIs do not return Promises. Lots of things use callbacks. Being comfortable creating Promises from a callback-based API is definitely something any competent JS dev ought to be able to do.
And in fact, there were detours in pretty much all the solutions I've seen posted online for part 2
The earth has "holes" and as such the proof of that statement for a sphere does not apply to the earth.
I can see this being useful when you're maintaining multiple versions and forward-porting patches. Some patches only make sense up to a certain version and you don't want to merge them in the next one up.
It's not just "some" caveats: then auto-unwrapping means that you cannot use then as fmap reliably. In JS there is no such thing as Promise<Promise<Number>>. You cannot await/then the outer promise so that you can do something with the inner promise.
In practice it's not too much of a problem, but it does mean that if you use some FP library, you cannot trivially wrap a promise to make it a monadic type that will work with the library's monad utilities.