I’ve been sick the last two days and utterly uninspired to do anything productive. I’ve instead procrastinated by writing a “minesweeper” clone in Erlang.
Why? I have no idea. I was just sort of thinking of simple desktop classics to mess around with that are de-facto standard to populate a GUI app launcher like Vapor… and several hours later I had this thing. By that point I figured I was invested enough to swap text for graphics, and poof! There we are.
I still need to add win/loss conditions, a wall-clock timer and some kind of score thingy, but anyway, this was actually a much more fun way to tool around on a sick day than I expected and makes me feel just barely less of a dirtbag than I would have been had I wrapped up in bed all day feeling crappy.
I hate being sick. Ugh.
Update
I went ahead and finished it (except for recording scores — does anyone ever look at that since they can’t be sanely shared and aggregated?) and put it on gitlab just in case someone wants to see what a really hasty/disorganized codebase looks like.
It even has settings! Hahaha! “Settings” really being code for me messing around and seeing if I remembered how wxSlider widgets work (turns out I do and they are boringly easy to use).
If I find myself not feeling in the mood and going to the gym is out of the question, I suppose I could do one of these in 3D next time. Seems like “minesensor” would be a slightly more involved sort of game.
It must be in the air: me coding a minesweeper in Erlang too. Well, not for the game itself, just a fingers’ warm-up.
Get well!
Do you have a link to your minesweeper implementation? :-) If it isn’t in a repo or something readily linkable, no worries — I just think it is fun to let people see different ways to approach the same thing.
For work I often write game servers instead of front-end code, but I wound up enjoying writing such a small-scale, fits-in-your-head puzzle game a lot more than I expected and have been thinking about doing more desktop games (some a bit more elaborate than Minesweeper) since it is now easy to launch them cross platform.
I’ve recovered from my not-so-fun days and am doing well now. Thank you very much for the well-wishes! Have a great time creating things!
Sure, have at it: https://bitbucket.org/r_s_o/epona/
Just do not expect anything, you know… fancy :)
Creating thing, that’s what really worth the effort. I work enterprise/academics, yet sometime i just have to code a thing or two beyond the job domain. Erlang does needs more desktop apps, not only games. It’s easy, it’s robust, it’s fast enough — what’s else to wish? More libraries may be.
Thanks! I see you did the Erlang part as a controller for a Qt GUI. Nice. :-)
IMO, Erlang’s greatest weaknesses are twofold (neither of them technical):
1. It has been stuck in the “Erlang releases” embedded mode mentality for so long that newcomers don’t quite know what to make of it. It runs perfectly fine as a dynamic runtime in the same way Python or Java are nearly always deployed, but that’s just not the way the tooling has ever been designed. Changing that is why I wrote ZX and Zomp: to make “running something for the first time” mean “building and caching the build”, and bring more environmental familiarity to newcomers. Elixir could have fixed this, but chose to do its own thing and abandon the Erlang roots almost entirely, so that just never happened. As it turns out, the choices involved there make Elixir a difficult to support lang for ZX (Elixir makes the assumption that you’ll only ever want to run anything as Elixir apps instead of from another language like Erlang or LFE).
2. Related to the first, there has never really been a good way to source packages aside from hex.pm, which is really aimed at Elixir. Let’s face it, github is less than a reliable source for stable code (packages can disappear overnight based on the whims of the author — poof!), and it is miles from being a package manager and distributor; the last thing you want to see when you have a major deployment coming up is “Oh crap! We can’t build because github is down!” — it happens). The alternative is explicitly vendoring out dependencies (instead of relying on implicit caching of them), and that gets messy.
These two conspire to cause Erlang to find very little use on the client-side up until just recently, and the few places it is used on the client side a lot of effort has to be made by either an administrator or a user to get things working properly. Fortunately that’s no longer an issue, but it means Erlang is way behind the power curve on including bindings for libs like Qt and Vulcan, and there is not yet any audio or video lib support.
As for libs in general — there are loads of Erlang libs, but they are spread out all over the place and it is hard, due mostly to the limits of personal experience and the size of the community, to determine what the “go-to” solution for a given problem is.
Hopefully with one of the contextual and infrastructural blockers gone now we’ll begin to see some activity in the client direction. Only time will tell. :-) I sure plan to take full advantage of the new easy launch tooling and start writing more general use desktop tools, and maybe that will put a bit more weight behind the Qt, Vulcan and A/V lib binding advocacy within the community. Who knows.
Thanks for the link! Have fun coding!
Well, that’s not a “Qt GUI” – it’s a Qt GUI *builder* :)
And it is controlled through stdin, so one may use it not only for Erlang. I prefer this approach over straightforward porting or bindings (like it was with wx libs). Vulkan, SDL etc – those could be apprehended as easily as Qt this way.
You are right in saying Erlang’s problems are not of purely technical nature. Good tooling, that’s what we need. Java’s infrastructure is more cumbersome actually, yet somehow it manages to hide all the complexity behind some pretty simple tools like ‘javac’ etc (that is, those tools *look* simple until you need to go a bit deeper, then hell it is). So we here in Erlangland have a strange situation: really simple language, really simple libs – and one can’t just get to that simplicity.
Honestly, i don’t like Elixir that much. The language is… too noisy and too self-concerned for my taste. I have a strong feeling we are yet to see a truly proper BEAM language. Still, they did quite a job on the tools (comparing to the old rebar at least).
As of github, i second your exp and opinion (that’s why my personal projects are stored in other place). Can’t appraise hex.pm – i’m yet to publish my first package :) (could it be epona?..)
Thanks for the wishes, same goes to you! :)
The hardest part about using a port to communicate with a non-integrated library or toolset (messiness aside — but that could be hidden behind a lib) for client side code is the inability to ensure that Joe Average User has the unincorporated library/toolset installed and available. With WX I know for absolute certain that, say, a Windows user who can run Vapor can also run anything else I might write with WX in Erlang — I lack this knowledge if I use an unincorporated toolset. Writing programs for myself or other programmers is fine, but if a normal users can’t just “click a thing and be sure it will launch” then it is lacking for practical use.
What would be the best way around that?
As for that simplicity, I’d love to get your opinion on ZX https://zxq9.com/projects/zomp/ and whether it gains a bit of territory on the “Impossible things are easy and easy things are hard” problem Erlang has traditionally faced. I don’t think the project creation procedure is too terribly messy and packaging/submitting is as simple as I could think to make them.
zx run [program]and, when running locally,zx rundir [projectdir]orzx runlocal(if you’re actually *in* the project dir) have accelerated my own development turnaround. I need feedback!Hmm. A port is just a plain simple executable. You put it into the path, you call open_port/n, bob’s your uncle. What’s so hard about installing a certain prerequisite for a certain lib? Basically, it’s the matter of ‘sudo apt install whatever’ once. Sure, Joe the Average won’t manage, but installing packages is an admin’s job anyway. So i fail to see any messiness here. Dunno about Windows (haven’t touch it for, like, 15 years or more), but surely there must be some kind of package manager as well.
Worst case scenario: we start, we fail to open_port, we let-it-crash with a nicely formatted terminal message. Anyway, it’s better than sitting tight with a pre-bundled pack of libs only, right?
Had a look at ZOMP tools. I’m not an expert, but those looks like quite an effort in right direction, definitely. Have you considered integrating it into, say, IDEA plugin? I’d love to be able to use it with some advanced scripts for building more complex skeletons, and nowadays i just can’t live without a modern IDE.