Hacker News Reader

Comment by btilly | Hacker News Reader

I agree that it is a language worth understanding. However the OO model of Ruby is identical. Without the drawbacks of being an image based language. So I'd suggest learning that instead.

For those who don't know what I am talking about, there are several families of languages where the state of your program is kept within an image. The upside of this is that you can integrate everything together in a really neat way and build neat tooling with introspection. The downside is that you have just made what's going on not visible from the filesystem, and have to replace all of the tooling that you're used to. You know, things like your favorite editor, command line programs, source control...

If you switch languages regularly (which most developers do in my experience), being able to use your favorite toolset everywhere turns out to be more important than being able to build an ideal toolset for only one language.

View on HN

> I agree that it is a language worth understanding. However the OO model of Ruby is identical....

I independently arrived at the same conclusion. The main problem with Pharo is the esoteric tooling; life is too short to struggle with tools.

That said, I consider Smalltalk, Objects and Design by Chamond Liu to be one of the best books I ever read on the subject of object oriented programming. Heartily recommended.

Tooling appears exotical because you are not using it day in day out.

And I actually find things like Spotter, Code Rewriter, GTInspector and Calypso pretty neat.

IntelliJ is not simpler and is closed source. It is neat, true. We even use its icons in Pharo.

Tooling appears exotical because you are not using it day in day out.

And that's the problem. The tools are different. They require learning. And once learned, they are only useful for dealing with one language. And that is a language that nobody around me uses.

The result is a barrier to entry. A barrier to entry of a type that I'm not bothering with again unless I have a good reason to.

Furthermore the small size of the community means that I am unlikely to get to choose tools that fit me. I'll be stuck with whatever the personal preferences were of the people who wrote the tooling. Even if I like them, my neighbor probably won't.

You bring up IntelliJ. However I don't use IntelliJ. I prefer vi and command lines. The guy sitting across from me likes Visual Studio. I couldn't tell you how many other IDEs are in use by programmers in the same space as me. No single toolset is going to be to all of our tastes. And it doesn't matter with a filesystem based language, because we are each free to use whatever we want.

> I'll be stuck with whatever the personal preferences were of the people who wrote the tooling.

User experience is one area where Smalltalk seems like it could use some focus on. Compare the screenshot of the system browser on pharo.org compared to figure 17.1 (page 293, PDF page 315) of the "blue book":

http://sdmeta.gforge.inria.fr/FreeBooks/BlueBook/Bluebook.pd...

Apparently that layout was perfected in 1980. Has anyone ever experimented with showing more than one method at a time in a window? And taking up less screen real estate with the class hierarchy? Seems ripe for some new thinking here.

I am also using Tmux and Vi an awful lot.

And working on a fuse thing that exposes my running image as a filesystem so that I can such tools as well.

But saying that the tools are different and you cannot be bothered to use them? Look, Visual Studio is a monster beast, with tons and tons of features, including Azure ones. It takes a serious while to master.

And vim also takes a serious while to use well. Especially when we use a couple of plugins.

An engineer knows the tools. Then a specialist masters them. The master makes them. Or changes them.

Pharo allows one to do that. Without strings attached.

I believe the point the parent is trying to make is that when you spend the time to learn Visual Studio, vim, etc. you can transfer that knowledge to multiple languages. With Pharo those tools are limited to, well, Pharo.

The benefits of learning a particular tool are essentially proportional to how often you use that tool. The greater flexibility of other tools such as vim means that the cost of learning it can be amortized over essentially as many projects as you wish. The costs for learning Pharo tooling are only spread over as many Pharo projects you do. If you don't believe you'll be doing all that much in Pharo, it makes it a fairly daunting proposition to invest that time.

I guess it depends on the taste of the developer. I really enjoy seeing newcomers posting in the mail list saying that Pharo makes "programming fun again".

But Pharo is all about the deep integration of the tooling. Its what facilitates such a tight Code->Compile->Run->Debug cycle. It can take a while for the penny to drop. If you do a drive-by taste of Pharo you probably didn't get chance to really get into the flow.

Some say... "The only programming languages worth learning are those that change the way you think about programming." And Pharo/Smalltalk tooling does that.

> The downside is that you have just made what's going on not visible from the filesystem, and have to replace all of the tooling that you're used to. You know, things like your favorite editor, command line programs, source control...

While Pharo (and Squeak, etc.) have baked in editors and source control, Pharo has integrating with general tools as a design goal. It includes an integrated Git client and can load packages from or move them into a Git repository.

Per https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-an... as of 2 years ago Pharo did not have an established convenient way to integrate with git. Per https://github.com/pharo-vcs/iceberg the current best solution for that is still an experimental tool, so you have to be careful. Being able to integrate with other version control systems is still off in the future.

Integrating with general tools may be a design goal. Yet it clearly isn't fully there. A filesystem based language does better without even trying.

Not it doesn't.

Iceberg is breaking new ground compared o Kraken/SourceTree etc.

Pharo took the risk of integrating git support in the tools.

It takes a few iterations.

So what? Either one is a user or one is inventing new stuff. When was it you wrote a full wrapper for libgit? And made it available to any app? Yes, any Pharo app now has the ability to use libgit features. Awesome and opening quite some doors.

Congratulations. You came up with a reason to do a whole bunch of work that you found fun. Work of a kind that is entirely unneeded in other languages. Do you want a cookie?

All developers are users of someone else's software and knowledge. I'm OK with that, and happy to not reinvent perfectly good wheels. You go ahead and enjoy wrapping libgit.

My preference is to understand how to use data to help businesses. For example a decade ago I gave a tutorial on A/B testing which resulted in multiple companies adding many millions to their own bottom line.

It is a big world. There is room for all kinds.

I am busy with serious size Hadoop clusters as well, using a gazillion of technologies (including some Pharo on YARN mind you).

Nobody forces one to use Pharo and I actually find it indeed useful to have an FFI binding to libgit.

Pharo has had git support for years with git filetree. There is no urgent need for a built in tool. Iceberg is an integrated tool which is not even yet released for the version of Pharo it is intended for (7).

The project is useful to test drive UFFI significantly. As such it is a really good test bed for all kinds 7of data structures and callbacks etc. Coupled with the 64 bit VM + image it is even more so.

I am in the Pharo ecosystem as a long play. Expedient solutions are plentiful. But they all lack this QWAN in Pharo that makes it enjoyable to me.

I am interested in understanding how things do work. Pharo allows me to do it in a way that suits me.

Given the count of "me" above, it is clear that I follow my own path and I couldn't care less about popularity.

Truth be told, I find it somewhat useful to have a harder to approach community. It keeps the signal to npise ratio at an acceptable level.

There is room for all kinds indeed.

Yes, I'd like a cookie. But not for libgit, but libstrophe. It was easier (and clean!) to bind with Pharo than with a lot of other technologies. The ability to pin objects is also very usable.

Pharo devs are not inventing new stuff, they're reimplementing existing stuff, poorly, in their favorite language because said language is incapable of interfacing with the existing mature tools.

Whoever designed the GUI also probably never used even git, or they couldn't stand their own tool. From the top of my head: 1) it shows all commits in a linear list (with broken unicode) completely ignoring branches 2) deletions are green and additions red.

>I agree that it is a language worth understanding. However the OO model of Ruby is identical.

Smalltalk is much more than the OO model.

And yet if your goal is to learn about OO programming from the concepts of its OO model, then either language is good and Ruby is more convenient.

On the other hand if your intent is to learn about its collection classes, what MVC looked like in its original inspiration, and so on, then you should learn Smalltalk.

There is more to learn than any of us has time for. If you know what you hope to get out of learning something like X, then you should pick the most convenient X around to learn it.

Ruby the language, fails quite short of Smalltalk full graphical experience.

Well, it's not an IDE, so it's not fair to compare it to Pharo which is trying to be both a runtime environment and an IDE. If anything, it's an advantage that Ruby allows you to make choices about the development environment you use.

I think it's fair to compare the language+environment which is the only thing that practically matters. Smalltalk has a really nice IDE and fast VM. Ruby doesn't have a native IDE, but does well with things like Vim & Notepad++. Ruby has a lot more modules and Rails. I wouldn't consider Ruby to be very fast being one of the slowest popular languages out there.

Rubyists might know of Ruby books written by Avdi Grimm, who recorded his early experience with Pharo... https://www.youtube.com/watch?v=HOuZyOKa91o

Reply on news.ycombinator.com