[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,