Live data from Hacker News

Pharo MOOC

mooc.pharo.org

91–100 of 114 posts

Re: Pharo MOOC

#91
post #78

Earlier quoted context omitted.

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

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.

Re: Pharo MOOC

#92

Earlier quoted context omitted.

Except the pain in pharo doesn't come from the difficulty of learning new things or self-improvement but from the buggy environment itself. Learning to save your work every 5 minutes because it might crash any time doesn't make you a better dev, it just lowers your standards.

Come on, you are just throwing mud around for some reason I do not even want to know about. It is hard to lose code with Pharo. I have always recovered everything 99.999% of the time. You are happy with VW, fine with me. I cannot stand it.

The reason is Stéphane Ducasse is using his students as unpaid testers[0]. I can't see any other reason he'd make us use the latest technologies as you mentioned.

I also don't like the approach "let's write some code that passes tests and maybe works 80% of the time, and then release a few fixes every week for the next few months". Some of my classmates had to wait for 2 weeks just to get a working version of iceberg for the team project. And by working i mean it managed to clone the project, we kept getting "message sent to nil" and "object X does not understand message Y" errors for the rest of the semester and not just from iceberg. Any of those would be trivially caught in a static language.

Yes, there's a recovery feature. I found it slightly buggy too but it worked most of the time (and yes, i used it a few times). Still doesn't help when the whole image gets corrupted and pharo segfaults on startup.

[0] https://news.ycombinator.com/item?id=16757107

Re: Pharo MOOC

#94

Earlier quoted context omitted.

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.

Except the pain in pharo doesn't come from the difficulty of learning new things or self-improvement but from the buggy environment itself. Learning to save your work every 5 minutes because it might crash any time doesn't make you a better dev, it just lowers your standards.

From your "learning experience report"(Dec 2017) linked further down I see that two of your main gripes relate to Bloc and Iceberg(Git).

* Bloc is not a "Released" subsystem. While its development group report Bloc is stabilizing and encourage more people to start exercising it, Bloc is not on the Pharo 7 Release roadmap. Pharo 6 is current stable release.

* For a long long time, Monticello was Pharo's main source code control system. Responding to general criticism that Smalltalk sometimes lives in its own shoebox and doesn't interface well to "standard" systems, Pharo is spending significant effort on Iceberg to adopt Git as its main version control system (I don't know of any other Smalltalk that has a GUI Git tool). But Iceberg is quite a new subsystem with a Technical Preview release in Pharo 6.0. It was initially slow to draw new users from Monticello as many users were not familiar with git, so bugs remained that were only exposed with broader use. Last December I was trying Iceberg and also experienced crashes with it.

One thing to keep in mind is that Pharo's usually great stability is due to everything being implemented in itself on a garbage collected virtual machine, i.e. memory-violation errors eliminated. Iceberg makes use of the "libgit" external C library via FFI. While this aligns with Pharo's policy of not reinventing the wheel (another oft criticism of Smalltalk) but does allow memory errors that normally could never occur. So the Iceberg subsystem is not a good benchmark to judge the stability of the rest of Pharo.

btw, Lately I've found Iceberg stability quite improved and I started using it daily. Also, based on constructive feedback an improved GUI is planned.

* Around December there was also bug in the new Garbage Compactor related to the conversion of the VM from 32-bit to 64-bit. This is a complex system that took a while to identify, diagnose and correct.

Unfortunately I think you landed in a perfect storm. If the presenter was trying to show off the latest features I guess you got caught up on the bleeding edge of development. Part of the problem here is Pharo bleeding edge is usually quite stable (I use it daily), but we of the Pharo choir better placed to work around any hiccups in order to push Pharo forward. But these should not be exposed to newcomers and you don't have time to deal with them in a classroom setting. I'm sorry this damaged your impression of Pharo, but please understand how your broad statements damage Pharo in turn.

Re: Pharo MOOC

#95
post #32

Even if you are not going to develop any major apps in Smalltalk, its a language worth learning. Teaches you a lot about OO programming

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…

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

Re: Pharo MOOC

#96
post #3

This is kind of an offtopic question, but regardless: Is there any application written in smalltalk in the debian repository? (or any other linux distro)

The only people I've heard of using Smalltalk at all other than in dogfood situations are people using Gemstone. https://en.m.wikipedia.org/wiki/Gemstone_(database)

Gemstone is not "using" Smalltalk. Gemstone "is-a" Smalltalk.

Here are commercial companies that believe in Pharo (in the money on the table way of measuring belief)

http://consortium.pharo.org/

Re: Pharo MOOC

#98
post #3

Earlier quoted context omitted.

The only people I've heard of using Smalltalk at all other than in dogfood situations are people using Gemstone. https://en.m.wikipedia.org/wiki/Gemstone_(database)

Gemstone is not "using" Smalltalk. Gemstone "is-a" Smalltalk. Here are commercial companies that believe in Pharo (in the money on the table way of measuring belief) http://consortium.pharo.org/

Interesting. So am I right in assuming there are:

    - 9 bronze level (1k Euro/year)
    - 5 silver level (2k Euro/year)
    - 11 gold level (4k Euro/year)
    - 5 platinum level (8k Euro/year)
...members of the consortium (based on the color of the surround on the member label/icon)? So that would be ~103,000 Euro per year? Or is that signifying a one-time contribution (vs. recurring annual)? It doesn't look like there has been a consortium report published since 2015:

http://consortium.pharo.org/web/reports

...any ideas what that means? (i.e. they stopped publishing them for privacy reasons, the consortium no longer has meetings, the consortium is no longer active, etc.?) Any ideas on what projects they are currently funding, and how many man-hours of programmer time are being purchased for Pharo in 2018?

Re: Pharo MOOC

#99
post #98

Earlier quoted context omitted.

Gemstone is not "using" Smalltalk. Gemstone "is-a" Smalltalk. Here are commercial companies that believe in Pharo (in the money on the table way of measuring belief) http://consortium.pharo.org/

Interesting. So am I right in assuming there are: - 9 bronze level (1k Euro/year) - 5 silver level (2k Euro/year) - 11 gold level (4k Euro/year) - 5 platinum level (8k Euro/year) ...members of the consortium (based on the color of the surround on the member label/icon)? So that would be ~103,000 Euro per year? Or is that signifying a one-time contribution (vs. recurring annual)? It doesn't look like there has been a…

Its a recurring fee. Of course, its dependent on members feeling they are getting value for money and continuing each year. The platinum level was only recently created.

I don't know what it means that there is not later reports. The consortium is definitely active. It arose because open source software is about people scratching an itch, and often the focus is on the fun stuff and not on the boring, difficult, dirty engineering required to make a product reliable and successful (e.g. operating a CI infrastructure). Pharo arose out of INRIA[1], one of France's publicly funded national research institutes. But their mission and governance structure is not suited to managing non-research engineers dedicated to working on Pharo. So InriaSoft[2] was created to fork off its successful software into consortiums funding pure engineering work on the software as an ongoing concern. At the moment the consortium has one full-time engineer, but hope to get another in the next couple of years if the consortium continues the current growth rate.

AFAIK (I am not directly involved), the main efforts decided by consortium members were:

* Stabilizing 32-bit to 64-bit conversion for Pharo, utilizing and contributing to the OpenSmalltalk-VM project.

* Stablizing Iceberg as our Git/GUI interface

* Maintaining CI infrastructure

btw, There is also the Pharo Association with 82 individual members. [3]

[1] https://www.inria.fr/en/institute/inria-in-brief/inria-in-a-... [2] https://www.inria.fr/en/news/news-from-inria/launch-of-inria... [3] https://association.pharo.org/

Re: Pharo MOOC

#100

Earlier quoted context omitted.

Come on, you are just throwing mud around for some reason I do not even want to know about. It is hard to lose code with Pharo. I have always recovered everything 99.999% of the time. You are happy with VW, fine with me. I cannot stand it.

The reason is Stéphane Ducasse is using his students as unpaid testers[0]. I can't see any other reason he'd make us use the latest technologies as you mentioned. I also don't like the approach "let's write some code that passes tests and maybe works 80% of the time, and then release a few fixes every week for the next few months". Some of my classmates had to wait for 2 weeks just to get a working version of iceberg…

Martin, IIUC you are a student that suffered a class using bleeding edge features. I can understand why you are bitter, but you should not be so quick to disparage Mr Ducasse. Your faculty was his client, and it seems that circumstance was outside his control. From our mail list...

Stephane Ducasse wrote:

> I told them NOT to use github.

> I told them that Bloc was alpha. They got a large list of topics and could have picked another one.

> Now of course we should improve and they too.

Post reply on HN