Smalltalk › Pharo › Pharo Smalltalk Users

Evaluation of Pharo for Commercial Project

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Runar Jordahl

Evaluation of Pharo for Commercial Project

I am looking at Pharo to evaluate whether it can be used for a
mid-size commercial project. The system will use Seaside. I have
looked at Pharo 1.0, 1.1 and 1.2.

I am impressed by the work done so far. Pharo looks and feels a lot
better than Squeak, and a lot of enhancements have been done since the
project started. There are however a few issues which hold us back
from using Pharo, listed (in decreasing importance) below:

1 - Package Management

From what I have seen so far, the concept of “packages and categories”
is confusing. We are used to VisualAge and VisualWorks, which clearly
shows the structure of packages in the browsers. In Pharo we cannot
find browsers which give us the same overview. We are uncertain how
packages are made and how they show up in Monticello. At one point we
thought category == package, but that seems not to be correct. We note
that method extensions are possible, but we also struggle to
understand all aspects of them.

I notice that a “Package management system” is in work, so hopefully
this area will improve.

2 - Dependency Management between Packages
Since we are unable to organize our code in packages, controlling and
verifying dependencies between them is hard. But from what I
understand, there are not many tools for controlling that packages do
not break dependency rules.

3 - Name Space Support
I understand name spaces will not be supported any soon. We have a
project with thousands of classes, and name space support would be
nice to have.

4 - Break Point Support
It would be better to have break points, than having to insert code
like “self halt” into the code.

Is there any reason to believe Pharo will improve to meet our
requirements? Did I misunderstand some aspects of Pharo, or are there
tools which can solve what we see as shortcomings?

Kind regards
Runar Jordahl

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Lukas Renggli

Re: Evaluation of Pharo for Commercial Project

> 1 - Package Management
>
> From what I have seen so far, the concept of “packages and categories”
> is confusing. We are used to VisualAge and VisualWorks, which clearly
> shows the structure of packages in the browsers. In Pharo we cannot
> find browsers which give us the same overview. We are uncertain how
> packages are made and how they show up in Monticello. At one point we
> thought category == package, but that seems not to be correct. We note
> that method extensions are possible, but we also struggle to
> understand all aspects of them.

You might want to read the chapter on Monticello from Pharo by Example 2:

https://gforge.inria.fr/frs/download.php/27018/Monticello.pdf

> 2 - Dependency Management between Packages
> Since we are unable to organize our code in packages, controlling and
> verifying dependencies between them is hard. But from what I
> understand, there are not many tools for controlling that packages do
> not break dependency rules.

For Seaside we wrote some tools to manage our 80+ packages and their
dependencies:

http://source.lukas-renggli.ch/packaging

> 3 - Name Space Support
> I understand name spaces will not be supported any soon. We have a
> project with thousands of classes, and name space support would be
> nice to have.

Albeit nice, it is not a big deal not to have first class namespaces.
Again see Seaside.

> 4 - Break Point Support
> It would be better to have break points, than having to insert code
> like “self halt” into the code.

I think there is support, see the class BreakpointManager. I have
never used it though.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Mariano Martinez Peck

Re: Evaluation of Pharo for Commercial Project

In reply to this post by Runar Jordahl

On Wed, Jul 14, 2010 at 1:13 PM, Runar Jordahl <[hidden email]> wrote:

I am looking at Pharo to evaluate whether it can be used for a
mid-size commercial project. The system will use Seaside. I have
looked at Pharo 1.0, 1.1 and 1.2.

I am impressed by the work done so far. Pharo looks and feels a lot
better than Squeak, and a lot of enhancements have been done since the
project started. There are however a few issues which hold us back
from using Pharo, listed (in decreasing importance) below:

1 - Package Management

From what I have seen so far, the concept of “packages and categories”
is confusing. We are used to VisualAge and VisualWorks, which clearly
shows the structure of packages in the browsers. In Pharo we cannot
find browsers which give us the same overview. We are uncertain how
packages are made and how they show up in Monticello. At one point we
thought category == package, but that seems not to be correct. We note
that method extensions are possible, but we also struggle to
understand all aspects of them.

I notice that a “Package management system” is in work, so hopefully
this area will improve.

2 - Dependency Management between Packages
Since we are unable to organize our code in packages, controlling and
verifying dependencies between them is hard. But from what I
understand, there are not many tools for controlling that packages do
not break dependency rules.

For 1 and 2, check Metacello: http://code.google.com/p/metacello/
It is done, working well, and achieves those points.

We also wrote a draft of a Metacello chapter for Pharo By Example 2. I attach it in case you want to read it.

3 - Name Space Support
I understand name spaces will not be supported any soon. We have a
project with thousands of classes, and name space support would be
nice to have.

There are some implementations done, but noone is working out of the box (and maybe in no case) in Pharo.
One is Namespaces in SqueakSource, and the other one I know is SecureSqueak.

However, from my point of view, I think namespaces is something I can live without. I mean, I rally really want to have namespaces in Pharo, but I don't it shouldn't be a stopper. I saw big projects done without using it.

On the other hand, there is a GSoC project working on that: http://gsoc2010.esug.org/projects/namespaces

4 - Break Point Support
It would be better to have break points, than having to insert code
like “self halt” into the code.

yes, I would like to have that also. I think gaucho put that? I am not sure...but in such it would be cool to integrate it.

Is there any reason to believe Pharo will improve to meet our
requirements? Did I misunderstand some aspects of Pharo, or are there
tools which can solve what we see as shortcomings?

Kind regards
Runar Jordahl

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Metacello.pdf (299K) Download Attachment

Geert Claes

Re: Evaluation of Pharo for Commercial Project

Administrator

In reply to this post by Runar Jordahl

Hi Runar!

Runar Jordahl wrote

1 - Package Management
From what I have seen so far, the concept of “packages and categories” is confusing. We are used to VisualAge and VisualWorks, which clearly shows the structure of packages in the browsers. In Pharo we cannot find browsers which give us the same overview. We are uncertain how packages are made and how they show up in Monticello. At one point we thought category == package, but that seems not to be correct. We note that method extensions are possible, but we also struggle to understand all aspects of them.

You are right, the whole packages and categories thing is still very confusing and in most cases they are indeed the same thing. Have a look at the Pharo By Example Book (http://pharobyexample.org) and the still-work-in-progress Pharo Collaboractive book (http://book.pharo-project.org/book/introduction/whatisanimage) which tries to clarify it a bit.

Runar Jordahl wrote

I notice that a “Package management system” is in work, so hopefully this area will improve.

2 - Dependency Management between Packages
Since we are unable to organize our code in packages, controlling and verifying dependencies between them is hard. But from what I understand, there are not many tools for controlling that packages do not break dependency rules.

This is where Metacello comes in. Metacello is a Package Management System for Monticello http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-for-monticello I believe there is also a Metacello browser called Metaceller. You may also want to have a look at GoferProjectLoader http://www.smallworks.com.ar/en/community/GoferProjectLoader

Runar Jordahl wrote

Is there any reason to believe Pharo will improve to meet our requirements? Did I misunderstand some aspects of Pharo, or are there tools which can solve what we see as shortcomings?

Pharo is continuously improving :) Pharo has already been used on commercial projects (see the Pharo success stories: http://www.pharo-project.org/about/success-stories)

Stéphane Ducasse

Re: Evaluation of Pharo for Commercial Project

In reply to this post by Runar Jordahl

Hi runar

> I am looking at Pharo to evaluate whether it can be used for a
> mid-size commercial project. The system will use Seaside. I have
> looked at Pharo 1.0, 1.1 and 1.2.

Do not use 1.2 :)
This is written Unstable on the box :)

> I am impressed by the work done so far. Pharo looks and feels a lot
> better than Squeak, and a lot of enhancements have been done since the
> project started.

We will start cleaning even more under the surface. See my mail about 1.2 vision.

> There are however a few issues which hold us back
> from using Pharo, listed (in decreasing importance) below:
>
>
> 1 - Package Management
>
> From what I have seen so far, the concept of “packages and categories”
> is confusing. We are used to VisualAge and VisualWorks, which clearly
> shows the structure of packages in the browsers. In Pharo we cannot
> find browsers which give us the same overview. We are uncertain how
> packages are made and how they show up in Monticello. At one point we
> thought category == package, but that seems not to be correct. We note
> that method extensions are possible, but we also struggle to
> understand all aspects of them.

really simple if you declare a package then you get:

PackageA = CategoryA + protocol *CategoryA

After if you have
PackageA
PackageAB
Then AB is included in A (bad)
So you should do
PackageA-Core
PackageA-B

Do you use *overrides-categoryA simple this is bogus

>
> I notice that a “Package management system” is in work, so hopefully
> this area will improve.

Removing completely categories would be good but we would end up with a lot of packages.
We have a really new and good implementation to have first class packages without relying on
string matching but now we should integrate them into the system.

> 2 - Dependency Management between Packages
> Since we are unable to organize our code in packages,
why?

> controlling and
> verifying dependencies between them is hard.

but you will use package and still you point is valid.

> But from what I
> understand, there are not many tools for controlling that packages do
> not break dependency rules.

You have
dependencyBrowser developed by Hernan Morales
eDSM to identify cycle in your program that is working on top of Moose

Then also really important and much better than the envy solution you have metacello
to describe the package dependency

> 3 - Name Space Support
> I understand name spaces will not be supported any soon. We have a
> project with thousands of classes, and name space support would be
> nice to have.

Not before we really understand how they interact with package.
I do not like the solution of VW, Java....
So we should build and prototype something good.

> 4 - Break Point Support
> It would be better to have break points, than having to insert code
> like “self halt” into the code.

If this is the only show stopper to use pharo this is easy.
There are some support for break points. We should look around.
Second you have haltIf: which is worth a lot more than halt

haltIf: #foo
stopped if the methods is eventually invoked by foo

> Is there any reason to believe Pharo will improve to meet our
> requirements?

I think that the two requirements are solved, because we managed
really complex software with Monticello and metacello.
Namespace can be solved with simple Prefixing for now.

Finally you can provide code for fixes and that you can really get an impact on the system.

> Did I misunderstand some aspects of Pharo, or are there
> tools which can solve what we see as shortcomings?

Stef
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Mariano Martinez Peck

Re: Evaluation of Pharo for Commercial Project

In reply to this post by Runar Jordahl

I cc'ed pharo-dev

On Wed, Jul 14, 2010 at 1:13 PM, Runar Jordahl <[hidden email]> wrote:

I am looking at Pharo to evaluate whether it can be used for a
mid-size commercial project. The system will use Seaside. I have
looked at Pharo 1.0, 1.1 and 1.2.

I am impressed by the work done so far. Pharo looks and feels a lot
better than Squeak, and a lot of enhancements have been done since the
project started. There are however a few issues which hold us back
from using Pharo, listed (in decreasing importance) below:

1 - Package Management

From what I have seen so far, the concept of “packages and categories”
is confusing. We are used to VisualAge and VisualWorks, which clearly
shows the structure of packages in the browsers. In Pharo we cannot
find browsers which give us the same overview. We are uncertain how
packages are made and how they show up in Monticello. At one point we
thought category == package, but that seems not to be correct. We note
that method extensions are possible, but we also struggle to
understand all aspects of them.

I notice that a “Package management system” is in work, so hopefully
this area will improve.

2 - Dependency Management between Packages
Since we are unable to organize our code in packages, controlling and
verifying dependencies between them is hard. But from what I
understand, there are not many tools for controlling that packages do
not break dependency rules.

3 - Name Space Support
I understand name spaces will not be supported any soon. We have a
project with thousands of classes, and name space support would be
nice to have.

4 - Break Point Support
It would be better to have break points, than having to insert code
like “self halt” into the code.

Is there any reason to believe Pharo will improve to meet our
requirements? Did I misunderstand some aspects of Pharo, or are there
tools which can solve what we see as shortcomings?

Kind regards
Runar Jordahl

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users