What an inspirational work of art. Thanks for making this and sharing it.
I've only played a few minutes (will have to revisit with more time). On first impression, the art style / characters / dynamics feel like a mix of "Little Kitty, Big City" and "Olli Olli World". Really great vibes!
Formal reasoning about functional programs in terms of their (denotational) semantics is normal in a functional programming class (e.g. it's about a quarter of our mandatory-for-undergrads FP course).
Formal reasoning about imperative programs in terms of their (e.g. axiomatic) semantics is only in a grad-level course, and the programs you can reason about are really, really limited compared to the functional ones. (The last time I TA'd the FP class, one of the homeworks involved proving a simple compiler correct. When I took the grad course, I think the most complicated program we proved correct was selection sort.)
I think "reasoning about programs" is more computer-science than "writing programs," and choosing an imperative language signals that you're not emphasizing the former.
It's one way of modelling the broad notion an algorithm, but it isn't the only one, and it's odd to treat it as the one true expression of computer science when essentially all modern computing follows a different model.
I recently came across a video that presumed to prove and settle the "free will" debate. I wrote about why the video's "proof" was faulty, but the "proof" nevertheless sparks some interesting questions on the topic.
> I hate praise that feels forced, and it seems like this kind of practice would make it seem quite forced.
This is a really good point.
Yeah, the `praise` comment is a call to find something to sincerely praise. If you can't find anything to praise (which is probably a warning sign that your head isn't in a happy place) don't leave a `praise`.
Very much inspired from Conventional Commits, this expands the idea to review comments.
At GitLab, we are a fully remote organization so we do a lot of written communication. This has been a great pattern for improving readability and the content of review comments. Plus, it's machine parseable which means we could easily query and aggregate these comments in the future!
TL;DR - Price is not a function of cost, and is ideally set before your product is built. Do not attempt to set a price unless you have a profile for your target market. Then, price according to what your customer is willing to pay.
IMO, this is a marketing question and here's a good entrepreneurial process for profiling the market and your target price. First, ask yourself these questions:
* What actual value does the product give to the customer?
* What are the competitors / substitutions to the product?
* What makes this product sustainable?
* What does the customer currently pay for comparable solutions - in money, time, and effort?
This should give you a good feel for what your customer is willing to pay. Then, set some financial profit targets which is your total revenue - total expenses (don't factor investment money as revenue). Finally, bend your product / process to this target price (not the other way around).
I would encourage any engineer to research courses on Marketing and Entrepreneurial Finance. The best marketers merge the engineering process (i.e. research, statistic, and financial analysis) with psychology (i.e. the feels).
Anyways, good question and it should not be taken lightly. I've stalked HN for some time now, but this question caused me to finally create an account.
I've only played a few minutes (will have to revisit with more time). On first impression, the art style / characters / dynamics feel like a mix of "Little Kitty, Big City" and "Olli Olli World". Really great vibes!