On Mon, Feb 24, 2014 at 2:47 PM, Norbert Hartl <norbert at hartl.name> wrote:

>
> Am 24.02.2014 um 23:09 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Mon, Feb 24, 2014 at 1:58 PM, Norbert Hartl <norbert at hartl.name> wrote:
>
>>
>> Am 24.02.2014 um 22:19 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>
>>  On Mon, Feb 24, 2014 at 12:29 PM, Alexandre Bergel<
>> alexandre.bergel at me.com> wrote:
>>
>>> Would be great to have: 'ConfigurationOfRoassal' chopCamel  =>
>>> #('Configuration' 'Of' 'Roassal').
>>>
>>
>> 'ConfigurationOfRoassal'  piecesCutWhere: [:a :b| a isLowercase and: [b
>> isUppercase]] an OrderedCollection('Configuration' 'Of' 'Roassal')
>>
>> It's too trivial, surely.
>>
>>
>> No it is not. Because you have to know about it. Thanks for that one.
>>
>> "I learned something today[tm]"
>>
>
> But the real things to learn are the Method Finder and the browser.
>  Adding a lot of names that are known to those that know some scripting
> language du jour, but are incomprehensible to me, and no doubt many others,
> is not doing anything for anybody, except trying to be pointlessly cool.
>  Trying to encourage programmers to use the ability of the system to
> self-introspect and self-document is giving them general skills they can
> build upon.  So a project to improve the UI so that programmers are led to
> tools they can use for discovery seems worth-while to me, while adding yet
> more short-hand to hand-hold the ignorant isn't helping, IMHO.
>
> I agree that adding a lot of names is not helping because that might be
> the reason I didn't know that selector. What kind of selectors are the
> right ones I'm not the one to judge. But to be honest if I think about a
> collection the selector #piecesCutWhere: is not intuitive to me, too. So
> I'm glad you brought that to my attention.
>

I get that.  All naming is difficult.  That there are many different ways
to say the same thing in natural language is I think a common problem to
many languages, especially English.  Just remember the last time you tried
to do some free text search for some phrase.  Takes me ages to find old
messages in email.  So even if method is well-named, it likely has only one
of a number of plausible good names.  And if it has a usefully short
nickname (look at unix and lisp, cat & cdr etc) then it must likely be
learned by rote.

So the issue is not naming; it is how to /find/ functionality.  And so in
Smalltalk the issue is how to encourage programmers to go find things.  The
MessageFinder is amazing.  But people don't use it.  If they did no one
would be proposing to add chomp to the standard library.

<old man alert>When I learnt Smalltalk there were several factors that made
it easy for me to learn.  It was much smaller.  I thought it was cool.  I
had the time to learn it.  But when I learnt it the browser was simple,
refactoring hadn't been invented, there was no MethodFinder, and there was
almost _no_ documentation.  Basically I learnt it by playing with it,
exploring it, reading it, building it.</old man alert>

So why aren't people taking the time to learn it today?  Is it the system's
fault?  Is it too big?  Are the readable parts of the system non-existent,
or too difficult to find?  Is it some cultural change that means people
can't learn such systems any more? Was it only learnable by a few people
back in the day and it remains unsuitable for a mass audience?  Is it
impossible to design user interfaces that invite exploration?  Do people no
longer want to play with the system but instead want to use it to get
something done fast, and can't spare the time to learn it properly?  Are
computing languages like English, and every programming language must adopt
the conventions and vocabulary of the most popular?  Is inheritance too
hard to navigate to discover that SequenceableCollection has lots of useful
String mehtods, and some useful methods on ByteString are in String, etc?

I think suggestions that one add functionality that already exists in the
system point to some interesting issues.  And I think someone with an HCI
or UI bent might get somewhere approaching these questions systematically.



> thanks again,
>

you're welcome :-)


>
> Norbert
>
>
>> Norbert
>>
>>
>>> Alexandre
>>>
>>>
>>> On Feb 24, 2014, at 2:30 PM, Daniela Meneses <daniela11290 at gmail.com>
>>> wrote:
>>>
>>> > Hi to all,
>>> >
>>> > As you may know I'm working on in some improvements for the String
>>> class. Until now I implemented some missing tests. Right now I'm looking
>>> forward to add new methods that could be useful based on Ruby API (
>>> http://www.ruby-doc.org/core-2.1.0/String.html). These are a few of the
>>> methods that I'm planning to implement:
>>> >
>>> >       * chomp(separator=$/) -> new_str
>>> >       * chop() -> new_str
>>> >       * ljust(integer, padstr='') ->new_str
>>> >       * next -> new_str
>>> >       * partition(sep) -> [head, sep, tail]
>>> >
>>> > Could you help to find out if these methods are already available for
>>> the String class?
>>> >
>>> > If you have any idea of new methods for the string class, will be
>>> really welcome.
>>> >
>>> > --
>>> > Cheers,
>>> > Daniela Meneses
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140224/039d9a1b/attachment.htm