Live data from Hacker News

Pharo 12

pharo.org

71–80 of 116 posts

Re: Pharo 12

#71
post #36

Earlier quoted context omitted.

I agree with you. I've worked for a while at a company using it in production [1]. For learning Pharo (while not working at a company), I've learned that going to ESUG [1] and Pharo Days [2] (2 conferences) is the best way to actually learn. On ESUG there are many professional Smalltalkers, including people that write Pharo. And on Pharo Days there are many OG Pharo devs. They can teach you certain things much quicke…

I think Pharo would benefit a lot from having lots and lots of screen casts, since so much stuff is visual. I don't think something like ESUG is a sustainable way to spread techniques. A lot of stuff that is well documented in the Pharo ecosystem is old. A lot of the new stuff doesn't have great docs. Just reference docs and code is not enough. There has to be a coherent narrative around an API to put it together. Al…

i agree. here is a screencast i made: https://news.ycombinator.com/item?id=38995507

i don't know how much has changed since then. but if pharo has changed so much that this screencast can no longer be used then that's a problem in itself. we are not going to gwt more screencasts if their halflife is to short.

Re: Pharo 12

#72
post #51

Many comments in the vein that pharo is weird and different from what they're used to. I'd say programming is such a young field programmers should dedicate time to try out the weird stuff that they aren't used to, opportunities to rewire your brain for better. Let's not get stuck in a local minima on how to do programming. There could be better ways not yet popular enough. Smalltalk came out of an environment of inn…

[deleted]

Re: Pharo 12

#73
post #11

Is any thought being put into adding parallelism in the future?

https://github.com/smarr/RoarVM is the main thing that comes up when trying to learn about this, and it hasn't been touched in over 10 years. I have also seen people working on spawning child VMs to handle parallelism, though unfortunately I don't have links to those discussions immediately at hand. It seems like perhaps an unnecessarily heavyweight approach, too, not a canonical solution that you would want to use in production.

I assume that step 1 towards parallelism, at least on the image side, would be going through the class library and making sure everything is thread-safe. I'd love to know where one would even get started with that effort. The Roar project claims to support Pharo 1.2, which doesn't seem to be very far after they forked from Squeak, but obviously a lot has changed since then. And the challenge is that Pharo is still rapidly developing all the overhauled classes that distinguish it from Smalltalk-80.

Meanwhile, if I want to play with parallel image/REPL-based programming, I can go over to Common Lisp and, while lacking an equally coherent GUI, be able to load up bordeaux-threads and off I go.

Re: Pharo 12

#74

It seems too research-oriented programming IDE+language, where there is not a big market compared to other areas. Who does Pharo want to compete with? Maybe developers think they shouldn't compete with other platforms? With the amount of real Pharo apps right now even on GitHub, it would be extremely difficult to "sell" Pharo to any decision maker.

Why would that be hard? Once you're fluent in it development in Pharo is very, very fast, you can build a GUI application while a prospect or customer is watching and supplying inputs about what they need.

Many companies that buy software don't care about programming languages, they care about functionality and price. With Pharo you can show them immediately what the application could look like and how their processes could be implemented. Fast development means you can sell at a lower price and reach customers that can't afford more 'classic enterprise'. You can also reach customers that do work in quickly changing regulatory environments, like insurance.

When you've banged out the frontend and some logic you return to your office and figure out things like database schema.

Pharo is specifically designed for commercial and industrial applications and not as a research environment. Partnering with private capital has been one source of funding for the project.

Re: Pharo 12

#75

Earlier quoted context omitted.

I agree with you. I've worked for a while at a company using it in production [1]. For learning Pharo (while not working at a company), I've learned that going to ESUG [1] and Pharo Days [2] (2 conferences) is the best way to actually learn. On ESUG there are many professional Smalltalkers, including people that write Pharo. And on Pharo Days there are many OG Pharo devs. They can teach you certain things much quicke…

My initial burst of enthusiasm was dampened by the big gap between the entry-level introductions (ProfStef tutorial, the introductory MOOC) and the sheer complexity of everything the image includes. I'm not a big-time Java developer, I certainly appreciate the elegance of the language and dev environment compared to, say, Python, but that huge list of packages and their Baselines in the left pane of the system browse…

Start with the Finder and the Examples-category if you want to know how to do something, don't browse the full package list in the hope you'll stumble over something useful.

There are small communities outside the Discord having meetups and whatnot. Would probably be nice to have a Discourse-instance for a more documentation-like meeting place, but that requires money and volunteers doing moderation.

I enjoy that some docs and other resources aren't expressed in US:ian advertising lingo. It's not a bug, it's a feature.

Re: Pharo 12

#76
Smalltalk is one of those "I'd like to learn" but haven't found a good resource that I like (oh and the time, sigh).

Re: Pharo 12

#77
post #67
post #55

Earlier quoted context omitted.

Smalltalk had a moment at the transition from green screen to PC's, fumbled the everything is a string internet, and never showed-up for the multicore + GPU party. Meanwhile the nasty statically type checked languages lowered the pain level with non-nullable and type inference for local vars.

Pretty sure Pharo has had GPU-support for a long time, and there's RoarVM for "manycore" applications in Smalltalk.

> Pharo has had GPU-support for a long time

For highly parallel general-purpose computations? Tell us more!

https://chapel-lang.org/docs/technotes/gpu.html

As-already stated in this discussion RoarVM "hasn't been touched in over 10 years". This discussion is about the Pharo 12 release and supposedly RoarVM is "compatible with Squeak 4.1 and Pharo 1.2 ".

https://github.com/smarr/RoarVM

Re: Pharo 12

#78
post #58
post #19

Earlier quoted context omitted.

Yes last time I checked they had their own versioning system as well... it's one thing to learn a language but having to learn a whole new set of tools put me off in the end. I guess I can see the argument that the Smalltalk files are not plain text but rather images (or something), but having to basically download a second OS within the OS just to write Hello World was off putting. I realise that that's also can mak…

> to learn a whole new set of tools The tools are how we find functionality that can be re-used and re-purposed to do what we need. A lot of exploring and reading existing stuff, less writing new stuff. > Smalltalk files are not plain text but rather images (or something) Mostly Smalltalk files are plain text files! There's a plain text log file with a replayable record of what you've been doing. There's a sources fi…

That's fine, I understand that a lot of my criticisms are arguably actually advantages, but after doing the MOOC about 8 years ago I just couldn't stick with it. Fun though, and a great way to really learn OOP at the time when I was just starting out programming.

Re: Pharo 12

#79
post #71
post #36

Earlier quoted context omitted.

I think Pharo would benefit a lot from having lots and lots of screen casts, since so much stuff is visual. I don't think something like ESUG is a sustainable way to spread techniques. A lot of stuff that is well documented in the Pharo ecosystem is old. A lot of the new stuff doesn't have great docs. Just reference docs and code is not enough. There has to be a coherent narrative around an API to put it together. Al…

i agree. here is a screencast i made: https://news.ycombinator.com/item?id=38995507 i don't know how much has changed since then. but if pharo has changed so much that this screencast can no longer be used then that's a problem in itself. we are not going to gwt more screencasts if their halflife is to short.

Looking over the syntax, it seems that lines end with a period, much like in English. This makes much more sense than semicolon!

That said, it looks like you end up with a million windows to do anything. Seems like the UI could be better UX'd, no? Guessing this a community that would treat such a comment as harassment.

Re: Pharo 12

#80
post #56

Earlier quoted context omitted.

Squeak / Pharo are alternate timeline technologies. Maybe the one where Betamax won and Al Gore read the intelligence briefing. Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. Rust is radical in some ways, but it's fundamentally a creature of the vaguely Unixy paradigm we all…

> Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. I would argue that this lineage of computing isn't as arcane and out-of-reach as people might think. Much of the "obvious" promise of Smalltalk / object-based runtime environments — specifically, all the UI stuff it enabled — w…

Also Inferno on DisVM, various Forths, and modern web browsers (especially running Lively JS)
Post reply on HN