Beginner question :) search and replace in String

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and replace in String

Adrian Kuhn
Douglas Brebner <squeaklists@...> writes:

> Please bear in mind that natural languages have much more redundancy and
> less precision than programming languages.

You are right!

Personally I believe programming languages should strive to be as close to the
 the more stringent English of specification documents, and not to natural
 language with *all* its facets. The main line of argumentation in my previous
 mail was thus that the very argument of natural languages can be used in favor
 of my point as well :)

> In addition, programming languages have handy tools like autocompletion
> that natural languages don't, making abbreviations less useful :)

That argument keeps popping up (eg from Ramon just in parallel to this
 answer, and also before) but I am not sure if auto completion is the whole
 story. For example in Object-C you have to write

   @"hello " stringByAppendingString: @"worlds!"

 to concatenate strings. Whereas in Smalltalk we just write

   'hello ', 'worlds!'

 clearly both are as writable when you got auto completion, but isn't the
 second just more readable? In his "Elements of Style" William Strunk
 recommends to omit unnecessary word. With regard to source code, I'd say the
 lesson should be that more verbose is typically more readable but *not*
 always.

So given this observation that sometimes operators (or single letters, which
 for that sake the same) are *sometimes* more readable than natural language,
 we can go an revisit the set of operators in Smalltalk and check if there
 might be more candidates. And I'd be more than surprised if are were not some
 more candidates for abbreviation.

For example Pharo already got #<< for appending to a stream, so the same would
 make sense to append elements to a collecton, such that we can write

    list := List new << 'lorem' << 'ipsum' << 'dolor'.

et cetera.

--AA


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and replace in String

csrabak
Em 06/01/2010 11:18, Adrian Kuhn < [hidden email] > escreveu:

> Douglas Brebner writes:
>
> > Please  bear  in  mind  that  natural  languages  have  much  more
> > redundancy and less precision than programming languages.
>  You are right!
>  Personally I  believe programming languages should strive  to be as
> close to the
>  the more  stringent English of specification documents,  and not to
>  natural  language   with  *all*  its  facets.  The   main  line  of
>  argumentation in my  previous mail was thus that  the very argument
>  of natural languages can be used in favor of my point as well :)
>
> > In   addition,  programming  languages   have  handy   tools  like
> > autocompletion that natural  languages don't, making abbreviations
> > less useful :)
>  That argument keeps  popping up (eg from Ramon  just in parallel to
> this
>  answer, and  also before) but I  am not sure if  auto completion is
>  the whole story. For example in Object-C you have to write
>
>  @"hello " stringByAppendingString: @"worlds!"
>
>  to concatenate strings. Whereas in Smalltalk we just write
>
>  'hello ', 'worlds!'
>
>  clearly  both are  as writable  when you  got auto  completion, but
>  isn't the  second just  more readable?

Two points on "more readable".  _Right now_ to Smalltalkers  that know
by heart that #, is a concatenation operator, it seems *less cluttered*
and thus it appears more readable.

Put forward some twenty to fifty years (or to do it right now ask a
girlfriend that doesn't know nor Objective C nor Smalltalk) to see
what of two expressions convene more meaning.

As everybody else knows :-P the string concatenation operator is '+',
right!?  So #, needs to be explained anyway. . .


> In  his "Elements  of Style"
>  William Strunk recommends to  omit unnecessary word. With regard to
>  source  code, I'd say  the lesson  should be  that more  verbose is
>  typically more readable but *not* always.
>  So  given  this observation  that  sometimes  operators (or  single
> letters, which
>  for that sake the same)  are *sometimes* more readable than natural
>  language, we  can go an revisit  the set of  operators in Smalltalk
>  and check if  there might be more candidates. And  I'd be more than
>  surprised if are were not some more candidates for abbreviation.
>  For example Pharo already got #<< for appending to a stream, so the
> same would
>  make  sense to append  elements to  a collecton,  such that  we can
> write
>
>  list := List new << 'lorem' << 'ipsum' << 'dolor'.
>  et cetera.

This may lead to the same problem we already have with #, namely it is
slow and not recommended for repeated operations.

We have to strike a balance between the easiness for writing the code
with the implementation that will run it.

my 0.019999....

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and replace in String

Levente Uzonyi-2
On Wed, 6 Jan 2010, [hidden email] wrote:

> Em 06/01/2010 11:18, Adrian Kuhn < [hidden email] > escreveu:
>
>> Douglas Brebner writes:
>>
>>> Please  bear  in  mind  that  natural  languages  have  much  more
>>> redundancy and less precision than programming languages.
>>  You are right!
>>  Personally I  believe programming languages should strive  to be as
>> close to the
>>  the more  stringent English of specification documents,  and not to
>>  natural  language   with  *all*  its  facets.  The   main  line  of
>>  argumentation in my  previous mail was thus that  the very argument
>>  of natural languages can be used in favor of my point as well :)
>>
>>> In   addition,  programming  languages   have  handy   tools  like
>>> autocompletion that natural  languages don't, making abbreviations
>>> less useful :)
>>  That argument keeps  popping up (eg from Ramon  just in parallel to
>> this
>>  answer, and  also before) but I  am not sure if  auto completion is
>>  the whole story. For example in Object-C you have to write
>>
>>  @"hello " stringByAppendingString: @"worlds!"
>>
>>  to concatenate strings. Whereas in Smalltalk we just write
>>
>>  'hello ', 'worlds!'
>>
>>  clearly  both are  as writable  when you  got auto  completion, but
>>  isn't the  second just  more readable?
>
> Two points on "more readable".  _Right now_ to Smalltalkers  that know
> by heart that #, is a concatenation operator, it seems *less cluttered*
> and thus it appears more readable.
>
> Put forward some twenty to fifty years (or to do it right now ask a
> girlfriend that doesn't know nor Objective C nor Smalltalk) to see
> what of two expressions convene more meaning.
>
> As everybody else knows :-P the string concatenation operator is '+',
> right!?  So #, needs to be explained anyway. . .

You're wrong, it's '.'. :)

>
>
>> In  his "Elements  of Style"
>>  William Strunk recommends to  omit unnecessary word. With regard to
>>  source  code, I'd say  the lesson  should be  that more  verbose is
>>  typically more readable but *not* always.
>>  So  given  this observation  that  sometimes  operators (or  single
>> letters, which
>>  for that sake the same)  are *sometimes* more readable than natural
>>  language, we  can go an revisit  the set of  operators in Smalltalk
>>  and check if  there might be more candidates. And  I'd be more than
>>  surprised if are were not some more candidates for abbreviation.
>>  For example Pharo already got #<< for appending to a stream, so the
>> same would
>>  make  sense to append  elements to  a collecton,  such that  we can
>> write
>>
>>  list := List new << 'lorem' << 'ipsum' << 'dolor'.
>>  et cetera.
>
> This may lead to the same problem we already have with #, namely it is
> slow and not recommended for repeated operations.
>

No, it's fast, because it doesn't create copies. Of course to know that
you also have to know that List is an alias for OrderedCollection...
It's just a C++ism that makes your code slower. :)


Levente

> We have to strike a balance between the easiness for writing the code
> with the implementation that will run it.
>
> my 0.019999....
>
> --
> Cesar Rabak
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and replace in String

csrabak
Em 06/01/2010 17:30, Levente Uzonyi < [hidden email] > escreveu:

>  On Wed, 6 Jan 2010, [hidden email] wrote:
[snipped]
> > As everybody  else knows :-P the string  concatenation operator is
> > '+', right!?  So #, needs to be explained anyway. . .
>  You're wrong, it's '.'. :)

You know this polyglot approach to programming ends up with some
confusion :-)

[snipped]

> > This may lead  to the same problem we already  have with #, namely
> > it is slow and not recommended for repeated operations.
> >
>  No, it's fast, because it  doesn't create copies. Of course to know
> that   you  also  have   to  know   that  List   is  an   alias  for
> OrderedCollection...   It's  just  a  C++ism that  makes  your  code
> slower. :)
>
Levente,

In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is
no List class, and:

Collection>>, aCollection
        ^self copy addAll: aCollection; yourself

Which creates copies for each #, method send, right?  Or do I miss
something here?

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and replace in String

Levente Uzonyi-2
On Wed, 6 Jan 2010, [hidden email] wrote:

> Em 06/01/2010 17:30, Levente Uzonyi < [hidden email] > escreveu:
>
>>  On Wed, 6 Jan 2010, [hidden email] wrote:
> [snipped]
>>> As everybody  else knows :-P the string  concatenation operator is
>>> '+', right!?  So #, needs to be explained anyway. . .
>>  You're wrong, it's '.'. :)
>
> You know this polyglot approach to programming ends up with some
> confusion :-)
>
> [snipped]
>
>>> This may lead  to the same problem we already  have with #, namely
>>> it is slow and not recommended for repeated operations.
>>>
>>  No, it's fast, because it  doesn't create copies. Of course to know
>> that   you  also  have   to  know   that  List   is  an   alias  for
>> OrderedCollection...   It's  just  a  C++ism that  makes  your  code
>> slower. :)
>>
> Levente,
>
> In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is
> no List class, and:
>
> Collection>>, aCollection
> ^self copy addAll: aCollection; yourself
>
> Which creates copies for each #, method send, right?  Or do I miss
> something here?

Yes you do, List is one of Adrian's ideas to Huffman code smalltalk.
Details here http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/


Levente

>
> --
> Cesar Rabak
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Beginner question :) search and rep lace in String

csrabak
Em 06/01/2010 22:06, Levente Uzonyi < [hidden email] > escreveu:

> On Wed, 6 Jan 2010, [hidden email] wrote:
>
> > Em 06/01/2010 17:30, Levente Uzonyi < [hidden email] > escreveu:
> >
> >> On Wed, 6 Jan 2010, [hidden email] wrote: [snipped]
> >>> As everybody else knows :-P the string concatenation operator is
> >>> '+', right!?  So #, needs to be explained anyway. . .
> >> You're wrong, it's '.'. :)
> > You know this  polyglot approach to programming ends  up with some
> > confusion :-)
> > [snipped]
> >
> >>> This may lead to the same problem we already have with #, namely
> >>> it is slow and not recommended for repeated operations.
> >>> No, it's  fast, because it  doesn't create copies. Of  course to
> >>  know
> >> that  you  also   have  to  know  that  List   is  an  alias  for
> >> OrderedCollection...   It's just  a C++ism  that makes  your code
> >> slower. :)
> >> Levente,
> > In a ordinary (sort of, it's  a dev image, Pharo 1.0 #10503, there
> > is no List class, and:
> >
> > Collection>>, aCollection ^self copy addAll: aCollection; yourself
> > Which creates copies for each #, method send, right?  Or do I miss
> > something here?
>  Yes  you  do,  List  is  one  of Adrian's  ideas  to  Huffman  code
> smalltalk.                        Details                       here
> http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/
>
Ok Levente!

In this case after reading Adrian's blog post, I would say "List" is
not a good choice:  VW uses List for a different kind of object (a
descendant from OrderedCollection, in fact).

As a side note, IMNHO Object>>out (as Travis' idea) seems to me better
than Object>>p for the same purpose.

Regards,

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12