[squeak-dev] Re: Call For *Your* Opinion

Hannes Hirzel hannes.hirzel at gmail.com
Mon May 3 17:14:20 UTC 2010


On 5/1/10, Ian Trudel <ian.trudel at gmail.com> wrote:
> (Repost of the survey is available below this message)
>
> This is most likely the last call for this survey as the number of
> contributions to it have drastically decreased. I have seen many on
> the list who haven't participated yet and I'd be glad to hear from
> you. Or do I have to email everyone personally? ;)))
>
> I will compile data around May, 10th and a report will be eventually
> written.
>
> Ian.
> --
> http://mecenia.blogspot.com/
>
> = Survey ======
>
> 1. What are your biggest hurdles preventing you from contributing to Squeak?

Actually with the new trunk system with several commiters are at work
it is possible to get something into the image in a much shorter time.
Putting things into the inbox is easy.
I'm interested in documentation and that has now become a priority. So
actually no hurdles anymore.

> 2. What would it take for you to contribute more?

The system as such is complex and there are many spots where one could
contribute.
Maybe a working group having a certain focus for a certain time.
XP style working groups. Or "sprints". Or putting something like
'Scrum' in place.

> 3. What are your expectations in regard to contributions?
To be of high quality. That does not mean that everybody's
contribution have to be perfect before they get submitted. But other
people should check it and give feedback quickly. A group of
moderately talented people can accomplish a lot in case they
cooperate, i.e. communicate. (In addition to the highly productive
exceptional coders :-)

> 4. What are the reasons behind the low level of contributions from
> other community members, according to you?

I think it needs some time (1..2 years) for people to realize that now
with the trunk system things are moving faster.

The other thing is that it is not easy because often you have to do
'design recovery'. There are many unwritten assumptions of concepts
which are not spelled out. And some of them are competing.

> 5. What would you improve in order to increase the number of
> contributions and the number of contributors?

Stable interfaces. In Java you have interfaces which gives you a lot
of work to do but libraries load fine.
The borders between interface and implementation in Squeak are blurred.
Method categories are their for informational purposes only.
If I want a mineral from a soda-vending machine I want to know which
buttons to press and I do not want to learn how to make a copy of the
soda-vending machine. Of course it is nice if I can do that if I want
so, but I should not be forced to go to quickly into details.

An example: Today I wanted to load the HTML parser of Todd Blanchard
http://www.squeaksource.com/htmlcssparser. It did not load though it
was last updated on 23 January 2009 and has 2768 downloads. So in the
past it was useful but now no longer works. An HTML parser is
something crucial these days.

Quality: It is not clear what Squeak delivers and what not. For a
small group of developers it is difficult to maintain a whole software
stack. Code breaks too often all the time.

> 6. How would you rate your sense of social identification to the
> Squeak community, on a scale from 1 to 10. (1 is the lowest, 10 the
> highest)

4...10 (varies over time, depends on the things I'm working on. If I
have a project where I can use Squeak the identification is high, if I
do not use it the interest is low). It takes a considerable effort to
mentally shift gears between Java and Smalltalk. However it is
refreshing to do so from time to time.

> 7. What is your rating based on?

just an estimate

> 8. Anything else?

a)I think the version 4.1 is a very nice new base to build upon. For
prototypes, data conversion and integrity checks exercises, Morphic
experiments, presentations, Seaside programming.

b) A downside is that contrariwise to Java a lot of the libraries are
weak and not well supported (often the work of a single person without
the cooperation of somebody doing test and documentation). This might
easily eat up the time gained because of the more productive
environment. The Java IDEs are good. You write a lot more
(configuration files etc), but there are lots of examples. Learning is
not easy either though. But there are many libraries to choose from.
When starting to work with Squeak you may easily get side-tracked to
start working on the IDE rather than your app.

c) I think we should get the Pharo tests (around 9000) into Squeak.

d) Make use of the synergy with Pharo. It is good to have this fork
with a focus on SWEngineering and Web development. Focus on apps which
run on both while maintaining the specific focus.

e) Squeak is more general purpose and multimedia oriented. In this
area it is outstanding. It is a huge success that etoys runs on 1 mio
machines. And that there are 1 mio Scratch projects. I value the goal
of bringing Etoys (currently based on 3.8) and Scratch together.

f) Somebody has written that Squeak has only produced 'forks' so far.
I think this is actually good. It should be encouraged to create
derivative work based on Squeak. This makes it possible that different
groups can work independently which enhances productivity. If
something worthwhile comes out of a derivative work it may be folded
back into the main stream if it is not used commercially. I see the
fact the MIT license permits commercial use as useful. The advantage
of having derivative work is that they can have a clear focus. This
has happened in the past.

g) So the focus should be - and I assume it is - to come up with a
rather minimal base image (around 1500 classes, well documented with a
lots of tests - 12000), a set of well supported packages (another 2000
classes) on which people can build their own things.

h) I like the RCP GUI look of Squeak 4.1. The Pharo look is more
makeshift. I don't have a workspace anymore from which I can save a
text file. Too many things are cut off. This is fine for web
development and SW engineering analysis tasks. But for a general
purpose IDE it is too narrow. But it's good to have this fork. A kind
of second source.

j) I would see getting a menu system where small apps may be
registered (e.g. calculator, notepad, small text processor, scrapbook,
graphical import viewer, games, learning software, simulations).
The same thing applies to a good Preferences system. Going for <method
tags> seems to be straightforward to get it quickly done.

k) Updated and well tested XML and HTML parsers are a real need for
me. Something like JDOM is there but a bit shaky. Not enough tests.

i) As a whole it is a worthwhile endeavor. Thanks to everybody who has
made 4.1 possible. This is a big step forward.



More information about the Squeak-dev mailing list