Garlic takes a long time, but it's easy and doesn't take up much space. It also repels some critters that might otherwise help themselves to your crops.
The electrical is relatively easy. It's not much harder than replacing a frayed power cord on a lamp (with an extra wire if the unit is 220 rather than 110).
Managing the lineset is the scary part (though it's not that hard). You're vacuuming copper lines that you've hopefully sealed correctly. If you get that wrong and your refrigerant yeets off into the sky, you have to call in help because it's hard for an unlicensed person to get the refrigerant legally. That half-hour of work and ~$1 of materials will cost you a punitive amount of money.
> I think it's a reasonable stance to not want other companies to profit from my hard work
For me, the dividing line is whether someone else's profit is at my expense. If I sell a book, and someone starts hawking cheaper photocopies of it, that takes away my future sales. It's at my expense, and I'm harmed.
But if someone takes my book's story and writes song lyrics derived from it, I might feel a little envy (perhaps I've always wanted to be a songwriter), but I don't think I'd harbor ill will. I might even hope for the song to be successful, as it would surely drive further sales of my book.
It's human nature to covet someone else's success, but the fact is there was nothing stopping me (except talent) from writing the song.
It doesn't infringe any kind of intellectual property.
This isn't copyright infringement; it isn't based on the original assembly code or artwork. A game concept can't be copyrighted. Even if one of SI's game mechanics were patented, it would have long expired. Trade secret doesn't apply in this situation.
That leaves trademark. No reasonable person would be confused whether Simon is trying to pass this creation off as a genuine Space Invaders product.
> No reasonable person would be confused whether Simon is trying to pass this creation off as a genuine Space Invaders product.
There may be no reasonable confusion, but trademark holders also have to protect against dilution of their brand, if they want to retain their trademark. With use like this, people might come to think of Space Invaders as a generic term for all games of this type, not the brand of a specific game.
(there is a strong case to be made that they already do, granted)
This seems to be a golden rule of many languages? `return 3` in a function with a signature that says it's going to return a string is going to fail in a lot of places, especially once you exclude bolted-on-after-the-fact type hinting like what Python has.
It's easier to "abuse" in some languages with casts, and of course borrow checking is not common, but it also seems like just "typed function signatures 101".
Are there common exceptions to this out there, where you can call something that says it takes or returns one type but get back or send something entirely different?
Many functional and ML-based languages, such as Haskell, OCaml, F#, etc. allow the signature of a function to be inferred, and so a change in the implementation of a function can change the signature.
In C++, the signature of a function template doesn't necessarily tell you what types you can successfully call it with, nor what the return type is.
Much analysis is delayed until all templates are instantiated, with famously terrible consequences for error messages, compile times, and tools like IDEs and linters.
By contrast, rust's monomorphization achieves many of the same goals, but is less of a headache to use because once the signature is satisfied, codegen isn't allowed to fail.
Concepts are basically a half solution - they check that a type has some set of properties, but they don't check that the implementation only uses those properties. As a result, even with concepts you can't know what types will work in a template without looking at the implementation as well.
Example [0]:
#include <concepts>
template<typename T>
concept fooable = requires(T t) {
{ t.foo() } -> std::same_as<int>;
};
struct only_foo {
int foo();
};
struct foo_and_bar {
int foo();
int bar();
};
template<fooable T>
int do_foo_bar(T t) {
t.bar(); // Compiles despite fooable not specifying the presence of bar()
return t.foo();
}
// Succeeds despite fooable only requiring foo()
template int do_foo_bar<foo_and_bar>(foo_and_bar t);
// Fails even though only_foo satisfies fooable
template int do_foo_bar<only_foo>(only_foo t);
> I'd say that's a mistake of the person who wrote the template then.
The fact that it's possible to make that mistake is basically the point! If "the whole point of concepts" were to "tell you what types you can successfully call it with" then that kind of mistake should not be possible.
It's true that there are certain cases where you know the full set of types you can use, but I'd argue that those are the less interesting/useful cases, anyways.
My interpretation of the post is that the rule is deeper than that. This is the most important part:
> Here is the most famous implication of this rule: Rust does not infer function signatures. If it did, changing the body of the function would change its signature. While this is convenient in the small, it has massive ramifications.
Many languages violate this. As another commenter mentioned, C++ templates are one example. Rust even violates it a little - lifetime variance is inferred, not explicitly stated.
Lifetimes for a function signature in Rust are never inferred from the function code. Rather Rust has implicit lifetime specs with straightforward rules to recover the explicit full signature.
I was speaking about variance specifically. They are not inferred from function bodies, but I think it's fair to say that it's a soft violation of the golden rule because variance has a lot of spooky action at a distance (changing a struct definition can change its variance requirements, which then has ripple effects over all type signatures that mention that struct)
> Are there common exceptions to this out there, where you can call something that says it takes or returns one type but get back or send something entirely different?
I would personally consider null in Java to be an exception to this.
There are languages with full inference that break this rule.
Moreover, this rule is more important for Rust than other languages because Rust makes a lot of constraints visible in function signatures.
But the most important purpose of the rule is communicating that this is a deliberate design decision and a desireable property of code. Unfortunately, there's an overwhelming lack of taste and knowledge when it comes to language design, often coming from the more academic types. The prevailing tasteless idea is that "more is better" and therefore "more type inference is better", so surely full type inference is just better than the "limited" inference Rust does! Bleh.
Even well-written code can be hard to understand -- practically impossible, even -- if what it's doing is sufficiently complex. Cryptography and certain areas of graphics have humbled me, for instance. I followed the flow, and I appreciated the comments, but I did not understand.
Your project is vastly more specified than a toy project, because it has a real customer (you) who will expect it to work after it ships. That expectation is what separates toys from real tools.
I bet you could write a word processor in an hour. It might only add or delete one character at a time (no selections). It might persist only to a hard-coded "output.txt" filename. You might have to kill the process because there's no quit operation. But that would suffice for a toy word processor.
Fair point, my example was indeed "shipped to production" and may not compare a throwaway static generator toy project.
I still think those estimates are off, because I think many of those projects would need significant research and learning time, possibly more than actually coding -- not to mention time spent troubleshooting when something goes wrong.
Imagine this source code becoming the unit tests for the legal code. Future tax-code changes would be accompanied by corresponding changes in GitHub. Inconsistencies would surface as new code and tests break the old ones. As courts introduce new nuances to the law's interpretation, new unit tests would follow.
This wouldn't replace human judgment; nobody in power would allow that. But even the capriciousness of politics can be expressed as Boolean logic (var isDeductible = taxpayerIsMe && !taxpayerIsYou). The tests could at least memorialize all the pork.
good luck with that; interpretation make things like this very difficult, if not impossible.
I agree that this would be nice, however. as a non-lawyer and someone who considers themself to be not a "real" developer (even though I write software every day) I have often wondered how alike law and code are, really, when it comes to defining intent via a keyboard.
The interpretation aspect isn't solvable in code, but it's representable. That's what I was getting at with the Boolean comment. A branch point might be "bool answerUnanswerableQuestion()" and the unit tests would mock it as true and then false. Even if the question isn't deterministically answerable in real life, at least the code can show what happens when it is answered.
You're conflating determination of factual and legal questions (out of scope) with modeling the decision tree (in scope and useful).
The function you ask about would be "getDeductiblePercentage()," and the unit tests would return various hard coded numbers. Actually determining that value for a real taxpayer is still hard.
Being able to show how information flows through the US tax code would be useful, even if it doesn't solve all the problems that arise from its intricacy.
reply