The only problem is that the functional replica anime sword section is probably going to be entirely empty. They’re basically all decorative wall hangers.
They’ll differ in build quality, though. Some might break if you swing them hard, others might break if you hit something with them.
Yes.
In particular, you ask questions like “what type of steel is this made out of” and “what kind of tang does it have”.
Many of these swordlike objects aren’t made to be swung, and are liable to break if you try it.
There’s a reason people call these wall-hangers “sword-like objects”.
it’s not unreasonable to expect the cool prop to feel like it’s not trying to fly across the yard if you swing it around.
You might think that, but most of these are called wall hangers for a reason.
Many of them have rat-tail tangs or are made with stainless steel. They might feel balanced, but are liable to snap if you swing them around.
Apparently that might or might not be a mistranslation?
https://www.etymonline.com/word/checkmate
mid-14c., in chess, said of a king when it is in check and cannot escape it, from Old French eschec mat (Modern French échec et mat), which (with Spanish jaque y mate, Italian scacco-matto) is from Arabic shah mat “the king died” (see check (n.1)), which according to Barnhart is a misinterpretation of Persian mat “be astonished” as mata “to die,” mat “he is dead.” Hence Persian shah mat, if it is the ultimate source of the word, would be literally “the king is left helpless, the king is stumped.”
And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.
This is facile.
According to Microsoft, about 70% of security bugs they see are memory safety issues.
Yes: if you introduce memory safety, there’s still those 30% of security bugs left. But, well, I’d rather worry about 30% of issues than 100%…
Similarly, I use libraries that eliminate SQL injections unless you really go out of your way.
One important thing to realize is that different dialects of English have slightly different grammars.
One place where different dialects differ is around negation. Some dialects, like Appalachian English or West Texas English, exhibit ‘negative concord’, where parts of a sentence must agree in negation. For example, “Nobody ain’t doin’ nothing’ wrong”.
One of the most important thing to understanding a sentence is to figure out the dialect of its speaker. You’ll also notice that with sentences with ambiguous terminology like “he ate biscuits” - were they cookies, or something that looked like a scone? Rules are always contextual, based on the variety of the language being spoken.
English definitely has rules.
It’s why you can’t say something like “girl the will boy the paid” to mean “the boy is paying the girl” and have people understand you.
Less vs fewer, though, isn’t really a rule. It’s more an 18th century style guideline some people took too seriously.
No.
There’s two types of grammar rules. There’s the real grammar rules, which you intuitively learn as a kid and don’t have to be explicitly taught.
For example, any native English speaker can tell you that there’s something off about “the iron great purple old big ball” and that it should really be “the great big old purple iron ball”, even though many aren’t even aware that English has an adjective precedence rule.
Then there’s the fake rules like “ain’t ain’t a real word”, ‘don’t split infinitives’ or “no double negatives”. Those ones are trumped up preferences, often with a classist or racist origin.
Inflation is calculated off of the cost of some particular basket of goods, and tends not to be even across those goods.
Yeah, if you eat a lot of corporate fast food, prices have skyrocketed recently. At a rate that far outpaces the local pizzeria and Chinese restaurant down the street, or the cost of chicken and eggs from the grocery store.
Symbols display with friendly string-y names in a number of languages. Clojure, for example, has a symbol type.
And a number of languages display friendly strings for enumy things - Scala, Haskell, and Rust spring to mind.
The problem with strings over enums with a nice debugging display is that the string type is too wide. Strings don’t tell you what values are valid, strings don’t catch typos at compile time, and they’re murder when refactoring.
Clojure symbols are good at differentiation between symbolly things and strings, though they don’t catch typos.
The other problem the article mentions is strings over a proper struct/adt/class hierarchy is that strings don’t really have any structure to them. Concatenating strings is brittle compared to building up an AST then rendering it at the end.
Edit: autocorrect messed a few things up I didn’t catch.
Javascript is generally considered OOP, but classes weren’t widely available till 2017.
Inheritance isn’t fundamental to OOP, and neither are interfaces. You can have a duck- typed OOP language without inheritance, although I don’t know of any off the top of my head.
Honestly, the more fundamental thing about OOP is that it’s a programming style built around objects. Sometimes OO languages are class based, or duck typing based, etc. But you’ll always have your data carrying around it’s behavior at runtime.
keeping state (data) and behavior (functions) that operate on that state, together
Importantly, that’s “together at runtime”, not in terms of code organization. One of the important things about an object is that it has dynamic dispatch. Your object is a pointer both to the data itself and to the implementation that works on that data.
There’s a similar idea that’s a bit different that you see in Haskell, Scala, and Rust - what Haskell calls type classes. Rust gives it a veneer of OO syntax, but the semantics themselves are interestingly different.
In particular, the key of type classes is keeping data and behavior separate. The language itself is responsible for automagically passing in the behavior.
So in Scala, you could do something like
def sum[A](values: List[A])(implicit numDict: Num[A]) = values.fold(numDict.+)(numDict.zero)
Or
def sum[A: Num](values: List[A]) = values.fold(_ + _)(zero)
Given a Num typeclass that encapsulates numeric operations. There’s a few important differences:
All of the items of that list have to be the same type of number - they’re all Ints or all Doubles or something
It’s a list of primitive numbers and the implementation is kept separate - no need for boxing and unboxing.
Even if that list is empty, you still have access to the implementation, so you can return a type-appropriate zero value
Generic types can conditionally implement a typeclass. For example, you can make an Eq instance for List[A] if A has an Eq instance. So you can compare List[Int] for equality, but not List[Int => Int].
The idea of a Pokémon clone isn’t protectable, but existing Pokémon are.
You can make a Pokémon clone with entirely novel monsters, but if a judge thinks they look too much like an existing Pokémon they’re gonna have a problem.
Apparently my brain silently inserted “ing with” into the middle of “program functions” a half dozen times without me noticing.
It’s really not just that Rust is new and C is old. Compare Rust with Go, for example. Go is a fairly modern example of a ‘worse is better’ language.
Back in 1970s when C was invented, Lisp had been around for over a decade. C came out the same year as smalltalk, a year before ML, and 3 years before Scheme.
Rust is a very modern language, yes. There’s no way we could have had it in the 70s; many of its language features hadn’t been invented yet. But it very much depends on MIT style research languages for its basis.
I agree with you that if you use functions it’s functional.
But many people don’t really realize how that contrasts with procedures and procedural code.
Functions, here, being the key word.
Functions are pure mappings from input to output.
Depends on how the product is described and what the warranty covers.
Like, if these are sold as decorative art pieces, swinging them around probably voids the warranty.