[vwnc] Developers from other languages trying Smalltalk

Ken Treis escreveu:
I could grasp (and agree) with the fist part, but I don't understand the
following. If you want to use Smalltalk you have to accommodate more
than just a one-to-one mapping of the foreign APIs. Expat comes handy
for this example: your proposition means we have to drop VW's XML
framework in favour of Expat?


> *2. No easy deployment strategy.* Runtime Packager is a decent tool, but
> it's a lot more intimidating than something integrated, with a "click
> here to build your .exe or .app" button.
>  

I think above these aspects there is a policy from Cincom that makes it
a little harder: for the non commercial version you cannot package the
application in a simple .exe.



--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 26/07/2008, at 7:08 AM, Ken Treis wrote:

> 1. No readily available bindings for common open source libraries.  
> Things like libpng, libjpeg, expat, etc. There are tons of free  
> libraries like this that solve lots of common problems, and VW looks  
> far less powerful than (say) Ruby or even C if these bindings don't  
> exist (or exist in the public repository in various states of  
> brokenness). Even where native VW versions exist, a developer from  
> another language has to learn an entirely new API and has no  
> guarantee that a particular feature will be supported.

There has been a recent issue in Ruby-land about the poor quality of  
XML support, and an effort is underway to resurrect a libxml binding  
to solve the problem. The effort involved in integrating libxml is  
considerable, even with a better foreign interface.

A easier-to-use/more reliable DLLCC story is needed to encourage that.  
And IMO such improvement is not just about  better header parsing, but  
also about reducing the impedance mismatch, and providing a mechanism  
for dealing systematically/automatically with mapping the API design  
patterns that individual libraries manifest.

> 2. No easy deployment strategy. Runtime Packager is a decent tool,  
> but it's a lot more intimidating than something integrated, with a  
> "click here to build your .exe or .app" button.

When talking of deployment, I think it's important to treat  
application packaging, which is e.g. Andre Schnoor's concern,  
separately from server deployment. If you consider the 'market' that  
Ruby/Python/Perl services, server deployment is the issue.

We could do with tools/facilites like Rake and Capistrano. I think the  
first step is for people to become totally familiar with how other  
systems deal with packaging and deployment, especially Ruby. IMHO  
there is insufficient recognition of, interest in, and understanding  
of how other cultures solve the problems that we grapple with. I  
recently spent $1500 buying a library of Ruby/Rails books and  
screencasts in order to be more fully informed, and I strongly  
recommend anyone that who is interested in solving problems with the  
Smalltalk tools and infrastructure deep drinkly of the Ruby/Rails kool-
aid as part of that process.

> 3. Look & feel. I agree with some of the comments here about the  
> look and feel being an initial turn-off. Regardless of what platform  
> you're on, the VW widgets feel like a cheap imitation of native  
> widgets. Most of my apps use custom or one-off widgets because I  
> need to tweak some behavior of the standard ones -- and it's amazing  
> what just a little Cairo gradient can do to spruce things up. I  
> don't need or want native widgets, just nice looking ones that don't  
> have any pretense of being native.

You may not need or want native widgets, either truly native or a high  
fidelity similation, but it is definitely a turn off for new  
developers. On the Mac it is an enormous barrier. You would need an  
amazingly good look to replace it, and by that I don't mean Cairo-
inspired eye-candy. To aim for excellence in this would need a level  
of aesthetic design commitment and talent, combined with deep  
experience, that is very rare.

> 4. Source control. Store is workable, and I see it improving more  
> rapidly now (the new shadow loader is a big step in the right  
> direction), but the whole system seems slow, underpowered, and  
> overly infrastructure-bound compared to some of the cool distributed  
> SCM systems out there.

Agreed.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Plurality is not to be assumed without necessity
   -- William of Ockham (ca. 1285-1349)


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

And if you want more than the five (5) last selections you could edit ParagraphEditor>>addPreviousSelection:.

I usually replace 5 for 50 to get last fifty selections in my clip buffer.

/Björn

-----Ursprungligt meddelande-----
Från: [hidden email] genom Stefan Schmiedl
Skickat: fr 2008-07-25 11:23
Till: [hidden email]
Ämne: Re: [vwnc] Developers from other languages trying Smalltalk

On Fri, 25 Jul 2008 11:32:02 +0300
"Steven Kelly" <[hidden email]> wrote:

> Stefan Schmiedl wrote:
> > Good thing you invoked VIM instead of VI, because now I can ask you
> > how to access the list of the last 10 chunks I deleted. Even The Other
> > Editor Which Shall Not Be Named has a "kill ring".
>
> VIM: http://bbs.archlinux.org/viewtopic.php?id=48290
> VW: Ctrl+Shift+V (or shift+Paste from menu) - the last 5 cuts and copies (and also deletes before 7.5)

ooohhhh.... nice.
I love getting my lame jokes getting back in my face, when I can learn
something at the same time.

Thanks!
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Cesar Rabak wrote:
No Emacs is a general editor with which you can edit anything.

While at a stretch I guess you could do the same with VW that isn't what
people do - they develop Smalltalk with it. For that it should have all
of the nice features most of us add by default. That immediately makes
the tool more useful and easier to use which is the whole point of it.

While some don't like syntax coloring it is pretty much the norm for a
language aware editor, and the standard keystrokes for cut, paste, copy,
find and replace are..well, standard. So fundamental, so obviously
missing, so simple to fix. Such a pain for new users.

Here's a question how many of the Cincom developers who live in VW use
the distribution image? If they don't do it why should a newbie be
expected to.

cheers
Steve
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 25.07.08 14:23 schrieb "James Robertson":
> What I like watching is the "defensive crouch" approach, whereby a
> clearly dated approach (pasting the error string into the method body)
> gets defended to the death as "the one true way" by so many people.
> Don't take that example too personally; there are lots of things like
> that in the product that people defend against all reason.
>
> This does demonstrate how hard it can be for a vendor to make changes
> in a longstanding product though :)

Just do it. VW has survived the move from Envy to Store, the introduction of
Namespaces, and immutable objects. There's still the occasional curmudgeon
mumbling "bad move", but hey, the world hasn't ended because of it.

But please no more forgetting about adapting the change list browser the
next time Namespaces are introduced. I don't want to load yet another
GHTools parcel. ;-)

Cheers,
Joachim Geidel


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 26.07.2008 um 04:59 schrieb Antony Blakey:

> You may not need or want native widgets, either truly native or a high
> fidelity similation, but it is definitely a turn off for new
> developers. On the Mac it is an enormous barrier.

As menitioned in an earlier post, even famous market leading design  
flagships don't use native widgets on the Mac (and possibly neither on  
Windows, but I have only tested Adobe InDesign on Mac) and they are  
renowned and successful despite of that. The need for a true cross-
platform codebase often forces vendors to fire up some generic UI  
framework on their own.

The market for pro-level desktop applications is a commercial  
perspective for Smalltalk:

* Cross-platform
* Complex and feature-rich application domains
* Number crunching and high throughput often irrelevant
* Subject to frequent changes and enhancments
* Relatively small markets vs. high development costs

Especially the last two points make Smalltalk very attractive. The  
smaller a market, the more critical the costs of maintenance and  
development. While "small" here means something that Adobe might  
consider relatively small, but which is a huge audience compared to  
the current reach of Smalltalk.

If VW was sexy enough to attract more people from the cross-platform C+
+ crowd, this would mean a big move forwward. IMHO, this is doable and  
realistic, provided the concerns discussed here are taken seriously.

Andre
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 27/07/2008, at 8:58 PM, Andre Schnoor wrote:

Sure, but the rest of that paragraph said:

"You would need an amazingly good look to replace it, and by that I  
don't mean Cairo-inspired eye-candy. To aim for  excellence in this  
would need a level of aesthetic design commitment and talent, combined  
with deep experience, that is very rare."

For me the best outcome would be a fantastic looking (which doesn't  
mean overly decorative), well though out, platform-indendent UI. But  
in the absence of that, it is easier to more faithfully simulate the  
native platform.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Man will never be free until the last king is strangled with the  
entrails of the last priest.
   -- Denis Diderot

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> If VW was sexy enough to attract more people from the cross-platform C+
> + crowd, this would mean a big move forwward. IMHO, this is doable and
> realistic, provided the concerns discussed here are taken seriously.


You forgot to mention that with Seaside we now have this unique feature of being able to serve a desktop Gui and a webserver out of the same domain model.

@+Maarten,
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 28 July 2008 14:47 Maarten MOSTERT wrote:
>> If VW was sexy enough to attract more people from the cross-platform C+
>> + crowd, this would mean a big move forwward. IMHO, this is doable and
>> realistic, provided the concerns discussed here are taken seriously.
>
> You forgot to mention that with Seaside we now have this unique feature
> of being able to  serve a desktop Gui and a webserver out of the
> same domain model.

Not very unique or new: VisualWave has done that since 1995. Of course, Seaside is a lot nicer, and it's great that VW's web support can be thought of as cool again.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Steven Kelly wrote:

>> You forgot to mention that with Seaside we now have this unique feature
>> of being able to  serve a desktop Gui and a webserver out of the
>> same domain model.

> Not very unique or new: VisualWave has done that since 1995.

... and Aida/Web with its strong MVC philosophy since 1996 :)

Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Thu, 24 Jul 2008 08:44:35 +0200
Joachim Geidel <[hidden email]> wrote:

> However, I have the impression that this package is almost forgotten. The
> last version was from 2001 and was not loadable any more due to obsolete
> class definition messages. I have republished it a few minutes ago with new
> class definitions.

SmallInterfaces defines SequencableCollection>>withIndexDo:,
Squeak-Extensions does so too.

The SmallInterfaces versions sets things up for [:index :element | ...],
the squeak version chooses [:element :index | ].

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stefan Schmiedl wrote: Is there any reason why SmallInerfaces isn't using keysAndValuesDo: ?

Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

However, a great benefit with VisualWorks, in comparison to IntelliJ IDEA, Eclipse and others, is that it is way faster at both start up and handling, and top of that with a much smaller footprint than the others.

More often than not the other IDE:es just hangs for a couple of seconds, or even minutes. Doing what?
To compare the speed for instance try searching for implementers, senders, to get a hierarchical browser or something similar. In VisualWorks this usually only takes a fraction of a second but in the other ide:es be prepared to waaaaiiiit. Just open a new window takes "forever" in other IDE:es. However, I don't think that non Smalltalk developers are as used to "multiple window editing" as a lot of Smalltalk developers are (it's not uncommon for me to have more than 50 VW windows on screen.)

Then we have incremental compilation which is outstanding in comparison to for instance the more common make, ant, or maven approach.
And you should not forgot the benefit of having all the tools available for inspection and change within the IDE and language itself. Writing a new (simple) kind of browser could be done in minutes. However its way harder to hack the RBBrowser than the classic one from the 80s.

Although I think one quite easily could make a face lift to the browser I think it is more important to
- Make it easier and smoother to get Smalltalk to interoperate with its surroundings (C, Java, opengl, os, hardware, ...)
- Make all api:s work properly in agreement with the current standards (xml, webservices, imap, ssh-2, etc)
- (Finally) support anti-aliasing and alpha channel
- improve the version control
- simplify the deployment process    
- modernize the gui api (widgetry??) and the GUI builder and then indirectly the look and feel of the rest of the system

This list could easier be longer but I stop here.

Björn

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>> SmallInterfaces defines SequencableCollection>>withIndexDo:,
>> Squeak-Extensions does so too.
>>
>> The SmallInterfaces versions sets things up for [:index :element | ...],
>> the squeak version chooses [:element :index | ].
>>  
> Is there any reason why SmallInerfaces isn't using keysAndValuesDo: ?

I can only guess: The last version in the public repository was from 2001,
and both Squeak-Extensions and SequencableCollection>>keysAndValuesDo: did
not exist at that time. In the version I published recently, I only changed
the class definitions such that the package is loadable again.

Obviously, somebody will have to take care of the package. As there is also
a Squeak port, this might mean maintaining both and keeping them in sync if
possible. The license will have to be clarified (I have the impression that
Benny Sadeh put it into the public domain, but that's only a guess). Any
volunteers?

But maybe it's better to do first things first: Is there any interest in the
package, or should we let it sink back into oblivion?

Best regards,
Joachim Geidel


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Thu, 31 Jul 2008 19:19:03 +0200
Joachim Geidel <[hidden email]> wrote:

>
> But maybe it's better to do first things first: Is there any interest in the
> package, or should we let it sink back into oblivion?

If it won't load, most probably nobody will.

I wanted to try it mainly because it offers functionality I remember
seeing with protocols in Dolphin: Drop a protocol on a class and get
method stubs to fill out. Or something like that.

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Might as well add the following to the list while we're at it,

- cure cancer
- invent time machine
- build a moon base with a pool and add sharks with frickin' laser beams

... it's just a list after all :)

-Boris (donning his flame suit)

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stefan,

Am 31.07.08 20:08 schrieb Stefan Schmiedl:
>> But maybe it's better to do first things first: Is there any interest in the
>> package, or should we let it sink back into oblivion?
>
> If it won't load, most probably nobody will.
>
> I wanted to try it mainly because it offers functionality I remember
> seeing with protocols in Dolphin: Drop a protocol on a class and get
> method stubs to fill out. Or something like that.

I had a closer look at the state of SmallInterfaces this morning. It's
loadable, but it needs some work.

- There are several methods which were useful extensions in 2001, but which
are now defined in various other packages. I found conflicts with
Programming-Extensions, Glorp, Convenience and Kernel. Of course, that's not
Benny Sadeh's fault. It's simply a fact that many useful methods have been
implemented over and over again. Most of these methods can simply be removed
from SmallInterfaces.

- SmallInterfaces extends the class creation protocol to add a keyword for
interfaces implemented by a class. However, the lookup of the Interfaces
named in the class definition does a global search which does not handle the
case of Interfaces or classes with the same name which are defined in
different Namespaces. This is a bug which has to be fixed, but which
shouldn't cause problems when there are no duplicate names.

- The definition message of a class which implements interfaces is not
replaced by a message showing the additional keyword for interfaces, such
that this fact is not visible in the browser.

- The extended class definition message is not recognized by the Refactoring
Browser (which has an ugly hard-coded list in a method called
classDefinitionMessages) and causes an exception when deleting an Interface.

- There is a mechanism which attempts to synchronize changes in an Interface
with the classes conforming to this interface. It opens a dialog, which
would be a problem when an interface is created or updated programmatically
at runtime. Also, if this needs manual intervention, it might point to a
conceptual problem, but I am not sure about this.

Using pragmas to annotate a class as conforming to an Interface, and methods
as being part of the implementation of an interface, might be a better
solution than using non-standard class definition messages. OTOH, there is a
Squeak port of SmallInterfaces, and using pragmas means incompatibility with
Squeak.

I'll try to find out about the license for SmallInterfaces, and if they
permit, I might fix these problems, but please don't expect this to happen
right away.

Joachim


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Mon, 04 Aug 2008 10:56:54 +0200
Joachim Geidel <[hidden email]> wrote:

> I'll try to find out about the license for SmallInterfaces, and if they
> permit, I might fix these problems, but please don't expect this to happen
> right away.

Joachim,

I do appreciate the efforts you already have put into this, and I won't
pressure you to spend spare time you probably don't have. We will see
what the future holds for SmallInterfaces.

Your pragma idea also sounds interesting, weren't pragmas introduced to
squeak a while ago? I'm totally out of sync here...

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc