I ended up making my own keyboard for consistency across devices for https://wordglyph.xyz Another nice thing about custom keyboard is it doesn't give you word predictions like a lot of built in keyboards do.
Yeah, I am starting to appreciate that view a bit more now after also struggling with the native keyboard. I already started working on adding that to Word Pivot.
> The rules are a bit unintuitive. Definitely surprising that horizontal words don't have to be words.
You are not the first person to say this, and I am starting to agree. I think that more basic ruleset is more fun and far more intuitive. Especially given the current UI layout. I am going to spin up a new version with that ruleset I think.
Also, the rule that you can't repeat a letter for a position with the horizontal word, or two immediate neighbours is just too...finnicky and arbitrary.
Uhh, no, the answer is not to avoid cascading deletes. The answer is to not develop directly on a production database and to have even the most basic of backup strategies in place. It is not hard.
Also, “on delete restrict” isn’t a bad policy either for some keys. Make deleting data difficult.
> Here's the technical takeaway: Never use CASCADE deletes on critical foreign keys. Set them to NULL or use soft deletes instead. It's fine for UPDATE operations, but it's too dangerous for DELETE ones. The convenience of automatic cleanup isn't worth the existential risk of chain reactions.
I actually agreed 100% with this learning, especially the last sentence. The younger me would write a long email to push for ON DELETE CASCADE everywhere. The older me doesn't even want to touch terraform, where an innocent looking update can end up destroying everything. I will rather live with some orphaned records and some infra drifts.
And still I got burnt few months ago, when I inadvertently triggered some internal ON DELETE CASCADE logic of Consul ACL.
This is super cool. I have been using TypeScript To Lua (https://github.com/TypeScriptToLua/TypeScriptToLua) for a little game side project and it works quite well, I am pleased with it. It does end up generating a lot of Lua code though because it has to support all of TypeScript’s features, which isn’t ideal. I’d expect Teal’s output to be much more concise Lua which has me interested.
Teal's output is currently pretty much 1-to-1 with the input apart from removing all of the type information of course. (I've been trying hard to keep it that way so that the error messages in stack traces match the input lines without having to do source mapping.)
I can do this with two lines in my nginx config. I have no idea why I would ever consider using another service for this if all it does is rate limiting.
This would be a fun game with some UX improvements. It's extremely frustrating when the reason I can't finish a puzzle is because my finger slipped off the line and not because I just don't know the solution. I stopped playing because of how frustrating that was.
Totally agree, the dexterity is what makes it fun. I was thinking about how a larger screen would help, or if I had longer fingers, or if I cut my nails it'd be better. The annoying fails build me toward a sweet victory. good rush.
Also, the cost of failing is not much, quick iterations. You just have to remember what you did.
No, they're not the same. In Jenga you usually lose in a way that you know could have been avoided. "If I had just held my hand still" or whatever. That is not what this is. This game is frustrating because it was poorly designed not because it is "hard".
I have tried several times to learn Haskell. The only resource that actually worked for me was Philipp Hagenlocher's "Haskell for Imperative Programmers".
It is incredible. He does an amazing job of starting from the basics and then diving deep. After going through the series I had a solid enough grasp on the language to use it for practical things.
I'm currently reading Graham Hutton's "Programming in Haskell" (2nd), which is also another great resource. He also has YouTube videos [1] for chapters in the book. Philipp's videos are great too, which I also watch after finishing a book chapter.
Going to give this a try later. I've had the same experience, and every time hit a point of going "I'm X levels deep in syntax I don't understand and can't see a benefit in sight..."
Trying to figure out how to create a stable orbit makes me think of "The Three-Body Problem" by Liu Cixin (https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel)). The characters in the book have to figure out something similar, though more complex and in a VR like world.
As with most things, the ancillary tasks are always the most annoying part of developing a language. Even if the language is just for yourself or a small group of people, you still need to build the tools around the language that make it usable and I find that to be the most tedious part and often the hardest part.
If you're getting hung up on parsing and what not, you might be more successful using a parser generator. People hate them, often for good reason, but they do allow you to iterate quickly at first.
I haven't used it personally, but if you plan on using LLVM I hear that is a nightmare to use. Probably would also fit in to the "hardest", "tedious" and "least enjoyable" category for you too.
> If you're getting hung up on parsing and what not, you might be more successful using a parser generator. People hate them, often for good reason, but they do allow you to iterate quickly at first.
I find using a parser combinator library or a PEG (https://en.wikipedia.org/wiki/Parsing_expression_grammar) is a better way to go. Usually expressing your grammar in these ways is not much more work than expressing it in an EBNF-esque style that a parser generator takes as input. The benefit is that you have a custom parser that is easier to modify and customize.
That is another great option, especially for getting started. This is something we have done at work to build our internal DSL. We used the wonderful Lark parsing library for Python. It allowed us to iterate very quickly and get the tool in the hands of the people that were intended to use it asap.
I don't think I would use a parsing lib to build a general purpose programming language though. At least not one that I intended to ship.
> > I don't think I would use a parsing lib to build a general purpose programming language though. At least not one that I intended to ship.
> Curious why not? Too big of a dependency?
Really very poor diagnostics. I've used a few, but for really nice helpful messages[1] you really need to build it yourself and handle some subset of the context when parsing the grammar.
--
[1] For example, maybe you want to issue errors of "'SomeVariable' not defined on line 53. Did you mean 'someVariable'?".
Or perhaps you want to issue the message "Unexpected end of input on line 570 - expected closing '}' to match opening '{' on line 515, column 22".
It gets especially annoying if the language provides meta-programming or compile-time logic - the parser generator, if it can even handle such a thing, spits out either an error for a line that is nowhere near the source of the error, or spits out pages and pages of a backtrace.
It is inevitable that you'd run into issues eventually that are due to the parsing library itself. Whether that be performance or otherwise. Sure, you can fix those problem in the lib yourself, but maybe you just can't for one reason or another. It is also possible that the lib is really good and has no problems, but your problem ends up being slightly different which makes it a pain to implement with the library that you choose.
When you are making a general purpose language that gets shipped to the masses, a core component of that thing you are making is the parsing. I'd say it is in your best interest to have complete control over how that works and be able to understand that well. That would mean putting in the work to make the parser yourself.
I don't just feel this way about building programming languages. I believe this is true for any kind of production level software that you write. It is important to maintain control and deep understanding of technologies that are core to your product. Building something from ready made components, while tempting, often ends badly.
There's literally a Nim plugin for Godot, commercially shipped games using it, and Nim compiles to C so it's easy to use it with Godot with or without bindings.
