Live data from Hacker News

Pharo MOOC

mooc.pharo.org

71–80 of 114 posts

Re: Pharo MOOC

#71
post #32

Earlier quoted context omitted.

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…

> 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.

Re: Pharo MOOC

#72
post #52

Earlier quoted context omitted.

> 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 pa…

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…

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.

Re: Pharo MOOC

#73
post #58

I've used Pharo, and, way back, programmed professionally in Cincom (then ParkPlace), IBM VisualAge, and whatever the Windows version of Smalltalk was called was called (Visual Smalltalk?). Also tooled-around a bit in Squeak. All three of the professional environments were very good. When Pharo kicked off, it was supposed to have been people building a free Smalltalk you could use to build real world software, as opp…

It is like fitness. One just hates it when it aches all over the place and then quits. Or keeps on moving through the pain/grind and grow a lot in all kinds of ways.

And saying that VA or VW give a better user experience when coding vs Pharo, I beg to differ.

Re: Pharo MOOC

#74
post #33

Earlier quoted context omitted.

The language itself is simple[1] but the environment and tools aren't. Smalltalk is a world in itself which is both its strength and weakness. https://learnxinyminutes.com/docs/smalltalk/

I am well aware of that as I had my own trouble learning Smalltalk. Yet in hindsight I like the clean design of the language. Nevertheless, I find the argument on their website kinda odd and a bit confusing. I mean, I see a lot of Smalltalk advocates claiming the language is so simple to learn and at the same time I see a lot of programmers having trouble learning it. Maybe it is just wrong to call it 'very easy to l…

Dabbling is easy.

Doing serious work is demanding.

But so is serious work in any environment.

Re: Pharo MOOC

#75

I had the "pleasure" of attending an OOP course at uni taught by Stéphane Ducasse. I didn't learn much OOP but i learned that pharo is an utter piece of garbage. The IDE randomly crashes, corrupts images (all your work is in the persistent image) and randomly ignores clicks making it insanely frustrating to use. Git integration is "WIP" which means it sometimes silently deletes files or you just don't get it to work…

From what I read on your project, it was quite daring to expose you to Bloc and Iceberg and the latest Pharo.

I wouldn't have.

Because these things are still in flux.

These things are interesting and are the way forward. But not ready for end users.

But this has exposed you to the realities of creating new things: it is not as clean as one would want nor are users that cool when facing them. In a unusual environment like Pharo, it gives a kind of blurring effect since a user has a hard time distinguishing between solid ground and treacherous new terrain.

I would advise you to look back at Bloc and Iceberg when Pharo 7 is released.

The occasionnal freeze of the environment is indeed a pain and a new user would cringe more than once. I actually have a REPL server running in my images to restart the UI when such stuff occurs. Not the realm of a newcomer for sure.

Pharo is great for my uses. It is not the best tool for everything, granted. But when dealing with complex domains, I haven't found anything close.

Re: Pharo MOOC

#76
post #65

Earlier quoted context omitted.

VS does have that functionality, although it was only added in VS 2015: https://johnkoerner.com/csharp/the-c-interactive-window-in-v... Previously there was the Immediate window but it is limited: https://msdn.microsoft.com/en-us/library/f177hahy%28v=vs.110...

unfortunately, it's not really the same as with proper message passing/late binding like in smalltalk.

You could use C# dynamic objects to achieve late binding.

Re: Pharo MOOC

#77

Earlier quoted context omitted.

The first one that comes to mind is the scratch package[1]. The entire scratch language, as far as I know, runs on top of squeak [1] https://packages.ubuntu.com/source/trusty/scratch

Scratch was rewritten in JavaScript a few years back, AFAIK.

It was rewritten in Flash and now is being rewritten in Javascript. An independent project created an extended Scratch clone in Javascript called Snap!.

Re: Pharo MOOC

#78

Earlier quoted context omitted.

> 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.

Re: Pharo MOOC

#79
post #52

Earlier quoted context omitted.

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…

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.

Re: Pharo MOOC

#80
post #78

Earlier quoted context omitted.

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 o…

> 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.

Post reply on HN