
Phratch: A port of Scratch on Pharo - mr_tyzic
http://www.phratch.com/
======
AceJohnny2
Can someone give me a TL;DR on what Pharo is? It's website is infuriatingly
vague. It seems to be a visual programming environment based on a language
related to Smalltalk? In which case, it's similar to Scratch, and in which
case what's the point of porting Scratch to it?

Edit: ah, the old Pharo website (accessible through the link at the top), puts
front an center "Pharo is a clean, innovative, open-source Smalltalk-inspired
environment". OK then. Good job on redesign that _loses primary information_.
/rant

~~~
AceJohnny2
Extra rant: I love the idea of Smalltalk and of reactive environment/IDE
(projects like excellent Lighttable try to emulate it), however in the case of
Scratch and Pharo this comes at the cost of bootstrapping. You're doing the
Bender thing: "fuck your OS and tools, I'll create my own OS and tools! With
Blackjack! And hookers!". As a result, it discards all the tools and
facilities we've built and are familiar with. I'm using a tiling window
manager and I love it. Why should I discard that entirely that to use Pharo's
own inferior window manager? I've invested much pain and effort into learning
Emacs. Can I bring over no skills from there to your environment?

Essentially, the transition cost to these Smalltalk environments (be it
Scratch, Croquet, or Pharo) is too high to ever gain critical mass. And that's
a shame. Considering how regularly this situation is repeated, I have to ask
if it's something inherent to Smalltalk? Or its legacy?

~~~
vfclists
You got it wrong actually. Smalltalk is not supposed to integrate with
everything. It is everything which is supposed to become Smalltalk based, the
desktop/working space, the GUI and the IDE, right down to the OS and the
kernel.

Smalltalk was not designed to be a programming language. It was intended to be
the whole system. I think those developers who are treating and developing
Smalltalk only as a programming language and a development environment have
got it wrong, although it is the pragmatic thing to do. People who are
ignorant of Smalltalk simply don't understand how backward contemporary
computing its, relative to the way it should be now, 30 - 40 years after the
first implementations.

After it emerged, the industry majors simply diverted it way from the original
vision of its developers, which was focused on exploring and developing for
personal use either recreational or work related, and turned it a development
tool costing thousands of dollars.

My own interpretation is that the industry majors stifled it, masking the
process as bad business and marketing decisions.

I mean what could be possibly have been wrong with Smalltalk when the IBM's
first Java implementations and IDEs were built with Smalltalk, and Sun bought
out the company which developed one the fastest Smalltalk implementations to
put their developers into creating Java?

I think the current problem with open source Smalltalk is that the developers
are spread among different implementations. It would be better if there was
one vision and one implementation that they all focused on.

~~~
seanmcdirmid
> It is everything which is supposed to become Smalltalk based, the
> desktop/working space, the GUI and the IDE, right down to the OS and the
> kernel.

Correct. This is a strength and a weakness. I was enamored to Smalltalk early
on (back in 95 when I learned it in a course) for this very reason. But then
the Internet was happening, the world of computing became a lot more
heterogeneous, and the idea of a mostly uniform world of computing mostly
faded away.

> I mean what could be possibly have been wrong with Smalltalk when the IBM's
> first Java implementations and IDEs were built with Smalltalk

It was handy after IBM's acquisition of OTI.

> Sun bought out the company which developed one the fastest Smalltalk
> implementations to put their developers into creating Java?

This is inaccurate. Animorphic was bought out for its compiler technology to
improve Java; Java was already invented at that point.

> It would be better if there was one vision and one implementation that they
> all focused on.

Developers are moving on to new things. There is Dart of course (if we are
talking about developers of smalltalk), and Kay's VPRI which are attempting to
develop the next best thing.

~~~
vfclists
> Correct. This is a strength and a weakness. I was enamored to Smalltalk
> early on (back in 95 when I learned it in a course) for this very reason.
> But then the Internet was happening, the world of computing became a lot
> more heterogeneous, and the idea of a mostly uniform world of computing
> mostly faded away

I don't think it was the world of computing becoming more heterogeneous, it
was more the desire of the industry majors to push their own backward
technologies.

What prevented Smalltalk from being used as the tool for developing web pages
instead of Java, other than Sun wanting Java to proliferate by making it free,
and IBM and the other Smalltalk developers messing up Smalltalk? And today we
have Oracle threatening Java by insisting that copying of APIs is infringing.

What prevented the Smalltalk interface from becoming the browser interface as
well as its main development tool? This was the original idea, the original
vision the Dynabook vision.

Smalltalk developers should develop it along the lines of Smalltalk/X or
Smalltalk/MT and build it all the way up and down as well. Trying to fit it
into environments which the industry majors are bent on fragmenting and
thwarting in order to buy time put their software, multimedia and storage
rental models into place simply won't work.

> Sun bought out the company which developed one the fastest Smalltalk
> implementations to put their developers into creating Java?

I meant the VM

> Developers are moving on to new things. There is Dart of course (if we are
> talking about developers of smalltalk), and Kay's VPRI which are attempting
> to develop the next best thing.

The Dart developer experience will never match the Smalltalk developer
experience and VPRI is also building on the crippled Javascript/HTML/DOM
foundations.

I can't see why these smart guys don't see that you cannot build on systems
which the industry majors are deliberately hobbling in order to buy time to
put the rental models into place. They break it and complain that the
standards bodies are slowing things down _when they and their proxies are the
standards bodies._

Smalltalk developers need to knuckle down and get their NPAPI/Pepper/NaCl act
together. As that is the only way they can succeed with a browser based act.

