Re: [Pharo-dev] [Article] Elegant Pharo Code
Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
Ruby and Pearl look very ugly to me. Programming languages are primarily personal preference. Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community. I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning. Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way. But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news. PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :) On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow@fastmail.fm> wrote:
Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
On 08 Jul 2014, at 21:53, kilon alios <kilon.alios@gmail.com> wrote:
Ruby and Pearl look very ugly to me.
Programming languages are primarily personal preference.
Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community.
I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning.
Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way.
Thanks, Kilon.
But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news.
Yes, I think we need more/better places to link everything together. A curated reading list maybe.
PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :)
I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence.
On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow@fastmail.fm> wrote: Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
It may have been mentioned already, but number 7 is wrong, is states: "7. Sum of the first 64 primes" when it actually is: "7. Sum of the primes not larger than 64" Cheers, Sergi 2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 08 Jul 2014, at 21:53, kilon alios <kilon.alios@gmail.com> wrote:
Ruby and Pearl look very ugly to me.
Programming languages are primarily personal preference.
Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community.
I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning.
Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way.
Thanks, Kilon.
But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news.
Yes, I think we need more/better places to link everything together. A curated reading list maybe.
PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :)
I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence.
On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow@fastmail.fm> wrote: Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
I've often wondered if there might not be a better way to write while loops that output a product, similar to enumeration sum: and count:. | sum count index | sum := 0. count := 0. index := 1. [ index := index + 1. index isPrime ifTrue: [ count := count + 1. sum := sum + index ]. count = 64 ] whileFalse. vs something like | count sum | count := 0. sum := 1 until: [ count = 64 ] sum: [ :index | index isPrime ifTrue: [ count := count + 1. index ] ifFalse: [ 0 ] ]. or | count sum | count := 0. sum := (1 until: [ count = 64 ]) sum: [ :index | index isPrime ifTrue: [ count := count + 1. index ] ifFalse: [ 0 ] ]. On Sun, Jul 13, 2014 at 3:05 PM, Sergi Reyner <sergi.reyner@gmail.com> wrote:
It may have been mentioned already, but number 7 is wrong, is states:
"7. Sum of the first 64 primes"
when it actually is:
"7. Sum of the primes not larger than 64"
Cheers, Sergi
2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 08 Jul 2014, at 21:53, kilon alios <kilon.alios@gmail.com> wrote:
Ruby and Pearl look very ugly to me.
Programming languages are primarily personal preference.
Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community.
I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning.
Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way.
Thanks, Kilon.
But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news.
Yes, I think we need more/better places to link everything together. A curated reading list maybe.
PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :)
I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence.
On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow@fastmail.fm> wrote: Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Hi Sergi, On 13 Jul 2014, at 15:05, Sergi Reyner <sergi.reyner@gmail.com> wrote:
It may have been mentioned already, but number 7 is wrong, is states:
"7. Sum of the first 64 primes"
when it actually is:
"7. Sum of the primes not larger than 64"
Cheers, Sergi
I fixed that, thank you ! Sven
2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 08 Jul 2014, at 21:53, kilon alios <kilon.alios@gmail.com> wrote:
Ruby and Pearl look very ugly to me.
Programming languages are primarily personal preference.
Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community.
I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning.
Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way.
Thanks, Kilon.
But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news.
Yes, I think we need more/better places to link everything together. A curated reading list maybe.
PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :)
I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence.
On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow@fastmail.fm> wrote: Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
Hi Paul, On 08 Jul 2014, at 21:33, Paul Davidowitz <pdavidow@fastmail.fm> wrote:
Very nice, except all this could be done in Ruby, also elegantly. The Smalltalk advantage is the live image, and that's where the focus should be.
I was hoping to get some discussions around this article - there is this sentence in the beginning: 'How would you tackle these problems using your favourite language ?'. Coming back to your point, IMHO, it is very hard to explain what I find so nice about Pharo/Smalltalk: it is a combination of different elements, not one single thing. I did mention the live objects idea. Another thing that I find important is that you can look at the source code of anything very easily, effortlessly, including the implementation of all tools. I do not know enough about Ruby to make authoritative comparisons, but since it is based on Smalltalk and Lisp, is dynamic and interactive, you obviously have a point: Ruby is in the right general area. Personally I do *not* like Ruby's more complex syntax (the convenience aspects, the unnecessary syntactic sugar). I also do not think a stock Ruby install/shell can do the same things as easily out of the box, but of course, Ruby will come much closer that say Java. Sven
participants (5)
-
J.F. Rick -
kilon alios -
Paul Davidowitz -
Sergi Reyner -
Sven Van Caekenberghe