October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] String >> #asSet

by Richard Sargent

In general, when desiring a specific class, to see (Specific collection class withAll: someOtherCollectionInstance). When sending a message, you don't typically expect a given class. Rather, you should expect a set of behaviour. (In this case, an object that behaves like a set.) On Oct 23, 2017, 05:50, at 05:50, "Prof. Andrew P. Black" <black(a)cs.pdx.edu> wrote: >If you have a String (or a Symbol), and you sent it the message #asSet, >what do you expect to get as an answer? > >A set of characters, one would think. But do you care what class is >used to implement that set of characters? > >-- One argument says that it should be a Set, because thatâs what asSet >answers when it is sent to other collections. Itâs conceivable that >you might initially populate the set with Characters, but then add >other kinds of object. > >-- Another argument says that it should be a CharacterSet (or a >WideCharacterSet), because you know that the receiver contains >characters. The expression 'abcd' asSet is a convenient way to create >a CharacterSet with: $a with: $b with: $c with: $d > >-- A third argument says that you shouldnât care. If you really want a >specific class, then you should use (aString as: Set) rather than >aString asSet. > >Right now, in Pharo 7, there is a test in >TConvertAsSetForMultiplinessTest that insists that the class of the >result of asSet is actually Set. This test is already overridden once, >in IdentityBagTest, because the result of sending asSet to an >IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is >already a precedent for asSet returning a set object that is not an >instance of Set. > >I think that the test is bad, and should be changed. But this raises >the larger question: if you want to know whether or not a collection >has set-like behaviour, what is the right way of finding out? >(aCollection isKindOf: Set) reads OK, but is actually wrong, because >itâs testing the implementation, and not the behaviour. A predicate >on all collections (isSet would be the obvious name) would seem to be >indicated. And thatâs what the test should be using. > >(You might ask why CharacterSet and WideCharacterSet are not subclasses >of Set. This answer is that subclassing Set implies inheriting a hash >table, and the raison dâÃªtre for CharacterSet is that it does not use a >hash table.)

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by Richard Sargent

That's the GemStone model. It works well for our customers. On Oct 23, 2017 07:03, "stephan" <stephan(a)stack.nl> wrote: > On 23-10-17 15:27, horrido wrote: > >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient and > in many cases we can avoid needing that. > > Stephan > > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by horrido

Yes, but isn't there an important class of concurrent software where lightweight threads work on shared state? Isn't that the reason for "goroutines" in Go, and STM in Clojure, and actors in Scala? Stephan Eggermont-3 wrote > On 23-10-17 15:27, horrido wrote: >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient > and in many cases we can avoid needing that. > > Stephan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by stephan

On 23-10-17 15:27, horrido wrote: > Do I just say that if you need concurrency, Pharo is the wrong choice? After > all, no programming language can be good at everything. You must always > choose the right tool for the job. No, you tell them to use many images and/or vms. We can effectively use state-full micro services. Immutable data is still rather inefficient and in many cases we can avoid needing that. Stephan

Oct. 23, 2017

Multi-core Software Concurrency

by horrido

With todayâs powerful multi-core processors, the demand for efficient software concurrency is high. We find strong support for such concurrency in the latest crop of âmodernâ languages such as Clojure, Elixir, Go, Haskell, and Scala. Whenever I present Smalltalk (Pharo) as a great language option, inevitably someone asks me about multi-core software concurrency. I have no response for them. Do I just say that if you need concurrency, Pharo is the wrong choice? After all, no programming language can be good at everything. You must always choose the right tool for the job. Do I say that doing concurrency right is very, very tough, even for the most experienced of developers? Let's focus on Pharo's strengths, instead. Sounds like an excuse. Can we safely ignore the multi-core reality? I welcome your feedback. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

Of all the responses here, I like this one the best because it's right on the money. In my long career, I've been dropped into many software projects where I had to quickly ramp up with a new programming language. The employer didn't hire me for my language expertise; they hired me for my programming skill and ability to deliver good quality software on time. The programming tool used was a mere technicality, and hardly an obstacle. There is not a software developer alive who can coast through their entire career without ever needing to pick up another programming language. This is simply not an issue except for the most myopic of employers. Pharo Smalltalk Users mailing list wrote > Hi Paulo, > > I think this is not the right question to ask. > The problem is not "Where to find Smalltalk developers?", the problem is > rather > "How much effort does it take to help a good experienced OO developer to > transition to Smalltalk?" > > OO developers have to steadily gain and learn new technologies and > frameworks... > So why not Smalltalk? > Those developers that are not willing to learn a new language just > because they consider the trade-offs of not finding a job in that field > that easily, might not be the best choice for your team anyway... > > That is my experience... I know more developers missing the "Smalltalk > experience" than those hating Smalltalk once they left a team... > > Sebastian > > > On 2017-10-19 12:04 AM, Paulo R. Dellani wrote: >> Dear all, >> >> after using Smalltalk for several years I developed a passion for the >> language (how not to?), and Pharo is just so great to develop with. >> So thank you guys for keeping this wonderful project running. >> >> Unfortunately, it is not easy to always point out why Smalltalk >> should be employed as "main development language" in a team >> or for a project. In the last discussion of this sort I was confronted >> with the question "where are we going to get new smalltalk >> developers if our startup grows or if you go?". Well, I had no >> good answer to that. What would have you answered? >> >> Cheers, >> >> Paulo >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Pharo/Win on a HiDPI display

by Raffaello Giulietti

Hi, not sure if this has already been discussed. I'm using Pharo/Win on a HiDPI (aka "retina") display scaled at 200%. Everything shows correctly scaled (widgets, fonts, icons, etc.), except for the cursor, which is not scaled at all in Pharo, so it is rendered half the expected size. Outside Pharo the cursor appears correctly. Is there something configurable in Pharo itself to overcome the tininess of the cursor with respect to the rest of the GUI elements? (BTW, kudos for the otherwise excellent HiDPI support in Pharo. Nice work.) Greetings Raffaello

Oct. 23, 2017

String >> #asSet

by Prof. Andrew P. Black

If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer? A set of characters, one would think. But do you care what class is used to implement that set of characters? -- One argument says that it should be a Set, because thatâs what asSet answers when it is sent to other collections. Itâs conceivable that you might initially populate the set with Characters, but then add other kinds of object. -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d -- A third argument says that you shouldnât care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. This test is already overridden once, in IdentityBagTest, because the result of sending asSet to an IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is already a precedent for asSet returning a set object that is not an instance of Set. I think that the test is bad, and should be changed. But this raises the larger question: if you want to know whether or not a collection has set-like behaviour, what is the right way of finding out? (aCollection isKindOf: Set) reads OK, but is actually wrong, because itâs testing the implementation, and not the behaviour. A predicate on all collections (isSet would be the obvious name) would seem to be indicated. And thatâs what the test should be using. (You might ask why CharacterSet and WideCharacterSet are not subclasses of Set. This answer is that subclassing Set implies inheriting a hash table, and the raison dâÃªtre for CharacterSet is that it does not use a hash table.)

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

To quote from The Wisdom of the Crowd <https://hackernoon.com/the-wisdom-of-the-crowd-c7aff954bd5f> : The crowd is indeed wise. This wisdom shows up in the latest StackOverflow survey <https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreade…> , as well. Under âMost Loved Languages,â Smalltalk shows up in clear second place (after Rust and before TypeScript, Swift, Go, Python, Elixir, and C#). This shows that people whoâve used Smalltalk love the language and are loyal to it. It also shows, by inference, that the programming community is not aware of how good Smalltalk is. Most in the community wallow in ignorance over it. /If they were to try Smalltalk programming, the language would very likely become popular./ itlists(a)schrievkrom.de wrote > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > >> >> The second most loved language by 67% of developers surveyed cannot >> simply >> be ruled out because of unfounded concerns. (Thanks again for the > > > -- > Marten Feldtmann -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Restoring an Alto

by Ben Coman

An interesting side story... A Digibarn Xerox Alto arrives for restoration https://www.youtube.com/watch?v=JSPlr4AZsKQ cheers -ben

Oct. 23, 2017