There's loads of slop and slop enthusiasm on lobste.rs; the only difference is that they have a moderation policy which forbids the most egregious forms of advertising and astroturfing.
Nothing public yet, it's an odd case, there is no contact with the author, but he apparently expressed to someone that he doesn't want the ROM shared. It all borders on the "five monkeys experiment" by now.
There is a community and a very devoted one, yes, but it's a very small and dispersed one as well, a lot happens over email. There is a group of collectors who mostly hoard the devices and ROM cards and keep them under glass and like these things to keep value, and then there's the more engineering types like me, who actively tinker and actually use the things.
This is all on a pocket 8-bit - calling the platform a "programmable calculator" is downright offensive! ;)
I wrote an (unfinished as of yet) IP stack for it in DL-Pascal, I have working UDP and a DNS resolver but no TCP yet: https://github.com/wowczarek/pbnet
The standard problem with "just voting" to solve problems is that you can only vote for the options you're offered. If all the options on the market suck, voting for the lesser of the available evils will not address the fundamental source of your dissatisfaction, and may help entrench it. If you vote "with dollars" there's the additional problem that dollars are not uniformly distributed, and a few wealthy "voters" can and will disenfranchise everyone else.
Abstaining from buying from companies you disagree with can help, but it is only one part of the broader solution. When there aren't alternatives yet "on the market" you may be forced to hold your nose for a while and buy from the vendors you hate while advocating for change and working toward their replacement. You don't have to solve every problem in your world at once so long as you're building in the right direction.
The changelog for this project dates back to 2019, well before SDL3 was available. SDL2 supports some older platforms that SDL3 has deprecated. If you value running on those deprecated platforms and/or you don't need any of the features introduced since SDL3, it's quite reasonable to stick with SDL2.
Not sure when the switchover happened, but IIRC I started out with SDL2 on Homebrew and recently got this compatbility shim instead when it updated: https://github.com/libsdl-org/sdl2-compat
I don't have an extremely high opinion of sdl2-compat specifically because my SDL2-based projects have had several bizarre bug reports which originated in downstream packages presuming they could use this "compatibility layer" instead of the actual dependency I develop and test against.
Oops: "The owner of this website (www.ablogtowatch.com) does not allow hotlinking to that resource (/wp-content/uploads/2022/09/Seiko-TV-Watch-T001-5019-15.jpg)."
In Decker, most of this example would be similar. The button's default script template would be:
on click do
end
And filling it in with an equivalent script would be something like:
on click do
myname.text:alert["What is your name?" "string"]
end
There is slightly more "programming-language-like" punctuation to Lil than HyperTalk, but simple examples are still simple, and in my opinion having first-class collections (lists, dictionaries, tables) and a richer set of APL-like operators makes Lil scale up much better to more complex programs. As a child I recall struggling tremendously with HyperTalk's "almost-english" structure; it made scripts easy enough to read and understand, but provided very little help when it came to writing new scripts.
Decker has a similar Widget -> Card -> Deck event bubbling hierarchy to HyperCard, and in my opinion retains much of the same directness and simplicity for simple applications. The differences in approach won't please everyone, but they are all carefully considered, and have been refined over time based on feedback from the user community. Decker is a living, growing platform!
Your example needs to add the part where you put that string into a card field so people can see their work.
But your example also includes a period, a colon, square brackets, and a space where someone might expect a comma. It's going to look a lot more daunting to a first time programmer. Simply knowing when to use a period vs. the colon is not going to be obvious.
The alert[] function prompts the user for input. The second "string" argument indicates the prompt will ask for a string, and return it. (alert[] can also ask for other datatypes, like a yes/no "boolean" prompt or a multi-choice selection from a list or dictionary of options.)
The colon (read aloud as "becomes" or "gets") is Lil's assignment operator. That single line,
myname.text:alert["What is your name?" "string"]
prompts for input and then stores the result in a card field. If you wish, you could also write it as:
on click do
name:alert["What is your name?" "string"]
myname.text:name
end
Learning the syntax for calling functions is partially scaffolded by the "Action..." dialog that button widgets offer for constructing simple button scripts with a GUI:
on click do
go["Next" "BoxIn"]
play["sosumi"]
end
Users can rely on the system to write code for them initially, and then slowly dip their toes into more complex compositions. Whereas HyperTalk has custom syntax for almost every programming construct and built-in function or feature, the Lil grammar is simple and uniform. Where symbols appear, they have a single meaning. Decker's "Listener" REPL allows the user to have a back-and-forth "conversation" with the Lil interpreter and see responses juxtaposed with their questions, versus the HyperCard "message box" which shows only user input or a single system response.
Ultimately, every programming language does require some degree of handholding and learning, and that's why Decker comes with dozens of example decks to take apart and study. The user community has also furnished some truly fantastic interactive tutorials:
reply