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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
I personally work for myself, and I have found it to be very rewarding and fulfilling. It's not for everyone, but for for some it is certainly far more rewarding than working a 9-5. Especially one where you feel like you have to turn off your brain for 8 hours which I find to be very unfortunate.
To some extent I agree with your mentality. I don't think we should treat work as anything other than that - trading your limited time for money. But you spend so much of it on this thing, work, that turning off your brain to engage in it seems just depressing.
That is what I thought too when I first started using them. "They just aren't as good as Google!". I have found this to not be the case as often as I thought it would be. In fact, 90% of my searches I'd say never require me to leave Duck Duck Go to find the answer, that includes technical queries.
That isn't to say that DDG is perfect, but for the times that it isn't perfect tacking an !g or !b to the end of the search does the job.
InsuranceToolkits | Experienced Software Engineer | Remote (Within the U.S.) | Full Time | https://insurancetoolkits.com
We are looking to hire an experienced software engineer to join our small team. We are a a bootstrapped startup company that is growing very quickly. We have a lot of big projects coming down the pike that we need help with.
InsuranceToolkits is an underwriting, quoting, and sales tool suite for life insurance agents. We are looking to hire a backend developer to work on our underwriting and quoting engines.
Technologies (Relevant to this position): Python, Django + Django Rest Framework, Flask, Redis, Postgres
Other technologies that we use: TypeScript, Nuxt.js, Dart, Flutter (mobile)
We are a small but profitable startup company that is growing very quickly and we're looking to expand our team. We are on a mission to bring high quality software solutions to an industry that has been lacking them.
If you are interested in learning more, feel free to reach out to me at: [email protected]
Also, writing a solver for these things is also surprisingly difficult, but fun!