Behold Pharo: The Modern Smalltalk

On 06/10/17 21:00, Dimitris Chloupis wrote:
> Again very generic statements , and I see you refer to tools and
> libraries instead of OOP. We talking here Pharo vs Python on the
> language level because Python obviously does not come with an IDE. But
> then Pharo does not come with literate programming tools or libraries
> as well.

No. We were talking about things "that Pharo can do that Python can't do
or is most difficult". And, for me that includes the (community &
computing) environment provided by Pharo that allow you to go from and
idea to its implementation. In my case the idea was to provide an
experience which mix outlining (a la Leo Editor) with literate computing
(a la Jupyter, IPython) [1]. Even if the original pieces where already
there in Python, mixing them was a nighmare (at least 3 years ago) and
Pharo was more empowering for going from idea to prototype and now Pharo
has literate *computing* (not literate programming [2]) tools.
Grafoscopio is one of them. GT Documenter, in alpha now, is promising.
You can not have a single document for complex books in Jupyter. You
need to split/storage a single work in a "pile of files" metaphor. You
can, today, with Grafoscopio put a 300 pages long PDF in a single
notebook. So yes, there are things that are more complex in one
technology that in other (of course all computer languages are the same
at enough distance, because all them are Turing complete and all that stuff)

[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html
[2] http://blog.fperez.org/2013/04/literate-computing-and-computational.html

>
> I rather not go down the rabbit hole of third party libraries because
> obviously I cannot participate in a discussion about libraries and
> areas of coding, I know nothing about. Plus Python has countless of
> libraries which makes a very longer discussion even if I was familiar
> with them and Pharo has much less but still quite a lot of libraries
> as well.

One of the advantages of being in a community is learning from others
experiences. You said that in your experience you have not found a place
where Python were more difficult that in Pharo. I have shown that in
*my* experience there are. And agree, is unwise to discuss about places
where one has no experience, when is better to learn from those who have it.

Cheers,

Offray

I think that there are some communities that are more receptive of live coding, beyond programmers. Scientist, journalists, hacktivists, data visualizers, musicians, come to mind and I have a better experience and more openness to live coding with them that with the "classical programmer/coder". With our recent Data Journalism Handbook, adaptation in Grafoscopio [1] and our recurrent Data Week hackathon+workshops[2], we're trying to reach new audiences and communities.

[1] http://mutabit.com/repos.fossil/mapeda/
[2] http://mutabit.com/dataweek/

Cheers,

Offray

On 07/10/17 07:40, Dimitris Chloupis wrote:

Yes I agree with this

Pharo is a live coding BASED enviroment. For Pharo live coding is not just an easy to use feature it based its entire mentality around the idea of live coding.

Even though Smalltalk borrowed live coding and image format from Lisp we are more "pure" in that regard even compared to Lisp. 

But one thing to note here is that live coding is not really that useful when used always. At least for me I rely a lot on it for debugging and experimenting. But when I work based on a plan , or code just works I do not care so much about it. 

So my workflow in the end is semi-live coding because I dont feel I need live coding 24/7 to be super productive. 

Of course that creates some barriers in the end when tools are not made to work 24/7 on a live coding context. To that extend Pharo is definetly superior and a true live coding enviroment.

You are suprised that you can do live coding in C++ but I was trully shocked. 

My saga to do live coding in C++ started as a joke, something to use to mock C++ ugliness and weakness. But oh boy it did slap it back to my face. 

The process is again simple, you wrap eveything inside a main loop,and call in this loop functions (C has no objects obvious) or methods if you use C++ from DLLs. Those DLLs obviously contain 99.9% of your code. Because a DLL can be reloaded it allows you not to stop executing and replace code on the fly. The main loop is wrapped inside an exception to make sure the an error will never crash your application, C/C++ exceptions are more powerful than Pharo live coding in that regard because in Pharo if you do anything bad with UFFI and crash it , it will crash for sure. 

If you keep the DLL small and  you use tons of small dlls your compile times will be almost instantenous. You can also with very view lines detect date signature change in source file and trigger background compilation. Again few lines of code. The last mountain is live state, in this case the executable pass a single pointer and instead of the executable handling the memory its actually the dlls that handle it but the executable because it cannot crash or exit will keep the live state running. You can also use memory mapped file to store live state as they perform pure memory dumps. 

All in all you will end up with 100 lines of code that can be wrapped into a library and reused in the next project with zero setup. Its an one time pain. 

Will I would recommend C++ over Pharo for live coding .... helll no.... C++ obviously misses a hugely important live coding ingredient which is reflection. We do live coding because we want to interact with those objects ask questions about what is going on and why our code does not work as intended

However Python has no such limitation following a very similar design to Smalltalk and being much more powerful language than C++. Python follow very closely the Smalltalk paradigm even though there is not a single mention of Smalltalk , anywhere in the Python community or of live coding.

 

Live coding in C++ has become a huge deal in game development mainly because game development tend to want to change things on the fly and games are so big with extremely long compile times. Unreal has made a huge deal over its ability to hot reload C++  code in its editor , though I do not like its approach so much.

Bottom line is yes its easy and simple to do live coding in other languages, not recommended so much in C++ because of its static compiled nature and lack of reflection but for dynamic language like Python it can come pretty close and I speak from experience. 

At least I have not found something in Python that made me wish I was live  coding in Pharo so far, but then yes I still think its better to have a full blown live coding. Also from my limited understanding I have figured out that pretty much every language out there allows for reloading code which is pretty much a very large requirement for live coding. 

So yes you can live code to an extend, lesser in languages like C++ , more so in language like Python, Ruby etc. Can you get the Pharo experience ? In a dynamic language with the creation of a live coding library you could get pretty close but never exactly the same.

Pharo still is the undisputed king of live coding. 

Why live coding is not a huge thing in coding in general, I am willing to bet it has more to do with coder mentality than language limitation. When you are used to "dead  code" workflow it difficult to switch. I struggle a lot to get use to the live coding workflow of Pharo because I had to rewire my brain. But in the end you cannot avoid live coding, there will be always scenarios you would want to change things on the fly, reload code, store live state etc. 

In the end it more a coder flaw than it is a language flaw. I know we love to blame languages for our mistakes. 

But in our back of our head we all know we debate over languages that we barely use only 0.000001% of their true potential. We are too lazy and sometimes we need someone to slam our face to the truth to actually see it. And by we I dont mean the Pharo community but human nature by itself.  That's exactly what Pharo did for me that motivated me exploring live coding in other languages. 

If it was not for Pharo I would still be doing the old slow method of correct, compile, restart and repeat till you hate yourself. 

On Sat, Oct 7, 2017 at 1:57 PM horrido <[hidden email]> wrote:

> My point is that indeed you can do with EASE live coding in a numerous
languages, at least to my experience. I have tried only Python and C/C++.

Until I came upon this thread, I never knew you could do live coding in
Python and C/C++. And I was a professional C/C++ programmer for over 15
years!

It is certainly a well-kept secret. I have found very little information on
the web about doing live coding in these languages (in fact, none). This
leads me to believe that the vast majority of Python and C/C++ developers
don't know about, or don't do, live coding.

Whether it's "easy" is rather subjective. I suspect it's not as easy nor as
convenient as in Pharo. If it were, then live coding ought to be much more
prevalent in the Python and C/C++ communities. After all, what developer
doesn't want to improve their productivity or increase their velocity of
development?

The key differentiator here, I think, is that live coding is baked into
Pharo/Smalltalk, thus making it natural to use. It is not natural for Python
and C/C++ programmers. It would be difficult to convince the IT industry to
adopt live coding en masse.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I never claimed that Python , which refers to CPython to the vast majority of python coders, is offering live coding out of the box. The fact that you have to reload modules manually would make such claims ridiculous.

From the very first post I was crystal clear that there is a need for creating a library that handles live coding for you and gave general instructions of what this library will have to do.

My claim is that Python and other languages CAN do live coding.

I NEVER claimed also that Python is a live coding environment which it stores in an image format. In short Python IS NOT Pharo. Period.

Can python reload modules ? Yes
Can python trigger the debugger in case of error ? Yes
Can python replace methods and variables during execution ? Yes
Can python recompile individual methods and classes and replace their previous instances ? Yes
Can python make you coffee ? Nope
Etc etc

Depending how deep you want to go live coding wise your live coding library will enlarge.

From my experience around  100 lines of code are enough to offer most of Pharo’s basic live coding functionality. Such task that needs to happen only once and then simply reused in each project that wants to utilize live coding , for my standards it is easy. It won’t be easy for a beginner python coder cause he may not even know what OOP is. So obviously I am referring to experienced coders. It won’t be easy if you want to fully replicate Pharo’s live coding capabilities , because you will Definetly go way beyond 100 lines.

I stated this before and I will state this again Pharo IS HANDS DOWN THE BEST LIVE CODING ENVIRONMENT I have ever used.

My point is that other languages CAN do what Pharo does. Even though they are NOT live coding environments. They just have the features to be live coding environments.

Jython has had a lot of problems using CPython libraries, live coding is the least of its problems. This is the reason CPython has almost the monopoly of python coding.

I just don’t like it when other languages are illustrated as garbage and Pharo as the holy grail. They all have their pros and cons. 

Can’t help with Jython , I used it on the premise that I may need Java libraries, I ended up finding what I wanted in CPython and have not touched it since. 

My post were not made to pick a fight but rather to inform and demolish the wrong assumptions that other languages CANNOT DO live coding. 

If we are to compare them the least we can do is do it in a fair and sincere way.

On Mon, 9 Oct 2017 at 20:06, webwarrior <[hidden email]> wrote:

kilon.alios wrote
> Care to explain what difficulty you experienced in live coding with
> Python.
> Or what Pharo can do that Python can’t live code wise ? Maybe I will learn
> something.

It's funny that one of main reasons why I discovered and started using Pharo
was failure to get live coding working for Python (Jython in particular).

And now time after time kilon.alios states that live coding in Python is
"easy" and no big deal.

I will tell you, Pharoers, about code reloading in Python, and let you
decide for yourselves how it compares to Pharo.


Out of the box in Python you can execute some Python code and reload modules
with reload() function.

What reload() does is it reads code from file (in Python each source file
corresponds to module), executes it, and replaces reference to [that module]
in current module.
From that moment, any code in current module, when referencing reloaded
module, will point to new version of it.

All implicitly imported names will (like from foo import bar, from foo
import *, etc.) will point to old version. Also all other modules except
current will not be affected.

There are, however, third-party libraries, that take care of it.

But that's not all. All instances and subclasses of old classes will point
to old versions of classes.
To counter that, instead of replacing old module you could replace its
contents by newer variables/functions and patch classes by replacing their
contents.
Some third-party libraries do that.

That's still not all. If you store references to functions/methods/classes,
that references will point to old versions.
reimport library takes care of that, but it uses implementation-specific
feature of CPython's GC, which lets you get all references to some object.
Unfortunately, it doesn't work in Jython, and probably in other alternative
Python implementations.

But wait, what if you rename a class or function, or change its base
class(-es)?
You're out of luck. Theoretically you could handle such change if recent
code change consists of a single rename, but that's it.

I may have missed some other edge cases and haven't talked about tools
support, but I hope you get the idea.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html