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

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

Sven, Sig, Well said. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, November 04, 2011 11:22 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy Sure, Cuis is really cool as well as very impressive. However, it is limited: I want: Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings â¦ I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. Pharo takes on all these and at the same time tries to simplify things, the hard way. Sven On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > 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

Re: [Pharo-project] Storing all source code in a relational database

by StÃ©phane Ducasse

Thanks alan for this post. I think that same. :) > I don't agree with that. There's certainly an impedance mismatch with Smalltalk code and relational databases, but there's also an impedance mismatch between Smalltalk code and file systems. Things like git which are custom-built to operate against a particular idea of source code and the operations on it very fast don't necessarily work well with Smalltalk-style operations like "show me the versions of this method". > > Cincom has spent a lot of time recently on Store, but only part of that involves the database. And much of the difficulty in the database part is not inherent to mapping the code to a database, but is because the original design of the relational schema and the way Store talked to it are very very bad, and can't easily be changed without breaking access to the database for older versions. We will change the schema to something much better at some point, but it's something that we really can't do incrementally, so we're being careful with it. > > ENVY has some very nice features, but I'd say that it shows some weaknesses relative to more modern systems. For example, it is very intrusive to make a version, and it is extremely sensitive to network latency. > > A database designed specifically for source code, and with the sort of operations that Smalltalk source code control would like to be able to do quickly would obviously be the ideal choice. Like relational databases, you'd want it to be extremely reliable, scalable, transactional, and have many different free implementations easily available on all platforms, with enough standardization that they are all reasonably compatible. A relational database isn't necessarily the best choice in all circumstances, but I don't think it's an obviously bad one either. > >> >> Reg Krock >> 3 November, 2011 10:42 AM >> >> >> Igor, >> >> I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database. >> >> We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out? >> >> Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories. >> >> Has anyone at INRIA looked at ENVY? >> >> Regards, >> >> Reg >> >> From: Igor Stasenko <siguctua(a)gmail.com> >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Thursday, November 3, 2011 10:00:31 AM >> Subject: Re: [Pharo-project] Storing all source code in a relational database >> >> On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl> wrote: >> > ... is a waste of time and computing resources. Relational databases are optimized >> > for specific usage scenarios. CAD systems and source code management systems >> > are the archetypical examples of systems that are a bad fit and will kill the performance >> > of a relational database. Of course 30 years later you can brute force it, but that doesn't >> > make it a good idea. Git is far superior to rdb based systems for the day-to-day work >> > and the analytics should be done from a ram-based object model. >> > >> >> Completely agree with you. But i think if you can store code in >> database, which one to use is a matter of taste >> (knowledge/availability etc). >> If we could have a nice abstraction for managing sources in image, >> then choosing where to store it is not a big deal. >> >> > Stephan >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> Igor Stasenko >> 3 November, 2011 10:00 AM >> >> >> On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> >>> ... is a waste of time and computing resources. Relational databases are optimized >>> for specific usage scenarios. CAD systems and source code management systems >>> are the archetypical examples of systems that are a bad fit and will kill the performance >>> of a relational database. Of course 30 years later you can brute force it, but that doesn't >>> make it a good idea. Git is far superior to rdb based systems for the day-to-day work >>> and the analytics should be done from a ram-based object model. >>> >>> >> >> Completely agree with you. But i think if you can store code in >> database, which one to use is a matter of taste >> (knowledge/availability etc). >> If we could have a nice abstraction for managing sources in image, >> then choosing where to store it is not a big deal. >> >> >>> Stephan >>> >>> >> >> >> >> >> >> Stephan Eggermont >> 2 November, 2011 7:20 PM >> >> >> ... is a waste of time and computing resources. Relational databases are optimized >> for specific usage scenarios. CAD systems and source code management systems >> are the archetypical examples of systems that are a bad fit and will kill the performance >> of a relational database. Of course 30 years later you can brute force it, but that doesn't >> make it a good idea. Git is far superior to rdb based systems for the day-to-day work >> and the analytics should be done from a ram-based object model. >> >> Stephan

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by StÃ©phane Ducasse

I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef > 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

Re: [Pharo-project] Simple vs. Easy

by StÃ©phane Ducasse

:) come on igor all these strange alphabets are not useful :) Ok I will stop and continue to work on our future. Stef On Nov 4, 2011, at 4:24 PM, Igor Stasenko wrote: > Just as a follow-up. A simple example: > Cuis doesn't supports unicode. It simply doesn't exists in Cuis. > Does it makes it simpler? Of course. > Does it makes life simpler for development of modern applications? > Absolutely not. > Because as i repeated many times, a unicode and i18n support is a must > have in any modern system. > And unicode is not _potentially_ useful, which you can just simply > discard because it is not flawlessly implemented. It is used a lot by > people, who living outside a latin world. > > -- > Best regards, > Igor Stasenko. >

Nov. 4, 2011

[Pharo-project] UUID comparaison is Incorrect

by StÃ©phane Ducasse

I was thinking that we should get the same bug for you UUID because the code right now is < aMagnitude "Answer whether the receiver is less than the argument." 1 to: self size do: [:i | (self at: i) < (aMagnitude at: i) ifTrue: [^true]]. ^false. >> |a b| >> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >> (a > b) = (b > a) returns true and this looks wrong :) What do you think? Stef Begin forwarded message: > From: Alan Knight <knight(a)acm.org> > Subject: Re: [vwnc] UUID Sorting Incorrect > Date: November 1, 2011 3:19:23 PM GMT+01:00 > To: Runar Jordahl <runar.jordahl(a)gmail.com> > Cc: vwnc(a)cs.uiuc.edu > Reply-To: knight(a)acm.org > > Thanks. Created AR 64162 > >> >> Runar Jordahl >> 25 October, 2011 7:13 AM >> >> >> Class UUID is included in beta in VisualWorks 7.8. It seems like #< is >> implemented incorrect. If you evaluate the statement below it answers >> true: >> >> |a b| >> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >> (a > b) = (b > a) >> >> The fix is to change the method to this: >> >> < aMagnitude >> "Answer whether the receiver is less than the argument. Add an >> initial size check, in anticipation of greater than 128-bit >> Smalltalk-specific UUID type." >> >> | ss ms | >> >> ss := self size. >> ms := aMagnitude size. >> ss < ms >> ifTrue: [^true] >> ifFalse: [ >> ss > ms >> ifTrue: [^false] >> ifFalse: [ >> 1 to: self size do: [:i | >> (self at: i) < (aMagnitude at: i) ifTrue: [^true]. >> (self at: i) > (aMagnitude at: i) ifTrue: [^false]]. >> ^false]] >> >> >> Runar Jordahl >> blog.epigent.com >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nov. 4, 2011

Re: [Pharo-project] Keymapping Questions

by Sean P. DeNigris

I found another bug - creating a shortcut with no modifiers e.g. "$c asShortcut" fires on c, shift-c, cmd-c... -- View this message in context: http://forum.world.st/Keymapping-Questions-tp3990667p3990743.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 4, 2011

Re: [Pharo-project] Someone bought Smalltalk?

by Alan Knight

It does sound like that's what it's a reference to. I note that the Personal Use License bars an organization rolling out Cincom VW / OS applications "for any revenue generating purpose or operation of any business venture". If someone was previously of the impression that the Non-Commercial license included the right to deploy applications for revenue generating purposes or operating a business I think they were mis-interpreting the intent of the license. > ------------------------------------------------------------------------ > > S Krish <mailto:krishnamachari.sudhakar@gmail.com> > 4 November, 2011 7:06 AM > > > 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." > / > > > ------------------------------------------------------------------------ > > Tudor Girba <mailto:tudor@tudorgirba.com> > 1 November, 2011 9:13 AM > > > 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 > > > > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > ------------------------------------------------------------------------ > > Damien Cassou <mailto:damien.cassou@gmail.com> > 1 November, 2011 6:12 AM > > > 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. > >

Nov. 4, 2011

Re: [Pharo-project] Storing all source code in a relational database

by Alan Knight

I don't agree with that. There's certainly an impedance mismatch with Smalltalk code and relational databases, but there's also an impedance mismatch between Smalltalk code and file systems. Things like git which are custom-built to operate against a particular idea of source code and the operations on it very fast don't necessarily work well with Smalltalk-style operations like "show me the versions of this method". Cincom has spent a lot of time recently on Store, but only part of that involves the database. And much of the difficulty in the database part is not inherent to mapping the code to a database, but is because the original design of the relational schema and the way Store talked to it are very very bad, and can't easily be changed without breaking access to the database for older versions. We will change the schema to something much better at some point, but it's something that we really can't do incrementally, so we're being careful with it. ENVY has some very nice features, but I'd say that it shows some weaknesses relative to more modern systems. For example, it is very intrusive to make a version, and it is extremely sensitive to network latency. A database designed specifically for source code, and with the sort of operations that Smalltalk source code control would like to be able to do quickly would obviously be the ideal choice. Like relational databases, you'd want it to be extremely reliable, scalable, transactional, and have many different free implementations easily available on all platforms, with enough standardization that they are all reasonably compatible. A relational database isn't necessarily the best choice in all circumstances, but I don't think it's an obviously bad one either. > ------------------------------------------------------------------------ > > Reg Krock <mailto:rkrock3@yahoo.ca> > 3 November, 2011 10:42 AM > > > Igor, > > I am emailing you offline but I just do not get why people are so > interested in storing source code in a relational database. > > We have objects, there is a known mismatch between the object and > relational world. So how does the relational database help out? > > Cincom has spent many man-years attempting to make STORE work well. A > few grad students wrote ENVY in the 80's and it is a way superior in > most ways to all other code repositories. > > Has anyone at INRIA looked at ENVY? > > Regards, > > Reg > > ------------------------------------------------------------------------ > *From:* Igor Stasenko <siguctua(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Thursday, November 3, 2011 10:00:31 AM > *Subject:* Re: [Pharo-project] Storing all source code in a relational > database > > On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > ... is a waste of time and computing resources. Relational databases > are optimized > > for specific usage scenarios. CAD systems and source code management > systems > > are the archetypical examples of systems that are a bad fit and will > kill the performance > > of a relational database. Of course 30 years later you can brute > force it, but that doesn't > > make it a good idea. Git is far superior to rdb based systems for > the day-to-day work > > and the analytics should be done from a ram-based object model. > > > > Completely agree with you. But i think if you can store code in > database, which one to use is a matter of taste > (knowledge/availability etc). > If we could have a nice abstraction for managing sources in image, > then choosing where to store it is not a big deal. > > > Stephan > > > > > > -- > Best regards, > Igor Stasenko. > > > > ------------------------------------------------------------------------ > > Igor Stasenko <mailto:siguctua@gmail.com> > 3 November, 2011 10:00 AM > > > On 3 November 2011 00:20, Stephan Eggermont<stephan(a)stack.nl> wrote: >> ... is a waste of time and computing resources. Relational databases are optimized >> for specific usage scenarios. CAD systems and source code management systems >> are the archetypical examples of systems that are a bad fit and will kill the performance >> of a relational database. Of course 30 years later you can brute force it, but that doesn't >> make it a good idea. Git is far superior to rdb based systems for the day-to-day work >> and the analytics should be done from a ram-based object model. >> > > Completely agree with you. But i think if you can store code in > database, which one to use is a matter of taste > (knowledge/availability etc). > If we could have a nice abstraction for managing sources in image, > then choosing where to store it is not a big deal. > >> Stephan >> > > > > ------------------------------------------------------------------------ > > Stephan Eggermont <mailto:stephan@stack.nl> > 2 November, 2011 7:20 PM > > > ... is a waste of time and computing resources. Relational databases > are optimized > for specific usage scenarios. CAD systems and source code management > systems > are the archetypical examples of systems that are a bad fit and will > kill the performance > of a relational database. Of course 30 years later you can brute force > it, but that doesn't > make it a good idea. Git is far superior to rdb based systems for the > day-to-day work > and the analytics should be done from a ram-based object model. > > Stephan

Nov. 4, 2011

[Pharo-project] Keymapping Questions

by Sean P. DeNigris

Where can I find documentation on Keymapping (if it exists)? Here are the basics I have so far: * the available set of shortcuts is per-class * a shortcut is created by creating a builder method (similar to World Menu registration) annotated with <keymap> * shortcuts are grouped into categories * categories (not individual shortcuts) are attached to Morph classes via KMBuilder>>attachShortcutCategory:to: * the system is updated when "KMPragmaKeymapBuilder uniqueInstance" resets itself via #reset (but see problems below) Questions: * What is the purpose of naming shortcuts? * Why are shortcuts held by categories as named entries and separately as keymaps? There seems to be a problem with updating shortcuts (esp. changing existing ones): * It seems that when an existing named shortcut is modified, eventually KMShortcut>>shortcutHasChangedIn:by: is called, but this method does nothing, so the shortcut never gets updated. Why is this? It seems like a bug. * When a <keymap> method is saved in OB, KMPragmaKeymapBuilder>>reset is called twice - once via AnnouncementSubscription>>deliver:, and once via KMPragmaKeymapBuilder>>event: * Because KMRepository class>>reset is never called, it becomes very dirty if shortcuts are repeatedly edited. For example, create a shortcut named "myShortcut" with Cmd+D in Category "Test", now change its name and accept the code. You will have two shortcuts with the same key combination. Now change to Cmd+E and accept again. You will have three shortcuts, even though you have only one specified in your builder method... So it seems to me to keep integrity in the shortcuts, either: * "KMRepository reset" when anything is changed, and start from scratch * or, improve KMPragmaKeymapBuilder>>reset's ability to keep the system clean. Sean -- View this message in context: http://forum.world.st/Keymapping-Questions-tp3990667p3990667.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by Igor Stasenko

Just as a follow-up. A simple example: Cuis doesn't supports unicode. It simply doesn't exists in Cuis. Does it makes it simpler? Of course. Does it makes life simpler for development of modern applications? Absolutely not. Because as i repeated many times, a unicode and i18n support is a must have in any modern system. And unicode is not _potentially_ useful, which you can just simply discard because it is not flawlessly implemented. It is used a lot by people, who living outside a latin world. -- Best regards, Igor Stasenko.

Nov. 4, 2011