Re: Discussion on vision!
ducasse <[email protected]> Wed, 24 Sep 2003 20:58:44 +0200
| Newsgroups | gmane.comp.lang.smalltalk.squeak.foundation |
|---|---|
| Message-ID | <[email protected]> |
Hi goran
I agree with your ideas.
- We will continue to work on the cleaning (slowly peeble by =
peeble)=20
of the kernel,
- lukas and/or adrian and/or nathanael and/or me will work on a =
new=20
completely from scratch implementation
of traits with tests and all the rest. We should decide who and =
the=20
plan next week.
- I'm planning to work on analysis for modularisation as a =
research=20
topics, and I will take Squeak as case study.
- A package mechanism is getting to really show up. Perfect. I =
know=20
that Ginsu is now open source and that
joseph has a mySql back end but we will see that later.
- I think that we should have a better infrastructure in the =
same=20
ideas that
FileList registration, for the menu for example
- The idea of a better code and better infrastructure is that =
people=20
can experiment much faster without breaking all the rest.
- I think that I liked 3.6 because it evolved at each level (TTF =
and=20
kernel and network). So this was a good model
for the future.
What I would like from the Guides is to push forward some key points=20
for 3.7 and the next:
- Flow (may be I'm not expert but having a good stream library =
could=20
be good)
- Some KCP stuff (I hope that the notification mechanism will =
get=20
mature)
- A new and sexy look
- Something that I would really like to have is a better tool =
kit to=20
build user interface May be you should send a call?
- marcus would like to use the SmaCC AST and clean the compiler =
this=20
is also important
and at ESUG john told us that he should discuss with don but =
that a=20
dual licensing SqueakL/MIT could be
possible.
- Ideally I would really to have the RB **engine** inside Squeak=20=
because when I see how fast I go with changing code in VW.
What I can tell you is that next year ESUG will be at brussels (we=20
tried to change the date but for money reasons
and room problems we got stuck with the last week of August). Now this=20=
is up to you to make a Squeak event at ESUG: we will provide all the=20
rest (beer, network....:).
=09
Stef
On Mardi, sep 23, 2003, at 14:42 Europe/Zurich,=20
[email protected] wrote:
> Hi fellow Guides and all others!
>
> NOTE TO ALL: Please do NOT crosspost this post to squeak-dev. It is
> meant as a seed for discussion and if stuff like this gets immediately
> crossposted to squeak-dev then it will make it much harder to use this
> list as an open discussion channel for the Guides.
>
> Once upon a time (the squeak-dev thread called "[IMPORTANT]Concrete
> proposals!") I
> promised that we Guides should come up with something like a Vision.
>
> Now I have taken some time to actually formulate *my personal* Vision=20=
> of
> Squeak and our future.
>
> So this is a "seed for discussion" and is (I repeat) *my personal
> thoughts* on the matter.
> Let's throw some thoughts around and try to condense this into=20
> something
> good.
>
> (AsbestSuit on: self) wear
>
> regards, G=F6ran
>
> PS. This was about the Vision. A totally different chapter is the=20
> Guides
> - us.
> There are three things I want us to do in that respect:
> 1. Get some Vision out there. The stuff here was my best first shot.
> 2. Get some form of decision process in place.
> 3. Rotate at least one Guide, maybe more.
>
> --------------
>
> My personal Vision on Squeak
>
> To me *all* the different directions, views and visions that live=20
> inside
> the Squeak community have great value. I want Squeak to be a platform,
> media,
> call it whatever you like - that is as versatile and universally =
useful
> as possible. The vision outlined here may though be perceived by some=20=
> as
> too vague or general. But I truly believe that many of the great=20
> virtues
> of Squeak and its community come from this diversity.
>
> Currently I use Squeak for my email, my private experiments in
> programming, our Swikis in our company, as the development environment
> of choice for my web apps and other projects that don't need "business
> UIs" and sometimes as a presentation tool.
>
> But I also "use" Squeak for personal fulfillment - the Squeak =
community
> is packed with ideas, creativity and interesting people from all over
> the world. Following the squeak-dev list is hard work, but it pays off
> by teaching me things almost every day. I also enjoy being a part of=20=
> the
> community, getting to know people, collaborating and simply solving
> problems together.
>
> A recent example of this is that Daniel Vainsencher and Andreas Raab
> visited Stockholm for a few days and to meet Squeakers in the real=20
> world
> is always inspiring.
>
> During this visit Daniel and I discussed the Guides "model", the
> community and how it works and much more. We didn't solve the issues =
of
> course - but for me personally it did clear my head about *my* vision
> for Squeak. It turns out that I actually can explain this vision using
> three headlines:
>
> #1 The universal tool
>
> I want Squeak - the tool - to improve in any and all areas possible.
> Better performance, more ports, more and better libraries, more
> possibilities for user interfaces, more implemented standards=20
> (typically
> communication) and so on. I want to be able to choose Squeak as my =
tool
> of choice for *any* development task.
>
> This also includes evolving Squeak the language. I am in favour of
> looking at for example Traits or implementing new and modern =
Collection
> classes. ANSI compliance is good - but IMHO it should never be allowed
> to stand in the way of the evolution of Squeak. Smalltalk is a dead
> language, if we consider the standard at least - Squeak on the other
> hand is very much alive. Being somewhat compatible with other=20
> Smalltalks
> is also a nice thing - but again, I don't think we should let it stand
> in our way
> into the future.
>
> So as I said in the introduction above - I don't want to point at any
> specific area to be more important than any other. The more diverse
> people and interests we can satisfy the more interesting solutions and
> cross-domain ideas we may find.
>
> BUT... for the tool Squeak to scale as a universal tool and platform -
> we need better infrastructure. And we are getting there slowly.
> SqueakMap has been a success - very much so to my personal=20
> satisfaction.
> Now we need to get the next version up as soon as possible, and that =
is
> still my first priority.
>
> But we also need other things - one thing is a Test server, and I=20
> happen
> to know that some people are working on that. A Test server could
> automatically run unit test suites for different packages and
> combinations of packages - and thus act as the big guardian of
> robustness and quality. After having seen Daniel Vainsencher describe
> how rules about dependencies in our code actually can be expressed as
> Unit tests (the package MudPie) a Test Server suddenly sounds like a
> really great addition to our infrastructure. (Note: Just saw Daniel's
> posts on this subject on the list)
>
> Another such thing that is missing is a big cross-reference server -=20=
> and
> AFAIK nobody is yet working on that. SqueakMap2 will of course be a
> fundamental prerequisite for such a beast. Imagine a server that knows
> about all the package releases on SqueakMap and can reliably answer
> questions like for example "all senders of..." and "all implementors
> of..." *globally* for all known packages.
>
> In short - we need better tools. The above two servers are just pieces
> of the puzzle. There are other tools we need too - like Monticello
> servers for team development on packages, some bug report tool for
> keeping track of bugs grouped by package and so on.
>
> Some people think that the current trend with partitioning Squeak into
> packages with appointed maintainers/stewards is making it harder to
> maintain Squeak as a coherent environment. Yes, the new scheme demands
> more of our infrastructure - but I am convinced that this move is
> healthy and will make Squeak scale and be able to sustain a much =
higher
> speed of evolution through parallellism.
>
> But this current direction also demands something from all of us - we
> must
> learn to delegate and *trust* other Squeakers to take decisions in the
> respective
> areas. This is something we need to work on and we Guides should take =
a
> lead
> in and try to finally establish different areas of responsibility =
using
> the
> previouslly outlined concept Stewards.
>
> Finally I want to note the importance of all the other projects going=20=
> on
> at
> the moment - KCP, MCP, m17n, Squeakland and many others come to mind.
> All these projects make Squeak better.
>
> #2 Collaboration and communication
>
> Currently Squeakers collaborate using a mailinglist, a number of=20
> Swikis,
> an ftp site, SqueakMap and to very little extent IRC. We do publish
> Projects for people to play with but that is still just a way of
> publishing a document - not much interaction going on there between
> Squeakers.
>
> Maybe I missed a thing or two but essentially IMHO we aren't using
> Squeak itself to its full potential. I want us to start thinking about
> building infrastructure for tying the Squeak community together in =
more
> real time. There have been numerous ideas in this respect and I hope =
to
> see more of it.
>
> Squeak is a great platform for groundbreaking new ways to collaborate
> and communicate. We are also in a unique situation since when we are
> using Squeak we are also *running it* - we are living inside the =
object
> space. So we can easily add various collaborative mechanisms to=20
> actually
> make Squeak stand out *even more* compared to other development
> environments.
>
> SqueakMap2 will actually lay the base for such mechanisms and ideas.
> How? It extends the map to not only keeping track of packages, but =
also
> keeping track of Squeakers. Eventually we will actually be able to=20
> track
> a single element of Squeak, say a method - to an SM package and thus =
to
> one or more Squeakers.
>
> Having such a model of the community itself is the first step towards
> more advanced communication than the mailinglist. Let the =
brainstorming
> begin!
>
> #3 Fun
>
> When all words have been said this is in fact the most important thing
> for me. I want to have fun. Squeak is fun. The community is full of =
fun
> ideas and fun people. I wouldn't be in the Squeak community if it=20
> wasn't
> as fun as it is. :-)
>
> One early peer reviewer of this text mentioned that Fun should be #1=20=
> and
> not #3. But I saved it for last to make it a better finish. :)
>
> Many people view Squeak as a vehicle for a cause - it may be to build =
a
> new 3D environment (Croquet) to create new possibilites for
> communication. It may be to create and spur a new way of learning=20
> (eToys
> etc).
>
> All these ideas are very interesting, inspiring and important. But the
> thing that makes them that - to me at least - is that they are fun. It
> is *great* fun to see kids explore, laugh and enjoy the buzzing
> fulfillment of creating something on their own. We also know that kids
> learn best through playing - having fun.
>
> It is also great fun to play around in 3D and imagining how such an
> awesome environment like Croquet can change the way we build systems=20=
> and
> "places" on the net.
>
> Again, when I talked to Daniel when he was here we realized that we
> really could have more... "fun events" in the community.
> <teaser>
> Daniel and I have loosely been cooking up one idea for such an event
> that would take place during a full weekend, 48 hours. Exactly what it
> would entail is the topic of a different post - but it is just pure=20
> fun.
> :)
> </teaser>
>
> So my final word is - whatever we do to move Squeak into the future -
> let's make sure we have fun doing it. :)
>
> regards, G=F6ran
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>