Ruby instead of Python? (for the PC side of MCU boards and lab tools)

[RoGeorge]

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 #474
Lex Fridman
https://youtu.be/vagyIcmIGOQ?t=2513

It 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?

[brucehoult]

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.

[tggzzz]

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.

When 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.

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.

That's the sole reason I would use Python.

Clearly the designer had never had to create/read/modify a makefile where the type of whitespace (tabs vs spaces) has different semantics. Any language where the number of spaces has semantic significance is going to cause interesting and easily missed bugs when code is copied/pasted e.g. during refactoring.

[DiTBho]

and .. AI stuff is 90% for Python

[jfiresto]

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.

[shapirus]

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.

My 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.

[tggzzz]

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 support
• computer 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 language
• potential employees are reluctant to commit themselves to learning non-transferable skills

DSLibraries have some of those drawbacks, but not to the same extent.

[tggzzz]

... but I can't understand how one can take a language that doesn't even have basic things like ternary operator seriously.

I 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"

[jfiresto]

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!

[jfiresto]

The question that arises is what can a Domain Specific Language achieve that a Domain Specific Library cannot?

I observe DSLanguages: [have a list of drawbacks]

DSLibraries have some of those drawbacks, but not to the same extent.

Python'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 latest t-strings they are suggesting for DSLs.

[tggzzz]

The question that arises is what can a Domain Specific Language achieve that a Domain Specific Library cannot?

I observe DSLanguages: [have a list of drawbacks]

DSLibraries have some of those drawbacks, but not to the same extent.

Python'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 latest t-strings they are suggesting for DSLs.

Oooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified language

The C++ committee refused to believe that a valid conforming C++ program cannot 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).

[brucehoult]

The question that arises is what can a Domain Specific Language achieve that a Domain Specific Library cannot?

I observe DSLanguages: [have a list of drawbacks]

DSLibraries have some of those drawbacks, but not to the same extent.

Python'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 latest t-strings they are suggesting for DSLs.

Oooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified language

The C++ committee refused to believe that a valid conforming C++ program cannot 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).

I 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 an infinite loop? 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.

[thephil]

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.

[jfiresto]

Oooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified language

I 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.)

[brucehoult]

(I actually have a lot of respect for TECO considering what people then had to work with.)

People who think TECO is bad have obviously never used its mutant clone "speed" on AOS or AOS/VS.

[jfiresto]

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.

[tggzzz]

The question that arises is what can a Domain Specific Language achieve that a Domain Specific Library cannot?

I observe DSLanguages: [have a list of drawbacks]

DSLibraries have some of those drawbacks, but not to the same extent.

Python'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 latest t-strings they are suggesting for DSLs.

Oooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified language

The C++ committee refused to believe that a valid conforming C++ program cannot 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).

I 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 an infinite loop? 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.

Yes, everything can be abused[1] - 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 experts did not understand what created - and refused to believe what 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 language experts did not understand.

I hope the Python language designers understand and follow Tony Hoare's principles.

[1] and probably will be due to PEBCAK

[tggzzz]

Oooh goodie. Python becomes as incomprehensible as C++, and every wannabe language designer can create their own poorly specified language

I 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.)

Is 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

[jfiresto]

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 printing n=3:

Code: [Select]

>>> 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 [see EDIT below]. 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.

EDIT: Sorry, I was wrong. You can also specify precision in an f-string with a nested {expression}, as in

Code: [Select]

>>> value = 2/3.
>>> sigfigs = 3
>>> f'{value:.{sigfigs}}'
'0.667'

I needed that for something, just tried that, and it worked. 

[Nominal Animal]

My main use case is [...] 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 done plenty of such, and in my experience, the language matters less than using a native termios library for serial ports instead of some random serial library (libserial etc. 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 (using PySide2/PySide6 or PyQt5/PyQt6), and writing any bulk data management in C, compiled to and loaded as a dynamic library via Python built-in ctypes module.  I do prefer specifying Qt user interfaces using Qt Widgets (not Qt Quick nor QML) in Qt Widgets Designer (pyside6-designer) .ui format, and instantiating it at run time using QtUiTools module (Qt 5/Qt 6).  I do use QtSVG, but not QtSerialPort (I use termios instead), nor do I use any of the Qt Quick modules.
QtCharts (Qt 5) and QtGraphs (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 user believes the 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 application design that 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 always reflect 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 is responsive 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.

[brucehoult]

I hope the Python language designers understand and follow Tony Hoare's principles.

Ahahahahahaha. 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: [Select]

print "Hello, World!"

Normal and valid Python2 code. Needs parens in Python3 (optional in Python2).

Code: [Select]

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.

[tggzzz]

I hope the Python language designers understand and follow Tony Hoare's principles.

Ahahahahahaha. 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: [Select]

print "Hello, World!"

Normal and valid Python2 code. Needs parens in Python3 (optional in Python2).

Code: [Select]

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.

I 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 library

Yet another reason I'll only think of using python for trivial glue applications.

[RoGeorge]

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:  Glimmer
https://github.com/AndyObtiva/glimmer
https://www.youtube.com/playlist?list=PLSN9HhZ_0-n741vRa_dL-M81cLbqD_kem

If 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 maintained
The 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-libui because it has no other dependencies, but the state of LibUI https://github.com/libui-ng/libui-ng as "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 SWT made for Eclipse and requiring Java, but very well polished and with video tutorials, or
  - Glimmer DSL for LibUI writen in C, and making use of the OS's native GUI?
Or maybe something entirely else?

Any experience with LibUI, is it stable enough?

[brucehoult]

After more looking around about how to make GUIs for Ruby, "Shoes!" seems no longer active, it looks like abandonware. 

https://rubygems.org/gems/imgui-bindings/

??

Simple things are easy. Beautiful things are possible.

libUI doesn't seem simpler though, and uses native widgets.

[tggzzz]

- 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.

Why 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.