November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Simple vs. Easy

by Jimmie Houchin

Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 Hi Folks, I'm answering you off-list because I'm not subscribed to the Pharo list. Feel free to forward this there, if you wish. I think it is great to put focus on simplicity (an objective value) over easyness (a subjective value). Rich also makes a good critic to usual practices, including the dichotomy between understanding and TDD (test driven development). However, the value of simplicity is not something new. The difference between essential complexity and accidental complexity is the heart of "No Silver Bullet â Essence and Accidents of Software Engineering" (by Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, http://drdobbs.com/184407534) It is also central to Smalltalk, see "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) These three articles might be the most important writings on software engineering ever. The problem with this discussion is that everybody will claim simplicity is a crucial objective of their project. However, Pharo and Squeak don't realize (or don't want to realize) that simplicity appears only by removing complexity, never by adding more of it. Cuis is a Squeak fork with the #1 objective of being simple and understandable. It is the result of more than 10 years suffering the accidental complexity in Squeak, comparing with other Smalltalks, together with a lot of reflection and work, by me and others. It is, I believe, the only Smalltalk in active development that pursues this objective of the original Smalltalk-80 project. You can get it from http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take statistics (lines of code, etc). Compare. You might have a nice surprise. Jimmie, you asked "How can we move Pharo to be a better answer to Simple vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up feature list as a priority, and focus on simplicity. Make a list of the features in Pharo that are really important, and not part of Cuis, and turn them into optional packages. Make that list as short as possible! Worry more about code quality and less about discarding potentially useful stuff, that is not good enough. Cheers, Juan Vuletich

Nov. 4, 2011

[Pharo-project] crash of the vm on ubuntu

by Alexandre Bergel

Hi! My students are experiencing frequent crashes of the CogVM when playing with Spy (a profiling framework that instrument compile methods and replace them during the execution). My students use a MooseOneClick bundle. I am not sure which version of the CogVM they use actually. Is there a way to check this? Anyone has experienced frequent crashes with Ubuntu? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 4, 2011

[Pharo-project] [update 1.4] #14215

by StÃ©phane Ducasse

14215 ----- - Issue 4957: Let asScaledDecimal use the right number of decimals Thanks nicolas cellier. http://code.google.com/p/pharo/issues/detail?id=4957 Change the policy for conversions to ScaledDecimal. Always honour the number of decimal places (scale) passed as argument to asScaledDecimal: When no scale is passed, uses strictly necessary number of decimal places if the number is exact (not Float) and if a finite decimal representation exists. Otherwise uses the default of 8 decimal places. This makes more sense IMO than previous implementation. Integer version was screwing the user by not fulfiling the requested number of decimal places, I can t believe it was the right interpretation of the ANSI standard.... Or someone gives me a good rationale. - Issue 4964: Number nthRoot: should be subclassResponsibility. Thanks nicolas cellier. http://code.google.com/p/pharo/issues/detail?id=4964 - Issue 4951: The version menu in the diff tool does not work. Thanks nicolas cellier. http://code.google.com/p/pharo/issues/detail?id=4951 - Issue 3197: Make Character class>>separators and Character class>>allByteCharacters return strings instead of Arrays. Thanks nicolas cellier, Andreas raab, and vonbecmann. http://code.google.com/p/pharo/issues/detail?id=3197 Stef

Nov. 4, 2011

Re: [Pharo-project] Someone bought Smalltalk?

by S Krish

I guess, this seems like a reference to the Cincom change in license format from: Non-Commercial to a Personal Use license that in effect bars any use of an organization rolling out Cincom VW / OS applications without paying the license. Personal license now dictates only an individual in his own personal single workstation having / using VW. Ofcouse the point about American co having bought Smalltalk seem out of synch as it occured a decade back. There is a long list of email chain on the VW list that allows lot of stuff despite the legalese, but I guess it is still muddy and does attract the legal notices on various organizations. ****************************** But I hope there is no real danger of Pharo / Squeak attracting any such provisions : "O*riginal Apple code, which is governed by the **Apache License*<http://en.wikipedia.org/wiki/Apache_License> *.* *Originally, Apple actually released Squeak under a license called the "Squeak License." While source code was available and modification permitted, the Squeak License contained an **indemnity clause*<http://en.wikipedia.org/wiki/Indemnity_clause> * that prevented it from qualifying as true **Free and Open Source Software*<http://en.wikipedia.org/wiki/Free_and_Open_Source_Software> *.* *In 2006, Apple relicensed Squeak twice. First, in May, Apple used its own * *Apple Public Source License*<http://en.wikipedia.org/wiki/Apple_Public_Source_License> *, which satisfies the **Free Software Foundation*<http://en.wikipedia.org/wiki/Free_Software_Foundation> *'s concept of a Free Software License [6]<http://en.wikipedia.org/wiki/Squeak#cite_note-5>and has attained official approval from the **Open Source Initiative*<http://en.wikipedia.org/wiki/Open_Source_Initiative> *[7]* <http://en.wikipedia.org/wiki/Squeak#cite_note-6>* as an Open Source License." * On Tue, Nov 1, 2011 at 6:43 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Oh, my God! I will have to delete every piece of Smalltalk evidence! > > Ah, but I guess it will be a while until they get to Switzerland. I just > hope they do not catch me in Argentina. > > Doru > > > > On 1 Nov 2011, at 11:12, Damien Cassou wrote: > > > I just received this email: > > > > > > ---------- Forwarded message ---------- > > > > I heard some rumors about Smalltalk. Apparently, an american > > enterprise bought Smalltalk and is trying to make money by sueing > > users. Therefore, they changed the licence agreements (and maybe other > > stuff). In my company we have a strict interdiction to use Smalltalk. > > > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Lambdas are relegated to relative obscurity until Java makes them > > popular by not having them." James Iry > > > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > >

Nov. 4, 2011

Re: [Pharo-project] relation to squeak

by Frank Shearar

On 4 November 2011 08:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Frank > > When I write we usually talk about my team or myself. Yes, I know. I just wanted to indicate that the Pharo/Squeak split is not as severe, for want of a better word, as might seem at first. While Pharo and Squeak have different goals, they're not antithetical goals. > Now I have a question: did you sign the pharo license because else it would indicate that you are not really interested in contributing > to our vision but more taking from it. This is ok too. You can do that but this is less positive energy. Actually, I have, but I must still post it off to you. Thanks for the reminder! (And of course the libraries I put on SqueakSource (zippers, delimited continuations, and so on) are all MIT, and I would be most appreciative of bug reports, critiques etc., that members of the Pharo community might send my way. frank > Stef > >>> >>>> Hello! >>>> >>>> One thing is not clear to me. How is Pharo related to standard Squeak? I know Pharo is a fork with its own mission, but is the development related? Do fixes in Pharo propagate upstream to Squeak? Is Squeak even considered "upstream"? Do fixes in Squeak propagate into Pharo? Automatically or manually? Or have they started being developed completely independently from some point in time? >>> >>> We do not really look at squeak. No time for that. Now if people having time mentioned that we have an interesting fix then we will be inclined to include it in pharo. >> >> Well, I guess it depends on what you mean by "we" - "we" as an >> Official Pharo Official, sure, I can understand - rightly so - that >> you're concentrating on what Pharo needs. "We" as a vocal subcommunity >> of Pharo also work with Squeak, trying to pull the two codebases back >> together. >> >> And that's a good thing, that there are both forces. Pharo the >> Official Direction is cutting new ground in a particular direction, >> and the Pharo+Squeak folk try to make sure that there isn't too much >> duplication of effort. There are few enough Smalltalkers in the two >> communities: we ought to try leverage off each other as much as we >> can. >> >> frank >> >>> Let me restate our vision and why we decided to make Pharo. >>> Our goal and vision behind Pharo is to twofold: >>> Â Â Â Â - make sure that people can make money and create their own wealth in Smalltalk. Provide the best environment we can for that (and this is not easy) >>> Â Â Â Â This is really important for us. A part of the team here is working on setting up a company around tools build on top of Pharo. >>> Â Â Â Â We are really happy when we hear that people are using Pharo for making business (net style, nextPlan, b9, pinesoft)â¦. >>> Â Â Â Â This is really great. >>> >>> Â Â Â Â - bring Smalltalk to the next level: >>> Â Â Â Â Â Â Â Â - first class variables >>> Â Â Â Â Â Â Â Â - small core >>> Â Â Â Â Â Â Â Â - may be new mop >>> Â Â Â Â Â Â Â Â - powerful tools and abstractions >>> Â Â Â Â The idea is to have a solid infrastructure to be able to invent the next generation smalltalkish system because smalltalk lacks a lot and innovation stopped a while ago. >>> Â Â Â Â Â Â Â Â (real sandboxing, real minimal kernel with pluggable uiâ¦) >>> >>> It will take time but we will get there. >>> >>> Stef >>> >> > > >

Nov. 4, 2011

Re: [Pharo-project] relation to squeak

by StÃ©phane Ducasse

Frank When I write we usually talk about my team or myself. Now I have a question: did you sign the pharo license because else it would indicate that you are not really interested in contributing to our vision but more taking from it. This is ok too. You can do that but this is less positive energy. Stef >> >>> Hello! >>> >>> One thing is not clear to me. How is Pharo related to standard Squeak? I know Pharo is a fork with its own mission, but is the development related? Do fixes in Pharo propagate upstream to Squeak? Is Squeak even considered "upstream"? Do fixes in Squeak propagate into Pharo? Automatically or manually? Or have they started being developed completely independently from some point in time? >> >> We do not really look at squeak. No time for that. Now if people having time mentioned that we have an interesting fix then we will be inclined to include it in pharo. > > Well, I guess it depends on what you mean by "we" - "we" as an > Official Pharo Official, sure, I can understand - rightly so - that > you're concentrating on what Pharo needs. "We" as a vocal subcommunity > of Pharo also work with Squeak, trying to pull the two codebases back > together. > > And that's a good thing, that there are both forces. Pharo the > Official Direction is cutting new ground in a particular direction, > and the Pharo+Squeak folk try to make sure that there isn't too much > duplication of effort. There are few enough Smalltalkers in the two > communities: we ought to try leverage off each other as much as we > can. > > frank > >> Let me restate our vision and why we decided to make Pharo. >> Our goal and vision behind Pharo is to twofold: >> - make sure that people can make money and create their own wealth in Smalltalk. Provide the best environment we can for that (and this is not easy) >> This is really important for us. A part of the team here is working on setting up a company around tools build on top of Pharo. >> We are really happy when we hear that people are using Pharo for making business (net style, nextPlan, b9, pinesoft)â¦. >> This is really great. >> >> - bring Smalltalk to the next level: >> - first class variables >> - small core >> - may be new mop >> - powerful tools and abstractions >> The idea is to have a solid infrastructure to be able to invent the next generation smalltalkish system because smalltalk lacks a lot and innovation stopped a while ago. >> (real sandboxing, real minimal kernel with pluggable uiâ¦) >> >> It will take time but we will get there. >> >> Stef >> >

Nov. 4, 2011

Re: [Pharo-project] bootable Pharo image

by StÃ©phane Ducasse

thanks pavel. Jean-Baptiste may be this can be interesting for your project On Nov 3, 2011, at 11:39 PM, Pavel Krivanek wrote: > Hi, > > I tried to prepare a bootable Pharo ISO image based on Tiny Core > Linux. Namely on MicroCore (kernel 3.0.3) that was extended with WiFi > support. There is standard Pharo 1.3 image with OSProcess and > CommandShell installed on the Smalltalk side. The resultant image has > about 37 MB. > > Download: > http://www.windmap.cz/playground/pharo/pharo.iso > > If you want to add it directly to your Grub menu, you may do it > without need of extra partition. To the grub.conf add something like: > > title Pharo > root (hd0,1) > kernel /boot/pharo/vmlinuz vga=791 quiet > initrd /boot/pharo/tinycore.gz > > where vmlinuz and tinycore.gz are the only files needed from the ISO image. > > Remastering: > > unpack: > zcat tinycore.gz | sudo cpio -i -H newc -d > > pack: > find | cpio -o -H newc | gzip -2 > ../tinycore.gz > > better compression: > advdef -z4 tinycore.gz > > create ISO (you need unpacked original ISO image): > /bin/cp -pfr tinycore.gz boot > mkdir -p newiso > /bin/cp -pfr boot newiso > mkisofs -l -J -R -V TC-custom -no-emul-boot -boot-load-size 4 \ > -boot-info-table -b boot/isolinux/isolinux.bin \ > -c boot/isolinux/boot.cat -o pharo.iso newiso > > Cheers, > -- Pavel >

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

Every so many years, somebody comes along with a fix for everything. First, it was assemblers. Actually, it probably started with punch cards, and then a *machine* to make them (no more hole punches<g>). People start to want more from software, so assembly language didn't cut it. Then we get compilers - that'll fix everything. Well, maybe not. As with most of the proposed magic fixes, some good will probably come of the resurgence of functional languages, but I very much doubt that they will provide a one-size-fits-all solution to everything. For us, I think we want most things to be simple, and some things to be easy. Calling C libraries is inherently complex, so let's just make it easy to do. Our GUIs should be simple. Making them would ideally be easy, at least to the extent that the result can remain simple. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Jimmie Houchin [jlhouchin(a)gmail.com] Sent: Thursday, November 03, 2011 7:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy On 11/3/2011 4:53 PM, Carlo wrote: > It's a great talk and I found him to be an engaging speaker. > Out of interest, what parts don't you agree with and would it affect how we move Pharo forward? > > Cheers > Carlo > > On 03 Nov 2011, at 10:21 PM, Jimmie Houchin wrote: > > It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. I didn't necessarily watch the video critically. But here goes. He is very pro a reasonably, but not purely functional approach. Data in data structures and functions which operate on them. I have not reached a place where I view the world statelessly. I have only dabbled with functional programming and do not fully understand how to do it purely or well. Thus far any attempts I have made to do things in a fairly pure functional manner with data structures and functions. I haven't truly succeeded. I end up going to a pretty simple object approach. The object is my data structure with its methods, my functions. I won't argue the sometimes object oriented gets very, seemingly unnecessarily complex. Which is why I keep an on more functional approaches. I think Smalltalk is better than others. But we still have a mess. I think Pharo is going the right direction on this. Untangling the mess. Which by definition in the video would be simplifying our artifact. I fully agree on wanting things to be Simple vs. Easy. I would like to see our Easy things become Simple, our complex things become Simple(r). I don't claim to know the best answer to the questions or claims by the functional proponents. But I do know that they are not all wrong, nor do I assume that are all right. My point of view at this 'state' of my life. :) Jimmie

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by Jimmie Houchin

On 11/3/2011 4:53 PM, Carlo wrote: > It's a great talk and I found him to be an engaging speaker. > Out of interest, what parts don't you agree with and would it affect how we move Pharo forward? > > Cheers > Carlo > > On 03 Nov 2011, at 10:21 PM, Jimmie Houchin wrote: > > It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. I didn't necessarily watch the video critically. But here goes. He is very pro a reasonably, but not purely functional approach. Data in data structures and functions which operate on them. I have not reached a place where I view the world statelessly. I have only dabbled with functional programming and do not fully understand how to do it purely or well. Thus far any attempts I have made to do things in a fairly pure functional manner with data structures and functions. I haven't truly succeeded. I end up going to a pretty simple object approach. The object is my data structure with its methods, my functions. I won't argue the sometimes object oriented gets very, seemingly unnecessarily complex. Which is why I keep an on more functional approaches. I think Smalltalk is better than others. But we still have a mess. I think Pharo is going the right direction on this. Untangling the mess. Which by definition in the video would be simplifying our artifact. I fully agree on wanting things to be Simple vs. Easy. I would like to see our Easy things become Simple, our complex things become Simple(r). I don't claim to know the best answer to the questions or claims by the functional proponents. But I do know that they are not all wrong, nor do I assume that are all right. My point of view at this 'state' of my life. :) Jimmie

Nov. 3, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

One other thought: "guard-rail programming." I share his skepticism about tests as a panacea, BUT, automated tests are useful, and I have been able to use them to make changes that would have been much harder to make without good tests. One thing that he does not acknowledge is the source of some of the best test cases/methods one can write: newly discovered defects. Tests do not prove that software in correct, but they can help us avoid repeating mistakes. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Thursday, November 03, 2011 6:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy It is a good talk - thanks for mentioning it here! At several points, I was reminded of Beck's "Lots of little pieces," which is great advice. I have mixed feelings on (what I think he meant??) using undifferentiated collections for holding data. I use dictionaries a lot, and some things really are naturally arrays - no argument there. However, there are times when "points" in some weird cross product space could be represented as arrays, but there are huge benefits from having a class that "understands" the problem-specifics (and proves it via #printOn:). Put another way, one can explore and array of arrays, or an array of objects with named aspects and helpful string representations. The resulting classes then provide natural places to add behavior. Stef, I like your list. I might tweak it just a bit: let's be easy in C integration and simple in UI building. Maybe we can layer an easy tool on top of a simple framework for the latter?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, November 03, 2011 4:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy We are easy in debugging. Now I would like to be easy in C interaction C embedding UI building File manipulation Stef > Hello, > > I watched a video presentation by Rich Hickey, the creator of Clojure, on Simple Made Easy. > www.infoq.com/presentations/Simple-Made-Easy > > It is a very interesting video. I don't necessarily agree with everything he says. But I believe he makes some valuable distinctions between simple and easy. > > Where are we in Pharo simple? > Where are we easy? > > What can we do to move things from easy to simple? > > I am not qualified to answer his challenge to object oriented languages. But I feel that Smalltalk is the most functional OO language I've seen. And I don't necessarily mean functional in the programming methodology sense, but I don't rule it out either. I don't believe that C++ and Java will provide the best OO or programming experience. > > Watch the video. > I would love to hear some opinions from the community. > > How can we move Pharo to be a better answer to Simple vs. Easy? > > Thanks. > > Jimmie >

Nov. 3, 2011