A naïve hash of the data you’re encrypting stuffed into the nonce leaks whether two plaintexts are the same (or…collided). A hash of the key and plaintext leaks whether the two plaintexts are the same under the same key. Using a proper keyed MAC prevents any rainbow table style attack in either case.
Generally speaking leaking that two plaintexts are the same is better than leaking two plaintexts XORed together. If you’re in a use case where that’s liable to happen (i.e., you don’t rekey “frequently”) I’d happily take the former leaked bit over the latter leaked messages.
There are also a handful of existing constructions you can just take off the shelf rather than rolling your own thing and getting it wrong.
A lot of these look like children. Nowhere in the article is it mentioned that a lot of these look like children. No one in the comments has brought up that a lot of these look like children. A lot of these look like children.
This seems like a very common sentiment regarding anime especially among white people in America. I think the reason for that is partly stylistic choices of anime but if we are really honest, Japanese people if not many Asian peoples appear as children to white people. This of course seems mostly visual/aesthetically based, a similar but opposite disposition towards black people exists in America[0]. Japanese animators draw characters that emulate characteristics they find familiar, which makes sense, and thus they appear "childish" to Americans.
I could bring up old racial stereotypes regarding Asian people to further bolster this point but I think most people are aware of this.
I don't know danbooru, but on another nsfw japanese comic site, 11500 of the 61973 english translated works are tagged as lolicon. Majority of the remaining are teenagers at best (because most anime are in a high school setting).
So you're not crazy. These are really young looking. It is probably just representative of the dataset. The dataset itself wasn't chosen for any malicious reason, the people who like this stuff just happen to be very prolific artists so there's a machine learning scale amount of it.
Danbooru requires one to have a 'gold' account to see pictures tagged as lolicon or shotacon. That's a $20 one-time purchase. It's not clear to me that they are using such an account.
In this artistic style, any character appearance would get more child-like characteristics. It's more of a feature of the overall "childish" view of the world associated with this style rather than an attempt to picture actual children.
Of course, it's just my perception and your interpretation may be different.
`as const` is useful there as well, as TypeScript’s type inference only narrows as far as the type and not the literal value. `let z = {text: "hello"}` has the shape `{text: string}`, with `as const` it has the shape `{text: "hello"}`.
Because `const` is a js level keyword that has different semantics: it applies only to the reference binding being immutable, not the value as being so. `const a = "hello"` does have the shape `"hello"` as you’d expect, since strings are immutable in js and the `const` keyword makes the binding immutable as well. But objects are mutable, so TS can’t be a superset of javascript and change the semantics of that behavior. Hence `as const`.
This is different to the widening of value types within objects, which is a tradeoff made towards unsoundness with the belief that it would otherwise make interoperability with existing js too difficult, for which `as const` now serves as a way to explicitly opt into sounder behavior.
> Many JavaScript developers are scared (by scared I am paralyzed in the face of death catatonic scared to the most possible irrational extreme) to write original code when often times original code takes less time and is a better fit to the immediate problem. This is called Invented Here Syndrome and is internally coddled when developers are appeased by writing configurations opposed to logic.
I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
JS being an "accessible" language and a mandatory part of practically all software companies with a front facing website makes this the most apparent in both the constant flow of new tools and libraries and the view that the new tools and libraries must be adopted. But any novice developer can fall prey to this behavior regardless of their choice of language, JS just makes it easier.
Lets step away from the front end for a second, on the server side you use a reasonble MVC framework.
* You get to stop worrying about how to structure your code.
* The guidence should use Depency Injection, allowing you to easily Unit Test.
* You get a templating language that helps with XSS.
* You get a validation language that helps with input.
* You get session handling that projects you against jacking, etc.
* You get an ORM that makes SQL easy and projects you against SQL Injection.
* You get Security Headers, etc.
Typically, the junior developer needs the above help, the mid level developer thinks they can do it all himself, and the senior doesn't think it's worth reinveting the wheel.
JavaScript has arguably been the wild west, and if you're creating a SPA, a lot of the above is no longer your consideration, but it alos doesn't neccessairly mean we should all write everything from scratch.
Now there are counter arguments where you can DIY your own framework using community modules, and this is how the Golang community seems to work, but this seems better when you have something like PHPs PSRs ala https://www.php-fig.org/ defining how this should fit together.
I'm not arguing that one should write things from scratch. I think I may have poorly articulated my position, but that you and I actually share the same opinion here.
I don't think you should reinvent the wheel unless for some reason all available wheels are insufficient for your case. But knowing this requires that you have some understanding of how wheels work, how to compare them, and how to hew your own out of raw materials if the need arises.
I would say JS is partially a wild west due to title inflation and the relative numbers of lesser experienced developers in the space relative to, say, your pool of Erlang engineers.
Yup. And it’s hard to even evaluate these things sometimes (and I have 20 years experience to guide me now).
We’re doing some frontend stuff at the moment and we needed a nice way to wire up keyboard shortcuts. After a week of false starts with other people’s libraries we wrote our own in a day that a) works how we need and b) is so small that anyone can understand it.
> I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
> The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc.
I agree with this. Many developers never think to ask clients "why do you want to do this?" also. Sticking boxes together, cleaning up code and coming up with clever coding tricks is fun and distracting; it's easy to lose sight of or never even learn of what high-level problem you're meant to be solving.
>The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
Writing my own sort routine? Pointless but pretty harmless.
Writing my own docx parser? Sure, that will be one mythical man century of work.
Sometimes we are using black boxes because we have created so much accidental complexity that we can't do better than "this works, we don't know why and we dare not change it". The browsers js must target are some of the biggest black boxes even though they are open(ish) source.
> Writing my own docx parser? Sure, that will be one mythical man century of work.
I'm not sure that's actually a great example. I had a project a while ago where I needed to extract certain information from Word and Excel files, and it was less work to just write my own parser (it's just XML in a ZIP file) that got exactly the information I needed than to figure out all the complexity of using a full-blown docx/xlsx parser. It ended up being 100 lines of Haskell, and half of that was imports.
There is, but if your problem requires just the former, it's faster and better to build it yourself than to pull in a heavy third-party dependency (of which you'll use 1% anyway).
Yes but if it requires the latter you end up with an uncontrollable mess of regular expressions which can accidentally parse the language needed to summon the great elder ones.
The media wiki parser is a perfect example of what can go wrong with simple solutions.
There's absolutely nothing wrong with using black boxes, and I'm not arguing that it should be totally avoided. I'm arguing that a lack of understanding of how to solve your problem leads to only gluing black boxes together as you lack the understanding with which to make more nuanced decisions, and to solve any part of the problems you have yourself.
It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.
Yes, and it is...not great. It's generally fine as far as the language goes (considering it's a retrofit), but the builtin asyncio library is not the way to go in my opinion. trio is far better for just aping a lot of the Erlang way of things.
But even then it's hard to debug, or work out ideas in the REPL, testing is a bit more complex than it should have to be, etc. There are probably better languages to reach for (I'd love to see rust firm up a one true way of async).
FWIW, I was at a talk by an asyncio core developer at EuroPython and he said they are looking very closely at how to improve the asyncio API in upcoming 3.8/3.9 releases. In particular, looking at good ideas they can pull in from libraries such as trio.
