Ruby instead of Python? (for the PC side of MCU boards and lab tools) - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: July 14, 2025, 08:53:51 am
content: This last weekend happened to let a podcast running in the background, a YT podcast. It was a very long one even at x2 playback speed, from the creator of Ruby on Rails, David Heinemeier Hansson (aka DHH). The pitch for Ruby caught my attention (between minute 41:53 and 45:10). Maybe the next 10 minutes or so, too, where he gives some syntax examples (in comparison with Python):DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474Lex Fridmanhttps://youtu.be/vagyIcmIGOQ?t=2513It happens that I also hated since forever the dunder dunder "__" in classes, or the unnecessary parenthesis in Python's print (optional in Python 2, but mandatory now, in Python 3), and so on, all the little pitfalls enumerated in that video (and maybe a few more not enumerated in that video, but I don't want to turn this into a bitching about Python topic).However, since the guy in the podcast is the developer of Ruby on Rails, maybe his pitch in the favor of Ruby is biased, so I'm asking here for more neutral impressions about Ruby (not Ruby on Rails) vs Python.My main use case is not web applications, but small PC programs for microcontroller boards tethered to a Linux PC (most often by a serial port, sometimes by LAN or USB + some GUI to print/plot on the PC whatever the MCU board is doing). Maybe controlling a few SCPI instruments, too (over LXI). Small programs like these, hobby level, at home. Typically a small GUI to plot something, plus a few buttons. Plotting data is a must.I've searched online already about Ruby vs Python, but the pros and cons are too generic. Overall, Python has 2-3 times more libraries than Ruby, and a much larger community support. Yet, adding a small GUI for Ruby programs (with Shoes), seems easier than in Python, but I didn't try yet.What I want to ask is if anybody tried both Python and Ruby.Does all the pros and cons of Python and Ruby will make any difference for my typical use case?Does it worth the time/effort to try to switch from Python to Ruby?

author: brucehoult
author_rank: Super Contributor
timestamp: July 14, 2025, 10:34:20 am
content: I used Ruby quite a lot 20 or 25 years ago. I've always preferred it to Python. Ruby is a little bit slower but if you're worried about speed then you shouldn't be using either of these languages, or you should be using them to organise the real code that is written in C/asm.Ruby is much more powerful. When there are different features and you kind of think that you should be able to combine them ... then you can. It's got some of the best parts from Perl, Lisp/Scheme, SmallTalk/ObjC. Python is just really restrictive. And I really hate the significant whitespace syntax.I've never used Ruby on Rails -- I'm not a web developer. I mean, at some point I followed a tutorial a bit, but I've never done anything real with it.I probably should refresh my Ruby. I've mostly dropped back to Perl5 for scripting needs. It's fine for simple purposes but once you need complex data structures it struggles a bit. Porting things from Perl to Ruby is more straightforward than from Perl to Python.I do use Python a bit simply because libraries exist for absolutely everything, so you can usually just go "pip install foo" then in Python "import foo" and write a 5 or 10 line program to do what you wanted. e.g. recently I started to buy TP-Link "Tapo" devices such as smart 240V switches / energy monitors and "security" cameras, all of which live on WIFI and you can work them from both their app and using a Python library.And then there's JavaScript. It's not as nice as Ruby but it's nicer than Python and has roughly as big a community and libraries. And node / V8 have had sooo many billions of dollars thrown at them (as have Apple's and Mozilla's implementations) that Javascript code runs many many times faster than Python or Ruby and something similar to Java or C# or C compiled with -O0.

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 10:55:19 am
content: Quote from: brucehoult on July 14, 2025, 10:34:20 amWhen I looked at Ruby I pegged it as a wannabe-Smalltalk, and hence never used it. If I wanted that set of features, I would just use Smalltalk.QuoteThat's the sole reason I would use Python.Clearly the designer had never had to create/read/modify a makefile where thetypeof whitespace (tabs vs spaces) has different semantics. Any language where thenumberof spaces has semantic significance is going to cause interesting and easily missed bugs when code is copied/pasted e.g. during refactoring.

author: DiTBho
author_rank: Super Contributor
timestamp: July 14, 2025, 11:12:28 am
content: and .. AI stuff is 90% for Python

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 11:36:35 am
content: I should point out that Python and Python style have evolved quite a bit over the last 20-25 years, and significant parts of the two have become more pleasant. I am probably much more of a pragmatist than DHH, as nothing his video criticizes really bothered me. I can also accept why Python did things that way and benefit from them.I do have a few criticisms of Python and for some things would suggest someone look at Ruby, for example, to construct "external" DSLs. I could also see switching to Ruby, if Python's significant whitespace and/or wordier style is still bothersome. So far for me, after 18 years of Python, that has not happened.

author: shapirus
author_rank: Super Contributor
timestamp: July 14, 2025, 11:50:56 am
content: Quote from: brucehoult on July 14, 2025, 10:34:20 amMy experience exactly. I learned Ruby ~12-13 years ago when I needed it to make effective use of Chef, the automated server (or whatever) configuration system. It was a wonderful experience. Ruby is a pleasure to work with: simple things are simple, complex things are possible (and easy enough, too). It doesn't try to hold your hand and lead you through a narrow path that the developers consider The Only Right Way To Do It, it doesn't want to take away your freedom. The same can be said about Perl, but writing clean easy to read code in Perl requires somewhat more of a conscious effort.Then, when I moved away from Chef, I mostly stopped using Ruby for scripts too and reverted to Perl, which is my native language, so these days whenever I need to write a helper program or a script, I use C when speed or small memory footprint is critical and Perl otherwise.I'm not sure where Ruby stands these days, in particular with respect to the availability of various libraries. I think it's getting marginalised similar to Perl, which is a shame. Everyone's using Python, apparently people like feeling constrained these days, or maybe it's just easier to understand for most folks. Go is also popular (apparently among the same crowd) and has its uses, but I can't understand how one can take a language that doesn't even have basic things like ternary operator seriously.

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 11:52:30 am
content: The question that arises is what can a Domain Specific Language achieve that a Domain Specific Library cannot?I observe DSLanguages:most (but not all) start small, but end up growing like cancer until even the authors don't fully understand how all the bits interact. (That can be true of general purpose languages, of course)tooling support is important, and has to be developed separately from the language and applications. General purpose languages come with lots of tooling supportcomputer science graduates yearn to develop their own language (Electronic engineers yearn to design their own processor)every new employee has to be trained in the languagepotential employees are reluctant to commit themselves to learning non-transferable skillsDSLibraries have some of those drawbacks, but not to the same extent.

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 11:57:08 am
content: Quote from: shapirus on July 14, 2025, 11:50:56 amI consider a language's basic semantics to be much more important than syntax.Poor syntax can be worked around, but poor semantics cannot.Yes, I realise I dislike Python's "whitespace with semantics"

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 01:54:38 pm
content: I thought a bit more about the OP's question on the way to lunch.I found that within the first 3–4 days of using it, Python (at least Python 2.5) was a very low friction language, that is, I quickly discovered that Python's way of doing things just made sense to me and I was spending nearly all my time thinking about the problems I was solving. If that has not happened for you, why not try Ruby for a few days on a project and see if it clicks? I hope it does!

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 02:27:06 pm
content: Quote from: tggzzz on July 14, 2025, 11:52:30 amPython's authors probably do not disagree, since their language could do a lot more to support DSLs. Or perhaps that used to be true, given the latestt-stringsthey are suggesting for DSLs.

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 02:45:01 pm
content: Quote from: jfiresto on July 14, 2025, 02:27:06 pmOooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified languageThe C++ committee refused to believe that avalid conformingC++ programcannot finish compilation! Erwin Unruh proved it by causing the compiler to emit the sequence of prime numbers. Will Python suffer the same fate? Or similar or worse?Will the Python toolset support be extended to cover any DSLs written in Python? (There would be no problem with DSLibraries, of course).

author: brucehoult
author_rank: Super Contributor
timestamp: July 14, 2025, 03:03:35 pm
content: Quote from: tggzzz on July 14, 2025, 02:45:01 pmI find it very weird that some people complain that templates can be abused, classes can be abused, macros and other syntactic extension mechanisms can be abused -- while ignoring at at least accepting that functions can be abuse, pointers can be abused.Heck ... did you know that in many programming languages it is possible to write aninfiniteloop? Or even one that no human (let alone compiler) knows whether it is infinite or not.I recall some dudes by the names of Church, Turing, and Kleene wrote about that 90 years ago.Preventing people from having powerful features that, if used with good taste, make programs clearer and easier to write, does not provide any guarantees that the remaining features will be used with good taste.

author: thephil
author_rank: Regular Contributor
timestamp: July 14, 2025, 03:08:30 pm
content: For hobby use, anyone is free to explore and use any language they like. If Ruby appeals to you – give it a try. If you like something else better in the long run, that's fine too. Learning something new is always a good thing.

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 03:17:16 pm
content: Quote from: tggzzz on July 14, 2025, 02:45:01 pmI can think of a ridiculous DSL that would demonstrate that and mock t-strings: t- as in TECO-strings. A pity I do not have time to write that as I have the source for an old EMACS it could execute.And to think, soon Python will have accumulated five (5) varieties of string: printf-style, template, str.format, f- and now t-strings.(I actually have a lot of respect for TECO considering what people then had to work with.)

author: brucehoult
author_rank: Super Contributor
timestamp: July 14, 2025, 03:43:35 pm
content: Quote from: jfiresto on July 14, 2025, 03:17:16 pmPeople who think TECO is bad have obviously never used its mutant clone "speed" on AOS or AOS/VS.

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 03:50:26 pm
content: The old slogan: Data General, we take care of our own. I felt that had an extra edge to it.Speed also ran under MP/OS and likely RDOS. I was too young to know the latter.

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 05:30:09 pm
content: Quote from: brucehoult on July 14, 2025, 03:03:35 pmYes, everything can be abused -but that isn't the point.There's a solid design principle that seems to have been forgotten or fallen out of fashion: “There are two ways of constructing a piece of software: One is to make it so simple that there are obviously no errors, and the other is to make it so complicated that there are no obvious errors.” - Tony Hoare.The C++language expertsdid not understand what created - andrefused to believewhat people told them until their noses were rubbed in it. That's damning.Yes powerful features are useful and good - but not if they are not understood or are misunderstood. And the languageexpertsdid not understand.I hope the Python language designers understand and follow Tony Hoare's principles. and probably will be due to PEBCAK

author: tggzzz
author_rank: Super Contributor
timestamp: July 14, 2025, 05:37:49 pm
content: Quote from: jfiresto on July 14, 2025, 03:17:16 pmIs it blindingly obvious which type of string should - and should not - be used, or are they multiple overlapping concepts? I imagine people could be perverse and misuse them (as per the Obfuscated-C contest); I would have fun reading such examples. But not if people copy-pasted LLM slop and misused them in production code.As for TECO... I started with 5 channel paper tape, so maybe I would have regarded TECO as an improvement

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 14, 2025, 06:51:46 pm
content: I did not get the wording quite right. There is still just only one type of string in Python 3, but four and soon to be five ways to format arguments to produces a string. Here is an example showing the first four, each printingn=3:Code:>>> import string>>> n = 3>>> 'n=%d' % n'n=3'>>> template = string.Template('n=$n')>>> template.substitute(n=n)'n=3'>>> 'n={}'.format(n)'n=3'>>> f'n={n}''n=3'Python originally just had printf-style string formatting, then added the others, over time, to address things you could not do or not entirely cleanly do with the ways of string formatting that were in Python at the time. Thus, there is a lot of overlap among the four, soon five ways. AFAIK, there is still no single way that is good for everything. For example, I believe you still need to use the ur-printf-style to have an extra variable specify a field's precision. But I have not looked at the recent changes that removed some restrictions on f-strings.I don't use Template strings, try to use f-strings, but resort to str.format() and printf-style when I must – whichever is a better fit. Some days I wonder if the grass on the other side is greener and Ruby has a single, clean way to create a formatted string.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 14, 2025, 06:56:58 pm
content: Quote from: RoGeorge on July 14, 2025, 08:53:51 amI've done plenty of such, and in my experience, the language matters less than using a nativetermioslibrary for serial ports instead of some random serial library (libserialetc. are all utter crap) and using a separate thread or subprocess for large bulk data transfers, communicating with the GUI thread or process via suitable messages and UI events.With Python, I do recommend using Qt5 or Qt6 (usingPySide2/PySide6orPyQt5/PyQt6), and writing any bulk data management in C, compiled to and loaded as a dynamic library via Python built-inctypesmodule. I do prefer specifying Qt user interfaces using Qt Widgets (not Qt Quick nor QML) in Qt Widgets Designer (pyside6-designer).uiformat, and instantiating it at run time using QtUiTools module (Qt 5/Qt 6). I do use QtSVG, but not QtSerialPort (I usetermiosinstead), nor do I use any of the Qt Quick modules.QtCharts (Qt 5)andQtGraphs (Qt 6)should make it easy to display any results as graphs (as long as you remember to use the Widget interface and ignore the QML stuff), although for realtime/continuous stuff I'd use OpenGL (Qt 5/Qt 6) to offload the rendering to the GPU (even on Linux ARM SBCs with OpenGL ES support).I haven't used Ruby with GUI toolkits at all, so don't feel comfortable recommending one over the other. All I know is that Python + Qt works extremely well on Linux hosts, even on SBCs with OpenGL ES, for my very similar needs. (I also prefer this way, because then the native code loaded dynamically to that same process can use a proprietary license, and Qt used via LGPL, making low-cost commercial development possible while still allowing end users to meddle (safely) with the UI. It is extremely common for many end user complaints to be handled by suitable small changes to the UI; the hard part is actually finding out the underlying issue, instead of what the end userbelievesthe issue to be.)The exact language used for the UI does not really matter that much, because almost all of the UI is done by the widget toolkit (Qt, FLTK, GTK, WxWindows, etc.), and the handlers/scripted code comprises only a tiny fraction of the total CPU time taken by the application. It is the applicationdesignthat is crucial.The best example of this and its importance I've mentioned before, is when a button press changes some state –– say, a relay, or maybe just a LED light –– on the microcontroller.Typical implementations of the host-side applications decouples the UI button from the actual state on the microcontroller: the button is just a graphical element that triggers a command to be sent to the microcontroller, and that's all. I consider this a fatal design error: the UI should alwaysreflect the state, or it is not as useful to the human users as it could be.Consider, instead, a design where the user pressing the UI button causes the UI button to become depressed, and a corresponding event sent to the microcontroller. The microcontroller does whatever it does, and responds with the related new state. When the UI receives the new state message, it updates the UI button visual state also. This way the user interface reflects the microcontroller state at all times, even between UI button press and UI button release! This isresponsive design.I personally prefer to do this in Python by having two worker threads. One thread is responsible for receiving UI events from the UI thread and sending them as commands to the microcontroller. The other is responsible for receiving microcontroller responses, and sending them as UI events for the UI thread. I prefer to do asynchronous command-responses, with each command and response having a monotonically increasing ID (number), and a shared set of pending commands.If you use Python + Qt + Python or Qt threads, then you can create your own derivative QObject class and use native Qt signals safely across threads for passing events and data between threads (including a worker thread and the UI thread). Just remember that the messages are asynchronous: not "immediately" acted upon, but some time in the near future, usually by another thread, possibly even by another CPU core.

author: brucehoult
author_rank: Super Contributor
timestamp: July 15, 2025, 02:43:13 am
content: Quote from: tggzzz on July 14, 2025, 05:30:09 pmAhahahahahaha. Oh boy oh boy oh boy.,Python doesn't even have a proper specification at all. And things change incompatibly from version to version.I'll give two examples:Code:print "Hello, World!"Normal and valid Python2 code. Needs parens in Python3 (optional in Python2).Code:print(5 / 2)Prints 2 in Python2 (integer floor division), 2.5 (floating point) in Python3. In Python3 you need to write // to get integer division.

author: tggzzz
author_rank: Super Contributor
timestamp: July 15, 2025, 09:40:53 am
content: Quote from: brucehoult on July 15, 2025, 02:43:13 amI was vaguely aware of significant differences between python 2 and 3, but didn't expect them to be that ridiculous! Must be entertaining when your application includes a libraryYet another reason I'll only think of using python for trivial glue applications.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 15, 2025, 11:28:25 am
content: After more looking around about how to make GUIs for Ruby, "Shoes!" seems no longer active, it looks like abandonware.Found something else that looks very nice and easy, also has 30+ videos of GUI examples: Glimmerhttps://github.com/AndyObtiva/glimmerhttps://www.youtube.com/playlist?list=PLSN9HhZ_0-n741vRa_dL-M81cLbqD_kemIf I got it right, Glimmer is only a DSL (Domain-Specific Language) to make GUIs in Ruby, and can be used as a "wrapper language" for various other existing GUI toolkits from this table:https://github.com/AndyObtiva/glimmer?tab=readme-ov-file#glimmer-dsl-comparison-table- SWT for Eclipse looks very well, but to me Eclipse is associated with heavy and slow, also SWT runs in a Java machine and requires jruby instead of ruby.- Tk might not look so good to the eye- LibUI is for C, usable as it is but still in development (mid-alpha, according to its github page)- GTK doesn't look very well on my Kubuntu (KDE/Qt), and I'm not a fan of GTK- vxWidgets is, from what I've heard, a thing of the past and no longer maintainedThe rest of the GUI toolkits from that table are mostly for web.All of these is what I've understood as a newcomer to Ruby, so I might be very wrong.So far I'm tempted to choose LibUI, "Glimmer DSL for LibUI"https://github.com/AndyObtiva/glimmer-dsl-libuibecause it has no other dependencies, but the state of LibUIhttps://github.com/libui-ng/libui-ngas "mid-alpha" sounds deterring to me. Also, all the video examples were made about Glimmer for SWT, which made me think that maybe SWT is the default choice for glimmer.Which one should I chose?-Glimmer DSL for SWTmade for Eclipse and requiring Java, but very well polished and with video tutorials, or-Glimmer DSL for LibUIwriten in C, and making use of the OS's native GUI?Or maybe something entirely else?Any experience with LibUI, is it stable enough?

author: brucehoult
author_rank: Super Contributor
timestamp: July 15, 2025, 12:28:07 pm
content: Quote from: RoGeorge on July 15, 2025, 11:28:25 amhttps://rubygems.org/gems/imgui-bindings/??Simple things are easy. Beautiful things are possible.libUI doesn't seem simpler though, and uses native widgets.

author: tggzzz
author_rank: Super Contributor
timestamp: July 15, 2025, 12:28:31 pm
content: Quote from: RoGeorge on July 15, 2025, 11:28:25 amWhy does it matter what language the IDE is written in? The first Java IDE I used in 1996 (Visual Cafe for Java) was written in C++, and it worked perfectly well. IBM's IDE for Java was written in Smalltalk.I haven't found Eclipse to be heavy and slow.

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 15, 2025, 01:12:01 pm
content: Quote from: tggzzz on July 15, 2025, 09:40:53 amI programmed in Python through the transition and what many of us did was to choose common code that worked under Python 2 or 3. I doubt I spent more that a few percent of my time on that. This strategy kept the code from breaking as often while Python 3 and its libraries were sorted out, until they settled down again around Python 3.5 or 3.6.

author: tggzzz
author_rank: Super Contributor
timestamp: July 15, 2025, 03:20:56 pm
content: Replace "code that worked" with "code where we didn't spot an error"Five or six versions seems an awfully long time and an awful lot of infelicities discovered and removed. But what do I know - fortunately.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 15, 2025, 05:55:21 pm
content: That oneprint "Hello!"without mandatory parentheses was what made me to consider Python as an option, some 10-15 years ago. Another thing that I loved at it, and is no more true was the string. All was ASCII, on byte one character, never needed more. And so on, simple things like these.Eventually, these little details that I loved the most when I stepped into Python for the first time, got removed with time.For moving from Python 2 to 3, at first I've tried to manually port a few of my little scripts, then I've realized that it's a waste of time, so now I am just running them using python 2. Python 2 and 3 can be installed at the same time. I'm grateful Python 2 was kept available all these years.Quote from: brucehoult on July 15, 2025, 12:28:07 pmI've no idea how to use imgui in general, or imguy from Ruby in particular. Searched online for examples/tutorials, and didn't find anything for the imgui ruby binding. While I did slapped a gui once in blue moon, I do not have the basics of GUI programming, so things that may appear trivial/obvious to a programmer, might not be known to me.To give an example, while I was watching today a demo video about Glimmer DSL for SWT, I've noticed the guy was talking about "controller" as if it were some standard concept. No idea what he was talking about. Then later he said something about MVC, which I didn't know what it means, searched the acronym and found for the very first time about the Model–view–controllerhttps://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controllerIt's funny because I was (kind of) using that style anyway, while cobbling GUIs for my scripts, though now, that the MVC concept was highlighted, many GUI related aspects suddenly started to make a lot more sense. MVC was like a little epiphany for me this afternoon.Another thing that I've just realized today, the only constant presence on my desktop PC, across many decades and across many OSs, was the spreadsheet. There was always an Office package installed. At first it was Microsoft Office, then after I've ditched Windows, it was Libre Office.The Office package always has had a GUI toolkit and a scripting language. Right now, LibreOffice supports 4 languages:LibreOffice BasicJavaScriptBeanShellPythonhttps://help.libreoffice.org/latest/en-US/text/shared/guide/scripting.htmlFrom the scripts I constantly use with LibreOffice Calc (though very small scripts, and no GUI is involved), they always worked with zero maintenance, so I guess the LibreOffice API pays a special attention when it comes to backward compatibility.Maybe I should just use the LibreOffice API, instead of yet another GUI toolkit.Any good reason why not to?

author: brucehoult
author_rank: Super Contributor
timestamp: July 16, 2025, 03:23:36 am
content: Quote from: RoGeorge on July 15, 2025, 05:55:21 pmRemoving that is really a terrible decision for a "scripting" language.Code:Mac-mini:~ bruce$ ruby -e 'name="Bruce";print "hello ",name,"\n"'hello BruceMac-mini:~ bruce$ perl -e '$name="Bruce";print "hello ",$name,"\n"'hello BruceQuoteAs noted on Wikipedia, has been around since Smalltalk in the 1970s. Lisa and Macintosh code was using this concept in the early 1980s.Heck, you don't even need a bitmapped display ... it applies equally to any interactive program that manipulates complex data, even if using a keyboard and a text terminal.QuoteI've never used Windows but kept using Mac Word 5.1a and Excel 4 (both released in 1992, and M68000 code) for many many years. You could run them "natively" (in the built-in "Classic" 68k emulator) on PowerPC Macs (the last ones were released in October 2005) as long as you didn't upgrade past OSX Tiger to Leopard (released late 2007). You can still run them in an emulator such as SheepShaver today.And they still do everything I need in an office app.But I've never really used Open Office or Libre Office. Google sheets was released in 2006. I guess I didn't use it right away, but I just checked and I have spreadsheets going back to 2014 on Google Sheets. It gets the job done, and the great thing about Sheets is that you can use it on any computer anyway, or your phone or tablet, etc.I've had also zero need for a full word processor since Markdown was released in 2005 or so. The one real exception is my CV. Looking at my archive of job applications, until 2012 my CV is a .doc but from 2013 it's a .pages

author: Picuino
author_rank: Super Contributor
timestamp: July 16, 2025, 08:09:24 am
content: Thinking ahead, Python is well maintained right now and will be for many years to come.In the case of Ruby, it is a language that is declining in favor of Python and it is not so clear that as many new libraries will be made as are made in Python.It is similar to Perl, a scripting language widely used years ago, which will still be used many more, but is now in decline and many developers prefer to start new projects with Python.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 16, 2025, 10:23:17 am
content: Tried yesterday a few GUI examples with glimmer-dsl-libui. Seems more than enough to made a GUI for a microcontroller data logger, or to automate some measurements by controlling SCPI capable lab instruments. I can switch later to some other GUI lib if needed, Glimmer makes them all look similar. Not identical, but close enough.Unfortunately there is no Glimmer with Qt. There are some other Qt wrappers for Ruby, but the resulting syntax is closer to Qt than to Ruby. To me, Qt looks great visually, yet it looks horrible in code. Also, the Qt documentation (for me) is very hard to follow, tons of details and links to get you lost in some obscure corner, about details you'll probably never need.Now, all I need is to learn Ruby, then learn how to program. See you guys in 10 years!Searched about learning Ruby, found many books and online tutorials, etc. Also found this video, which was very valuable to me, because it tells how classes in Ruby are not "blueprints" to instantiate future object. Ruby classes are in fact objects. In Ruby, classes can be executed just like an object. And by knowing how 'self' changes while navigating the objects hierarchy, all the classes and objects (surprising) behaviors suddenly become clear.The Ruby Object Model by Dave ThomasSzymon Madejahttps://youtu.be/X2sgQ38UDVY(it's a 1 hour long video, but with very easy to follow examples, so it can be watched at x2-x3 playback speed)Aside from that, when searching about Ruby, Smalltalk is mentioned uncannily often.I don't reacall that happening while I was learning Python, for example.Do I need to learn Smalltalk before Ruby?If not, should I learn Smalltalk anyway?

author: brucehoult
author_rank: Super Contributor
timestamp: July 16, 2025, 11:47:25 am
content: Smalltalk is primarily used in an all-inclusive graphical IDE e.g. Squeak, but there is GNU SMalltalk (gst) if you want to to scripting / command-line style things.https://people.eecs.berkeley.edu/~fateman/264/papers/smalltalk-tutorial.htmlhttps://www.gnu.org/software/smalltalk/manual/gst.htmlMaybe that can be interesting, but I think enough of the Smalltalk ideas have made it into Ruby and Objective C to just use them there.ObjC is a very practical language in that you have the Smalltalk stuff for highly dynamic stuff for user interaction (whether command line or GUI) but at the same time you have the full power of C / C++ for things that need performance. ObjC is the secret behind the NeXT workstation (a number of things including the first web server and browser were developed there because it is very quick for software development), MacOS X and iOS. Even today InterfaceBuilder is one of the most powrful and fastest ways to build UIs.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 20, 2025, 03:44:47 pm
content: Looked at a few Ruby learning resources last week. The same range of books and tutorials always pop in the first page of any search result, yet I've found them not that useful. Dunno if I'm in some search bubble.Browsed already a few "classical" Ruby resources, and they were not what I was expecting them to be:-https://poignant.guide/too childish, nice as entertaining/art or as a philosophical reflection, but it only makes sense if one already knows Ruby, so you won't learn that much Ruby from it, though a very entertaining fantasy-novel/comics read- the POODR book, way too verbose, I don't really need 2 pages of text to explain me how the bicycle gears work, also I'm not in the agile cult and such, also, that bicycle was tediously hammered back and forth throughout the entire book, a nope for me, too verbose- found a very promising one, seems very interesting: "Ruby Under a Microscope", by Pat Shaughnessy. Browsed it yesterday, but didn't start reading more into it (at first they are all promising). This book assumes one is already familiar with Ruby (which I'm not so much yet), so I'm not very sure if that would be a good read for me.All the Ruby learning resources tried so far were to me not exactly what I was expecting.I did program before, so don't need an entire chapter book about variables. Though, I would appreciate a brief bullet points list, so to notice if there is anything new/different about Ruby variables. And so on, similar for all the rest of the Ruby language and concepts. Not pretending to be a programmer, but I did programmed before (hobby level) in many languages over the last 30+ years or so.In this spirit, any recommended learning resources for Ruby (books/videos/tutorials/whatever, or maybe should I just read thehttps://ruby-doc.org/)?So far I like Ruby a lot!What to read, what exercises to do, to come up to speed with the Ruby language? Asking about learning Ruby with the purpose of writing small hobby projects at home, so I can automate my lab instruments and Arduinos and such, tools around the home lab written and maintained by a single guy.Not planing to become a programmer in some multinational corporation, thought I would VERY MUCH like for my Ruby programs to last as many years as possible, and to be backwards compatible along time, and across various Linux distributions.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 20, 2025, 08:22:38 pm
content: Quote from: tggzzz on July 15, 2025, 09:40:53 amThose examples are honestly pretty silly. They are both easily worked around and had essentially perfect compatibly options. That is, the change was a simply find an replace you could opt-in to the new syntax in python 2 on a per file basis, and you code would be compatible with both. They both look major since they are so ubiquitous but in practice were non-issues.Don't get me wrong, Python 2->3 transition was a major debacle and basically resulted in a lost decade. There is universal agreement among the python developers that it should have been done differently. Specifically that they should have found a way to allow python 2 and 3 to coexist at runtime. Removing the print statement and fixing the broken division operator were relatively minor.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 24, 2025, 10:51:05 am
content: The more I learn Ruby, the less I understand how come that Python became the most popular choice, and not Ruby.Found a learning Ruby book that seems just right:Programming Ruby 3.3 (5th Edition) - The Pragmatic Programmers' Guide - by Noel Rappin, with Dave Thomashttps://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-edition/(AKA the pickaxe book)Funny thing, remember theHAL 9000 computerfrom the "2001: A Space Odyssey"? Do you know what was the successor of HAL? Use the Ruby successor method 'succ' to find out:Code:$ irbirb(main):001> ["H", "A", "L"].each { |x| puts x.succ }IBM=> ["H", "A", "L"]irb(main):002>

author: brucehoult
author_rank: Super Contributor
timestamp: July 24, 2025, 11:10:34 am
content: Quote from: RoGeorge on July 24, 2025, 10:51:05 amYeah I've been wondering that at least since I did some coding in both Ruby and Python for different tasks at a job in 2004.Also...Code:"HAL".each_char { |x| puts x.succ }IBM=> "HAL"orCode:"HAL".chars.map { |x| x.succ }=> ["I", "B", "M"]orCode:"HAL".chars.map { |x| x.succ }.join()=> "IBM"

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 24, 2025, 01:58:00 pm
content: Code:>>> ''.join(chr(ord(c)+1) for c in 'HAL')'IBM'?

author: RoGeorge
author_rank: Super Contributor
timestamp: July 24, 2025, 03:27:36 pm
content: That was just an example from that Ruby book. Unrelated with the previous remarks about Python, sorry for not stating that. My previous post was mainly to write down the book title/authors, so I can found later which one was that book I liked.As for the IBM as the successor of HAL, that was a funny numerical coincidence to me, between the famous HAL computer from a SF novel written in 1968, and the famous IBM PC standard after which every computer in the world was made, from 1980 to today, so I thought I might put that piece of code as an entertaining coincidence.

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 24, 2025, 04:06:46 pm
content: Quote from: RoGeorge on July 24, 2025, 03:27:36 pmNo problem. I just thought you might like to see what you might be leaving behind, going to Ruby. It appears you have found your language.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 24, 2025, 06:24:51 pm
content: Quote from: RoGeorge on July 24, 2025, 10:51:05 amWhen I was first learning python around 2006 it had by far the most comprehensive and usable online documentation for both the language and the standard library as well as the most capable standard library. Honestly that's the only reason you need, but there were others. Python had ctypes which gave a relatively easy way to interface with native C libraries without needing to write native language wrapper code. This was huge for me personally since I was doing a lot of stuff with proprietary data acquisition hardware and the vendors would provide C DLLs. I was proficient with C, but the ability to just import a DLL and start calling functions was huge. I think ruby offers this now, but it didn't back then. It also meant I could write my own DLL in C and just call it from python without having to learn the CPython API. And finally python had a well supported windows port at a time when windows users had basically no other good options. I worked at a cross platform CAD tool company in 1999-2000. I was using perl for scripting at the time, but the windows developers were really excited about python because it was more usable on windows than perl. Ruby wasn't even a consideration at the time.In short, python solved a lot of actual problems people had, while Ruby honestly didn't really have anything special to offer except for Rails. It might have better design, but no killer features. So much so that a lot of people including myself heard about RoR before realizing that Ruby was actually a stand alone language. And by the time Ruby on Rails was getting popular for web service development python was already well established as the de-facto standard systems scripting language and data processing language.

author: shapirus
author_rank: Super Contributor
timestamp: July 24, 2025, 10:57:16 pm
content: Quote from: ejeffrey on July 24, 2025, 06:24:51 pmWhile I don't have any hard numbers, I'd say that I'm pretty sure that Perl was way ahead of Python in this regard at that time.

author: brucehoult
author_rank: Super Contributor
timestamp: July 25, 2025, 12:47:39 am
content: Quote from: RoGeorge on July 24, 2025, 03:27:36 pmNo coincidence, IBM started selling electronic computers in 1952 (their first product was a clock for stamping worker's time cards in 1911) and they dominated mainframe sales after the introduction of the IBM System/360 in 1964. It was of course very well known to A C Clarke and the word-play was deliberate.As for "every computer in the world" I was using Apple microcomputers before IBM entered that market, and am typing this on an Apple computer (with many others between). None of them have ever been "IBM PC" compatible.

author: tggzzz
author_rank: Super Contributor
timestamp: July 25, 2025, 12:54:40 am
content: Quote from: brucehoult on July 25, 2025, 12:47:39 amClarke repeatedly denied that.

author: brucehoult
author_rank: Super Contributor
timestamp: July 25, 2025, 02:04:48 am
content: Quote from: tggzzz on July 25, 2025, 12:54:40 amRegardless, he certainly had the knowledge required to do it deliberately, whether he actually did or not. The point is that IBM didn't suddenly appear from nowhere a dozen years later in 1981. They were already extremely famous. Even in the 1960s people at rival companies were saying "IBM isn't the competition, it's the environment". Not to mention the ad DG commissioned but never ran "They Say IBM's Entry Into Minicomputers Will Legitimize The Market. The Bastards Say, Welcome" (it was framed on the wall of de Castro's office in the mid 70s)

author: ejeffrey
author_rank: Super Contributor
timestamp: July 25, 2025, 02:49:45 am
content: Quote from: shapirus on July 24, 2025, 10:57:16 pmThe documentation is debatable the standard library is certainly not. Perl of course was very well established in the 90s, and it had tons of documentation in the form of books written about Perl and also books about using Perl for certain applications from databases to CGIs to bioinformatics. But as someone who used Perl in the late 90s and early 2000s, and then moved to python in the mid 2000s, the quality of the online references was a major improvement over Perl.The standard library wasn't even close. CPAN existed of course, but the Perl standard library itself was extremely weak in comparison. This was another factor in the documentation advantage. With python, the extensive standard library was documented right along side the core language with the same style and crosslinking. 3rd party tutorials would all typically use and reference the standard library implementations as well. In contrast, three different Perl tutorials on any topic would pick three different sets of CPAN modules.There were a lot of other problems with Perl in the early 2000s that made room for python's ascendency. It was OK for what it had been used for in in the 90s, but it had a number of serious limitations. And all those limitations were basically tied up in a bow with the disaster that was perl6. The perl6 effort makes the python 2->3 transition look like a smooth well oiled machine. I've never looked at perl6 since it was actually "released" to see if it's any good, but if it came out in 2002 and was any good there is a chance that python would have never caught on.

author: brucehoult
author_rank: Super Contributor
timestamp: July 25, 2025, 02:58:01 am
content: Perl6 does not exist. That was a weird project, run I'd say by zealots , making not anything particularly similar or compatible to Perl5 at all, but essentially a completely different language, which is now called "Raku" and no one uses it.In 2025 if someone says "Perl" they mean Perl5. including Wall, seehttps://en.wikipedia.org/wiki/Second-system_effect

author: shapirus
author_rank: Super Contributor
timestamp: July 25, 2025, 07:30:11 am
content: Quote from: ejeffrey on July 25, 2025, 02:49:45 amWhat are you referring to as "standard library"? I'd say it's this one:Code:POSIX(3perl) Perl Programmers Reference Guide POSIX(3perl)NAMEPOSIX - Perl interface to IEEE Std 1003.1This has pretty much everything. It has existed for ages. This is not to mention other modules included in the standard distribution (even before we start talking about CPAN).Quote from: ejeffrey on July 25, 2025, 02:49:45 amWell, that can be viewed as an advantage just as well. "There's more than one way to do it" is the Perl's motto, which, I believe, is the opposite of the Python's approach, which is to do what you're told to, and any other way is considered being next to heretical.Speaking of documentation as such, Perl itself and vast majority of the modules (save for a a number of oddball things on CPAN written by random folks often as one-off unmaintained pieces of code) are extremely well documented, and have always been as far as my recollection goes, which is back to about 2000. There are detailed man (and/or perldoc) pages on everything, which of course include references to other pages.Quote from: ejeffrey on July 25, 2025, 02:49:45 amPerl6 is a joke. As was already said in a post above, it's not a development of Perl5, but really a completely different language that nobody really asked for and so it's hardly used today or receives any general public interest.Perl5 had other issues of course. I think it was, to summarize, its failure to adapt well in the world of the changing Web, in all respects, from the ease of implementing server-side apps (compare that with PHP) or presenting itself and its documentation and everything in the new online fashion expected by the young generation. The CPAN (or metacpan, whatever) website, for example, still looks like a '90-s relic today, which is good: it's lightweight and functional, but it doesn't catch the eye of the TikTok generation. That plays a role, even if not a decisive one, but add up everything like that, and you have the result we see today.

author: tggzzz
author_rank: Super Contributor
timestamp: July 25, 2025, 08:34:20 am
content: Quote from: brucehoult on July 25, 2025, 02:04:48 amI presume you and I had the knowledge to kill out parents/siblings, but that doesn't mean we did it!Having read "The Lost Worlds of 2001" many times, this wackypedia article is correct (and saved me from having to dig out the passage in the book)...HAL's name, according to Clarke, is derived from Heuristically programmed ALgorithmic computer. After the film was released, fans noticed HAL was a one-letter shift from the name IBM and there has been much speculation since then that this was a dig at the large computer company, something that both Clarke and Kubrick denied. Clarke addressed the issue in The Lost Worlds of 2001:...about once a week some character spots the fact that HAL is one letter ahead of IBM, and promptly assumes that Stanley and I were taking a crack at the estimable institution ... As it happened, IBM had given us a good deal of help, so we were quite embarrassed by this, and would have changed the name had we spotted the coincidence.QuoteJust so. I remember it well.Irritating how youngsters confidently misstate history

author: ejeffrey
author_rank: Super Contributor
timestamp: July 25, 2025, 05:54:26 pm
content: Quote from: shapirus on July 25, 2025, 07:30:11 amHuh? No of course not. I mean the Python standard library (https://docs.python.org/3/library/index.html) vs the Perl standard library (https://perldoc.perl.org/modules#Standard-Modules). Not just the interface to POSIX/C, which was an important but rather small part of both languages.QuoteI am explicitly saying that Python's online (web) documentation circa 2005 was *vastly* superior to perldoc / man, especially from a new user point of view. It was tremendously more discoverable, easily referenced from external links like blog posts, and by virtue of the much more comprehensive standard library, actually contained far more actual information that helped users figure out how to do what they needed.QuoteI would argue that a lot of people *did* want many of the features that were promised to be part of perl 6. Like actual subroutine parameters and usable classes / objects, and getting rid of the dumb sigil system. They just found them in python while perl 6 remained vaporware and perl 5 languished. I never looked closely at the actual design of perl 6, so I don't know if it actually could have delivered on what it promised, but the limitations in perl5 were/are real.So in the original question of "why in the mid 2000s did python become the dominant scripting language instead of Ruby", I don't even consider perl 5 a serious contender. It was just not suited for the purposes people used either of those platforms for.

author: brucehoult
author_rank: Super Contributor
timestamp: July 26, 2025, 12:33:53 am
content: Quote from: ejeffrey on July 25, 2025, 05:54:26 pmIt's not intended to be.Perl is an alternative to shell scripts, sed, and awk improving on each of them, and the combination. Ruby can play in that space too.Python is more like a slower but less verbose Java.

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 26, 2025, 08:18:04 am
content: Quote from: brucehoult on July 26, 2025, 12:33:53 am... Or a slower but less verbose C, or something like an interpreted Lisp with infix notation and no macros.I think a big reason Python 2 caught on was that it is similar to and accepting enough of many different languages – enough so, that you could start by treating it as a dialect of languages you already knew and then gradually adopt succinct, characteristic Python. My early Python code could almost have been C without the semicolons and curly braces, in fact, such code is one way to write and test C.

author: DiTBho
author_rank: Super Contributor
timestamp: July 26, 2025, 11:44:14 am
content: Python is problem #1 in GentooWhen it breaks, and too often it does, everything collapses.Also, being Gentoo/OpenRC based on python booting scripts ... Is toooooooooo slow on my PowerBook G3 (ppc750@400Mhz), and even slower on my japanese PDA (pxa270@400Mhz) and router (mip32r2@400Mhz)Replaced with C stuff I wrote myself5x faster on booting, 12x faster on emergency shutdown

author: jfiresto
author_rank: Frequent Contributor
timestamp: July 26, 2025, 11:51:17 am
content: Quote from: DiTBho on July 26, 2025, 11:44:14 amOut of curiosity, what version(s) of Python?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2025, 02:19:23 pm
content: Quote from: DiTBho on July 26, 2025, 11:44:14 amHaven't looked at Gentoo in a longgg time, didn't know they used Python scripting for booting. Ouch.

author: DiTBho
author_rank: Super Contributor
timestamp: July 26, 2025, 02:49:51 pm
content: Quote from: SiliconWizard on July 26, 2025, 02:19:23 pmThey did! During the early OpenRC era (2005-2009).Now OpenRC is fully written in C and POSIX-compliant shell, making it usable on BSD and Linux systems.However, the core part of OpenRC was weak, it's the part that handles the dependency management and the init script parsing.This stuff works by scanning the runlevels, building a dependency graph, then starting the needed service scripts.So, for that stuff, Python was mainly used for as dependency solver at run-time, re-using part of the code already used for "emerge".Dunno what next, at some point they introduced "runscript", then "openrc-run", and then "systemD" as option.All things for which it was not always easy or possible to compile.So I used the old system, before replacing it completely with my own stuff.

author: DiTBho
author_rank: Super Contributor
timestamp: July 26, 2025, 02:56:36 pm
content: Quote from: jfiresto on July 26, 2025, 11:51:17 amBetween v2.6 and v3.1, included.Lot of troubles on PPC, HPPA and MIPS.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2025, 03:03:34 pm
content: Given that those scripts likely do not require the full and very rich ecosystem of Python and probably do just basic scripting, they should just have used Lua instead.Lua is great, simple, veryyy fast, and I dare you to find a platform on which it doesn't build.

author: peter-h
author_rank: Super Contributor
timestamp: July 28, 2025, 07:44:42 pm
content: Ruby seems dead now.15+ years ago it was all the rage.I "run" a few websites. One was written in Ruby on Rails, and by a real expert, and despite being attacked 10-100x per second, has not AFAIK been penetrated or damaged. But I cannot get anybody to do any work on it, below about £1500/day. Another is PHP because (after the Ruby dead-end experience) I specced it thus and there are no problems at all with it; it also withstands attacks just fine (the dev knew about SQL injection, XSS, etc). Both of these are fronted by Cloudflare for free https certs and in case of DOS attacks. Another is just HTML, gets attacked constantly but no penetration but it has no "language"; it is just HTML done in Dreamweaver, NGINX running on Centos, and also fronted by Cloudflare.I think Ruby being such a dead end for server side work is not helped by the fact that most people working in that area get to hate their job by the time they get to about 40and are really keen to get out of it.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: October 16, 2025, 06:36:17 am
content: I understand and also share some of your sentiment towards Python, but in a different way. That python V2 had a weird print statement that did not follow normal function syntax was one of the many abominations, and that has luckily been fixed.But python's whitespace formatting dependency is still one of it's biggest horrors. The way that python 3 was made incompatible with python V2 was also a 10 years lasting horror show. There were some ways that V2 libraries could be used with V3 but it was not implemented very well. Another thing that I don't like in python is that it just invents a new variable when you make a simple typo. Having to declare variables is a bit of a nuisance, but not detecting typo's in variable names is much worse. I dislike python for very similar reasons I never liked basic. Those are scripting languages designed to "quickly cobble things together" and not really meant nor suitable for bigger programs. MeldMerge is for example written in Python (and a quite nice program) but it suffers enormously from the slowness of python. When I was interested in Python I looked at the source of MeldMerge and even hunted down a bug. The bug was missing whitespace so one line of code was not included in a loop, but it was executed only once after the loop ended. Now try to format a diff for that.But despite that. python has become pretty much the standard scripting language, and it's "workable". It's used in KiCad, FreeCAD, Pulseview (slow protocol decoders). In comparison, I have not heard anything about Ruby in years. If you find it easy to learn a new language, and get to know all the libraries for that language, then you can use nearly anything. But if you want to limit the amount of programming languages you know and want to use, then using python for "all the scripting stuff" would be a logical choice.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: October 16, 2025, 06:59:26 am
content: Quote from: RoGeorge on July 14, 2025, 08:53:51 amI managed to see a few minutes of that. He's grossly exaggerating C syntax "ugliness", and is also a proponent of "messy programming", because "humans are messy". I'm a messy human too, and I like a clear syntax such as using parenthesis for functions. Apart from a "print" I also saw a "puts" in an example. This triggers a memory on one of the other (and similar) horrors in python. I once was writing on a pretty generic class for some basic low level management, and it turned out that all the variable names I wanted to use were already interpreted by python as keywords.From what I see, ruby and python are pretty much on the same level of ad-hoc messyness. In ruby you also don't have to declare variables.When starting to program with python I wrote a simple loop to add things to a list. But the program did not work. It turns out that you can't add to an non existing list, so you have to declare an empty list before you start your loop. It's just one of the many inconsistencies in python.When I was young, 35+ years ago, I disliked basic. The first program I bought was Turbo C++. I did have some difficulty with the syntax in the beginning, but I always (and still to) liked the straightforwardness of C syntax. Sure, C (and C++) has it's complexities hornets nests and dragons too, but I find those more understandable and comprehensible. Maybe that is partly because I learned those languages when I was still young, but back then I disliked basic too.

author: brucehoult
author_rank: Super Contributor
timestamp: October 16, 2025, 07:02:27 am
content: Quote from: Doctorandus_P on October 16, 2025, 06:36:17 amBelieve it or not, but JavaScript avoids all the problems you mention, if you put "use strict" at the start of the program.- it won't let you assign to an undeclared variable. (None of these languages let you *use* an undefined variable, unlike Perl, which needs "use strict" even for that)- uses a C/Java-like syntax, not whitespace dependent- has as huge a library of modules as Python- in modern nodejs runs at a similar speed to Java / C# or C++ with -O0, much much faster than Python

author: Picuino
author_rank: Super Contributor
timestamp: October 16, 2025, 07:51:05 am
content: One of the major problems I encounter in this type of PC application is creating a graphical interface that is easy to program. The old VisualBasic or Delphi/Pascal were very good at that. Python and Ruby do not have simple tools for creating graphical interfaces.

author: brucehoult
author_rank: Super Contributor
timestamp: October 16, 2025, 08:15:41 am
content: Quote from: Picuino on October 16, 2025, 07:51:05 amFunnily enough, JavaScript has a shit ton of libraries for that, if you have a web browser. (And all modern OSes allow you to embed an HTML pane inside an app window)

author: Picuino
author_rank: Super Contributor
timestamp: October 18, 2025 11:05:56 am
content: JavaScript has many libraries and frameworks for creating GUIs. Which one do you recommend for interacting with microcontrollers? It should be easy to use and powerful enough to create graphs or lists with the microcontroller's output data.Edit: Alpine.js and Chart.js together to provide full functionality?