Smalltalk is not file-based. For better or for worse.
The fundamental problem with Smalltalk is that it is image-based.
Removing a method from a file is not sufficient to remove the method from the
image.
Change sets were invented to provide a file-based solution to the "how do I
remove a me
Even if SmalltalkHub looks like GitHub, its still based on Monticello.
Another aspect also important in github and similar tools is social coding.
This is very easy to follow your favorite developpers and to
participate by cloning his/her repository.
Regards
On Wed, Apr 20, 2011 at 11:01 PM, Dale
2011/4/20 Dale Henrichs :
> Smalltalk is not file-based. For better or for worse.
>
> The fundamental problem with Smalltalk is that it is image-based.
>
> Removing a method from a file is not sufficient to remove the method from the
> image.
>
> Change sets were invented to provide a file-based s
2011/4/20 Serge Stinckwich :
> Even if SmalltalkHub looks like GitHub, its still based on Monticello.
> Another aspect also important in github and similar tools is social coding.
> This is very easy to follow your favorite developpers and to
> participate by cloning his/her repository.
>
> Regards
Objection! ;)
Using git has nothing to do with a file based system. The approach would be to
use git as a storage backend for monticello. Git just stores 3 types of
objects: commit, tree, blob.
There are no files involved!! So this would be perfectly compatible with and
image based system such
El mié, 20-04-2011 a las 18:51 +0200, Camillo Bruni escribió:
> Objection! ;)
>
> Using git has nothing to do with a file based system. The approach would be
> to use git as a storage backend for monticello. Git just stores 3 types of
> objects: commit, tree, blob.
> There are no files involved
Le mercredi 20 avril 2011 à 13:47 -0300, Germán Arduino a écrit :
> 2011/4/20 Serge Stinckwich :
> > Even if SmalltalkHub looks like GitHub, its still based on Monticello.
> > Another aspect also important in github and similar tools is social coding.
> > This is very easy to follow your favorite d
I want to comment. As already Camillo said, git has nothing intrinsic
with files. It only stores bytestrings and the commit id is the sha1 of
that bytestring. When comparing a version with other it just compares
the content of the object (bytestring). This is marvelous explained here
with ruby and
>
> However I see that smalltalkers tend to ignore the fact that there are other
> tools not written in smalltalk which are widely used and they actually work!
> For instance monticello. Although the model works perfectly fine, the UI is
> just plain crap, it does not provide a nice workflow no
Thanks by the comments Nico.
2011/4/20 Nicolas Petton :
> Le mercredi 20 avril 2011 à 13:47 -0300, Germán Arduino a écrit :
>> 2011/4/20 Serge Stinckwich :
>> > Even if SmalltalkHub looks like GitHub, its still based on Monticello.
>> > Another aspect also important in github and similar tools is
I think MC is working out really well for Squeak: development has been unstuck
ever since we started using the workflow from Pharo;)
I really enjoyed reading the historical info in your post. I hope it's okay to
throw out a couple of counter arguments, just for fun.
In particular, files don't w
On Apr 20, 2011, at 8:02 PM, Casey Ransberger wrote:
> I think MC is working out really well for Squeak: development has been
> unstuck ever since we started using the workflow from Pharo;)
>
And when we started to do that in 3.9, we got critized to death... it's not the
process that unstuck S
Camillo,
I understand that folks don't understand why Smalltalkers "don't just start
using files like everyone else". I have tried to explain ... it is not
arrogance nor ignorance. The image is the difference ...
The image makes it possible for developers to debug and explore the "live
object
On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni wrote:
> Objection! ;)
>
> Using git has nothing to do with a file based system. The approach would be
> to use git as a storage backend for monticello. Git just stores 3 types of
> objects: commit, tree, blob.
> There are no files involved!! So this
Casey and Miguel,
I agree that there are alternative approaches to SCMs that could give us
Smaltalkers what we already have in Monticello with the added benefit that
we could play nicely with the traditional tools, but keep in mind that we are
making the problem harder for ourselves:)
It'
Below.
On Apr 20, 2011, at 11:09 AM, Marcus Denker wrote:
> And when we started to do that in 3.9, we got critized to death... it's not
> the process that unstuck Squeak.
>
> The fact is: Squeak moves because Pharo marches in front. Pharo unstuck
> Squeak.
>
> I *tried* with all my energy to
On Apr 20, 2011, at 9:04 PM, Casey Ransberger wrote:
>
> What happened with me was I saw Andreas look at what you guys had done with
> Pharo in terms of tools and process and propose we do it too. I thought it
> was a good idea. My ideal world, frankly, is somewhere between Cuis and
> Pharo, b
Amen!
Norbert
Am 20.04.2011 um 18:01 schrieb Dale Henrichs:
> Smalltalk is not file-based. For better or for worse.
>
> The fundamental problem with Smalltalk is that it is image-based.
>
> Removing a method from a file is not sufficient to remove the method from the
> image.
>
> Change se
2011/4/20 Eliot Miranda :
>
>
> On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni
> wrote:
>>
>> Objection! ;)
>>
>> Using git has nothing to do with a file based system. The approach would
>> be to use git as a storage backend for monticello. Git just stores 3 types
>> of objects: commit, tree, blob
2011/4/20 Dale Henrichs :
>
> It's just an added dimension of complexity ... not to mention the cost of
> converting existing development processes, tools, artifacts to the new
> system...it took Monticello nearly a decade to become commonly used:)
>
> I think that this is a problem that does nee
Inline and abridged.
On Apr 20, 2011, at 2:00 PM, Germán Arduino wrote:
> 2011/4/20 Dale Henrichs :
>>
>> It's just an added dimension of complexity ... not to mention the cost of
>> converting existing development processes, tools, artifacts to the new
>> system...it took Monticello nearly
On Apr 20, 2011, at 2:00 PM, Germán Arduino wrote:
> 2011/4/20 Dale Henrichs :
>>
>> It's just an added dimension of complexity ... not to mention the cost of
>> converting existing development processes, tools, artifacts to the new
>> system...it took Monticello nearly a decade to become comm
On 20. 04. 2011 23:26, Dale Henrichs wrote:
>> A thing I not understand is why we need to go "file-based" if we are
>> already object based (several steps ahead)?
>
> The folks that would like to see Smalltalk be more file-based have very good
> points ... Smalltalk would be more accessible to o
I have been using a DVCS since at least 2005 and live by it for Perl (as well
as other things) development. It is frustrating for me to use anything else.
Because I have to jump between tasks, and because I am so scatter brained, I
need it in order to simply keep track of all my projects and t
On 21 Apr 2011, at 00:09, Janko Mivšek wrote:
> Here is the point - familiarity! And we don't need to adopt GitHub
> completely for that, just visual familiarity of SmalltalkHub will help
> us to come closer to GitHub communities, that's I'm pretty sure.
>
> So, let we stop thinking about "file-
I don't think that the issue is the file-ness of the subject, but the
easiness that other opensource projects enjoy in part because of their
tool, even if they aren't as pure in their object-ness as the ones
Smalltalk have.
As someone said, the UI of Monticello is very, umm, unintiuitive, has
bad
El mié, 20-04-2011 a las 18:17 -0400, Scott Gibson escribió:
> I have been using a DVCS since at least 2005 and live by it for Perl (as well
> as other things) development. It is frustrating for me to use anything else.
> Because I have to jump between tasks, and because I am so scatter brained
I would had responded to Casey, Dale and more, but selected this mail
to write my response!
2011/4/20 Scott Gibson :
> I have been using a DVCS since at least 2005 and live by it for Perl (as well
> as other things) development. It is frustrating for me to use anything else.
> Because I have t
2011/4/20 Janko Mivšek :
> Next thing, let we rather start integrating different Smalltalk code on
> all our dialects first and using SmalltalkHub for socializing in
> Smalltalk community as a whole. First, and before socializing with
> others! Here SmalltalkHub again promise a lot and we can actua
I think it was Kent Beck who ended his email with: "Source code in files? How
1970ish"
Reg
On 2011-04-20, at 4:17 PM, Norbert Hartl wrote:
> Amen!
>
> Norbert
>
> Am 20.04.2011 um 18:01 schrieb Dale Henrichs:
>
>> Smalltalk is not file-based. For better or for worse.
>>
>> The fundamental
More recently, he said "Smalltalk: Welcome to the Balkans."
On Apr 20, 2011, at 7:01 PM, Reg Krock wrote:
> I think it was Kent Beck who ended his email with: "Source code in files? How
> 1970ish"
>
> Reg
>
> On 2011-04-20, at 4:17 PM, Norbert Hartl wrote:
>
>> Amen!
>>
>> Norbert
>>
>> Am
>
> So, we can complain that we are not using git, but there are very good
> reasons for not using git ... today.
First: anyone complaining that we can't use git, hasn't used great version
control tools. I think what people want is GitHub, which is great. We can have
GitHub and base it on
> Using git has nothing to do with a file based system. The approach would be
> to use git as a storage backend for monticello. Git just stores 3 types of
> objects: commit, tree, blob.
> There are no files involved!! So this would be perfectly compatible with and
> image based system such as s
Thank you!
It bothers me slightly that we're actually having this discussion. Trying to
divorce Smalltalk from the image loses a great deal of flexibility that we have
all come to know and love. Divorcing Smalltalk from the image so we can use
great tools might be a reasonable thing to do, but
>> A thing I not understand is why we need to go "file-based" if we are
>> already object based (several steps ahead)?
>
> The folks that would like to see Smalltalk be more file-based have very good
> points ... Smalltalk would be more accessible to other developers, it would
> be easier for fo
Just a meta question that each of us can try to answer when looking at himself
in the mirror.
What do we do to get a better system?
If everybody would do something simple everyday we would be more than busy.
So yes MC UI is funky, now who tried to develop a new widget?
Don't tell me that morphic
On 21 Apr 2011, at 04:47, Steven Baker wrote:
> Monticello may have a poor UI, but Git has the worst possible UI, encourages
> awful practices, and just doesn't do the job well.
+10
Most people find git hard to use, indeed.
Monticello is not harder to use, you just have to understand what it
Hi Dale and everyone--
I think traditional Smalltalk is just file-based enough to cause
major annoyance for everyone. :)
This seems like yet another good moment to read Ingalls' "Design
Principles Behind Smalltalk"[1]. What resonates most for me are the
"messages" and "uniformity" prin
38 matches
Mail list logo
