Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 innovations that were ahead of their time.

EDIT: while doing the Pharo mooc, I was able to create a DSL for what I understand to be D&D dice representation without using special metaprogramming syntax of the language or parsing and tokenizing strings. Just plain old OOP of the Smalltalk/Pharo flavour. This were just basics btw



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


Kinda weird to move the goal posts like this.


The goal posts started at "the multicore + GPU party."

For example: "Optimizing Machine Learning Performance at Netsuite with GraalVM and NVIDIA GPUs"

https://medium.com/graalvm/optimizing-machine-learning-perfo...


How else is GPU-support for a programming language to be understood other than that you can write GPU shaders/kernels in it?


I don't like Pharo because they changed it too radically from Squeak, which I DO like very much.


As a curious outsider - what are the key differences between Squeak and Pharo that make it worse in your eyes?


They removed a lot of the capabilities of Squeak and most of the nice legacy code included for educational and historical purposes, and neutered the object inspection tools. I understand that Pharo is no longer Squeak and the whole idea was to simply take Squeak and change not just the UI but the actual language. But I'm just a Squeak person.


actually, from pharo's perspective the goal was to remove bloat, things that didn't help active new development. as a result pharo images were smaller, and didn't have to support lots of old legacy code or objects.

another problem that squeak had was that it was built on top of old images, containing objects that date back to the beginning of squeaks history, and possibly even older than that, and because of that it was (at least at the time) not possible to verify the ownership and license of all the source that the image was made of. for some objects the source was even lost altogether. this made squeak incompatible with FOSS licenses and it was a reason why it was not included in linux distributions. which is one factor that limited its spread among developers.

one of pharo's goals was to remove those old objects and unverified source and make it possible to build new images purely from a verifiable source.

from a certain perspective, the inclusion of those old objects creates a certain sense of awe, considering who were the people that worked on smalltalk that created these objects, whereas pharo in that respect feels more sterile.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: