Hi, On 10/01/16 17:16, Dimitris Chloupis wrote: [...]

I think when people referring to Smalltalk refer to Smalltalk as the language or OOP itself, but thats only the tip of the iceberg, Pharo tries to stay true to vision of smalltalk creating the virtual enviroment where the user can easily create his or her own tools or modifying the existing ones, something that I feel no other language out there can emulate because they follow a non monolithic approach where there is a deep dichotomy between language, libraries and the environment itself. You could say that Smalltalk is the anti-Unix architecture , a great example of monolithic design that works great in practice yet its easy to modify and extend.

[...] A place where I finally got this clear was in the book Tracing the Dynabook by John W. Maxwell[1], where its author says that a fair comparison wouldn't be between Smalltalk and other programming languages, but between Smalltalk and the operative systems paradigm. I had found Squeak in 2005 and even reading something about the Dynabook, but was until reading this text on 2007 when I finally get it. It has a different approach that the classical programming book, but was one of the most enlightening reading for me about Smalltalk, the dynabook and the popular computer paradigm we have today. [1] http://tkbr.ccsp.sfu.ca/dynabook/ Cheers, Offray

Welcome! Norbert

Am 10.01.2016 um 23:37 schrieb Alexandre Bergel <alexandre.bergel@me.com>:

Welcome David!

Alexandre

...

On Jan 10, 2016, at 6:37 PM, David Allouche <david@allouche.net> wrote:

Hello folks.

Some people have already seen me on Twitter and Slack, but I believe there might be some people on the mailing list that did not see those conversations.

As I have done on Slack, I am writing this introduction so people have an idea where I come from and what is my business with Pharo.

I am a professional programmer. My current job is tech on a small company I run with two associates (by the way, we are hiring a good Python web dev with a passion for good code). The product is a SaaS web application for recruiters. They call that an Application Tracking System, it is a workflow, communication and archival system for job applications and candidates.

I started programming 25 years ago with HyperCard, and since I have at least played with Pascal, C, Prograph, asm68k, HP-48 (RPL, Saturn asm), Java, bash, C++, LaTeX, XSLT, Delphi, Scheme, elisp, JavaScript.

I have contributed to GNU TeXmacs where I made important contributinos during about 2 years, as I completed by training as an software engineer, and worked at CNRS in Rennes. Then I got involved in GNU Arch (wrote a Python driver), Bazaar (bzr scm) where I worked with the founding team at Canonical while working on the version control aspect of launchpad.net. After that, I had mostly no contribution to free software, working on financial modeling at a bank and then on my current business. I made a presentation on SQLAlchemy at PyCon.fr 2015.

I am a fan Design Patterns (GoF) and the Refactoring book. My mentor at Canonical (Robert Collins) is heavily influenced by Smalltalk and championed XP there. I always had strong interests in software systems design, programming language design, typography, and user interface design. I feel strongly for the concept of software craftsmanship.

My current job is nice, good pay, lots of independence ; after 6 years working on the same project, I need some fresh intellectual stimulation. And I was recently impressed by the presentation "Nothing is Something", by Sandi Metz, who is heavily influenced by Smalltalk.

http://confreaks.tv/videos/bathruby2015-nothing-is-something

So, I here I came, bumbling my way around the system, looking for intellectual stimulation, and for a way to make a positive contribution.

I was very impressed by the nice welcome I have received. And I see there is lots of useful work to do here.

So that's where I come from when you see me chipping in the conversation here.

Regards.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

"I have seen someone in another thread expressing the desire for namespaces. As a newcomer, I also feel that is something important and missing. But since one of the goals of Pharo is to produce an environment that can be understood by a single person, the lack of namespace might actually be a feature. Namespace are essential for languages like C++, designed for large projects, produced by large teams, where nobody understands the whole system. They embody an industrial approach to programming. In contrast, I have the impression that Smalltalk emphasises regularity to minimise system size, rather than modularity to manage system size, and that it embodies a craftsmanship approach." Pharo contains over 800000 methods spread around several thousands classes and the system has not imploded yet even though we have no namespaces. The reasoning is simple, Pharo does not need namespaces because its not a programming language. Namespaces primary role is not organization so much as prevention of name clashes , this is not a problem for Pharo since it does not allow name clashes in the first place. Thats is happening in the enviroment and not language level, if you want to organise your classes you use packages . Packages also are not part of the language and are also implemented on enviroment level, though one could argue that language is also part of the enviroment. So yes it feelt strange even for not having namespace coming from python but after coding in pharo for over a year its clear to me that pharo does not need it and would probably benefit by more sophisticated and specific implementation when it comes to organisations. But generally speaking we already have plenty of tools that help you locate classes and methods with ease, so that is not much of a problem. Pharo enviroment is far from simple, quite the contrary Smalltalk implementations were always far more complex than you average language like C++, the big diffirence is that the enviroment is constructed in such way to help you deal with complexity. Where modern languages ephasize simplicity pharo and smalltalk in general invest on better dealing with complexity , hence why Smalltalk has been very popular in specific very complex fields like Banking Sector, Shipping etc. C++ is no where as suitable for complex applications , its popularity merely stems from the fact that is OS language with immediate access to OS libraries and massive support. On Wed, Jan 13, 2016 at 7:30 PM David Allouche <david@allouche.net> wrote:

Thank you everyone for the kind responses. I will answer some of the questions and suggestions here.

To get faster to the intellectual stimulation, pick a task / project and start asking questions. And have fun :).

That is good advice, but right now I think I will just explore the system, review changes, and wait for the tasks to find me. There are already more things I want to do than I will probably every be able to accomplish :-)

I think when people referring to Smalltalk refer to Smalltalk as the language or OOP itself, but thats only the tip of the iceberg, Pharo tries to stay true to vision of smalltalk creating the virtual enviroment where the user can easily create his or her own tools or modifying the existing ones, something that I feel no other language out there can emulate because they follow a non monolithic approach where there is a deep dichotomy between language, libraries and the environment itself. You could say that Smalltalk is the anti-Unix architecture , a great example of monolithic design that works great in practice yet its easy to modify and extend.

The fact Smalltalk the language cannot be taken in isolation from Smalltalk the environment became clear rather early on: reading the UPBE and other materials shows that the language itself does almost nothing: it cannot even define classes or packages. It is all part of the environment.

I have seen someone in another thread expressing the desire for namespaces. As a newcomer, I also feel that is something important and missing. But since one of the goals of Pharo is to produce an environment that can be understood by a single person, the lack of namespace might actually be a feature. Namespace are essential for languages like C++, designed for large projects, produced by large teams, where nobody understands the whole system. They embody an industrial approach to programming. In contrast, I have the impression that Smalltalk emphasises regularity to minimise system size, rather than modularity to manage system size, and that it embodies a craftsmanship approach.

Since I am just old enough to remember a time where computer systems could be understood by a single person, I find it an attractive idea to try and produce a modern system with that property.

I can't remember who famous said something like "The only languages worth learning are the ones that changes the way you think about programming..." and I found that with Smalltalk & Pharo.

I am familiar with that idea too. And most good languages provide that.

One day I will have learn some language from the ML family. I choose Smalltalk because it clearly had such a strong influence on the thinking of people who have used it, I thought I could learn

A good way to get your hands dirty is to review fixes submitted by others... https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=45 There are never enough hands there :) (my own action here fluctuates from time to time)

I will try to spend some time reviewing code. That is a good way to get exposed to things one does not even know they exist.

Did you look at Seaside? Since you should be able to read french there is a nice tutorial: tinyBlog. In two days you can build a small web app with a mongo back end.

I have no looked at Seaside yet, I have not even read the corresponding chapter in UPBE. But I certainly will, eventually. The web is an essential part of society today.

Where are you located ?

Paris, France.

It did occur to me that the Pharo community does have a unusually large fraction of french people. But that is not a factor for me.

Thanks again for all the kind words. I am sure this journey is going to be a lot of fun. :-)

sure but namespaces do not solve that problem either. They actually make it much worse. You can have a library named Door by X author and then another library named Door by author Y , hello name clash. Even worse those libraries may contain objects than name class, normally that would not be a problem under the expected usage of name space but lazy coders being .... well lazy... they love to collapse the namespace to reduce typing. So House.Door.Handle will become just Handle which may clash with with the name of another collapsed namespace. Pharo is immune to such issues and the enviroment guarantees that you wont have name clashes inside the image. Namespaces , dont. Add to that that we are very much centralised community around STHub and GitHub which makes it dead easy to find any potential name clash, compared to other languages that are spread all over the internet. So I would say its more a luxury solution than a poor man's. What pharo lacks is something that helps us organise our classes even more and even tag them to form relationships between them. But thats easy to implement the questions is who is going to port the thousands of classes to a new system. On Thu, Jan 14, 2016 at 4:50 AM Ben Coman <btc@openinworld.com> wrote:

On Thu, Jan 14, 2016 at 2:12 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

"I have seen someone in another thread expressing the desire for namespaces. As a newcomer, I also feel that is something important and missing. But since one of the goals of Pharo is to produce an environment that can be understood by a single person, the lack of namespace might actually be a feature. Namespace are essential for languages like C++, designed for large projects, produced by large teams, where nobody understands the whole system. They embody an industrial approach to programming. In contrast, I have the impression that Smalltalk emphasises regularity to minimise system size, rather than modularity to manage system size, and that it embodies a craftsmanship approach."

Pharo contains over 800000 methods spread around several thousands classes and the system has not imploded yet even though we have no namespaces. The reasoning is simple, Pharo does not need namespaces because its not a programming language. Namespaces primary role is not organization so much as prevention of name clashes , this is not a problem for Pharo since it does not allow name clashes in the first place.

Name clashes can still happen between different external libraries. Effectively we have a poor-mans namespaces with prefixes. But its harder to port libraries from other Smalltalks that support namespaces, limiting our ecosystem. Not necessarily the main driver, but worthy of consideration. Squeak has recently done some namespace stuff so will be interesting to see their experience.

cheers -ben

...

Thats is happening in the enviroment and not language level, if you want to organise your classes you use packages . Packages also are not part of the language and are also implemented on enviroment level, though one could argue that language is also part of the enviroment.

So yes it feelt strange even for not having namespace coming from python but after coding in pharo for over a year its clear to me that pharo does not need it and would probably benefit by more sophisticated and specific implementation when it comes to organisations. But generally speaking we already have plenty of tools that help you locate classes and methods with ease, so that is not much of a problem.

Pharo enviroment is far from simple, quite the contrary Smalltalk implementations were always far more complex than you average language like C++, the big diffirence is that the enviroment is constructed in such way to help you deal with complexity. Where modern languages ephasize simplicity pharo and smalltalk in general invest on better dealing with complexity , hence why Smalltalk has been very popular in specific very complex fields like Banking Sector, Shipping etc. C++ is no where as suitable for complex applications , its popularity merely stems from the fact that is OS language with immediate access to OS libraries and massive support.

On Wed, Jan 13, 2016 at 7:30 PM David Allouche <david@allouche.net> wrote:

...

Thank you everyone for the kind responses. I will answer some of the questions and suggestions here.

To get faster to the intellectual stimulation, pick a task / project and start asking questions. And have fun :).

That is good advice, but right now I think I will just explore the

system,

...

review changes, and wait for the tasks to find me. There are already more things I want to do than I will probably every be able to accomplish :-)

I think when people referring to Smalltalk refer to Smalltalk as the language or OOP itself, but thats only the tip of the iceberg, Pharo tries to stay true to vision of smalltalk creating the virtual enviroment where the user can easily create his or her own tools or modifying the existing ones, something that I feel no other language out there can emulate because they follow a non monolithic approach where there is a deep dichotomy between language, libraries and the environment itself. You could say that Smalltalk is the anti-Unix architecture , a great example of monolithic design that works great in practice yet its easy to modify and extend.

The fact Smalltalk the language cannot be taken in isolation from Smalltalk the environment became clear rather early on: reading the UPBE and other materials shows that the language itself does almost nothing: it cannot even define classes or packages. It is all part of the environment.

I have seen someone in another thread expressing the desire for namespaces. As a newcomer, I also feel that is something important and missing. But since one of the goals of Pharo is to produce an environment that can be understood by a single person, the lack of namespace might actually be a feature. Namespace are essential for languages like C++, designed for large projects, produced by large teams, where nobody understands the whole system. They embody an industrial approach to programming. In contrast, I have the impression that Smalltalk emphasises regularity to minimise system size, rather than modularity to manage system size, and that it embodies a craftsmanship approach.

Since I am just old enough to remember a time where computer systems could be understood by a single person, I find it an attractive idea to try and produce a modern system with that property.

I can't remember who famous said something like "The only languages worth learning are the ones that changes the way you think about programming..." and I found that with Smalltalk & Pharo.

I am familiar with that idea too. And most good languages provide that.

One day I will have learn some language from the ML family. I choose Smalltalk because it clearly had such a strong influence on the thinking of people who have used it, I thought I could learn

A good way to get your hands dirty is to review fixes submitted by others... https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=45 There are never enough hands there :) (my own action here fluctuates from time to time)

I will try to spend some time reviewing code. That is a good way to get exposed to things one does not even know they exist.

Did you look at Seaside? Since you should be able to read french there is a nice tutorial: tinyBlog. In two days you can build a small web app with a mongo back end.

I have no looked at Seaside yet, I have not even read the corresponding chapter in UPBE. But I certainly will, eventually. The web is an essential part of society today.

Where are you located ?

Paris, France.

It did occur to me that the Pharo community does have a unusually large fraction of french people. But that is not a factor for me.

Thanks again for all the kind words. I am sure this journey is going to be a lot of fun. :-)

...

I can't remember who famous said something like "The only languages worth learning are the ones that changes the way you think about programming..." and I found that with Smalltalk & Pharo.

Oh, I just found it. Epigram 19 by Alan J. Perlis. http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

Le 13/01/2016 18:29, David Allouche a écrit :

The fact Smalltalk the language cannot be taken in isolation from Smalltalk the environment became clear rather early on: reading the UPBE and other materials shows that the language itself does almost nothing: it cannot even define classes or packages. It is all part of the environment.

It is not the case. For example, to define a new class, the unique way to do this is from Smalltalk itself, with the message #subclass:instanceVariableNames:classVariableNames:category: sent to the parent class. The GUI, just makes it more transparent, but it is pure Smalltalk code. Well it can't be different as the GUI is written in Smalltalk :) Hilaire -- Dr. Geo http://drgeo.eu