Smalltalk for small projects only?

On 28.01.2012 21:16, Janko Mivšek wrote:

Dale,

I agree with you that source code management is where we are weak. A
process therefore, as James already said.

In SCM  VisualWorks is ahead in my opinion, even that Store is also not
perfect yet. But it would be useful to reuse some of ideas in Monticello
based SCM tools too. With Metacello we got a good packaging tool, so,
where to go to be even better? I think SCM tool integration into code
browser can be next and relatively easy step. As Store is integrated
into VW code browser.

Wow, Store. Did you know that Store is so bad that some of the biggest Cincom success stories paid a really huge, undisclosed sum so that they don't have to use it?

If something cries 1995 then it's handing a SQL connection to the client. Your "interface" is the database schema. It ties the database schema to the client. You change the schema and you have to update all of the clients unless you "fake" the old schema with updatable views (if your RDBMS even supports this) and give the changed tables new names.

Also security becomes more or less impossible to do. Once you have write access to the public Store repository you can more or less do anything you want to do on any project unless implement it using triggers. And then there are all the possible DoS attacks like SELECT FOR UPDATE.

Cheers
Philippe

Janko,

Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ...

I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers.

I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ...

Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image...

I think we may focus too much on the in-image tools and not enough on the external tools that are just as important.

We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does  pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling.

Dale

Very good point . The tools and the libraries sometimes can play more important role than the language itself. However Java seems to constantly loosing developers because if something is a mess for small project for big projects becomes a big mess , just take a look how many gazillion scripting languages Java has , way more than C/C++.  

I think Java is not that ideal for large project as people think. I will go as far as saying that if it was not such a well marketed product would be an abandoned product by now and not a dominating platform. Companies may like , but coders certainly do not . Companies are attracted by good marketing, but coders are not. 

Coders are attracted , pro coders that is, from what can bring food to their table and pay their bills. And in that respect Java is phenomenal. If I was a big company however Java would be the last thing I would use for big project. As a matter of fact python has gained quite a momentum with huge projects and it is afterall a smalltalk child. Why not smalltalk ?

---

From: Janko Mivšek <[hidden email]>
To: [hidden email]; dimitris chloupis <[hidden email]>
Sent: Saturday, 28 January 2012, 22:08
Subject: Re: [Pharo-project] Smalltalk for small projects only?

S, dimitris chloupis piše:

> I think this is a post that clearly illustrates the big problem with
> smalltalk. The very fact that is compared with Java and Java survives.

Yes, that 4-5 peole can do what 50 Java people are needed is both a
blessing and a curse :) Blessing because of productivity, curse because
we are not able to scale beyond one highly connected development group.
We don't have project management practices and tools, while Java guys
have because they need them from the start.

> You know I dont find it mysterious at all that smalltalk is unpopular as
> it is. If I go to the python website I know in 4 second why I should use
> python, if I go to a Java site in 10 seconds I know what Java is good
> for, if I go to a C/c++ again in seconds it becomes clear what is the
> goal, even Assembly websites explain in a few lines what the language is
> all about.

> With Squeak and Pharo on the other hand it took me literally hours to
> figure out what they are good for and by the time I did I was amazed how
> underhyped smalltalk is. For me at least is the most underhyped piece of
> software I have ever used.

This is a valuable point to consider in the future.


> The issue with image here its easy to totally miss the whole point. An
> image is loading lighting fast , a java application is not, its also
> great way to organise object orientated code because it allows you to
> quickly navigate through it, loading files , is expensive and frankly
> quite archaic. The idea behind filesystem was created on the basic that
> computer could only load just a few kbs or even less because of limited
> memory.
>
> In the age we live , filesystems are unnecessary anyway. I am not saying
> that hardware storage  is , just file systems,  and I think smalltalk
> moves towards that direction. You dont really need files and extensions
> to separate data and  code,  OO  can do the job just fine in that area.
>
> I cant comment on the specifics of the image I am new to smalltalk and
> still exploring the basics, but let me say that I would love to take the
> idea of image abit further maybe following the brilliant architecture of
> our brains which stores information not in packages but via association,
> I think this kind of workflow is alot closer to what OO tries to be.
>
> For me the image play a pivot role inside the OO of smalltalk, which
> unlike Java does not stop at class definition. Besides an oversize
> clumsy library , smalltalk has very little to be envious of Java.
>
> Regarding huge project I will boldly say that inside a system of
> gazillion files a single file can easily lost its identity, OO can plays
> a huge role here, it can create that association I was talking about
> earlier and it can make sure that the user and coder has immediate
> access to information that he want to focus on at that particular moment
> but also has a structure that is obvious and simple to navigate.
>
> About the limitation of an image , i think that is a matter of
> implementation , obviously smalltalk has not been used as extensively in
> large projects as Java. But then what stops us from implementing an
> image that can brake any barrier, even do direct streaming from disk
> when the memory is not enough or when we dont want to occupy its entirety ?
> ------------------------------------------------------------------------
> *From:* Janko Mivšek <[hidden email]>
> *To:* "[hidden email]"
> <[hidden email]>; Squeak
> <[hidden email]>; 'VWNC' <[hidden email]>
> *Sent:* Saturday, 28 January 2012, 17:46
> *Subject:* [Pharo-project] Smalltalk for small projects only?
>
> Hi guys,
>
> Ralph Johnson in his InfoQ interview made an interesting observation:
>
> 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> build something with 4-5 people what 50 people can build in Java, but if
> you take 200 people in Java ... it is really designed for small systems
> ...  "
>
> Are we because of the image really destined for relatively small
> projects and small systems (of Java 50 people project size)?
>
> Are we really not able to scale to bigger projects/systems because of that?
>
> Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
>
> [1] http://www.infoq.com/interviews/johnson-armstrong-oop
>
> Best regards
> Janko
>
>
> --
> Janko Mivšek
> Aida/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>

Steve,

I have two comments:

 1. "inventing the future" doesn't happen by considering
    how "ambitious" it may seem. In the end it is probably
    easier than you think and harder than I think. If it was
    real easy, I'd have been done by now:)

 2. I propose a race:

    You start working on your git backend for Smalltalk and
    I'll continue working on Metacello, first one to "git work
    flow" wins ... But then the real winners will be the Smalltalk
    Community...

    I have said this before: "I can hardly wait until someone
    invents the replacement for Metacello---it will give me
    more time for other projects:)"

Dale

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

| From: "Steve Wart" <[hidden email]>
|
| The idea of building the git workflow on top of metacello strikes me
| as being somewhat ambitious.