On 10.01.2022 14:13, David Crayford wrote: > On 10/1/22 8:34 pm, Rony G. Flatscher wrote: >> On 09.01.2022 16:29, Seymour J Metz wrote: >>>> Well all of your languages miss the support for the message paradigm. >>> What do you mean by "the message paradigm"? How does it differ from sending >>> method invocation >>> and response messages to objects? >> The message paradigm as set forth by Smalltalk explicitly defines a class >> for messages, allows for >> intercepting messages, rerouting messages at the will of the programmer and >> much more, as messages >> themselves become objects that the programmer can interact with, if needed. >> >> ooRexx implements the message paradigm in full, something that is easily >> overlooked as usually it is >> not necessary to be aware of it. > > If it's not necessary then why did you make such a big deal about it?
Well if you have really read the entire post you should know. Without implementing the message paradigm things become clumsy and some important features, if you need them, are simply not available. > >> As you can see, if there should be need for adding external functions and/or >> methods to ooRexx, this >> can be done with the powerful and easy to use C++ API of ooRexx. As a matter >> of fact BSF4ooRexx and >> dbusoorexx are using those native C++ APIs allowing high speed and using all >> that is available in >> and via the C++ world. > > ooRexx will never be high speed because it's implementation is fundamentally > ineffecient. LOL! ooRexx for any practical purpose is more than speedy enough! And its speedness has been excercised in quite a few applications I wrote in the past twenty, twenty fiver years. Have you every tried it out, e.g. for controlling applications, processes, having macros dispatched against hosting applications, for processing MS Office documents, OpenOffice/LibreOffice documents, controlling your Linux infrastructure via DBus, taking advantage of e.g. data mining Java class libraries etc., etc.? Clearly you have not, hence it is unfortunately ongoing badmouthing without any practical experience knowledge. > Most scripting languages compile to bytecode which is then processed by a VM. > For example, the Lua > VM is less tha 2K lines of code and can fit into L2 cache which is why it's > blistering fast > https://www.lua.org/source/5.1/lvm.c.html. Cool! If high speed is so important then Assembler would be much better, of course, forget Lua by comparison! ;) > ooRexx chose to use a graph of C++ classes with abstract base classes for > every instruction and > clause. OMG, dynamic dispatch for every instruction! You seem to not understand - or intentionally ignore - the implications of a true implementation of the message paradigm, the power, the flexibility and the easeness for unleashing it. > https://github.com/ooRexx/ooRexx/tree/master/interpreter/instructions > > It's gigantic clump of inefficient code based upon inheritance. Badmouthing again. If you really believe that you should go back to text books then and read about oo and inheritance all over and stop requesting OO-features to be present in programming languages at all, which you have been claiming is so important in the first place... And while giving us the impression you would be an expert in this field how does it compare to Objective-C? Now the red herring seems to be clumsiness, high speed, unnecessary inheritance, ... unfortunately distracting and badmouthing again. :( > The GoF Design Patterns book which dates back to the 90s was a > groundbreaking, seminal work which > had a central theme of introducing patterns to avoid inheritance. Please stop giving misinformation (I have read the book decades ago)! But fighting inheritance, declaring it to be useless, clumsy all of a sudden is quite strange to say the least. > Modern languages like Rust don't even support Inheritance. There are assemblers that do neither, so wouldn't they be much better than Rust then? ;) [Your "name calling" of languages suggesting you would be an expert in all of them has not been really convincing and not really relevant in this context.] > If you want high speed then use a JIT compiler. The Lua Functional library > used with LuaJIT can > boil a chain of method calls down to a dozen instructions with no linkage > overhead > https://luafun.github.io/intro.html. The Julia programming language can do > the same with similar > syntax. If I wanted to use REXX > I would use NetRexx to take advantage of the JVM JIT. Indeed, if high speed is of high priority and you are not able to mix and match languages then that is always a nice path to go: starting out with Assembler of course. And yes, NetRexx qualifies like Java, Kotlin, Groovy and the like which is really great as REXX programmers can quickly take advantage of the NetRexx language. If there are segments that need high speed such that ooRexx would not qualify, then you can easily use ooRexx to interface with those high speed libraries and applications e.g. DBMS that are specialized on high speed implementations with an expertise a regular programmer would not possibly have; or would you suggest to implement DBMS rather in Lua because of LuaJIT? ;) Rather Lua - like Python and other languages - would use high speed implementations of libraries (database, AI, ...). ooRexx for instance can immediately take advantage directly of all such high speed Java libraries (it is really a breeze). So please stop using red herrings and seeding misinformation: it is more important (and much cheaper) for humans to use programming languages that are clear, easy to learn, easy to code, easy to maintain. It is more important to have flexibility and patterns available that are easy to understand and to exploit. REXX, NetRexx and ooRexx are programming languages with a design philosophy that puts the human as the most important factor in the center of the design. That makes it so attractive and powerful. E.g. if a problem at hand needs multiple inheritance to be solvable in an easy, clear manner, then it is important to have that concept available at that point in time. ooRexx supports multiple inheritance. And the way it got implemented in ooRexx is really very easy, yet very powerful (because of the flexibility and power the message paradigm allows for). If business administration students are able to learn REXX and ooRexx in a four hour lecture in a single semester, thereby becoming able to take advantage of Windows and Windows applications like MS Office on Windows, *and* OpenOffice/LibreOffice, client-server-programming, GUI-programming in a single semester, then we talk about a programming language that is phenomenal to say the least! Therefore it is easy for CS graduates to learn REXX and ooRexx within a week or two in depth that adds SAK problem solving abilities to their toolbox of IT knowledge. To insist that they must learn Lua or must only program in Python is - well let me say that explicitly - quite unprofessional! --- Just a last remark: today's hardware (even smartphones!) is so abmysal fast that speed only matters in certain application domains like DBMS, mass data analysis, AI and the like. Such application domains have their own specialized applications and libraries that can be interfaced to and thereby exploited in full. (The subcommand feature of REXX/ooRexx is just one easy to use feature to support that philosophy that other programming languages lack most of the time.) This is what REXX and ooRexx have been doing for decades anyway, and they shine in doing so. Usually nothing more is needed, its speed is more than appropriate! :) ---rony ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
