It's interesting to compare the game play and design. My game is written in Elm and open source if anyone is interested. This website has keyboard inputs (y or n) which is a good idea. My game only does click/touch inputs.
- Having a global registry of machines does not scale. Anyone building an app won't want to deal with the name conflicts. Having a `displayName` for debugging is fine but that's all. Having people pass the Machine instance to transitions directly is much more reliable/scalable.
- This [...rest] for event handlers is not good. Put those in a dedicated object because if you don't any new prop you add has the potential to break users. It's also bad because it looks like memory gets merged with those methods, making it likely the keys will conflict in view().
- Find a better name for T, it's confusing with Transition. Since it looks like a simple struct, maybe just have people pass {name, to} as plain data.
- You don't provide a rejected Promise example. I am interested how that works since it is something people tend to overlook.
- How the heck do I test my machines?
- A micro-framework that doesn't mention byte-size? Probably worth adding that statistic. My idea of a micro-framework is one that fits in a tweet.
- Write up how you expect this to be used. I don't think you could use this to build a real app because there's no way compose machines, only switch between them. You'd end up with huge machines because UIs are trees.
Also, if you have some solution or extra thoughts about machine composition (or about anything else) please write it here (or open issue) because is interesting for me
If anyone wants the Elm architecture in JavaScript there is Raj: https://jew.ski/raj/
I spent over a year building the framework and a set of libraries around it so that the architecture feels natural to JavaScript developers.
There's only a few of us building apps with it right now, but the stories for doing most anything are covered and as of 2 months ago the framework hit 1.0. It is a safe foundation to build on as I don't plan to ever change it.
Last winter I built an application called Subtweet that built on top of Twitter's Direct Message service, using Twitter's API as much as I could to reduce overhead. It is bittersweet that Twitter is improving DM as it makes Subtweet more and more unnecessary to users, but I am so happy to have all of these features built right in. I saw this shift coming when Twitter added multi-user DMing so I had already written the post mortem if anyone is interested.
If anyone is interested in just scrapping links between webpages with JavaScript, I made Slinky (https://github.com/andrejewski/slinky). The API is simple and easily overridable.
I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application.
>Go is good for what it was intended for which is concurrent programming and server/web application.
I absolutely agree that Go is nice for writing web servers! However, there is no reason that it can't still be nice for that and also a well-designed language in general.
For example, Haskell has awesome concurrency features, and writing a web server in Haskell is reasonably nice (not quite as nice as in Go, IMO).
`const` is for compile-time constants where something like `let` in Rust can be used for values generated on the fly.
The latter is immensely more powerful and actually provides the described benefits like guaranteeing that data is not changing under your feet.
Edit: While `const PI = 3.1415…` is threadsafe, it's not very useful in comparison to runtime-immutability :)
Yes, the guarantees provided by true immutability are not met by "const". I wrote the note loosely using the author's expectations and advantages of immutability, not the exact definition. But thank you for letting me clarify.
Also I just noticed with Go's Unicode support we can write `const π = 3.14..` if we really wanted.
Yeah, this post seems to be most about general purpose language features, and not so much about stuff that is relevant to the niche Go is trying to carve for itself.
For people who have wanted to try this type of programming out but have not jumped the boat from JavaScript to ClojureScript, I created a little library that mixes Backbone and React in a similar model described in the article: https://github.com/andrejewski/reactbone
It takes away a lot of the data-binding cruft that you find in Backbone.View and works well with React without making you switch languages, design paradigms, or add new libraries. The Backbone component makes it easier to build data hierarchies than with plain JS, but I assume other MVC frameworks could be retrofitted to work with React.
This is not unprofessionalism; it is poor UX. The sensible backlash to the Nickelback feature is that is was set "by default," not that ripping on Nickelback is a humorous, widely accepted activity. This app could have retained that "cleverness" and "easter egg" vibe by keeping the setting but not having it be active by default. With proper UX considered, the backlash in this case could have been avoided.
Having it not set by default may have decreased the amount of hate they received but it would also have likely decreased its effectiveness at getting people to talk positively about the app.
I have a similar problem, but I'm off by a year. I'm fifteen and have basically run out of any CS-related classes to take at my school. I have shifted into math classes (Calc, Stats) to help me get some "computation" this year at school. Just as someone who was where you are, I'd say don't get discouraged by what your school offers and try to work on your craft outside of school. Depending on how much you have learned about CS and programming, maybe learning more and iterating on some side projects would suffice. It's definitely something that is hard to get over, you're not alone. Keep developing.
It's interesting to compare the game play and design. My game is written in Elm and open source if anyone is interested. This website has keyboard inputs (y or n) which is a good idea. My game only does click/touch inputs.