Re: [Pharo-dev] a Pharo talk from a ruby conference
To me, “Smalltalk” is everything. Take anything away (language, tools, image, or library) and it’s not nearly as interesting. On May 16, 2014, at 12:04 PM, Sean P. DeNigris wrote: > Esteban A. Maringolo wrote >> All the previous dialects were advertised as "a new Smalltalk dialect" >> ... >> This time we could, at least, try to advertise it differently. > > +1. I think that delaying the Smalltalk conversation a bit a la Clojure > might be the sweet spot. A good time to mention it might be in describing > the language, since it's obviously Smalltalk. I'll reiterate that I strongly > feel that the language - which has always been the least interesting thing - > should be introduced /last/, after the environment - which is the real blue > plane idea here - and the libraries, which are of practical importance. > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759290.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] a Pharo talk from a ruby conference
Yes, but Clojure being a Lisp is why I use it. Same as Pharo being a Smalltalk is why I use it. They are both evolutions, and looking at them there is no way not to immediately see what they are. On May 15, 2014, at 1:56 PM, Sven Van Caekenberghe wrote: > > On 15 May 2014, at 20:18, David Astels wrote: > >> I agree whole heartedly. Ditch “agile” a tool/language can’t be agile >> anyway… agile is a characteristic of a team, their process, and their >> dynamic. And it’s generally meaningless now. >> >> Also, Pharo IS a Smalltalk. That’s the biggest thing that makes it >> interesting. Saying Pharo isn’t Smalltalk is like saying Clojure isn’t >> Lisp. In Clojure’s case, it’s further from classic Lisp than Pharo is from >> Smalltalk-80. >> >> Dave > > Copied today from http://clojure.org : > > << > Clojure is a dynamic programming language that targets the Java Virtual > Machine (and the CLR, and JavaScript). It is designed to be a general-purpose > language, combining the approachability and interactive development of a > scripting language with an efficient and robust infrastructure for > multithreaded programming. Clojure is a compiled language - it compiles > directly to JVM bytecode, yet remains completely dynamic. Every feature > supported by Clojure is supported at runtime. Clojure provides easy access to > the Java frameworks, with optional type hints and type inference, to ensure > that calls to Java can avoid reflection. > > Clojure is a dialect of Lisp, and shares with Lisp the code-as-data > philosophy and a powerful macro system. Clojure is predominantly a functional > programming language, and features a rich set of immutable, persistent data > structures. When mutable state is needed, Clojure offers a software > transactional memory system and reactive Agent system that ensure clean, > correct, multithreaded designs. > > I hope you find Clojure's combination of facilities elegant, powerful, > practical and fun to use. >>> > > Lisp is _not_ mentioned in the first paragraph, and only once (ok twice, but > in the same sentence) in the second. > > This is all about marketing, not about denying something. Yes, the goal is > not to scare people away or to start with potentially limiting or worse > negative connotations. > >> On May 15, 2014, at 1:02 PM, kmo wrote: >> >>> Looking at the new pharo website (it’s great, by the way), I found I was >>> more >>> upset than I thought I would be by the total absence of the s-word. >>> >>> Perhaps lots of people think smalltalk is a dead language but that’s not the >>> only view of smalltalk that people have out there. >>> >>> I came to pharo looking for a new, better way of developing applications. I >>> knew from reading about the history of computing that smalltalk was the >>> purest object oriented language. I knew that it had pioneered many advanced >>> ideas in program development. I knew that it was so far ahead of its time >>> that other languages were still hobbling along behind it trying to catch up. >>> I knew that java and C# were constantly trying to be more smalltalk-like. So >>> I looked for a smalltalk – ideally an open source smalltalk that I could use >>> on Linux. And so I came to pharo. If someone had told me that pharo was not >>> smalltalk, I would not have been interested, I would have though pharo was >>> just a niche product (like Rebol, say) - something that might simply fade >>> away with no history behind it. And I’m sure there are other people like me >>> out there who also have heard of the smalltalk mystique. This heritage is >>> something to be proud of. >>> >>> So why hide what pharo is? >>> >>> It’s not smalltalk’s reputation as /dead/ that I think is likely to put >>> people off. It’s more smalltalks’s reputation as an academic’s language, >>> used to investigate abstruse computer science problems, but unsuitable for >>> mundane day-to-day development. The sort of language that cannot produce a >>> stand-alone executable (a myth - but pharo could do with a deployment wizard >>> of some kind). The sort of language that can produce incredible data >>> visualisations (Roassal) but is unable to put up a decent data entry screen >>> (Spec). (Sorry, that's unfair but I could not resist it! ) >>> >>> Rather than hide the smalltalk origins of pharo, I think they should be >>> shouted from the rooftops. I would add something like this to the web page. >>> >>> */Pharo
[Pharo-dev] One complaint about Pharo
One of the big issues I have with Pharo is that I’m stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. I’m assuming this is a hard limit in OSX, but it’s a bit annoying. Yes, Self has the same issue, and it’s just as annoying. Dave
Re: [Pharo-dev] a Pharo talk from a ruby conference
I agree whole heartedly. Ditch “agile” a tool/language can’t be agile anyway… agile is a characteristic of a team, their process, and their dynamic. And it’s generally meaningless now. Also, Pharo IS a Smalltalk. That’s the biggest thing that makes it interesting. Saying Pharo isn’t Smalltalk is like saying Clojure isn’t Lisp. In Clojure’s case, it’s further from classic Lisp than Pharo is from Smalltalk-80. Dave On May 15, 2014, at 1:02 PM, kmo wrote: > Looking at the new pharo website (it’s great, by the way), I found I was more > upset than I thought I would be by the total absence of the s-word. > > Perhaps lots of people think smalltalk is a dead language but that’s not the > only view of smalltalk that people have out there. > > I came to pharo looking for a new, better way of developing applications. I > knew from reading about the history of computing that smalltalk was the > purest object oriented language. I knew that it had pioneered many advanced > ideas in program development. I knew that it was so far ahead of its time > that other languages were still hobbling along behind it trying to catch up. > I knew that java and C# were constantly trying to be more smalltalk-like. So > I looked for a smalltalk – ideally an open source smalltalk that I could use > on Linux. And so I came to pharo. If someone had told me that pharo was not > smalltalk, I would not have been interested, I would have though pharo was > just a niche product (like Rebol, say) - something that might simply fade > away with no history behind it. And I’m sure there are other people like me > out there who also have heard of the smalltalk mystique. This heritage is > something to be proud of. > > So why hide what pharo is? > > It’s not smalltalk’s reputation as /dead/ that I think is likely to put > people off. It’s more smalltalks’s reputation as an academic’s language, > used to investigate abstruse computer science problems, but unsuitable for > mundane day-to-day development. The sort of language that cannot produce a > stand-alone executable (a myth - but pharo could do with a deployment wizard > of some kind). The sort of language that can produce incredible data > visualisations (Roassal) but is unable to put up a decent data entry screen > (Spec). (Sorry, that's unfair but I could not resist it! ) > > Rather than hide the smalltalk origins of pharo, I think they should be > shouted from the rooftops. I would add something like this to the web page. > > */Pharo is an alive-and-kicking, developer-focused, version of smalltalk – > the most beautiful idea in the history of computing./* > > Just my two cents. > > By the way, I really don't like the idea of using /agile /as a description > of pharo. Agile means almost nothing now - it's just a management buzzword > for nothing in particular. > > > > > > > -- > View this message in context: > http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4759204.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Immutable collections and encapsulation
If someone uses your class by using instVarNamed, they deserve any pain that results. Your job is to publish a clean public interface to your class, their job is to use that interface. On May 13, 2014, at 10:29 AM, Chris Muller wrote: > You could answer a copy of the collection, so it won't matter > internally if they try to add to it. Or you could wrap the collection > with operations too. > > However, doing that, I suppose someone could still write, "(someObject > instVarNamed: 'internalCollection') add: junk. So, why bother? > > Writing code that does nothing more than try to "protect" your > program-state from bad code elsewhere is like inflicting static-typing > on yourself. Easier to simply not write the bad code in the first > place. :) > > On Tue, May 13, 2014 at 4:53 AM, Yuriy Tymchuk wrote: >> Hi, >> >> sorry if there was already this question, but I couldn’t find it anywhere. >> >> I’m looking in the OO-design concerns and it seams that Java guys are crazy >> about returning the collection that is used for state of an objects. The >> only acceptable option is returning it in the immutable wrapper. As far as I >> know, pharo does not have immutable collections (except from intervals and >> symbols). Are we missing something important, or there is a philosophy >> behind the building blocks we have now, and the design we come up while >> using them. >> >> Cheers. >> Uko >
Re: [Pharo-dev] Immutable collections and encapsulation
Well, an issue of good OO design or not. Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose. If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections. Java devs aren’t crazy… they just tend not to understand OO very well. Dave On May 13, 2014, at 8:28 AM, Esteban A. Maringolo wrote: > I think it is more an issue of design. > > If your Invoice has a collection of "Items", you shouldn't manipulate > the collection directly and instead use accessor/operator methods. > > I wouldn't restrict having the option of direct manipulation of the > collection, but it is a nice thing to have covered by some LINT rules. > :) > > > Regards, > > > Esteban A. Maringolo > > > 2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk : >> Hi, >> >> sorry if there was already this question, but I couldn’t find it anywhere. >> >> I’m looking in the OO-design concerns and it seams that Java guys are crazy >> about returning the collection that is used for state of an objects. The >> only acceptable option is returning it in the immutable wrapper. As far as I >> know, pharo does not have immutable collections (except from intervals and >> symbols). Are we missing something important, or there is a philosophy >> behind the building blocks we have now, and the design we come up while >> using them. >> >> Cheers. >> Uko >
Re: [Pharo-dev] a Pharo talk from a ruby conference
I worked at a company writing commercial (i.e. shrink wrapped boxes on store shelves) application using Smalltalk V. On May 12, 2014, at 3:54 PM, Nicolas Cellier wrote: > > > > 2014-05-12 22:33 GMT+02:00 Göran Krampe : > Hi! > > On 04/30/2014 10:02 PM, kilon alios wrote: > Another mistake is that people tend to over idealising Smalltalk and it > appears as if Smalltalk used to be popular, but I have found no evidence > that Smalltalk was ever popular. Again I may be wrong but this is also > maybe a motivation to regard Smalltalk dead. > > It was quite popular in... 1985-ish to 1995-ish. I would guess that during > those years VisualWorks and VisualAge (primarily) covered 33% of the OOP > market and C++ about 60% - and the rest by other even smaller things like > Eiffel. Those numbers I recall from some magazine, so I am not making them > up. If you were into OO at the time it was quite a lot of buzz around both > Smalltalk and C++ IMHO. > > But OOP was almost exclusively used in large corporations or institutions > that could muster the licenses. But Smalltalk *was* fairly big and some truly > huge systems were built. > > But it was not in any serious awareness outside the corporate world - since > there was hardly any cheap or free Smalltalk available. C++ was though and > ate up that space, and of course... > > ...you know what came in 1995. :) > > If say... Dolphin had been born as an open source (or at least gratis > download) project - so that people could easily build Win32 apps for consumer > use, like VB or Deplhi... then perhaps the world had been different. > > regards, Göran > > > But Smalltalk V was cheap, small, fairly well documented and worked on > windows (DOS even).
