Behold Pharo: The Modern Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
167 messages Options
123456789
Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

kilon.alios
That's definetly not a wrong view point, but neither is python's , its all about context. Who you are ? What you want do ? What live coding means to you ? How you want to use it ? How much you want to use it? etc

If you want to do Pharo coding the pharo way , then Pharo is your No1 choice, but if you want to Pharo coding the python way , Python is your No1 choice and  etc. 

Thus I never pick sides in language wars , I am participating merely to find things I do not know. Like I just found about become in the VM list, though I still wait for enumarion of classes and reified frame stacks to be explained as well.  

I am here to learn as much I am here to teach. Well ok , more likely to learn :D 

For example messages vs method calls. What happens if method calls are executing by reference, does that make them cross message territory?. Meaning you use a name to hide the reference to an object of a method. You change the reference to the method but without changing the name of the call. Or what happens when you extend the MethodObject to cross message territory, is this still "bastardised OOP" or Alan's Keay great regret of naming it "OOP" ? OR is it smalltalkish OOP in python , or is it something more ? 

Those question do fascinate me.Languages are so fluid, its like clay in our hands. We live in very exciting times.    

On Thu, Oct 12, 2017 at 11:08 AM Nicolai Hess <[hidden email]> wrote:
2017-10-12 9:28 GMT+02:00 Dimitris Chloupis <[hidden email]>:

 
This is what Smalltalk gives you for free.
Sorrry for being rude but I wll use the two usually heavily annoying word, at least for me :D

It depends

See there is a problem for Python here. Ideology. 

The zen of python has been both a joke a serious mantra in the python world . Its a joke because its obviously oversimplify decision making in such a complex subject as language designe but is serious because it clearly illustrates the philosophy of its creator, Guido van Rossum. 


 Guido is not any less of a rock star to Pythoners than Alan Kay is for Smalltalkers. The zen has become so popular that is even included in python implementation and can be fetched as the link says using the "import this" in any implementation of Python. It's the very sould of python as messages and objects are the very soul of Smalltalk.

So the problem here is that a live coding enviroment brakes the second rule. "explicit is better than implicit". Because live coding in Pharo and Smaltalk is about replacing old instances with new while keeping the state it non the less an implicit behavior and especially become is a no go scenario for python because not only replaces references to an object it also breaks the references to the other object. Of course the old object is garbage collected and RIP. Python follows this rule very strictly.

Thus means that not only that Python will not offer a live coding enviroment in the future as the basis of its implementation . It means it does not want to. It may offer it as part of its extensive library.

That also leads us to the inescapable conclusion that nothing comes free, everything has a cost. Because there will be scenarios you dont want to lose your old instances or not affect them at all and instead affect only the classes or maybe you dont even want to do that and want to do something else.


Hm, we have our own Pharo Zen, which includes a
Explicit is better than implicit.
So we are violating our own (zen)rules :)

in my point of view, live or interactive coding has not much to do with explicit or implicit program code.

Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

Stephan Eggermont-3
In reply to this post by Markus Stumptner
On 12-10-17 08:30, Markus Stumptner wrote:
> Just to lead this back to the original question.  What you say is
> undoubtedly true.  It is not, however, necessarily something that a
> beginner will understand or be able to share in.

That is a very important point. It also explains a lot of why we are
missing certain things that developers coming from other environments
take for granted: they simply provide less value to experienced
smalltalkers. And that is indeed a barrier to entry.

I remember sharply my first looking at squeak, and just not
understanding how I could create a new class or method in a browser.
Another was that I have been programming in seaside for a year without
using senders and implementers. Pair programming for an hour with
Philippe Marschall showed me so much invisible/hidden functionality.

Other (mainstream) environments don't provide the immediate feedback of
navigating, inspecting and manipulating the whole environment, and
therefore newcomers have no appropriate expectations (internal model),
and are clueless on what they are able to do in Pharo. Combined with the
lack of systematic visual clues and the high density of the class
library that makes it not easy to learn.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

kilon.alios
The one things I trully miss, even know that I am "experieced" Pharo coder, depending on your standards, is python namespaces 

I dont care about the dot syntax but containers of containers at language level that will make me avoid giving weird names to my Pharo classes to avoid potential collisions is a must have for me. It would also make the System Browser experience much smoother not only for beginners but also experts in Pharo. 

Also again under the threat of being thrown tomoatoes (probably justified) I would not mind a more modular approach to image format, for example having mutlipe files instead one monolithic. Not as a mandatory thing just something optional, the ability to break an image to pieces , send those pieces around so people do not have to close their image to open yours. Fuel covers this case nicely but again it could become a bit more "out of the box" and more automatic. . 

On Thu, Oct 12, 2017 at 11:22 AM stephan <[hidden email]> wrote:
On 12-10-17 08:30, Markus Stumptner wrote:
> Just to lead this back to the original question.  What you say is
> undoubtedly true.  It is not, however, necessarily something that a
> beginner will understand or be able to share in.

That is a very important point. It also explains a lot of why we are
missing certain things that developers coming from other environments
take for granted: they simply provide less value to experienced
smalltalkers. And that is indeed a barrier to entry.

I remember sharply my first looking at squeak, and just not
understanding how I could create a new class or method in a browser.
Another was that I have been programming in seaside for a year without
using senders and implementers. Pair programming for an hour with
Philippe Marschall showed me so much invisible/hidden functionality.

Other (mainstream) environments don't provide the immediate feedback of
navigating, inspecting and manipulating the whole environment, and
therefore newcomers have no appropriate expectations (internal model),
and are clueless on what they are able to do in Pharo. Combined with the
lack of systematic visual clues and the high density of the class
library that makes it not easy to learn.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

horrido
I'll second that. Having separate namespaces would be really good.
VisualWorks has them. Why not Pharo?



kilon.alios wrote

> The one things I trully miss, even know that I am "experieced" Pharo
> coder,
> depending on your standards, is python namespaces
>
> I dont care about the dot syntax but containers of containers at language
> level that will make me avoid giving weird names to my Pharo classes to
> avoid potential collisions is a must have for me. It would also make the
> System Browser experience much smoother not only for beginners but also
> experts in Pharo.
>
> Also again under the threat of being thrown tomoatoes (probably justified)
> I would not mind a more modular approach to image format, for example
> having mutlipe files instead one monolithic. Not as a mandatory thing just
> something optional, the ability to break an image to pieces , send those
> pieces around so people do not have to close their image to open yours.
> Fuel covers this case nicely but again it could become a bit more "out of
> the box" and more automatic. .
>
> On Thu, Oct 12, 2017 at 11:22 AM stephan &lt;

> stephan@

> &gt; wrote:
>
>> On 12-10-17 08:30, Markus Stumptner wrote:
>> > Just to lead this back to the original question.  What you say is
>> > undoubtedly true.  It is not, however, necessarily something that a
>> > beginner will understand or be able to share in.
>>
>> That is a very important point. It also explains a lot of why we are
>> missing certain things that developers coming from other environments
>> take for granted: they simply provide less value to experienced
>> smalltalkers. And that is indeed a barrier to entry.
>>
>> I remember sharply my first looking at squeak, and just not
>> understanding how I could create a new class or method in a browser.
>> Another was that I have been programming in seaside for a year without
>> using senders and implementers. Pair programming for an hour with
>> Philippe Marschall showed me so much invisible/hidden functionality.
>>
>> Other (mainstream) environments don't provide the immediate feedback of
>> navigating, inspecting and manipulating the whole environment, and
>> therefore newcomers have no appropriate expectations (internal model),
>> and are clueless on what they are able to do in Pharo. Combined with the
>> lack of systematic visual clues and the high density of the class
>> library that makes it not easy to learn.
>>
>> Stephan
>>
>>
>>





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

Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

Sean P. DeNigris
Administrator
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*, and 2) where they fall
on the endless prioritized todo list



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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

kilon.alios
For me there is also question 3) How closely they are related to the bootstrap project

namespaces afterall is all about modularity which is the goal of bootstrap as well . no ?
So maybe we should not view them as a separate project and more as boostrap v2 , after v1 is released of course
Proably Pharo 9 or 10 should be a good period to focus on them. Bootstrap will have matured and stabilize and then we can go the extra step of namespaces. 

Also in Delphi , besides namespaces which is purely a language construct we had "Components" , think of them as namespaces but meant to work convenient in a IDE enviroment. I really like it as an idea and Delphi based its whole library on components. Again pure objects of course, with some metadata for the IDE to use, like category, dependencies etc

So if namespaces is the bridge between bootstrap and the language , Components can be the bridge between bootsrap and the IDE , because their role was to assembly libraries together via drag and drop and make code like legos. So it can be Components containing namespaces, namespaces containing objects. 

Thats one idea that worked well enough in practice to make Borland very profitable. It applied it both in Delphin and C++ Builder products. The library was called VCL (Visual Component Library) and still exists today after decades of use. 

Metacello also can come to this game on the basis that nowdays everything is online , Components could abstract git and other version controls and offer a convenient drag and drop from the github directly to the comforts of you image with no extra tool needed like Iceberg.

You can then use Iceberg to commit back to the repo. 

It can really come together quite nicely if Components function as in Delphi, a common protocol for object to communicate for IDE convenience, without braking the existing legacy code in Pharo. 

Well thats just an idea, based on my personal experience.   

On Thu, Oct 12, 2017 at 3:53 PM Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*, and 2) where they fall
on the endless prioritized todo list



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

Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

Brad Selfridge
Plus, namespaces are difficult to implement. It could tear your class library to pieces 

Brad Selfridge
913-269-2385

On Oct 12, 2017, at 9:10 AM, Dimitris Chloupis <[hidden email]> wrote:

For me there is also question 3) How closely they are related to the bootstrap project

namespaces afterall is all about modularity which is the goal of bootstrap as well . no ?
So maybe we should not view them as a separate project and more as boostrap v2 , after v1 is released of course
Proably Pharo 9 or 10 should be a good period to focus on them. Bootstrap will have matured and stabilize and then we can go the extra step of namespaces. 

Also in Delphi , besides namespaces which is purely a language construct we had "Components" , think of them as namespaces but meant to work convenient in a IDE enviroment. I really like it as an idea and Delphi based its whole library on components. Again pure objects of course, with some metadata for the IDE to use, like category, dependencies etc

So if namespaces is the bridge between bootstrap and the language , Components can be the bridge between bootsrap and the IDE , because their role was to assembly libraries together via drag and drop and make code like legos. So it can be Components containing namespaces, namespaces containing objects. 

Thats one idea that worked well enough in practice to make Borland very profitable. It applied it both in Delphin and C++ Builder products. The library was called VCL (Visual Component Library) and still exists today after decades of use. 

Metacello also can come to this game on the basis that nowdays everything is online , Components could abstract git and other version controls and offer a convenient drag and drop from the github directly to the comforts of you image with no extra tool needed like Iceberg.

You can then use Iceberg to commit back to the repo. 

It can really come together quite nicely if Components function as in Delphi, a common protocol for object to communicate for IDE convenience, without braking the existing legacy code in Pharo. 

Well thats just an idea, based on my personal experience.   

On Thu, Oct 12, 2017 at 3:53 PM Sean P. DeNigris <[hidden email]> wrote:
horrido wrote
> Having separate namespaces would be really good.
> VisualWorks has them. Why not Pharo?

I can't remember ever hearing disagreement on this subject. It seems the
only questions have been: 1) how to do them *right*, and 2) where they fall
on the endless prioritized todo list



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

Brad Selfridge
Reply | Threaded
Open this post in threaded view
|

"Building-With versus Building-on"

aglynn42
In reply to this post by bestlem
https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71

This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place.

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheers
Andrew Glynn
Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

Peter Fisk
Thanks for posting this.

It is one of the best descriptions of the state of the software industry that I have seen.


On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <[hidden email]> wrote:
https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71

This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place.

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheers
Andrew Glynn

Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

kilon.alios
It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it. 

And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.  

Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook. 

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope. 

I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity

Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions. 

Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc. 


On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <[hidden email]> wrote:
Thanks for posting this.

It is one of the best descriptions of the state of the software industry that I have seen.


On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <[hidden email]> wrote:
https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71

This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place.

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

cheers
Andrew Glynn

Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

Stephane Ducasse-3
In reply to this post by horrido
On Mon, Oct 9, 2017 at 2:45 PM, horrido <[hidden email]> wrote:
> Hey, guys, I'm mentioned in this  O'Reilly newsletter
> <http://post.oreilly.com/form/oreilly/viewhtml/9z1zgj2l150hp80ah3enjvhjhqcnr218calos5bd9o0?imm_mid=0f7103&cmp=em-prog-na-na-newsltr_20171007>
> !!! All because of the Pharo article.
>
> I wonder, is my campaign /actually/ succeeding? If so, I can die happy. ;-)

Great!
But do not die yet we have more to do :).

Stef

Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

Stephane Ducasse-3
In reply to this post by aglynn42
Thanks Andrew I read it fast and I will reread it. It is really
interesting to me because I never took the time to understand "worse
is better".

On Thu, Oct 12, 2017 at 5:50 PM, Andrew Glynn <[hidden email]> wrote:

> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
>
>
> This is an article not specifically about Pharo, rather on the state of the
> industry
> in general and how it got that way, but positing Pharo as a way to learn
> building-on rather than building-with, where in the latter case on
> every project you start at essentially the same place.
>
>
> As a result it does put in front of people a fair amount of info on Pharo,
> and challenges them to try it.
>
>
> cheers
>
> Andrew Glynn

Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

aglynn42
In reply to this post by kilon.alios

I know about personalization being a lot of work, particularly with Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into Kate, and it was 1233 lines long, lol. 

 

I was one of two team leads on what was probably the most complex application I’ve worked on, using VA Java and VA C++ with CORBA to exchange objects (the need to combine both was due to legacy issues).  Siemens now owns the application, which was successful enough to bankrupt its closest competitor, but the binary jars in the latest version are still dated 2002, and every addition has been made via .the WS* API we included, which if I remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it still runs at all tbh, but its security must be horrible by now.

 

Eclipse’s only saving grace is EMF/CDO, and a few projects built on them, IMHO.

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Thursday, October 12, 2017 2:05 PM
To: [hidden email]
Subject: Re: [Pharo-users] "Building-With versus Building-on"

 

It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it. 

 

And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.  

 

Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook. 

 

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope. 

 

I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity

 

Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions. 

 

Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc. 

 

 

On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <[hidden email]> wrote:

Thanks for posting this.

 

It is one of the best descriptions of the state of the software industry that I have seen.

 

 

On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <[hidden email]> wrote:

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
 
This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place. 
 

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

 
cheers
Andrew Glynn

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

Ben Coman
In reply to this post by Offray Vladimir Luna Cárdenas-2
On Wed, Oct 11, 2017 at 10:39 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:

The more I use Pharo, the less I use web documentation.

That is a familiar path, but still an obstacle for people to get over in trying Pharo - i.e. its a barrier of entry.  I've previously referred to this article by JoelOnSoftware, but to pull out a key part... "Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.  This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again."

For example, Stef mentioned that the Pharo web docs were dropped because were't used much.  But perhaps their value is not for regular use by the community, but more for outsiders evaluating Pharo, or newcomers transitioning from their old workflow to a Pharo one.  In that case their value eliminating one barrier of entry is much greater than measured from the number of page hits.


btw, What I like about Richards's articles is that... most of our community's articles are for people already using Pharo, even if only a newcomer of a few days working through an introductory tutorial.  Richard's articles target outsiders and one of the side benefits for *me* is that it pulls in critical outside perspectives to remind me of the barriers-of-entry stopping people using Pharo.  

Take for instance the common angst people have against working in an Image in Smalltalk.  There are some legitimate concerns with ending up in a state you can't recreate, which we are addressing this with the bootstrapping projects.  But I think we might publicize this better to outsiders. For example... Mr Smith knows nothing about Smalltalk and takes an interest in Pharo.  Smith discusses with colleague Jones who presents a poor opinion of the Smalltalk Image approach. So Smith never tries Pharo!  Alternatively, if Smith has already read in an FAQ about this common argument and how we address it by our bootstrap process, he can inform Jones', and maybe now we've got two curious newcomers.  

cheers -ben


Reply | Threaded
Open this post in threaded view
|

Re: Behold Pharo: The Modern Smalltalk

kilon.alios

That is a familiar path, but still an obstacle for people to get over in trying Pharo - i.e. its a barrier of entry.  I've previously referred to this article by JoelOnSoftware, but to pull out a key part... "Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.  This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again."


 
****WARNING LONG POST AHEAD**** 

There numerous reason why this kind of thinking is fundamental flawed, if not completely wrong

1) How you get people to run in this race ?
2) What makes you think that people participating in the race doing to get first or even finish ?
3) How you are certain that those barriers are not the very reason people participate ?

The fundamental problem is that if you base your assumption that people are motivated on avoidance of pain, this is a very popular argument by the way, you going to be severely disapointed. From the very first fact that there is a 90% chance that right now that you use almost 100% of your time one of the worst software to be ever created. 

Microsoft Windows. 

Of course you can throw claims to me that peope use Windows because that is what's popular and widely available, but then so is MacOS is by far the easiest to use OS out there. When you pit Windows vs Macos a such taboo subject , fuel to so many flame wars, there is one thing that both sides agree on and that is that MacOS is far easier to use , perdiod. The rest of the debate which OS is the best is up in the air and frankly not the point of my argument. 

The fact is , we love pain, we love barriers, we love doors that slam into our face. We love challange. But only if we find it interesting. 

Of course Windows is not the only example  (C/C++ , Java , Web dev, computer games and the list is just endless)of the machocistic nature of human beings. I dont need to look far, my own story about how I started coding is more than enough . I am going to ramble about my initiation to the realm of coding , so feel free to ignore the rest of my post but what the hell here we go. 

From an early age , no idea when, I was exposed to the idea of the computer. Never used one before or saw on in person other than what I saw in the TV I asked my father to get me one and he agreed on the ground that I wont use it just to play games but to learn how to code. My father had no idea what coding is, had no idea what technology is, to this day he hates technology and he refuses to learn even how to close a window. None , friend , relative or random stranger I knew used a computer.

So I got this weird thing called computer and turned it on, of course motivated to play games like any other kind in my age, I was 9 years old at the time, december 1988. But I had a sense of honor even from that age so I had to keep my promise. So I did and I was fascinated by it, to the degree that I was coding as much I was playing games. Problem is that it was mainly masochistic venture. I had one book and one book alone, none that had any clue how to show how to turn this thing on and of course no internet, no schools, no magazines I could afford to buy or even know where to buy them . So in 3 years, I made nothing special, only tiny fragments of code and I was still struggling with basic concept like looping.

Yes, looping.

 But I already was doing things that a greek kid did not suppose to do and I did not even fit the geek stereotype at the time (not that the term existed at the time, I still does not exist in my language), I had tons of friends, I was anything but shy , I was the craziest nosiest kid suffering from the annoying syndrom of hyperactivity and with very lmited attention span. 

I was the absolute worst candidate to learn how to code, yet I did . Sort of. Then my father decided to send me, after me begging on my knees, on a prrivate school, that just opened near our neighborhood for learning. At the time time I only still had the same computer, Amstrad CPC 6128 and knew the very basics of Locomotive Basic which was used also by the computer as a bash like language for its OS. 

I went 3 years, the first year I did ok, an average student even though I had by far the most experience than other kids we learned GWBASIC. The second year I did terrible, we learned DBASE and the third we learned CLIPPER and blow any other student completely away, I was the only to graduate with 99.8% and our teacher was super strict on the matter of grades. But I wanted more. 

So I went and learned C++ and assembly because why not and when I told my teacher that, he was looking me with his eye wide open, took me quite a lenghy discussion to convince him that this was true. 

The reason why the first year I did average was that it was too easy. I was already familiar with Basic , sure I was struggling with basic concepts when I started but   under the wing of the teacher (he was a great teacher, professional coder and highly skilled at helping you understand even the most difficult concepts) and full access to multiple books in few months became a walk in the park. The second year was a disaster, partly because our teacher decided to hire a relative of his to teach us DBASE and the guy was a moron wasting his time with telling jokes. The truth is that I did not like and still dont like database coding. Clipper I fall in love with it at the time because still a database orientated language but our teacher tought us, his relative got sacked as soon as he learned that he sucked, that happened one year after because none of the kids had the courage to go tell him and it was probably a parent the told him and did so well I was even offered to make a database for a considerable amount of money. Said no. Again not interested. 

My story is nothing special, I heard it in slightly diffirent versions by countless others in a similar situation however my point is  not to brag, because lets face it I was just merely learning languages and not doing any serious coding , my point is that the drive behind it was the pain. Was the obstacles. Was the challange. 

Pharo for me is also the same story. At the time I was coding in Python, super easy, got the job done, had no intention learning another language because why bother when they all look the same and they would have been much less powerful than Python. I was super happy with Python and still is one of my favorite language as you all know. Then I saw people on forums rambling about this weird language called Lisp , I was interested, google a tutorial , saw the parentheses , said "hell no!" and carried on coding in python. Then even more people claiming that it was so amazing, that it can cure cancer and make you super sexy. I always wanted to be super sexy so I said, ok lets give this a serious try. So I bought a book called "Land of Lisp" very fun to read, terrible teaching material, messy and all over the place. Community was terrible too (Common Lisp), at least some people, rude, snobs, evangelistic and plain stupid. A minority of people but still enough to ruin your day.Then I was introduced to emacs, another super painful experience, thoroughly enjoyed and one day I mentioned how cool it would be if one could combine the simplicity of Lisp with emacs but via a GUI IDE and without elisp which was hog slow. People immediately recommended Squeak, I though they were messing with me because none would pick such a ridiculous name for a language. Looked to me like a toy language for kids and then it hit my face like a train. 

Pain, pain and more pain. 

But it was well worth, I was completely blown away from the elegance of Smalltalk.

The learning curve of Smalltalk and Lisp are plain insane. Made learningh DOS Assembly a walk in the park in comparison. 

But frankly thats half of the fun. 

Many obstacles, many challanges. 

And there lies my point that an obstacle is a good thing when it becomes an interesting challange. You have to have at least a degree of masochism to learn how to code in any language. Of course the question is what makes an interesting challange and welcome to the abyss that is called "human brain". None knows and we are not anywhere close in finding out. 

What we know is that documentation is super important , whether you are a masochist or not, you need it to progress. Problems is that documentation is hard to create and maintain, again masochism required. So we should not just worry about making it easier for people to reach documentation we should make it easier for people to maintain it. Because even masochism has its limits. Those limits are as far it is a pleasureable pain. 

So congratulations to anyone reading this long post , you already proven my point.

Thus, let embrace the pain of Pharo and the pain of smalltalk and instead of trying to make it easy, boring and usual. Lets turn it to a challange, lets turn it to a painful yet pleasureable experience 

I think to that extend we in a very good path, I think Pharo is definetly a fun experience to use and learn. 

A huge plus also for Pharo is the community and how welcoming it is, we take for granted but my experience with Python was not the best either. I joined the IRC channel, other than having to endure the stupidity of "say lol 3 times and you are banned" , too many wars over languages and how superior Python is than anything else. Guido is god and blah blah blah... No thanks. 

People here are open minded, still "religious" about Smaltalk but they actually want to help , not to teach, actually help. 

I think we are a bit too obsessed on how to make Pharo popular, Smalltalkers suffer from this insecurity of the "failure" of the "best language of the world" not only to become popular but also to convince coders that "is not a a relic of the past".  

But we are fine, documentation is doing grear, Pharo is improving rapidly , the community is welcoming as ever. All we need is embrace our successes and our failures, reject the hype, consider the crticism and accept it or reject it and generally carry on doing what we all love. 

Improving Pharo. 

;)
Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

kilon.alios
In reply to this post by aglynn42
What is a VA Java ? and a VA C++ ? 

Call me an idiot or insane but I am in favor of combiding languages, though I only have heard of COBRA never used it. 

I am a lawyer by profession, I know fellow lawyers still using DOS and QBasic databases and yes under windows ...... sadly very common for businesses here. Ah the pleasures of technology but nothing comes close to the pleasure of rejecting it. 

On Fri, Oct 13, 2017 at 12:49 AM Andrew Glynn <[hidden email]> wrote:

I know about personalization being a lot of work, particularly with Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into Kate, and it was 1233 lines long, lol. 

 

I was one of two team leads on what was probably the most complex application I’ve worked on, using VA Java and VA C++ with CORBA to exchange objects (the need to combine both was due to legacy issues).  Siemens now owns the application, which was successful enough to bankrupt its closest competitor, but the binary jars in the latest version are still dated 2002, and every addition has been made via .the WS* API we included, which if I remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it still runs at all tbh, but its security must be horrible by now.

 

Eclipse’s only saving grace is EMF/CDO, and a few projects built on them, IMHO.

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Thursday, October 12, 2017 2:05 PM
To: [hidden email]
Subject: Re: [Pharo-users] "Building-With versus Building-on"

 

It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it. 

 

And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.  

 

Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook. 

 

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope. 

 

I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity

 

Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions. 

 

Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc. 

 

 

On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <[hidden email]> wrote:

Thanks for posting this.

 

It is one of the best descriptions of the state of the software industry that I have seen.

 

 

On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <[hidden email]> wrote:

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
 
This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place. 
 

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

 
cheers
Andrew Glynn

 

 

Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

Thierry Goubier
In reply to this post by Stephane Ducasse-3
Hi Andrew, Stephane,

thanks for the read. It was interesting, albeit a bit confusing at times. I do like your evaluation of the thesis.

2017-10-12 23:10 GMT+02:00 Stephane Ducasse <[hidden email]>:
Thanks Andrew I read it fast and I will reread it. It is really
interesting to me because I never took the time to understand "worse
is better".

Reading through "worse is better", and the follow-up "worse is better is worse" by the same author, I'm not sure there is much to understand ;)

Apart if you want to study how a misunderstood quote can become a driving force in software development...

Thierry
 

On Thu, Oct 12, 2017 at 5:50 PM, Andrew Glynn <[hidden email]> wrote:
> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
>
>
> This is an article not specifically about Pharo, rather on the state of the
> industry
> in general and how it got that way, but positing Pharo as a way to learn
> building-on rather than building-with, where in the latter case on
> every project you start at essentially the same place.
>
>
> As a result it does put in front of people a fair amount of info on Pharo,
> and challenges them to try it.
>
>
> cheers
>
> Andrew Glynn


Reply | Threaded
Open this post in threaded view
|

Pillar (was Re: Behold Pharo: The Modern Smalltalk)

Gour
In reply to this post by kilon.alios
On Wed, 11 Oct 2017 17:18:54 +0000
Dimitris Chloupis <[hidden email]>
wrote:

> Well there is a move towards Pillar for class and method commands so
> who knows maybe we will have that soon enough ;)

Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
addition of support for footnotes) as well as plan for the future (*.epub
support) since I'm considering whether it could serve as single-source markup
for all of one's writings?

After migrating from Python-powered static-site-generator (to Hugo) and rst
markup I was considering to use AsciiDoc(tor) markup for all my content, but,
so far, due to using Emacsm settled to use org-mode instead. Haven't tried with
slides (yet), but there is Pandoc support for it.

Therefore, I'd rather see Pillar support in Pandoc which would buy us even more
import/export capabilities for free instead of focusing on single formats like
*.odt, *.epub etc.

Pillar with 1st class support in Pandoc would, imho, improve status of Pharo
itself making it along with Pillar exceelent tool for development as well as
for all writing needs - articles, books, documentation, slide-presentations.

But it would be nice to make it more transparent where/how can one submit
feature request for Pillar?

Fogbugs issue trakcer is certainly not the ideal place these days...


Sincerely,
Gour

--
Everyone is forced to act helplessly according to the qualities
he has acquired from the modes of material nature; therefore no
one can refrain from doing something, not even for a moment.



Reply | Threaded
Open this post in threaded view
|

Re: Pillar (was Re: Behold Pharo: The Modern Smalltalk)

CyrilFerlicot

On ven. 13 oct. 2017 at 12:05, Gour <[hidden email]> wrote:
On Wed, 11 Oct 2017 17:18:54 +0000
Dimitris Chloupis <[hidden email]>
wrote:

> Well there is a move towards Pillar for class and method commands so
> who knows maybe we will have that soon enough ;)

Let me say that I'm very happy seeing that Pillar is moving forward (e.g.
addition of support for footnotes) as well as plan for the future (*.epub
support) since I'm considering whether it could serve as single-source markup
for all of one's writings?

After migrating from Python-powered static-site-generator (to Hugo) and rst
markup I was considering to use AsciiDoc(tor) markup for all my content, but,
so far, due to using Emacsm settled to use org-mode instead. Haven't tried with
slides (yet), but there is Pandoc support for it.

Therefore, I'd rather see Pillar support in Pandoc which would buy us even more
import/export capabilities for free instead of focusing on single formats like
*.odt, *.epub etc.

Pillar with 1st class support in Pandoc would, imho, improve status of Pharo
itself making it along with Pillar exceelent tool for development as well as
for all writing needs - articles, books, documentation, slide-presentations.

But it would be nice to make it more transparent where/how can one submit
feature request for Pillar?

Hi, 


I don't have much time so, fast answer: https://github.com/pillar-markup/pillar/issues





Fogbugs issue trakcer is certainly not the ideal place these days...


Sincerely,
Gour

--
Everyone is forced to act helplessly according to the qualities
he has acquired from the modes of material nature; therefore no
one can refrain from doing something, not even for a moment.



--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Reply | Threaded
Open this post in threaded view
|

Re: "Building-With versus Building-on"

aglynn42
In reply to this post by kilon.alios
VA (VisualAge) for C++ and for Java were two IBM products, the latter being the predecessor to Eclipse. They were both available on OS/2 and Windows NT variants (2000 mainly), and the C++ version on AIX. Whichever platform the C++ version was run on, you could target any supported runtime platform. They were all (along with VisualAge Smalltalk, now maintained and sold by Instantiations and currently at version 9.0, and VisualAge Generator - a Cobol version) written in IBM Smalltalk.

I still use VA C++, Java, and occasionally VA Smalltalk, albeit the latter at v. 6.02, in a VM running OS/2 (well, Ecomstation, but it's the same as OS/2 4.5, just updated for more recent hardware - interestingly Arca Noae released a version 5.0, the first official (i.e. called OS/2 version since 2004, in June of this year).  

I use them for prototyping and quickly creating cross-VM client/server apps that allow me to generate virtual network traffic without using tons of memory for each VM (much of what I do involves monitoring network protocols such as BGP, and without traffic to exercise the virtualized aggregated service routers, I can't demonstrate the code without carrying 6 75lb servers on my back).  

I can run Lotus Domino plus 10-12 server apps written in VA C++ in a VM with one or two vCPU's and 256MB RAM. On the client, I can run a couple dozen Java clients, connecting either to the C++ servers or Domino, in 128MB. I put a screenshot of the CPP and Java versions below.

For Smalltalk code, Pharo is better than VA, certainly better than the 6.02 version, but for C++ or Java, as long as you don't mind prototyping in an old Java version (lacking the syntactic parmesan, mainly), they're still better than anything else. Both incrementally compile/precompile in-memory on save the way ST does, but that's fairly rare in C++. Both have ways of writing arbitrary test code similar to a playground, which is also rare in either language. Both also have data access libraries that are far faster and easier to use than JPA, never mind CMP. VA Java also includes an ancient version of WebSphere for J2EE.

CORBA (Common Object Request Broker Architecture) is a complex way of exchanging objects/data between languages. I've seen interviewers who are/were developers actually shake if I mention it. However both the C++ and Java versions handled most of the details without any fuss.

All the build/deploy tooling was in the environment. With the app I mentioned, lacking those environments it's maybe not impossible, but likely at least close to 'infinitely improbable' to get the thing built properly, never mind actually change the code and configs. The junior developer from that project is a friend of mine's little brother, he's still at the company that paid to have it built, and it's now 15 years later, just so it will keep running. Ironically he was fresh out of school at the time and basically worked as a gopher, he didn't write or even debug a line of code. After we finished the project I taught him how to modify/build it using those tools, and they're still the only thing he can use.

cheers
Andrew







-----Original Message-----

Date: Fri, 13 Oct 2017 07:26:13 +0000
Subject: Re: [Pharo-users] "Building-With versus Building-on"
To: Any question about pharo is welcome <[hidden email]>
Reply-to: Any question about pharo is welcome <[hidden email]>
From: Dimitris Chloupis <[hidden email]>
What is a VA Java ? and a VA C++ ? 

Call me an idiot or insane but I am in favor of combiding languages, though I only have heard of COBRA never used it. 

I am a lawyer by profession, I know fellow lawyers still using DOS and QBasic databases and yes under windows ...... sadly very common for businesses here. Ah the pleasures of technology but nothing comes close to the pleasure of rejecting it. 

On Fri, Oct 13, 2017 at 12:49 AM Andrew Glynn <[hidden email]> wrote:

I know about personalization being a lot of work, particularly with Eclipse.  I copied the text out of the ‘summary’ page in About Eclipse into Kate, and it was 1233 lines long, lol. 

 

I was one of two team leads on what was probably the most complex application I’ve worked on, using VA Java and VA C++ with CORBA to exchange objects (the need to combine both was due to legacy issues).  Siemens now owns the application, which was successful enough to bankrupt its closest competitor, but the binary jars in the latest version are still dated 2002, and every addition has been made via .the WS* API we included, which if I remember correctly, uses version 1.x of WebSphere.  I’m a bit surprised it still runs at all tbh, but its security must be horrible by now.

 

Eclipse’s only saving grace is EMF/CDO, and a few projects built on them, IMHO.

 

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Thursday, October 12, 2017 2:05 PM
To: [hidden email]
Subject: Re: [Pharo-users] "Building-With versus Building-on"

 

It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it. 

 

And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it.  

 

Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook. 

 

Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope. 

 

I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make  a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity

 

Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions. 

 

Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc. 

 

 

On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <[hidden email]> wrote:

Thanks for posting this.

 

It is one of the best descriptions of the state of the software industry that I have seen.

 

 

On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <[hidden email]> wrote:

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71
 
This is an article not specifically about Pharo, rather on the state of the industry
in general and how it got that way, but positing Pharo as a way to learn
building-on rather than building-with, where in the latter case on
every project you start at essentially the same place. 
 

As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it.

 
cheers
Andrew Glynn

 

 


123456789