Live data from Hacker News

Hush, a modern shell scripting language

hush-shell.github.io

191–192 of 192 posts

Re: Hush, a modern shell scripting language

#191
post #190

Earlier quoted context omitted.

Whelp, didn't make it in time and I can't edit anymore... Here's what I wanted to write: I don't want to talk about Pharo. Please, don't make me talk about Pharo at length. Even a short summary will be painful... But I'll do it anyway if only to have something to link to in the future. In short: Pharo is the worst Smalltalk out there, with a community that is small, elitist, and entirely unconcerned with user experie…

Cuis is a really interesting incarnation. It's quite stripped down, and Juan, the creator, has done a lot of work to simplify things as much as possible. He has even stripped down Morphic and has an early working version of its "successor," which is vector based. The dual problem with the open source Smalltalks is that there aren't enough people working on them, and the community that is working on them is fractured.

> He has even stripped down Morphic and has an early working version of its "successor," which is vector based.

That's very interesting, actually, I didn't know, thanks. Morphic is not a bad idea in itself - the problem is that its implementations are ~30 years behind the times, and slapping framework after framework on it won't make the pig fly. But, rethinking and modernizing the ideas behind the base implementation might be a way to make all those frameworks work properly, finally. I will pay attention to Cuis more.

> The dual problem with the open source Smalltalks is that there aren't enough people working on them, and the community that is working on them is fractured.

No, the problem is that the open source Smalltalk community comes from academia mostly, plus some hobbyists, and they are by and large simply poor software engineers. Smalltalk is capable enough to allow them to get what they want more-or-less working, and quickly, but the code is a mess. The authors then go on to write their dissertations or publish some papers, which generates a bit of interest in the project. But then two things happen, almost every time: a) the author gets the promotion or title they wanted and leave the project; and b) the people who got interested in the project are met with a steaming pile of garbage code that modifies half of the Kernel category for no reason at all, has methods with 100+ lines of code, has complex hierarchies that were abandoned halfway but left in the code, has no or almost no comments, the names of identifiers are incomprehensible abbreviations, and so on. Coupled with "move fast, break things" of Pharo, this results in the project stagnating and then quickly stopping to work altogether, other than with the original image (if you're lucky and the author actually posted the image).

Diving into the world of commercial Smalltalks showed me that it's actually possible to write solid, extensible, well documented, tested and stable Smalltalk code. Later, looking at Cuis showed me that it is in fact possible to do the same with open source implementation, but you need a strong leadership, a vision, and skills that most of the Pharo community is simply not interested in having.

Note: this is the first ever time where I'm knowingly, willingly, and somewhat brutally attack or complain about a particular community. I'm really tolerant. I can deal with a lot. But half of the Discord channel shouting at me and calling me names like "masochist" just because I want Ctrl+A and Ctrl+E work as Home and End in the editor? That was too much, even for me.

Re: Hush, a modern shell scripting language

#192
post #190

Earlier quoted context omitted.

Cuis is a really interesting incarnation. It's quite stripped down, and Juan, the creator, has done a lot of work to simplify things as much as possible. He has even stripped down Morphic and has an early working version of its "successor," which is vector based. The dual problem with the open source Smalltalks is that there aren't enough people working on them, and the community that is working on them is fractured.

> He has even stripped down Morphic and has an early working version of its "successor," which is vector based. That's very interesting, actually, I didn't know, thanks. Morphic is not a bad idea in itself - the problem is that its implementations are ~30 years behind the times, and slapping framework after framework on it won't make the pig fly. But, rethinking and modernizing the ideas behind the base implementatio…

I love so much about Smalltalk but also felt many frustrations with implementations and community issues.

A couple of me own rants on that include from 2007: "[Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re: More Pipeline News)" https://mail.python.org/pipermail/edu-sig/2007-March/007822.... "There is once again the common criticism leveled at Smalltalk of being too self-contained. Compare this proposal with one that suggested making tools that could be used like telescope or a microscope for relating to code packages in other languages -- to use them as best possible on their own terms (or perhaps virtualized internally). Consider how the proposal suggests scripting all the way down -- yet how are the scripting tools built in Squeak? Certainly not with the scripting language. And consider there are always barriers to any system -- where you hit the OS, or CPU microcode, or proprietary hardware specifications, or even unknowns in quantum physics, and so on. :-) So every system has limits. But by pretending this one will not, this project may miss out on the whole issue of interfacing to systems beyond those limits in a coherent way. For example -- OpenGL works, and represents an API that has matured over a quarter century, and is linked with lots of hardware and software implementations; why not build on it instead of "bitblt"?. Or consider how Jython can use Java Swing libraries and other such Java libraries easily. Consider this example of proposed failure: the proposal's decision to punt on printing -- no focus there in difficulties of interfacing with a diversity of OS services as a guest -- of relating to prior art. This is where Python often shines as a system (language plus libraries plus community) -- and Python is based on a different design philosophy or perhaps different design ethic. Python has also prioritized "modularity" from the beginning, which has made a lot of these issues more manageable; Kay's proposal talks a lot about internal integration, but the word "modularity" is not even in the document. In this sense, I think Kay's group are repeating mistakes of the past and also dodging another very difficult issue -- one that Python somehow has more-or-less gotten right in its own way. It's their right to do their own thing; just pointing out a limitation here."

And later from 2010: "[fonc] On inventing the computing microscope/telescope for the dynamic semantic web" https://www.mail-archive.com/fonc@vpri.org/msg01445.html "As I said at the end of my second post linked above: "It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)""

The sourceforge link in that post rotter; that last quoted text can now be found at: "Re: [PataPata-discuss] Thinking on PataPata four years later..." https://sourceforge.net/p/patapata/mailman/message/26393156/

Post reply on HN