
Pharo Smalltalk IDE as Visualizer: Mondrian in Action [video] - i_feel_great
https://vimeo.com/143858200
======
vixen99
Looks interesting. A bit of explanation and background would be useful for
those not familiar with Pharo. As I've mentioned before, a major IT publisher
offers not a single book on Pharo or even Smalltalk where publication dates
range no further than 1999. Have I missed a later one aside from the excellent
'Pharo by Example' and 'Deep into Pharo' available free online? I believe the
community is buzzing but somehow I don't get that impression from without the
inner circle of enthusiasts. Seems a pity.

~~~
mariodiana
"Click with the mouse on the background of the main window to show the world
menu, then choose Workspace to create a new workspace."

That's from "Pharo By Example." Only, if you download Pharo today, the above
description (and the illustration in the book's text) don't match the way
Pharo works. As far as I can tell, Workspace is now called "Playground."

This is the problem with projects like this; and, believe me, I have been at
least somewhat interested in Smalltalk for years. When I download something
and come across the above by Page 3 or so, I just expect a lot of extra little
frustrations that I don't need, and that turns me off to the rest of it.
Smalltalk is different enough to begin with. I don't need extra aggravation.

~~~
estebanlor
But Pharo by Example comes with a Pharo version suitable with the book, you
just hasto download it and use it. Of course, is an old Pharo version (1.1, I
think), but enough to learn and jump to the newer versions. There is an update
of the book coming soon too, btw).

------
agentultra
This is a really useful tool. A related project, PetitParser, makes it fairly
straight-forward to turn a grammar definition into a working parser and
mapping that data straight into Mondrian is simple. I have a mostly working
Python parser already and I've only spent an hour at lunch and a short break
on it. Can't wait to get this going tonight... something I've wanted for a
while!

 _update_ Spelling, grammar

------
i_feel_great
This is the IDE that is used to code in Pharo Smalltalk itself, not a
separate, external tool.

------
azeirah
Damn.. I've seen Pharo and smalltalk before, I really want to learn this
somehow, I want to use it as my programmable operating system

------
marvel_boy
Wow ! I love dynamic languages. Smalltalk is by far the most awesome language
I've ever seen.

~~~
pjmlp
Yep. This is why I always think the programming world did a left turn by
adopting UNIX tooling instead of what was going on at Xerox PARK.

It is not only Smalltalk, Lisp had a similar environment,whic was the Genesis
of Lisp Machines.

Similarly you had Mesa/Cedar. Think of a similar dynamic environment developed
in a system programming language with RC and a GC for cycle collection.

So now we have to reach for IDEs, INotebooks, Playgrounds and similar tools,
keep on fighting on the adoption of safe languages for system programming, so
that we can catch up with the past.

~~~
progman
> This is why I always think the programming world did a left turn by adopting
> UNIX tooling instead of what was going on at Xerox PARK.

The real reason was that Unix (which is written in C) runs way more
efficiently on legacy hardware, orders of magnitudes faster than Smalltalk and
Lisp, even on special Lisp hardware. Performance was really an issue in those
days.

If Lisp and Smalltalk would have had modern PC power at their time then things
likely would be very different today.

~~~
agentultra
I think performance is still an issue today. We have orders of magnitude
faster hardware as you say but the software is still slow as molasses.

The C99 specification is much more interesting than the K&R C of yore. And it
still gives the programmer a close mapping between language and target
hardware platform.

Pharo is super-awesome to work with and play in. However I won't be writing
large simulations or ray tracing rendering systems in it any time soon. I'll
have to wait another couple of decades before that becomes feasible.

Fortunately the FFI API in Pharo let you hook into C code fairly easily.

~~~
zeveb
> We have orders of magnitude faster hardware as you say but the software is
> still slow as molasses.

Modern Lisps, at least, are fast enough, albeit not often as fast as or faster
than C.

~~~
agentultra
Some can be which is interesting enough to stick with them. Lisps that compile
code to the target platform and give the programmer control over stack vs.
heap allocation and memory layout... interesting. The meta-language features
remove the need for a separate code-generation tool to handle boiler-plate
like generating jump and decision tables.

However with CL and most of the popular "modern lisps" you're still stuck with
allocating everything on the heap and having to compile in a GC into your
image along with the rest of the ball of mud. You can get pretty fast code at
run-time if you're mindful and precise... but it's still pretty hard to
debug... and of course, incurs an overhead.

"Well we have the processor cycles now to make it feasible!"

Well... just barely. We tend to think people don't mind waiting thirty seconds
for our browsers to load or seeing the beachball-of-doom when working on a
large document... but I think that's pretty wrong.

~~~
pjmlp
Common Lisp allows for stack allocation and offers many more data structures
besides Lists.

What I am missing here in regards to the likes of Allegro Common Lisp, for
example?

Never used them, hence the question.

~~~
agentultra
wrt stack allocation are you referring to DYNAMIC-EXTENT? It's implementation
dependent so you have to know your compiler well. Allocation in C is
explicitly a part of the language on the other hand. A conforming compiler has
to initialize the memory you ask for in the place you tell it to (at least
with optimizations off you can think of it this way):

    
    
        uint32_t flags[100];
    

vs

    
    
        (defun form ()
          (let ((xs (make-array 100 :element-type :unsigned-int)))
            (declare (dynamic-extent xs)
              ...)))
    

The CL example could optimize _xs_ depending on the implementation and its
configuration to allocate it on the stack. The C example has to initialize
enough memory on the stack for 100 32-bit integers no questions.

I hope I didn't give the impression that lists were the only data-structure in
CL; I use structs, arrays, and macros to manage structs-of-arrays, etc. Plenty
more of course.

I do prefer to use CL but I end up spending more time in C/Python for reasons.

What I find interesting in lisp land are lisps that don't try to take over the
whole system and whose principle design is to be small and fast. C has a large
run-time library but you can compile programs without it if you're willing to
write your own stuff. You don't have such control in the open source
implementations I've used.

The open source CL implementations, afaik, still lack tree shakers to try and
remove unused code from the image prologue before running the top-level. SBCL
still produces a 25MB binary to print "Hello, world!" to the console...
because you still have to compile in a GC, the entire CL library, the
implementation's run-time, etc -- even if your code never uses it.

~~~
lispm
> It's implementation dependent so you have to know your compiler well.

In any larger application you have to know your compiler and the special
libraries well. GCC, CLANG, whatever...

SBCL is kind of large. Other open source Common Lisps create smaller
applications: CLisp, CCL, ECL, ...

Some thought there was a use for delivery Common Lisp with or without GC. But
it has not caught on widely. See for example Thinlisp, CLICC, mocl (derived
from CLICC) and others. Those have compilers written in Common Lisp, which
translated the code to static C. In case of Thinlisp without GC - its origin
is in soft-realtime expert systems for process control. Thinlisp is probably
not much used, but a related compiler (not publicly available) is still used
for product development.

There were and still are inhouse delivery compilers.

Also specialized languages: You develop in a Common Lisp environment, but
write in a special language. SubL, Stella, ... For example Cyc is written on
top of SubL, which is derived from Common Lisp (and can be used inside Common
Lisp) and the Cyc application then can run on top of C or Java.

------
jevgeni
This is eye opening...

