> Pay attention because Pharo could be better for supplanting bash. That was one of the first things I was evaluating Pharo on, to see its potential for replacing Bash (and therefore Lua, which I was also considering for this, initially; I'm one of those holdouts who hasn't learned Python -- I want "the real OOP" instead). But I have many years of programming Bash; I automate things. I really want Pharo to become my "handy tool" for this. And more.
Now, there's this wrinkle: Pharo doesn't run in the same realm (e.g., Linux Userland) as the OS and associated tools I need to work with; it runs in its own container, akin to running in Docker or LXC. We call them "image files", but they're really like Docker or LXC containers -- only Pharo containers are plugged into a VM instead of a Linux kernel (so it's much better!). Also, the realm of Pharo is "Objectland", not an isolated filesystem such as LXC provides. But the principles are the same, and.. do I really want to learn Docker? The consequence of this is, "How do you cross the container boundary, as needed, to interact with 'the real world'?" And do so with ease? This is distinctly different from, say, file I/O, where you're almost doing the opposite in Pharo: Bringing (a representation of) the file system into the image in order to interact with it. I can't bring 'grep' into Pharo; I need to reach outside and launch 'grep', and interact with it, all from code executing in my image. Pharo shares this issue with Docker, but goes one further: Marshalling in/out of objects, because that's all there is "on the inside". These are interesting CS/IT issues, for sure... We depend on skillful IDE developers in the Pharo community to make it all work smoothly, almost invisibly. > To me Pharo is not really at the level I would like to. I have already gotten the feel for this. I started with an impression of "Pharo is Smalltalk that's modernized and mature, finally!" (having shifted from Squeak), to a more subtle feeling of "Wow, it's evolving (quickly!), there are many areas being improved, and still some things that are "in the rough". And that's okay; Rome wasn't built in a day and this is a major project. We're "rebuilding a 1970's sedan into a 21st Century electric autonomous car" sort of thing, and doing it while it's being driven. And successfully, too. So I will still recommend that engineers and developers spend time evaluating it. What language/IDE stands still anyway? They all evolve. > But this is my view. > Now we have nice binding to invoke shell and other like subOSProcess. > We should also progress on that front. I was frustrated a bit at first, but then I found Christopher Fuhrman's page on using 'LibC': https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html which shows how to "get a shell" on the host to run commands & access the environment variables (including returning stdout, stderr, and the $? result -- excellent). That seems to cover most needs, but I'm not sure if this is the "standard way to do it". It does seem pretty powerful, though. Then I found the "clap" project, https://github.com/cdlm/clap-st and then "Scale", https://github.com/guillep/Scale So I conclude that the ability is there, with more potential to be realized as things evolve. > To me Pharo is super good at manipulating complex data and object > and building nice abstraction. I get that! Bash is terrible at this, but it's super good at blending scripts with the OS evironment to make Userland tools work so seemlessly as part of your custom code they seem to be elements of the language. Now flip that around: How does Pharo fare at OS/environment interaction? We can't operate in a vacuum (unless we build, what? Single-player games?) > So I hope that you will not be disappointed. So far, I'm not; I'm inspired, if anything. Here's the list of what I consider to be the ideal capabilities of any language/programming environment, in increasing challenges. (And keep in mind that I don't come from a corporate IT background, shuttling & transforming data from cloud to cloud; I build code to automate machines, devices, instruments, operating systems, applications, processes, tools.. and every now & then processing the data. :^) 1.) I want to have full host file system capabilities. Not just read/write files, but manipulating the file system. Pharo seems to have this covered. 2.) I want to have good TCP/UDP capabilities. I want to act as a server to provide TCP sockets to connect to, act as a client and connect to servers using TCP, and be able to read and write UDP packets easily. Again, Pharo seems to provide this nicely. 3.) I want to be able to interact with the OS, the host environment, and tools and applications in the host. This includes being able to launch, monitor, and control processes -- and pass I/O in & out dynamically. In Bash, if I need complex pattern matching, I just "ask grep"; if I need programmatic editing of a file, I just "tell sed to do it". There's no hoops to jump through, and nothing to set up. Just "use the tool" and keep coding... I see ability here with Pharo. 4.) I want to be able to connect to compiled libraries of code and call them easily -- so that I can interact with devices as well as export behavior to pre-existing code. This is the Pharo uFFI. And I'll mention USB/serial use here; device control is Pharo IOT I'm told. I have yet to look at Pharo IOT, but I will be doing so soon, just as I will be immersed with the uFFI as I help with the docs and later the code. So I know Pharo can do this, too, yet it seems an area that's evolving. 5.) I want to be able to write applications that I can interact with from my host's command line. I want to write REPL apps, Linux filters, and the like. For example, I ought to be able to recreate 'grep' in Pharo (if I wanted to go to the trouble. Not really, but I should be able to do it). Most of my Bash and Lua scripts work at this level. With Pharo..? I'm not sure how well this can work. 6.) I want to create apps that have a nice, professional-looking mouse-driven GUI interface -- without the tedious nature of, say, Tk to build them. I know now that SpecUI answers that, to some degree of ease; but I'm not sure yet how well, as I need to run a tutorial & play with it. Pharo Launcher proves that these apps can be built. So I wonder, "How hard would it be to recreate Pharo Launcher?" Because of course, I want to deliver apps to my colleagues that work like running Pharo Launcher. So here it's a matter of "It can do it well, but how hard is it?" 7.) I want to create web apps, where my Pharo code, running in its container, is reached by a web browser or another app's code, over sockets (like accessing Docker microservices), whether it runs on the same host or a remote host. This is the ultimate -- it makes deployment, maintenance, access, and so forth much easier, enables scaling, redundancy, platform-independence, etc. My customers want this, but I can't give it to them currently. I know that Pharo can do this, and do it well. I like that the cognitive burden of learning web programming is significantly reduced with Pharo. (Here's a suggestion for Pharo: Make Pharo easily capable of plug-and-play in a Docker cluster. I want to make/deploy microservices built with Pharo, not Docker. The IT world seems to be swinging towards this, and if Pharo pursues this, perhaps it would be that breakout feature it needs.) 8.) Finally, I want to be able to create the client-side view/behavior/experience that my user sees and interacts with in a browser-as-my-GUI. I think this is Amber or PharoJS, and I know that this the summit of the mountain and most likely a separate skill area. I have never wanted to learn JavaScript, CSS, etc. but one can never get far from that, so I would leave this to the specialists. But being able to give them a Pharo environment to build these would be nice. I have no idea how ideal Amber/PharoJS is for making web pages... Where I am now, I have at least one language/IDE that gives me all but the last two capabilities on this list (and doesn't do #5 very well). But my primary IDE is closed-source and *expensive*. (I can pay several thousand more to a third-party vendor for an add-on that gives web control, but no one here wants to pay for that, even though many ask for the capability.) I want an open-source, platform-independent IDE instead. I started to think that Lua (with MANY add-on libraries) would cover enough of these "desirements", but I've always wanted to work in that pure OOP environment of Smalltalk. So I'm encouraged at all I've seen, because Pharo touches on all these capabilities. Not all perfectly, of course, but many very well. I don't think I'll be disappointed. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
