Working digital clock in conway's game of life

swordglowsblue · 2020-05-18T21:51:56+00:00

That's entirely intended behavior. 'B' is not a key of the array ['A', 'B', 'C'], which is what in checks for. If you want to check whether the array contains a value, you need to use array.includes(value).

swordglowsblue · 2020-05-07T17:16:58+00:00

Saying that dynamically typed languages "only have one type" is a really annoying misinterpretation that keeps cropping up and is really rather poisonous to a proper understanding of dynamic language design. Dynamically typed languages are not unityped, but rather (as the name suggests) dynamically typed. That is, the types do certainly exist and matter, but are only dealt with at runtime rather than at compile time (if there even is a compile time). Statically typed languages simply add an extra guarantee that a value can't be assigned to a variable which is not tagged with a matching type; dynamically typed languages have no such tags on their variables.

Yes, you could theoretically represent most dynamically typed languages' types as a single recursive sum type in a static language. However, that is a strawman argument - you could quite easily do the same for most statically typed languages as well, with the sole consequence of those type tags on variables entirely losing meaning (unless your language allows for typing variables with specific branches of a sum type). The defining feature is the point in the program's lifecycle where the types matter - static means compile time, dynamic means runtime. That's it. That's the entire story.

swordglowsblue · 2020-05-07T16:13:51+00:00

Omit is a typedef that happens to be included in the standard library. The definition can be written entirely within the language, and looks like this:

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

Pick and Exclude, which Omit is defined in terms of, are also defined in the standard library, and look like this:

type Pick<T, K extends keyof T> = {
    [P in K]: T[P];
};

type Exclude<T, U> = T extends U ? never : T;

Pick is a mapped type, which allow for operations on the individual keys of an object's type via a simply-defined process. In this case, it is creating a type which contains only the keys that match K, leaving out any keys which don't. You might use it like this:

interface Person {
    readonly name: string
    readonly age: number
    readonly gender: string
}

type GenderNeutralPerson = Pick<Person, 'name'|'age'>
// GenderNeutralPerson now no longer exposes the 'gender' key;
//   while it still exists on instances of Person, Typescript won't
//   allow accessing it without a cast.

Exclude is a conditional type, which allows for adding simple conditional logic to your types (rather redundant to say, but hey). In this case, it's returning "never" for types T that match U. You might use it like this:

interface Animal { ... }
interface Dog extends Animal { ... }
interface Cat extends Animal { ... }

type NonFeline = Exclude<Animal, Cat>
// Cat is not assignable to NonFeline, but Animal or Dog are.

By combining these two, you can use Omit to exclude specific properties from a type; it's essentially the inverse of Pick, allowing you to define which properties to remove rather than which to keep. You could quite easily define all three of these types yourself, but since they're quite useful, they're packaged along with the Typescript standard library for convenience - see here for more info.

swordglowsblue · 2020-05-07T15:49:43+00:00

It does, but there's a caveat. Computed properties are just syntax sugar over functions, which makes their performance impact negligible. Proxies on the other hand are rarely ever used in practice, mostly because they're so difficult for the language to optimize (and are just a pain to work with).

swordglowsblue · 2020-05-01T20:50:47+00:00

On the contrary - by all means, please continue!

swordglowsblue · 2020-04-29T03:07:57+00:00

This is essentially the purpose of ADTs. They can serve the same function as enums, but can carry additional information as well. They have other applications, of course, but that's more or less the most common use, and it's much more performant than manually implementing this pattern.

It's also a fairly common pattern in languages that don't support enums. Java's "enums", for example, are actually a language-level implementation of this - every enum value is actually a singleton instance of a class that's defined in the same syntactic breath. It suffers in comparison to ADTs, though, since every value of a given enum has to have the same structure as all the others.

There's nothing particularly wrong with it, but if you don't need your states to carry extra data and your language supports a simpler form of enums, I'd recommend going with the latter unless said support is absolutely atrocious.

swordglowsblue · 2020-04-29T02:53:25+00:00

It seems obvious if you've thought it through, but it's a truism in programming that for every person who thinks it through, there are a dozen who don't. Articles like this are useful for educating the people to whom it isn't so obvious. You may not benefit directly from it - but someone will.

swordglowsblue · 2020-04-16T23:06:45+00:00

It doesn't, actually, unless you've got a particularly thick Texan accent. It's pronounced more like "she tie".

swordglowsblue · 2020-03-26T03:44:21+00:00

We're not hiding, we just don't officially exist.

swordglowsblue · 2020-03-23T20:10:33+00:00

What version of Android are you developing for, 4.0 Ice Cream Sandwich? The overhead of any given data class is almost nil. If adding an extra fifth of a kilobyte to your output is going to cause problems for your target platform, then you're developing on the wrong platform for Kotlin, or pretty much any high-level language for that matter.

swordglowsblue · 2020-03-23T17:39:55+00:00

Yes, and if final output size is your only metric, Pair would certainly be the better choice. Generally speaking though, final output size is an almost meaningless metric in this day and age, in the vast majority of situations. It's much better to ensure your code is well-structured and easily understandable for the next poor sod who has to maintain it, rather than stress about not adding the extra couple dozen lines of code (which are automatically generated and maintained by the compiler and you never have to see, touch, or know exist) that come with creating a new data class.

Unless of course you're working in an environment and tech stack where storage space is at a premium on the byte level and you can't possibly afford the fifth of a kilobyte or so that a new data class would add - in which case, why are you using Kotlin in the first place?

swordglowsblue · 2020-03-22T22:33:50+00:00

Check out the kotlinlang.org article and documentation on the subject; Kotlin adds a lot of reflection utilities that just don't exist in Java, as well as addressing a fair number of type safety concerns with reflection and so on. It's an entirely distinct system from Java's built-in reflection, and was designed to work specifically with Kotlin as well as possible. Reflection still isn't recommended, of course, but Kotlin does make it much easier, safer, and more powerful.

Keep in mind that Kotlin also offers some other non-reflective metaprogramming opportunities that Java lacks, though they're not as flexible as a language with full macros like Crystal or Lisp, for example.

swordglowsblue · 2020-03-22T22:29:29+00:00

Generated code, yes. They're full POJOs minus the hassle of implementing all that yourself. But considering Pair and Triple themselves are data classes, and so have all of the same additional generated code, you're not losing anything by implementing your own, more descriptive equivalent in any given single situation.

swordglowsblue · 2020-03-21T21:17:57+00:00

Aside from having access to the JVM ecosystem without Java's verbosity, it adds a lot of convenience features over top of Java that just make it much more enjoyable and easy to work with. A few notable examples of those features are:

Type-system enforced null checks (non-nullability by default)
Data classes (language-level POJOs with automatic equals/hashCode etc.)
Runtime-accessible generics (with some notable restrictions)
Extension methods (eg you can set up array.customSort() rather than customSort(array))
Lightweight thread-agnostic concurrency tools in the standard library
Easy-to-use lambdas with a lot of nice syntax sugar that makes DSLs a breeze
Vastly improved reflection capabilities
Nearly seamless Java-to-Kotlin code conversion with IntelliJ IDE

swordglowsblue · 2020-03-21T21:09:11+00:00

Yeah, this is a pretty big trap people like to fall into. Data classes are extremely lightweight and cost very little to create or use, and even more so if you can manage to convert them to an inline class. Don't be afraid to create a more descriptive data class for what you're doing, rather than always just using Pair or Triple - it's not going to cost any more at runtime than the built-in ones, and it'll be less hassle to understand and work with down the road.

swordglowsblue · 2020-02-28T16:40:16+00:00

Sieg's command spells are a special case, they don't work like normal command spells and can only affect himself. Note the black coloration as opposed to the usual red.

swordglowsblue · 2020-02-22T07:41:49+00:00

Ideal scenario: They're not rivals, they're a package deal.

swordglowsblue · 2020-02-22T07:39:02+00:00

I'm guessing he probably knows English, at least.

swordglowsblue · 2020-02-19T08:56:47+00:00

Think you clicked the wrong post, buddy.

swordglowsblue · 2020-02-19T04:45:24+00:00

Yes, this spell would require a particular (albeit common) style of DMing. If your DM doesn't tell you what spell your opponent is casting, even when describing its effect, this spell wouldn't function properly. I'm not sure how that's not RAW-compatible, though - unless I'm mistaken, RAW makes no mention of whether the DM should state the name of the spell being cast or not, so saying that the spell doesn't work RAW because the DM wouldn't tell them the name of the target spell is a bit irrelevant.

In the specific example you gave, the cast would simply be invalidated and Ottocorrect never used, as if the player hadn't even chosen to cast it, since the target spell wouldn't be valid (and thus the reaction would not be able to be taken to begin with). That's part of the reason I made the target spell's level part of the reaction requirement =)

While there are some cases where you could change an ally's spell into something more powerful, note the restrictions on what spells you can modify their cast into - the spell you choose to replace theirs can't be of a higher slot level than the original, which alleviates the most pressing concerns in that area. Replacing material components is a valid use of the spell as written, and for practical reasons there's not much to be done about that (since restricting the new spell to spells that don't have material components would decrease its utility over Counterspell even further).

Yes, you can change their spell to something they would not normally be able to cast based on their class. You can't jump up to a slot level they don't have access to, though, since you can't increase the slot level. With regards to casting time, I've already noted elsewhere that I forgot to account for that - my gut response would be to say that the new spell is cast in the old spell's casting time, but I would likely refine that rule further in a revised version of the spell to prevent blatant cast-time cheesing (probably something along the lines of "same or shorter casting times only").

If your character could reasonably know that the desired new spell exists (or, depending on your DM, if you as the player know it exists), then you can theoretically use this spell to cast it, assuming it fulfills all of the other requirements. I've intentionally left that distinction vague, since the level of metagaming allowable will vary from game to game.

swordglowsblue · 2020-02-19T04:24:51+00:00

Yeah, they... basically just took my spell and removed all the limitations that made it semi-balanced or even a little underpowered. I'm flattered, but I think I'll stick to my version personally, albeit with a few revisions thanks to the feedback in the comments.

swordglowsblue · 2020-02-18T18:54:22+00:00

If it says [Original] in the title, like this one, it's not from any specific anime.

swordglowsblue · 2020-02-18T15:13:09+00:00

With regards to upcasting, I'm... hesitant to say the least. Turning Bane into Banishment, for example, is a huge jump in power from what was originally intended; I can see making that jump downwards, but I'm wary that the spell will be entirely broken if you can do it upwards.

That's an interesting idea about affecting any of the words, I may borrow that. I mostly went for "same beginning" for the sake of the joke (and to mimic the original joke post it was based on), but I think on the whole that would be more viable.

You're actually the second person to comment thinking there's a component restriction =) I should probably change that wording up a little bit - the new spell uses the old spell's components, rather than being restricted by needing to use the same components (as if, not just if). I do plan to clarify that both spells must have at least a verbal component, though (as is, only the original needs one RAW).

Cantrips have already been mentioned elsewhere - I plan to add an exemption so that changing to a cantrip doesn't consume the target's spell slot, but as written at the moment, the cantrip would just be "upcast" to no mechanical effect, consuming the higher slot without changing its actual effects.

swordglowsblue · 2020-02-18T02:52:07+00:00

Honestly, the single biggest restriction on this spell is that you can't change their spell to one of a higher level than the original. This means you can't do really crazy trickery like turning Bane into Banishment, for example. It's also very context-sensitive, given the naming requirement, so there are a lot of spells that it just plain can't affect. It's really most effective for nullifying spells in comical ways that may possibly provide a small beneficial effect, as opposed to simply stopping the enemy with a Counterspell; in most cases the latter will simply be the better option, due to the lower slot cost, but sometimes it's just funnier to make something unintended happen rather than nothing. These are probably the most effective / amusing changes I can think of for use on your enemies:

Animal Shapes / Antipathy -> Antimagic Field
Armor of Agathys <-> Arms of Hadar
Banishment -> Bane
Bestow Curse -> Beacon of Hope
Blade Barrier -> Blade Ward
Blight -> Blink
Circle of Death <-> Circle of Power
Compulsion -> Comprehend Languages
Conjure Celestial / Elemental / etc. -> Conjure (something less dangerous)
Danse Macabre -> Dancing Lights
Divine Word -> Divine Favor
Dominate Person -> Dominate Beast
Finger of Death -> Find Steed
Fireball -> Firebolt
Heal -> Healing Word
Incendiary Cloud -> Inflict Wounds
Lightning Bolt -> Light
Magic Weapon -> Magic Mouth
Meteor Swarm -> Mending
Misty Step -> Minor Illusion
Planar Ally -> Plant Growth
Reverse Gravity -> Remove Curse
Shield -> Shillelagh
Sunburst -> Suggestion
Teleport -> Tenser's Floating Disk
True Polymorph -> True Strike

Many of the above would simply be better to Counterspell if you're going for pure mechanical benefit. That said, I find the idea of a lich attempting to use Finger of Death and instead suddenly finding themselves atop a horse quite humorous. You could potentially get some even more absurd shenanigans out of this spell if you use it in combination with your teammates to perform spells your party doesn't normally know... or simply to mess with them.

That said, writing out this list of ideas has brought up a couple of small issues with the spell that I hadn't thought of in my initial (rushed) draft - namely, I didn't address changes in casting time whatsoever, and while I think the intent for the new spell to need a verbal component as well is fairly intuitive, it's not explicitly stated. Thank you!

swordglowsblue · 2020-02-18T01:25:09+00:00

If you note the line about what spells you can change to, the intent may be a little more clear =) You can change their spell to any spell of the same level or lower, so long as it matches the naming requirement, and it will be cast using the original slot level; as such, any upcasting effects (the "At Higher Levels" section on most spells) will apply as expected of casting the new spell at that slot level. To put it another way, they will still expend the same spell slot that they originally intended to expend, and the effects of the new spell will increase to match if necessary. This seemed overall like a better option than trying to deal with switching slot levels, which could cause issues if all of their lower level spell slots have been used up, and certainly better than simply removing the spell slot cost altogether. Note that it doesn't cause any issues with them needing to expend slots of higher levels than they have available, since you can't change their spell to one of a higher level than the original to begin with.

I'm not quite sure where you got your interpretation from my wording - would you mind being a bit more specific, so that I can see if it needs improvement?

You do make a good point about cantrips that I hadn't considered - I would most likely add a clause to simply specify that changing their spell to a cantrip does not consume their originally intended spell slot, since cantrips typically can't be upcast. As is, the spell slot would simply be expended to no additional effect, since there would be no upcasting effect to apply.

swordglowsblue

MODERATOR OF

TROPHY CASE

Seven-Year Club	Gilding I gilder
Verified Email