Ruby Windows installer
Ruby is an interesting language introduced to me by one of my good
friends who is also one of the top computer gurus I know as a language
that was worth learning. Ruby appears to be rapidly gaining a following because
it provides many of the features that attracted us to Perl and Python while
also retaining true dynamic object oriented support that attracted us to
Smalltalk. It is slower than C++ but it can still generate over 30,000 lines of
GCODE in under a second so I think it is fast enough.
I have professionally used many programming languages including the popular ones such as C#, C++, Java, Basic and many others so I could easily have chosen one of them for CNCUtil but they all represented a substantial learning cost which I didnt think the typical users of CNCUtil would be willing to pay. Whenever I start on a new project I look first at the typical users learning curve, The cost of training new resources, speed of execution, deployment cost, etc and Ruby appeared to be a good fit for all these criteria especially in the area of providing a very easy learning curve.
Ruby was introduced to me about a year ago as a programming language that had many of the features I was complaining about missing in C# and Java and when I read through the Ruby introduction I came to the conclusion that for the purposes of scripting CNC GCODE it would be as easy to learn as either Python or Logo both of which where designed as teaching tools for non technical people and children.
Ruby is free, runs on almost all platforms including Windows, Linux and Macintosh. Perhaps most important is that it provides a rare combination of being extremely simple to start using while also providing support for advanced software engineering concepts that I have found essential when producing complex projects on limited budgets.
CNCUtil was conceived as a project that was the right size to allow the risk of using a new language while also being large and complex enough to require sophisticated features. The result has been better than I would have hoped. Ruby has been extremely fast to learn and even its advanced features where intuitive and easy to pick up. Rubys support Object Oriented design is one of the best I have encountered since Smalltalk.
I have taught quite a few people how to program in various languages over the years including both technical engineers and non technical managers and I think Ruby would be one of the easiest to teach I have ever encountered especially when teaching non programmers.
The first operational version of CNCUtil took about 3 days while also learning the basics of Ruby. Many times that amount of time has been invested adding more intelligence and more automatic capabilities and Ruby is still performing well. Now that we have invested in the range of 300 man hours I would say that Ruby is competing favorably with Smalltalk, Python and Perl as the most productive language when measured in time to testable features. It allows me to add far more features per hour than Java, C# or C++ which is where I spend most of my programming time.
I find that a good syntax aware editor is helpful when editing Ruby because it helps to visualize the code and avoid stupid spelling errors. I would really like a vocabulary aware editor that provides features similar to what Visual Studio provides for C#.
I really do not like the Scitec editor included with Ruby because it seems cumbersome and is missing essential features such as automatically recognizing when a file it is editing has been changed on disk. The free IDE that came with the windows version of Ruby didn't work on my machine. There are quite a few choices for editors that provide very good Ruby support. I have listed some of these our running programs page
In general the Ruby compiler is not as powerful as the Python compiler when detecting problems and properly reporting the cause and location of the problem but Ruby does a better job supporting some of the object oriented semantics so it is still a reasonable trade off especially for complex projects that benefit from strong OO semantic support.
What Ruby really needs is a development environment similar to what the Digitalk Smalltalk provided complete with Object browsers and method editors. All the hooks needed to build such an environment in ruby are present but this is a pretty substantial project so we will have to wait and hope somebody else comes up with it.
The following items have repeatedly cost me time and energy during the code and test process. It helped me to codify them so that I work down this list automatically whenever I have a problem
· Accidental use of Java comments not effectively reported by compiler. The presence of the leading // rather than the leading # seems to cause really weird errors from the compiler and are not reported on the line where they occurred. This would be fixed by a good Smalltalk type editor that edits one method at a time.
· Accidental assignments in conditional assignments just happen without warning. This is one that the Ruby developers should be ashamed of. To be able to make an assignment inside the conditional part of a if statement should be outlawed in all languages because it is just begging to create very hard to find problems. Most languages that allow this to occur will at least throw warnings but ruby in its default mode is completely silent. I had a bug that took longer than any other problem to find and fix that ultimately turned out to be a place where I accidentally used a single = in a if statement rather than a ==.
· Accidental use of @ variable when supposed to use function or local variable quietly creates new variable and assigns nil so the value being assigned to get a nil instead of valid value which is not detected until much latter. This is another one which the Ruby engineers should be ashamed of. I am the one of the loudest advocates of highly dynamic languages because I like to make heavy use of dynamic polymorphism that may not be directly inheritance based but this is a dynamic feature that is just too dangerous and too easy to make mistakes that are quite hard to track down. In general if a @instance variable is referenced before being assigned it should at least throw a warning if not an error rather than doing a quiet creation.
· Missing end statements are not detected until end of file which can make finding the offending block time consuming. A good Smalltalk style development environment would make this problem go away since it would compile a method at a time and in general most methods are short enough where it is not that difficult to find the missing end.
· Can mis-spell names in the formal parameter lists when calling functions. EG: mill_circle(dism = 29) will go without complaint but when it gets to the function where dism was actually supposed to be diam the variable diam will contain a nil or the default parameter value and the dism will go off into the ether. I think they did this to allow variable length parameter lists which had not been pre-defined but there should be some separate syntax for those since they represent a boundary condition and the normal accidental inclusion of a named parameter that is not in the original def for the method should throw a warning. (JOE: Re-verify in small test)
In fact you still spend a lot of time figuring out how to get prolog to do procedural kinds of things but it is a master of being able to enforce a general set of rules that have lots of exceptions which is exactly what CNCUtil has turned in to.
As it turns out the CNC library has many requirements that are very similar to both the language translator and the converter. It may in fact be a superior choice for the implementation of product like CNCUtil. The reason I didnt choose Prolog is that it has a difficult learning curve for new users and I didnt think it could be adopted and enhanced by our target users without a lot of support and packaging to hide the Prolog from the end users. I know that when I first started learning Prolog it took several weeks of unlearning before I could accomplish anything and I didnt want to impose this learning burden on the CNCUtil users.
If I ever get a couple months of free time I may come back and try such an implementation just to see how it works. In an ideal implementation we would be able to keep the Ruby syntax and ease of learning for the machinists doing the scripting while transparently using the Prolog engine to help resolve the rules for choosing RPM, Feed rates and feed directions but this would require integrating Ruby and Prolog. This could be done via HTTP and two processes but that would significantly increase the installation and configuration startup overhead for new users.
·
The Prolog Programming Language
an introduction / course.
·
A list of Prolog implementations
compilers and interpreters
·
The AMZI Prolog
server. AMZI is one of the versions I have spent
quite a bit of time with and has historically been one of the faster versions
available for windows. It is not cross platform but is available on Windows and
Linux. It is a commercial product but there is a free version available.
·
GNU Prolog A
fairly generic version with completely free deployment and produces stand along
executables. It includes most ISO features and compiles to almost all operating
systems including windows and Linux.
·
Free Online Prolog Tutorials,
Prolog Tutorial, Prolog Primer,
·
SWI
Prolog another Open source version from