[drinfinity]

What the Smalltalk and apparently now the Pharo people don't seem to understand is that the entire OS is the IDE, "the image".

My OS and all of its rules, tools and configuration, the UNIX philosophy, the POSIX standard, all of its history and convention: _that_ is my dev environment and it's as LIVE as anything can be.

Not some one-off unicorn IDE - no matter how awesome it is, sorry guys.

My entire toolchain in all of its diversity is one big living ecosystem. That is not, as you eloquently hinted at, a bunch of refined steam engines. It is maglev-level awesomeness. Some pointy-clicky IDE where you can inspect objects with trivial properties is not impressive. It was in the 90s, but now now. Ironically Pharo itself, to me, evokes the admittedly beautiful image of a bunch of refined steam engines. A beautiful thing of the past. Impressive, but obsolete - not unlike France itself.

You have to interact with dozens of systems for even the simplest applications now. Databases, HTTP APIs, knowledge systems, OS'es, all kinds of IoT and machinery, all of which have their own standards, their own philosophies, their own tools, their own way of doing things. None of this would ever work if one tool decides it has the Truth and all other should conform to it. Without the UNIX philosophy none of this would even get off the ground. Because that is wat Pharo is, a tool, _inside_ an already living ecosystem. That is exactly why you get programmers asking, why can't I use my tools, why can't I use the "shell", do this do that.. This tool does not fit the UNIX mindset: it's just another tool, but it pretends to be an entire ecosystem that handles everything. An OS inside an OS. This does not make sense to anyone (but the Smalltalk people apparently). Also, as an aside, that is exactly why emacs sucks (take that HN!!).

For some reason some people think programming is hard because you have to create some classes and struggle with basic syntax. Inspecting trivial object and deciding the value of its sole attribute is "2" or "A" is not what makes our work hard.

And yes, UI _is_ a crutch. Only visual tasks need visual interfaces, think Photoshop. Visual UIs slow you down, that's just a physical fact - how fast is you hand? - and it is totally reasonable for new/incompetent users and/or users that perform visual tasks, but programming is not a visual task. Programmers think in abstractions, in symbols. GUIs have their place to be sure, without autocomplete I would be useless, so there's that, but beyond that, nope, useless crutch for incompetent users. Take that, society.

~Angry Engineer

[goatlover]

> Without the UNIX philosophy none of this would even get off the ground.

So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other? Is there some sort of CS proof of this claim? Or was it just how history played out?

> For some reason some people think programming is hard because you have to create some classes and struggle with basic syntax. Inspecting trivial object and deciding the value of its sole attribute is "2" or "A" is not what makes our work hard.

Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files. You might not agree with that, but the reason you have such good tools for text and file manipulation is because the Unix way prevailed. Magnitudes more effort has been poured into making that tooling than alternative approaches.

> Visual UIs slow you down, that's just a physical fact - how fast is you hand? - and it is totally reasonable for new/incompetent users and/or users that perform visual tasks, but programming is not a visual task.

Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.

> GUIs have their place to be sure, without autocomplete I would be useless, so there's that, but beyond that, nope, useless crutch for incompetent users

I guess debuggers, refactoring and class browsers aren't useful, then.

> Impressive, but obsolete - not unlike France itself.

LOL, wat?

[drinfinity]

Update: I'm using it now for a while and it's quite epic. So yeah, it's awesome, but in a forbidden fruit kind of way that I cannot condone and thus none of you guys should be using it.

[drinfinity]

LOL sorry about that.

But still, yeah.

> So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other?

I don't know and it is not relevant. If you're so inclined you may come up with another paradigm. Anyway, Pharo in particular is not such a paradigm, it's a fancy tool. Fancy, but a tool and it should behave as such and should co-operate, and it doesn't and that makes me very, very, very angry. And upset. And hurt. :-)

> Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files.

I understand, but saying "text manipulation" is quite derogatory. It is _symbol manipulation_, that is what we are doing. The underlying mechanisms of the OS, filesystem and various media are irrelevant. What if I don't work with files, but "symbol maps" or whatever the F* some academic can come up with in his own custom fancy GUI tool. It doesn't change one bit. I still have to manipulate symbols and it still needs to be encoded somewhere. Increases on the fancy-dimension mean decreases on the is-robust-and-useful-in-a-general-way-dimension, not to mention the works-at-all-in-20-years-dimension.

Text files are just low common denominators. They are simple to understand and work well, not only across space, but more importantly, time as well.

> Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.

I know, but that's not the point. I'm not saying Pharo is bad at what it does, being an excellent IDE. It's wonderful. I'm opposed to the ideology of throwing away all UNIX lessons and integrating everything into one God-system. I guess I've upset not only the Smalltalk, but now also the Windows people. Sorry.

> I guess debuggers, refactoring and class browsers aren't useful, then.

These are aids, typically implemented graphically, but not always - Vim has excellent autocomplete, refactoring and class-browsing plugins. Yes, some tasks map excellent to the visual metaphor. Scanning hierarchies and seeing high-level overviews are indeed useful abstractions, but that is not the point. The point is that if you want an excellent debugger, use an excellent debugger. If you want a good refactoring tool, use a good refactoring tool. Don't throw it all in one system and call it a day. That is not the UNIX way and yes, I am saying that is the superior way. In all of its vulgar, plebeian ways, the UNIXes have stood the test of time and I'd seriously reconsider dumping that.

~ Angry, but generally peaceful if slightly anxious and over-caffeinated Engineer

[khinsen]

I sympathize with your criticism, which reflects my first impressions of Smalltalk when I played with Smalltalk 80 on my Atari ST 25 years ago. An impressive system, but isolated from the rest of the universe.

However, today's Pharo has made significant progress with interfacing to "foreign" stuff. The file system has become a first-class citizen of the environment. There is an FFI to work with C libraries. And of course support for network protocols. Source code management is based on Git. It's the GUI that remains in a world (window) of its own, but otherwise Pharo's system integration level is just a notch below languages such as Python or Ruby.

[offray]

Your comparison of Pharo/Smalltalk with Unix is pretty accurate and is the one much people misses, comparing Pharo with other computer language, without taking into account all the companion tooling to make such system work: debuggers, editors, DVCS, graphical toolkits and a long etc. A more detailed explanation of how Smalltalk compares to the whole Unix environment can be found in "Tracing the Dyanbook"[1], but goes in the same route as you (with a pretty detailed philosophical, educational and historical view of the Smalltalk/Dynabook approach about what computing could be).

[1] https://open.library.ubc.ca/cIRcle/collections/ubctheses/831...

So Pharo/Smalltalk can be orders or magnitude less complex that a full OS and yes is running inside one, but for me that means that it gives you a unified way of dealing with environment/OS complexity (mostly incidental) by providing an interactive, live, supporting place to thing about your prototypes. I made Grafoscopio[2] using Pharo, after trying the Operative System approach and translating symbols to files and dealing with that mismatch and with a plethora of (incidental) complexity (See [3]). Despite of being a Unix/Linux user since 20+ years and a novice coder at that time, the feeling of empowerment provided by Pharo compared to the tools I was using in Linux before was pretty big.

[2] http://mutabit.com/grafoscopio/index.en.html [3] http://mutabit.com/offray/static/blog/output/posts/grafoscop...

I'm glad you have decided to test the tool by yourself and I highly recommend reading [1] for a deeper understanding on how Unix and Pharo/Smalltalk compare to each other and how the last implodes complexity, even when living inside the first one.

Cheers,

[philippeback]

I am using Linux a ton (actually on clusters of boxes) and have a boatload of tools and languages (including low level C and in the past, assembly).

Now, I am also using Pharo to do things on Linux and it is easier and faster to get results out of it, especially when I need to fix a failure.

Pharo is not replacing the OS (even if it may feel like it).

One can deal with a running Pharo remotely (either via VNC directly into Pharo or with Pharo7, using Calypso remote connections).

I am with you on the symbolic aspect but still, having an image that one can inspect is great. I was not understanding its value when I started. Now, I do. And I also find it awesome to have a stacktrace saved to disk on a server so that I can reload it into my desktop box and see exactly where things went south, including variables, values etc. Try that with a core dump.

Now, to each its own and I have a personal little project I should actually deliver, namely being able to expose a fuse filesystem from a Pharo image, so that I can use vim and tmux and those things right from a server. There is no technical issue doing this, just damn code it.

The current Pharo is not an OS inside an OS. UnifiedFFI actually makes it easy to bind with C libraries (heck, I wrapped LibStrophe which is full of callbacks, callbacks that are actually written in Pharo, including full debugging on callbacks, see https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPj...) and the more Pharo evolves (been there since Pharo 2.0) the more it delivers on what I need.

With the new boostrapping, one can actually have images with just the bare minimum (no UI, no devtools) so that it can run.

Also there is lowcode, a way to do really fast stuff in Pharo (actually putting C types in there): https://hal.inria.fr/hal-01353884/document

What is also interesting for me in Pharo is that it actually stood the test of time. I am sick of new languages that pop up all the time, where one is relearning the basics with half baked libraries. Pharo core classes are solid, work well and after working in there for a while, it becomes second nature to do quite advanced stuff that one would not even dream to do in, say, Java.

Pharo is indeed a tool and in my toolbox, it is one the best ones so far. Coupled with Unix tools, it is a beast.

I not care if it is getting popular or not. What I care is that it works, that I can influence its course and change what is not pleasing me (try that with other toolchains).

And also that its community actually owns it, not a commercial organization like Oracle, Google, Microsoft... In that regard, Pharo is pretty much aligned on Linux.

The Pharo community understands the limitations or warts of Pharo, because there are some. But the features are currently delivering a net positive.

And, a little thing that is quite important: I have fun creating and maintaining systems I have done in Pharo.

This really contrasts with other solutions where fighting with accidental complexity takes 50% of the time, if not more.

Anyway, to each its own. I can relate to being angry when engineering. Pharo is lowering the level on my WTF-o-meter, which is actually good.