DSLs for LibUI in README #58
Replies: 4 comments 3 replies
-
Sorry, but in light of my years of experience as an amateur programmer, I have a different opinion than you.
Running Ruby programs on Windows is not much fun. I used to use Tk and Ocra to program for Windows. I had some trouble at that time and came up with that idea. I believe that when programming on Windows, I should reduce dependencies as much as possible and keep things simple. |
Beta Was this translation helpful? Give feedback.
-
Right, but amateur experience is obviously inferior to professional experience, and my target is professionals that build big impressive apps not amateurs building toy apps. Amateurs often fail due to their lack of skill regardless of what you provide them. I wouldn't worry about amateurs. Their job is to improve their skills and become as skilled as pros before their concerns have any importance because once they become pros with their skill-level their amateur-level concerns are resolved automatically. Also, nothing of what you said invalidates what I said, but what I said does invalidate what you said. |
Beta Was this translation helpful? Give feedback.
-
One Rubyist I admire is Lars Kanis, who maintains RubyInstaller for Windows. Until he resolves windows issues, Ruby for Windows will not be released, and I feel that Ruby for Windows is built on the contributions of great individuals. Almost all Ruby tools are like that. There are many packages that are available in Homebrew and Apt but not in Mingw. So there are many Ruby libraries that don't work as expected on Windows, and I think the difficulty of creating tools for Windows in the Ruby language is considerable. If I were to professionally create software for Windows, I wouldn't be using Ruby in the first place. If you want to claim that LibUI's Glimmer DSL supports Windows packaging on a professional level, that's fine, but to be honest, I'm skeptical. Because it would take a lot of work to keep it going. Many people give up in the middle of the way. (I just wrote that we are in the middle of the way, but in reality, the way does not end, it goes on forever.) I am no exception. GR.rb recently gave up updating the Mingw package for Windows. Even if it works well temporarily, it becomes very difficult to guarantee that it will continue to work for three or five years. Even if you guarantee that each version works with something like CI and testing, for example, it would be quite difficult to guarantee that the packaging by Ocra and others would work as well. |
Beta Was this translation helpful? Give feedback.
-
OK, I changed my mind. From my vague recollection (unlike Ocra's READEME description), I think the more dependency files there were, the more difficult it tended to be to package by Ocra, even for Pure Ruby scripts. But that is no longer an issue. The problem now is that there may be no good way to create Windows excutables files in the Ruby language. This is beyond my scope and I hope someone in the community can solve it. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I saw that you added this comment in the README:
Glimmer DSL for LibUI
If you want to write object-oriented, please use Glimmer DSL for LibUI. This is recommended for most users. However, if your target is Windows users and you want to use ocra to create and distribute executables on Windows, you may not want to use DSLs. The more dependencies, the harder it is to run ocra. libui_paradise is another DSL for LibUI.
This statement "The more dependencies, the harder it is to run ocra" is not accurate! ocra will automatically detect all gem dependencies and include them, so adding more gems does not make anything harder as long as the gems do not require extra dlls. All of Glimmer DSL for LibUI's gem dependencies are pure Ruby gems (except for libui), meaning they do not make anything harder to package. They are exactly the same as someone adding pure Ruby code to their LibUI project directly.
Given my actual professional experience in desktop development (about 5 years in addition to my 14 years of web development experience), I would tell you right now that all business professionals who want to build desktop apps for their enterprises want to use all the libraries (e.g. gems) they could find to facilitate solving their customer problems. This is a given in software engineering since the 90's at least. And, keep in mind that if you ask professionals not to use libraries, what they will have to do then to solve their customer problems is manually write all the code for the solutions that available libraries already solve through code reuse, thus multiplying their effort by 10x-100x, which is very impractical, let alone it opens the door to the competition to outdo them with their customers and steal their business (by using libraries). Not being able to use libraries (gems) is a big no no! It must never be recommended to users no matter the circumstances.
Also, remember that Rails includes tons of libraries and everyone loves using Rails no matter how big its footprint is. Professional software engineers prefer the convenience of reusing solutions to problems to stay competitive in the market than to write all solutions themselves from scratch. And, today's computers can handle any extra memory or disk usage with libraries without beating a sweat (besides, if the libraries were written manually, the applications would effectively have the same memory and disk usage anyways as using libraries).
The statement " you may not want to use DSLs" is also inaccurate because if professional software engineers end up not including a library dependency that provides higher abstractions to solve their problems, what they will do if they are good and effective software engineers is write their own DSLs and then build their apps on top of them (this approach is as old as Lisp from the 70's). I am mentioning this again in accordance to my real professional desktop development experience. On enterprise projects I worked on, we wrote libraries for providing data-binding support and widget factories (via DSLs) and then built our desktop apps on top of them to quickly roll out features to users. The whole point of using Glimmer DSL for LibUI is to save software engineers the effort of writing DSLs themselves. That way they have the DSL ready to go so they can jump on delivering business and customer requirements from the get go and be much faster and more effective at meeting customer demand.
One last thing to note is we must not let the limitations of a library not directly related to libui, like OCRA, affect our recommendations to users about using libui because OCRA is not the only solution out there for packaging native executables. There are quite a few competing solutions like ruby-packer and rb2exe. Furthermore, Ruby might soon provide a native Ruby way of packaging native executable using the new WASI support that got merged into Ruby, so we wouldn't even need OCRA anymore.
I would rewrite your statements on Glimmer DSL for LibUI into the following, bringing back the older version, which was mostly correct:
DSLs for LibUI
LibUI is intentionally not object-oriented because it is a thin Ruby wrapper (binding) for the procedural C libui library, so it mirrors its API structure.
It is recommended that you build actual applications using a DSL for LibUI because DSLs enable writing object-oriented code the Ruby way (instead of procedural code the C way):
Beta Was this translation helpful? Give feedback.
All reactions