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

[jfiresto]

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

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

[tggzzz]

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.

[RoGeorge]

That one print "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.

https://rubygems.org/gems/imgui-bindings/
Simple things are easy.
...

I'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–controller https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller 

It'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 Basic
    JavaScript
    BeanShell
    Python
https://help.libreoffice.org/latest/en-US/text/shared/guide/scripting.html
From 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?

[brucehoult]

That one print "Hello!" without mandatory parentheses was what made me to consider Python as an option, some 10-15 years ago.

Removing that is really a terrible decision for a "scripting" language.

Code: [Select]

Mac-mini:~ bruce$ ruby -e 'name="Bruce";print "hello ",name,"\n"'
hello Bruce
Mac-mini:~ bruce$ perl -e '$name="Bruce";print "hello ",$name,"\n"'
hello Bruce


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

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

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.

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

[Picuino]

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.

[RoGeorge]

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 Thomas
Szymon Madeja
https://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? 

[brucehoult]

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

https://www.gnu.org/software/smalltalk/manual/gst.html

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

[RoGeorge]

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 the https://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. 

[ejeffrey]

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

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

[RoGeorge]

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 Thomas
https://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-edition/
(AKA the pickaxe book)

Funny thing, remember the HAL 9000 computer from the "2001: A Space Odyssey"?  Do you know what was the successor of HAL?  Use the Ruby successor method 'succ' to find out:

Code: [Select]

$ irb
irb(main):001> ["H", "A", "L"].each { |x| puts x.succ }
I
B
M
=> ["H", "A", "L"]
irb(main):002>

 

[brucehoult]

The more I learn Ruby, the less I understand how come that Python became the most popular choice, and not Ruby. 

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

"HAL".each_char { |x| puts x.succ }
I
B
M
=> "HAL"

or

Code: [Select]

"HAL".chars.map { |x| x.succ }
=> ["I", "B", "M"]

or

Code: [Select]

"HAL".chars.map { |x| x.succ }.join()
=> "IBM"


[jfiresto]

Code: [Select]

>>> ''.join(chr(ord(c)+1)  for c in 'HAL')
'IBM'
?

[RoGeorge]

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. 

[jfiresto]

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

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

[ejeffrey]

The more I learn Ruby, the less I understand how come that Python became the most popular choice, and not Ruby. 

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

[shapirus]

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

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

[brucehoult]

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. 

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

[tggzzz]

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. 

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

Clarke repeatedly denied that.

[brucehoult]

Clarke repeatedly denied that.

Regardless, 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)

[ejeffrey]

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

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

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

[brucehoult]

Perl6 does not exist. That was a weird project, run I'd say by zealots [1], 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.

[1] including Wall, see https://en.wikipedia.org/wiki/Second-system_effect

[shapirus]

The standard library wasn't even close.  CPAN existed of course, but the Perl standard library itself was extremely weak in comparison.

What are you referring to as "standard library"? I'd say it's this one:

Code: [Select]

POSIX(3perl)                        Perl Programmers Reference Guide                        POSIX(3perl)

NAME
       POSIX - Perl interface to IEEE Std 1003.1
This 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).

  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.

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

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.

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

[tggzzz]

Clarke repeatedly denied that.

Regardless, he certainly had the knowledge required to do it deliberately, whether he actually did or not.

I 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.[7][27][1] 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,[28][29] something that both Clarke[27] and Kubrick denied.[1] Clarke addressed the issue in The Lost Worlds of 2001:[7]

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

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)

Just so. I remember it well.

Irritating how youngsters confidently misstate history

[ejeffrey]

The standard library wasn't even close.  CPAN existed of course, but the Perl standard library itself was extremely weak in comparison.

What are you referring to as "standard library"? I'd say it's this one:

Code: [Select]

POSIX(3perl)                        Perl Programmers Reference Guide                        POSIX(3perl)
NAME
       POSIX - Perl interface to IEEE Std 1003.1


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

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.

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

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

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

[brucehoult]

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.

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