September 2014 - Pharo-dev - lists.pharo.org

pharo4 ci build queue now has download links on top

by Marcus Denker

Hi, I added download links on top of https://ci.inria.fr/pharo/ (they download from files.pharo.org) Marcus

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by Sven Van Caekenberghe

On 01 Sep 2014, at 15:15, phil(a)highoctane.be wrote: > Err..., not really longer nor lots of methods. +1 It can't get much shorter than this... > ButtonModel new > label: 'Click me'; > whenActionPerformedDo: [Transcript show: 'Clicked!' ]; > openWithSpec. > > Bear in mind that Spec is based on models, not actual "Morphs". > The ComposableModel idea is key here. > > HTH > > > Phil > > > On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do: > > button := PluggableButtonMorph new. > button label: 'Button'. > button openInWindow . > > According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods. > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong. > > > On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > Personally there are two thing I dont like about Spec > > a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use. > > Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code > for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway. > > nicolai > > > > b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes. > > On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve. > > > On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out. > > How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain). > > Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular. > > It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping. > > An example: MorphicRadioButtonAdapter > > defaultSpec > <spec> > ^ {#CheckboxMorph. > #on:selected:changeSelected:. #model. #state. #state:. > #label:. { #model. #label }. > #labelClickable:. { #model. #labelClickable}. > #beRadioButton. > #hResizing:. #shrinkWrap. > #vResizing:. #shrinkWrap. > #setBalloonText:. #(model help). > #dragEnabled:. #(model dragEnabled). > #dropEnabled:. #(model dropEnabled). > #dragEnabled:. #(model dragEnabled). > #dropEnabled:. #(model dropEnabled). > "#borderWidth:. #(model borderWidth). > #borderColor:. #(model borderColor)"} > > A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself. > > Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine? > > Phil > > > > > On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > +1 to both of you :) > > Doru > > > On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: > Hi sean > > > I've been mulling this over for a while, and since we've been having > conversations about Spec's place in our future... > :) > Good. This is important that everybody express itself. > > > DISCLAIMER: this is a visceral experience I've been having over a long > period of time, so it may not be factually "true" or current, but I present > it as a contribution, if only by someone saying "you're full of crap > because..." and we all learn something. > > The purpose of Spec as I understand it is to both come up with a nice > streamlined UI API, and to make multiple targets (e.g. Morphic, html) > possible with the same codebase. These are both important goals. And it > seems we've made some progress at least in the first case. I definitely > enjoy working with Spec's API far more that e.g. PolyMorph. > > Spec could be a very valuable application-level tool. If I want to write a > business application, I can write once via a nice API and deploy "anywhere". > Life is good. > > My discomfort is with making *all* our core tools Spec-based. > > I agree this is why I started to write some little tool to be able to browse the system > when Spec is shaking. > > Now when you see the code of the old browser this is not nice either. > So we will see and learn. But I can tell you that nothing is curved in stone. > We will introduce GT but again you will get the same because GT is a frameworks. > > > While it is great from an "eating our own dog food perspective", one of the great > principles of Morphic is exploration and discoverability. Many times before > Spec I was able to poke around a tool, figure out how it worked, and apply > that lesson to my own UI. However, with Spec I find it extremely difficult > to figure out WTH is going on. Parsing of arrays of symbols seems to have > replaced Smalltalk code, and each field/model piece of a Spec UI seems to be > buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now > that we have e.g. specialized inspectors, we might be able to alleviate > this. > > We should iterate on it. > May be another framework will be better in the future > > > My 2c. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nai… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > >

Sept. 1, 2014

Re: [Pharo-dev] Experiments in Code Typography

by Stephan Eggermont

The performance of this can easily be made fast enough. I've used Think Pascal on a 25 MHz 68LC040 and that was fast enough for normal sized methods. 20 years of hardware improvement should be enough. Squeak was not fast enough on that machine, b.t.w. Stephan

Sept. 1, 2014

Re: [Pharo-dev] Experiments in Code Typography

by stepharo

Nice :) Thanks for your return on experience. Stef > About AST, we did something at work in dotnet for syntax checking when > typing SQL requests in a tool (not only simple statements, some of the > developers requests are real monsters, iirc one of the biggest was 42k), :) May be synectique should build special tools for your company. We worked with companies have 2000 lines method long :) > and we built the ast on the fly at each typing, it was incredibly > fast. I was sceptic at the beginning, but given the power of current > cpu, few milliseconds between key strokes is more than enough. > Perhaps it could/should be done only on "special" characters like > spaces ;[]() -> and so on, or only on a special keymapping > (reformating at each keystroke could be very disturbing).

Sept. 1, 2014

Re: [Pharo-dev] Roadmap on tools?

by phil＠highoctane.be

A friend of mine ("Makis") is a greek and utterly skilled at programming. Phil On Mon, Sep 1, 2014 at 2:10 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > This reminds me though a bit of Truman Show. Everyone was happy and so > was Truman, but Truman was living a lie and in the end he preferred living > in the real world than be trapped inside his happy bubble. I think this > movie teaches very well the importance of honesty. Also if you really > intend to create tools that are according to people needs and wants, its > way more important to find what people don't like than people like. Because > people mostly and I include myself have no idea what they like apart from a > few things here and there but have a very good idea what they don't like. > > But yes criticism does not mean you have to be rude about it. Just because > someone designed something you don't like that does not make him a moron or > an idiot or.......... afterall none is the center of the world and none can > represent the bulk of users out there, each one of us wants something > diffirent. > > Also most people are easily offended by the truth, I had such an incident > during the weekend when I said " Greek computing is still in the stone age" > someone near asked me if I am professional coder , he was and obviously > offended by my remark but as a lawyer myself heavily dependent on software > I explained him in detail what I meant . He assumed that I was implying > that we dont have Greeks that excel at coding , software development etc > which of course is not the case since I was referring to big Greek software > companies and the whole computing policy of my country. We ended up > agreeing in many things. > > So the reality is that truth is a very complex subject and the best way to > approach is head on, leaving hurt egos and excessive emotions out of the > door and trying to be specific about it . > > Or else you will end up with a "frozen smile" community that wont be very > productive. > > > On Mon, Sep 1, 2014 at 1:21 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Guys - this reply has interesting content with potentially useful >> insight, but I really encourage everyone to think about how to best frame >> these kinds of comments without âsappingâ the energy out of those writing >> frameworks like Spec. We all need to make sure that we can have healthy >> debate and iterate on new ideas but without causing others to feel >> despondent. >> >> We need to energise everyone in our conversations! This was a strong >> message from ESUG this year (and we didnât always get it right, but we >> tried to help each other do this). >> >> If there are better ideas out there - you really want someone already >> working on something (which they may have spent lots of energy on already), >> to not give up in despair, but to seize the opportunity of new insight and >> apply their knowledge and creative to get a better outcome OR to iterate on >> their current solution and apply observations from others to create >> something better. >> >> At ESUG, this was a topic of conversation for one of the âShow us your >> projectsâ slots (disclaimer - I presented that topic on the Zapp framework >> because I found a few of us in the pub going down a more negative path than >> we had intended). I presented Zapp - >> http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/0712680… and >> urged everyone to consider how we can ALL help each send sparks of >> excitement (aka Zapp) to encourage better things. This seemed to strike a >> chord in the audience. >> >> I wanted to share this - because I certainly appreciate peoples thoughts >> on all of these topics, but I really donât want to see us have more >> casualties in our amazing community. >> >> So please - try and think âZappâ not âSappâ - and try and use your >> experience/advice/observations as a way to empower others to make useful >> change - or consider the direction they may be taking such that they want >> to do more. >> >> Tim >> >> p.s. This is easy to say/write - and quite hard to do well. I know we >> will all make mistakes doing this well - but practicing it is important, >> and having words like âZappâ and a way to tell each other this is just as >> important as the code we write. >> >> >> On 28 Aug 2014, at 19:15, kmo <voxkmp(a)gmail.com> wrote: >> >> philippeback wrote >> >> Building a UI with Morphic alone is what one would use to do something >> very >> custom (like a game for example). >> >> Now, creating a larger UI that way is definitely going to be super pain in >> the assets. >> >> That's where Spec does fit. >> >> >> Is there any evidence of this? As far as I know no one has built anything >> more complex than a class browser. I would say Spec was incapable of >> building a complex interface of any kind. It's clumsy, developer-hostile, >> and counter-intuitive. >> >> The whole Spec process of writing code in three different places is the >> very >> definition of a /super pain in the asset/s. it is far less intuitive to my >> mind than creating composite morphs. >> >> Progress on Spec is glacially slow - but that's not the problem. Spec is >> profoundly misconceived and fundamentally flawed and offers nothing over >> raw >> Morphic. The Spec model is simply not how anyone would want to build an >> interface in 2014. I certainly would never use it. >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> >

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by phil＠highoctane.be

Err..., not really longer nor lots of methods. ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec. Bear in mind that Spec is based on models, not actual "Morphs". The ComposableModel idea is key here. HTH Phil On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Lets take a very simple example of creating a UI that contains one very > simple button in Morphic I would do: > > button := PluggableButtonMorph new. > button label: 'Button'. > button openInWindow . > > According to Spec to do the same I would need several methods just for > initialization and a separate class to host these methods. > > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > I would need initializeWidgets , defaultSpec , list and title . Unless I > am reading the documentation wrong. > > > On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> Personally there are two thing I dont like about Spec >>> >>> a) There is quite a lot of setup just to start adding things together >>> making quite verbose for small GUIs. It may be just my lack of >>> understanding but I find Morphic much easier to use. >>> >> >> Can you give me an example of this setup for a small GUI? The examples I >> have seen so far only use some lines of code in #defaultSpec and some lines >> of code >> for wiring up the different models (like onSelectedDo, onChangedDo, ...) >> All of that are things you would do anyway. >> >> nicolai >> >> >> >>> >>> b) I have a deep dislike about the use of pragmas. I know they are >>> useful for primitives that cant be pure smalltalk objects like for example >>> Nativeboost but I still feel they brake the uniformity of smalltalk syntax >>> at least in my eyes. >>> >>> On the other hand having something that can quickly produce guis is >>> essential. But personal I prefer lego-like approaches which is what Morphic >>> uses. As side note I think designing GUI via code is a bad idea, at least >>> in my eyes, we need a designer for that, afterall most of the powerful IDEs >>> out there have GUI designers. Nonetheless wishful thinking is not >>> productive , Spec is here, it is certainly helpful and I hope it continues >>> to evolve and improve. >>> >>> >>> On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be> >>> wrote: >>> >>>> When one looks at the implementers of "defaultSpec" (lots of Adapters, >>>> tools), I find it more understandable to figure out how a tool is laid out. >>>> >>>> How to follow what messages are sent around, err... much less >>>> understandable indeed (So, sharing Sean's pain). >>>> >>>> Of course, this is different from inspecting morphs. But it shouldn't >>>> be so. If Morphs where isofunctional with the Adapters, it would be much >>>> more regular. >>>> >>>> It is glaring that the Morphs all have their own little view of the >>>> world with no unified set of protocols, which isn't helping. >>>> >>>> An example: MorphicRadioButtonAdapter >>>> >>>> defaultSpec >>>> <spec> >>>> ^ {#CheckboxMorph. >>>> #on:selected:changeSelected:. #model. #state. #state:. >>>> #label:. { #model. #label }. >>>> #labelClickable:. { #model. #labelClickable}. >>>> #beRadioButton. >>>> #hResizing:. #shrinkWrap. >>>> #vResizing:. #shrinkWrap. >>>> #setBalloonText:. #(model help). >>>> #dragEnabled:. #(model dragEnabled). >>>> #dropEnabled:. #(model dropEnabled). >>>> #dragEnabled:. #(model dragEnabled). >>>> #dropEnabled:. #(model dropEnabled). >>>> "#borderWidth:. #(model borderWidth). >>>> #borderColor:. #(model borderColor)"} >>>> >>>> A halo that would outline the SpecLayout bits and pieces would go a >>>> long way in helping people figure out what's going on. A project in itself. >>>> >>>> Now, can we both have a declarative UI and an easy to debug UI? As the >>>> declarative things has its own interpreter and engine? >>>> >>>> Phil >>>> >>>> >>>> >>>> >>>> On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> +1 to both of you :) >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>>> Hi sean >>>>>> >>>>>> >>>>>> I've been mulling this over for a while, and since we've been having >>>>>>> conversations about Spec's place in our future... >>>>>>> >>>>>> :) >>>>>> Good. This is important that everybody express itself. >>>>>> >>>>>> >>>>>>> DISCLAIMER: this is a visceral experience I've been having over a >>>>>>> long >>>>>>> period of time, so it may not be factually "true" or current, but I >>>>>>> present >>>>>>> it as a contribution, if only by someone saying "you're full of crap >>>>>>> because..." and we all learn something. >>>>>>> >>>>>>> The purpose of Spec as I understand it is to both come up with a nice >>>>>>> streamlined UI API, and to make multiple targets (e.g. Morphic, html) >>>>>>> possible with the same codebase. These are both important goals. And >>>>>>> it >>>>>>> seems we've made some progress at least in the first case. I >>>>>>> definitely >>>>>>> enjoy working with Spec's API far more that e.g. PolyMorph. >>>>>>> >>>>>>> Spec could be a very valuable application-level tool. If I want to >>>>>>> write a >>>>>>> business application, I can write once via a nice API and deploy >>>>>>> "anywhere". >>>>>>> Life is good. >>>>>>> >>>>>>> My discomfort is with making *all* our core tools Spec-based. >>>>>>> >>>>>> >>>>>> I agree this is why I started to write some little tool to be able to >>>>>> browse the system >>>>>> when Spec is shaking. >>>>>> >>>>>> Now when you see the code of the old browser this is not nice either. >>>>>> So we will see and learn. But I can tell you that nothing is curved >>>>>> in stone. >>>>>> We will introduce GT but again you will get the same because GT is a >>>>>> frameworks. >>>>>> >>>>>> >>>>>> While it is great from an "eating our own dog food perspective", one >>>>>>> of the great >>>>>>> principles of Morphic is exploration and discoverability. Many times >>>>>>> before >>>>>>> Spec I was able to poke around a tool, figure out how it worked, and >>>>>>> apply >>>>>>> that lesson to my own UI. However, with Spec I find it extremely >>>>>>> difficult >>>>>>> to figure out WTH is going on. Parsing of arrays of symbols seems to >>>>>>> have >>>>>>> replaced Smalltalk code, and each field/model piece of a Spec UI >>>>>>> seems to be >>>>>>> buried behind multiple ValueHolder/Adapter/whatever levels. Granted, >>>>>>> now >>>>>>> that we have e.g. specialized inspectors, we might be able to >>>>>>> alleviate >>>>>>> this. >>>>>>> >>>>>> >>>>>> We should iterate on it. >>>>>> May be another framework will be better in the future >>>>>> >>>>>> >>>>>>> My 2c. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/When- >>>>>>> all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html >>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>> Nabble.com. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >> >

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by kilon alios

yes ignore me I am an idiot I missed the fact I need to pass a block as argument to action method now it works as expected, again thank you :) On Mon, Sep 1, 2014 at 3:23 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > ok looks like I don't understand the Spec documentation well enough. So I > tried this code in workspace based on your code > > dcm := DynamicComposableModel new. > dcm instantiateModels: #(button ButtonModel ). > dcm button label: 'Button'; action: Transcript open. > dcm openWithSpecLayout: (SpecLayout composed > newColumn: [:c | c add: #button]) > > but I have an issue, that action method there I assumed its the action > triggered when I click the button. But instead Transcript opens when I do > the code and if I close the Transcript window and click the button again, > it does not open Transcript. Am I doing something wrong ? I am using latest > Pharo 3 on Ubuntu. > > By the way thank you very much about your reply it looks like Spec is much > closer to what I like that I initially thought , will study the > documentation carefully and try some experiments to gain a better > understanding. > > > On Mon, Sep 1, 2014 at 2:56 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> | dcm | >> (dcm := DynamicComposableModel new) >> instantiateModels: #(button ButtonModel). >> dcm button >> label: 'Button'; >> action: [ self halt ]. >> dcm openWithSpecLayout: (SpecLayout composed >> newColumn: [: c | c add: #button ]; >> yourself). >> >> >> >> 2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >> >> Lets take a very simple example of creating a UI that contains one very >>> simple button in Morphic I would do: >>> >>> button := PluggableButtonMorph new. >>> button label: 'Button'. >>> button openInWindow . >>> >>> According to Spec to do the same I would need several methods just for >>> initialization and a separate class to host these methods. >>> >>> >>> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >>> >>> I would need initializeWidgets , defaultSpec , list and title . Unless >>> I am reading the documentation wrong. >>> >>> >>> On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> >>>> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>>> >>>> Personally there are two thing I dont like about Spec >>>>> >>>>> a) There is quite a lot of setup just to start adding things together >>>>> making quite verbose for small GUIs. It may be just my lack of >>>>> understanding but I find Morphic much easier to use. >>>>> >>>> >>>> Can you give me an example of this setup for a small GUI? The examples >>>> I have seen so far only use some lines of code in #defaultSpec and some >>>> lines of code >>>> for wiring up the different models (like onSelectedDo, onChangedDo, >>>> ...) All of that are things you would do anyway. >>>> >>>> nicolai >>>> >>>> >>>> >>>>> >>>>> b) I have a deep dislike about the use of pragmas. I know they are >>>>> useful for primitives that cant be pure smalltalk objects like for example >>>>> Nativeboost but I still feel they brake the uniformity of smalltalk syntax >>>>> at least in my eyes. >>>>> >>>>> On the other hand having something that can quickly produce guis is >>>>> essential. But personal I prefer lego-like approaches which is what Morphic >>>>> uses. As side note I think designing GUI via code is a bad idea, at least >>>>> in my eyes, we need a designer for that, afterall most of the powerful IDEs >>>>> out there have GUI designers. Nonetheless wishful thinking is not >>>>> productive , Spec is here, it is certainly helpful and I hope it continues >>>>> to evolve and improve. >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be < >>>>> phil(a)highoctane.be> wrote: >>>>> >>>>>> When one looks at the implementers of "defaultSpec" (lots of >>>>>> Adapters, tools), I find it more understandable to figure out how a tool is >>>>>> laid out. >>>>>> >>>>>> How to follow what messages are sent around, err... much less >>>>>> understandable indeed (So, sharing Sean's pain). >>>>>> >>>>>> Of course, this is different from inspecting morphs. But it shouldn't >>>>>> be so. If Morphs where isofunctional with the Adapters, it would be much >>>>>> more regular. >>>>>> >>>>>> It is glaring that the Morphs all have their own little view of the >>>>>> world with no unified set of protocols, which isn't helping. >>>>>> >>>>>> An example: MorphicRadioButtonAdapter >>>>>> >>>>>> defaultSpec >>>>>> <spec> >>>>>> ^ {#CheckboxMorph. >>>>>> #on:selected:changeSelected:. #model. #state. #state:. >>>>>> #label:. { #model. #label }. >>>>>> #labelClickable:. { #model. #labelClickable}. >>>>>> #beRadioButton. >>>>>> #hResizing:. #shrinkWrap. >>>>>> #vResizing:. #shrinkWrap. >>>>>> #setBalloonText:. #(model help). >>>>>> #dragEnabled:. #(model dragEnabled). >>>>>> #dropEnabled:. #(model dropEnabled). >>>>>> #dragEnabled:. #(model dragEnabled). >>>>>> #dropEnabled:. #(model dropEnabled). >>>>>> "#borderWidth:. #(model borderWidth). >>>>>> #borderColor:. #(model borderColor)"} >>>>>> >>>>>> A halo that would outline the SpecLayout bits and pieces would go a >>>>>> long way in helping people figure out what's going on. A project in itself. >>>>>> >>>>>> Now, can we both have a declarative UI and an easy to debug UI? As >>>>>> the declarative things has its own interpreter and engine? >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>>> wrote: >>>>>> >>>>>>> +1 to both of you :) >>>>>>> >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>>> >>>>>>>> Hi sean >>>>>>>> >>>>>>>> >>>>>>>> I've been mulling this over for a while, and since we've been >>>>>>>>> having >>>>>>>>> conversations about Spec's place in our future... >>>>>>>>> >>>>>>>> :) >>>>>>>> Good. This is important that everybody express itself. >>>>>>>> >>>>>>>> >>>>>>>>> DISCLAIMER: this is a visceral experience I've been having over a >>>>>>>>> long >>>>>>>>> period of time, so it may not be factually "true" or current, but >>>>>>>>> I present >>>>>>>>> it as a contribution, if only by someone saying "you're full of >>>>>>>>> crap >>>>>>>>> because..." and we all learn something. >>>>>>>>> >>>>>>>>> The purpose of Spec as I understand it is to both come up with a >>>>>>>>> nice >>>>>>>>> streamlined UI API, and to make multiple targets (e.g. Morphic, >>>>>>>>> html) >>>>>>>>> possible with the same codebase. These are both important goals. >>>>>>>>> And it >>>>>>>>> seems we've made some progress at least in the first case. I >>>>>>>>> definitely >>>>>>>>> enjoy working with Spec's API far more that e.g. PolyMorph. >>>>>>>>> >>>>>>>>> Spec could be a very valuable application-level tool. If I want to >>>>>>>>> write a >>>>>>>>> business application, I can write once via a nice API and deploy >>>>>>>>> "anywhere". >>>>>>>>> Life is good. >>>>>>>>> >>>>>>>>> My discomfort is with making *all* our core tools Spec-based. >>>>>>>>> >>>>>>>> >>>>>>>> I agree this is why I started to write some little tool to be able >>>>>>>> to browse the system >>>>>>>> when Spec is shaking. >>>>>>>> >>>>>>>> Now when you see the code of the old browser this is not nice >>>>>>>> either. >>>>>>>> So we will see and learn. But I can tell you that nothing is curved >>>>>>>> in stone. >>>>>>>> We will introduce GT but again you will get the same because GT is >>>>>>>> a frameworks. >>>>>>>> >>>>>>>> >>>>>>>> While it is great from an "eating our own dog food perspective", >>>>>>>>> one of the great >>>>>>>>> principles of Morphic is exploration and discoverability. Many >>>>>>>>> times before >>>>>>>>> Spec I was able to poke around a tool, figure out how it worked, >>>>>>>>> and apply >>>>>>>>> that lesson to my own UI. However, with Spec I find it extremely >>>>>>>>> difficult >>>>>>>>> to figure out WTH is going on. Parsing of arrays of symbols seems >>>>>>>>> to have >>>>>>>>> replaced Smalltalk code, and each field/model piece of a Spec UI >>>>>>>>> seems to be >>>>>>>>> buried behind multiple ValueHolder/Adapter/whatever levels. >>>>>>>>> Granted, now >>>>>>>>> that we have e.g. specialized inspectors, we might be able to >>>>>>>>> alleviate >>>>>>>>> this. >>>>>>>>> >>>>>>>> >>>>>>>> We should iterate on it. >>>>>>>> May be another framework will be better in the future >>>>>>>> >>>>>>>> >>>>>>>>> My 2c. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> Cheers, >>>>>>>>> Sean >>>>>>>>> -- >>>>>>>>> View this message in context: http://forum.world.st/When- >>>>>>>>> all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html >>>>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>>>> Nabble.com. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by kilon alios

ok looks like I don't understand the Spec documentation well enough. So I tried this code in workspace based on your code dcm := DynamicComposableModel new. dcm instantiateModels: #(button ButtonModel ). dcm button label: 'Button'; action: Transcript open. dcm openWithSpecLayout: (SpecLayout composed newColumn: [:c | c add: #button]) but I have an issue, that action method there I assumed its the action triggered when I click the button. But instead Transcript opens when I do the code and if I close the Transcript window and click the button again, it does not open Transcript. Am I doing something wrong ? I am using latest Pharo 3 on Ubuntu. By the way thank you very much about your reply it looks like Spec is much closer to what I like that I initially thought , will study the documentation carefully and try some experiments to gain a better understanding. On Mon, Sep 1, 2014 at 2:56 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > | dcm | > (dcm := DynamicComposableModel new) > instantiateModels: #(button ButtonModel). > dcm button > label: 'Button'; > action: [ self halt ]. > dcm openWithSpecLayout: (SpecLayout composed > newColumn: [: c | c add: #button ]; > yourself). > > > > 2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > > Lets take a very simple example of creating a UI that contains one very >> simple button in Morphic I would do: >> >> button := PluggableButtonMorph new. >> button label: 'Button'. >> button openInWindow . >> >> According to Spec to do the same I would need several methods just for >> initialization and a separate class to host these methods. >> >> >> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >> >> I would need initializeWidgets , defaultSpec , list and title . Unless I >> am reading the documentation wrong. >> >> >> On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>> Personally there are two thing I dont like about Spec >>>> >>>> a) There is quite a lot of setup just to start adding things together >>>> making quite verbose for small GUIs. It may be just my lack of >>>> understanding but I find Morphic much easier to use. >>>> >>> >>> Can you give me an example of this setup for a small GUI? The examples >>> I have seen so far only use some lines of code in #defaultSpec and some >>> lines of code >>> for wiring up the different models (like onSelectedDo, onChangedDo, ...) >>> All of that are things you would do anyway. >>> >>> nicolai >>> >>> >>> >>>> >>>> b) I have a deep dislike about the use of pragmas. I know they are >>>> useful for primitives that cant be pure smalltalk objects like for example >>>> Nativeboost but I still feel they brake the uniformity of smalltalk syntax >>>> at least in my eyes. >>>> >>>> On the other hand having something that can quickly produce guis is >>>> essential. But personal I prefer lego-like approaches which is what Morphic >>>> uses. As side note I think designing GUI via code is a bad idea, at least >>>> in my eyes, we need a designer for that, afterall most of the powerful IDEs >>>> out there have GUI designers. Nonetheless wishful thinking is not >>>> productive , Spec is here, it is certainly helpful and I hope it continues >>>> to evolve and improve. >>>> >>>> >>>> On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be >>>> > wrote: >>>> >>>>> When one looks at the implementers of "defaultSpec" (lots of Adapters, >>>>> tools), I find it more understandable to figure out how a tool is laid out. >>>>> >>>>> How to follow what messages are sent around, err... much less >>>>> understandable indeed (So, sharing Sean's pain). >>>>> >>>>> Of course, this is different from inspecting morphs. But it shouldn't >>>>> be so. If Morphs where isofunctional with the Adapters, it would be much >>>>> more regular. >>>>> >>>>> It is glaring that the Morphs all have their own little view of the >>>>> world with no unified set of protocols, which isn't helping. >>>>> >>>>> An example: MorphicRadioButtonAdapter >>>>> >>>>> defaultSpec >>>>> <spec> >>>>> ^ {#CheckboxMorph. >>>>> #on:selected:changeSelected:. #model. #state. #state:. >>>>> #label:. { #model. #label }. >>>>> #labelClickable:. { #model. #labelClickable}. >>>>> #beRadioButton. >>>>> #hResizing:. #shrinkWrap. >>>>> #vResizing:. #shrinkWrap. >>>>> #setBalloonText:. #(model help). >>>>> #dragEnabled:. #(model dragEnabled). >>>>> #dropEnabled:. #(model dropEnabled). >>>>> #dragEnabled:. #(model dragEnabled). >>>>> #dropEnabled:. #(model dropEnabled). >>>>> "#borderWidth:. #(model borderWidth). >>>>> #borderColor:. #(model borderColor)"} >>>>> >>>>> A halo that would outline the SpecLayout bits and pieces would go a >>>>> long way in helping people figure out what's going on. A project in itself. >>>>> >>>>> Now, can we both have a declarative UI and an easy to debug UI? As the >>>>> declarative things has its own interpreter and engine? >>>>> >>>>> Phil >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>> >>>>>> +1 to both of you :) >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>>> Hi sean >>>>>>> >>>>>>> >>>>>>> I've been mulling this over for a while, and since we've been having >>>>>>>> conversations about Spec's place in our future... >>>>>>>> >>>>>>> :) >>>>>>> Good. This is important that everybody express itself. >>>>>>> >>>>>>> >>>>>>>> DISCLAIMER: this is a visceral experience I've been having over a >>>>>>>> long >>>>>>>> period of time, so it may not be factually "true" or current, but I >>>>>>>> present >>>>>>>> it as a contribution, if only by someone saying "you're full of crap >>>>>>>> because..." and we all learn something. >>>>>>>> >>>>>>>> The purpose of Spec as I understand it is to both come up with a >>>>>>>> nice >>>>>>>> streamlined UI API, and to make multiple targets (e.g. Morphic, >>>>>>>> html) >>>>>>>> possible with the same codebase. These are both important goals. >>>>>>>> And it >>>>>>>> seems we've made some progress at least in the first case. I >>>>>>>> definitely >>>>>>>> enjoy working with Spec's API far more that e.g. PolyMorph. >>>>>>>> >>>>>>>> Spec could be a very valuable application-level tool. If I want to >>>>>>>> write a >>>>>>>> business application, I can write once via a nice API and deploy >>>>>>>> "anywhere". >>>>>>>> Life is good. >>>>>>>> >>>>>>>> My discomfort is with making *all* our core tools Spec-based. >>>>>>>> >>>>>>> >>>>>>> I agree this is why I started to write some little tool to be able >>>>>>> to browse the system >>>>>>> when Spec is shaking. >>>>>>> >>>>>>> Now when you see the code of the old browser this is not nice either. >>>>>>> So we will see and learn. But I can tell you that nothing is curved >>>>>>> in stone. >>>>>>> We will introduce GT but again you will get the same because GT is a >>>>>>> frameworks. >>>>>>> >>>>>>> >>>>>>> While it is great from an "eating our own dog food perspective", >>>>>>>> one of the great >>>>>>>> principles of Morphic is exploration and discoverability. Many >>>>>>>> times before >>>>>>>> Spec I was able to poke around a tool, figure out how it worked, >>>>>>>> and apply >>>>>>>> that lesson to my own UI. However, with Spec I find it extremely >>>>>>>> difficult >>>>>>>> to figure out WTH is going on. Parsing of arrays of symbols seems >>>>>>>> to have >>>>>>>> replaced Smalltalk code, and each field/model piece of a Spec UI >>>>>>>> seems to be >>>>>>>> buried behind multiple ValueHolder/Adapter/whatever levels. >>>>>>>> Granted, now >>>>>>>> that we have e.g. specialized inspectors, we might be able to >>>>>>>> alleviate >>>>>>>> this. >>>>>>>> >>>>>>> >>>>>>> We should iterate on it. >>>>>>> May be another framework will be better in the future >>>>>>> >>>>>>> >>>>>>>> My 2c. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Cheers, >>>>>>>> Sean >>>>>>>> -- >>>>>>>> View this message in context: http://forum.world.st/When- >>>>>>>> all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html >>>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>>> Nabble.com. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>> >>> >> >

Sept. 1, 2014

Re: [Pharo-dev] Roadmap on tools?

by kilon alios

This reminds me though a bit of Truman Show. Everyone was happy and so was Truman, but Truman was living a lie and in the end he preferred living in the real world than be trapped inside his happy bubble. I think this movie teaches very well the importance of honesty. Also if you really intend to create tools that are according to people needs and wants, its way more important to find what people don't like than people like. Because people mostly and I include myself have no idea what they like apart from a few things here and there but have a very good idea what they don't like. But yes criticism does not mean you have to be rude about it. Just because someone designed something you don't like that does not make him a moron or an idiot or.......... afterall none is the center of the world and none can represent the bulk of users out there, each one of us wants something diffirent. Also most people are easily offended by the truth, I had such an incident during the weekend when I said " Greek computing is still in the stone age" someone near asked me if I am professional coder , he was and obviously offended by my remark but as a lawyer myself heavily dependent on software I explained him in detail what I meant . He assumed that I was implying that we dont have Greeks that excel at coding , software development etc which of course is not the case since I was referring to big Greek software companies and the whole computing policy of my country. We ended up agreeing in many things. So the reality is that truth is a very complex subject and the best way to approach is head on, leaving hurt egos and excessive emotions out of the door and trying to be specific about it . Or else you will end up with a "frozen smile" community that wont be very productive. On Mon, Sep 1, 2014 at 1:21 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Guys - this reply has interesting content with potentially useful insight, > but I really encourage everyone to think about how to best frame these > kinds of comments without âsappingâ the energy out of those writing > frameworks like Spec. We all need to make sure that we can have healthy > debate and iterate on new ideas but without causing others to feel > despondent. > > We need to energise everyone in our conversations! This was a strong > message from ESUG this year (and we didnât always get it right, but we > tried to help each other do this). > > If there are better ideas out there - you really want someone already > working on something (which they may have spent lots of energy on already), > to not give up in despair, but to seize the opportunity of new insight and > apply their knowledge and creative to get a better outcome OR to iterate on > their current solution and apply observations from others to create > something better. > > At ESUG, this was a topic of conversation for one of the âShow us your > projectsâ slots (disclaimer - I presented that topic on the Zapp framework > because I found a few of us in the pub going down a more negative path than > we had intended). I presented Zapp - > http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/0712680… and > urged everyone to consider how we can ALL help each send sparks of > excitement (aka Zapp) to encourage better things. This seemed to strike a > chord in the audience. > > I wanted to share this - because I certainly appreciate peoples thoughts > on all of these topics, but I really donât want to see us have more > casualties in our amazing community. > > So please - try and think âZappâ not âSappâ - and try and use your > experience/advice/observations as a way to empower others to make useful > change - or consider the direction they may be taking such that they want > to do more. > > Tim > > p.s. This is easy to say/write - and quite hard to do well. I know we will > all make mistakes doing this well - but practicing it is important, and > having words like âZappâ and a way to tell each other this is just as > important as the code we write. > > > On 28 Aug 2014, at 19:15, kmo <voxkmp(a)gmail.com> wrote: > > philippeback wrote > > Building a UI with Morphic alone is what one would use to do something > very > custom (like a game for example). > > Now, creating a larger UI that way is definitely going to be super pain in > the assets. > > That's where Spec does fit. > > > Is there any evidence of this? As far as I know no one has built anything > more complex than a class browser. I would say Spec was incapable of > building a complex interface of any kind. It's clumsy, developer-hostile, > and counter-intuitive. > > The whole Spec process of writing code in three different places is the > very > definition of a /super pain in the asset/s. it is far less intuitive to my > mind than creating composite morphs. > > Progress on Spec is glacially slow - but that's not the problem. Spec is > profoundly misconceived and fundamentally flawed and offers nothing over > raw > Morphic. The Spec model is simply not how anyone would want to build an > interface in 2014. I certainly would never use it. > > > > > > > > -- > View this message in context: > http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by HernÃ¡n Morales Durand

| dcm | (dcm := DynamicComposableModel new) instantiateModels: #(button ButtonModel). dcm button label: 'Button'; action: [ self halt ]. dcm openWithSpecLayout: (SpecLayout composed newColumn: [: c | c add: #button ]; yourself). 2014-09-01 8:49 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > Lets take a very simple example of creating a UI that contains one very > simple button in Morphic I would do: > > button := PluggableButtonMorph new. > button label: 'Button'. > button openInWindow . > > According to Spec to do the same I would need several methods just for > initialization and a separate class to host these methods. > > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > I would need initializeWidgets , defaultSpec , list and title . Unless I > am reading the documentation wrong. > > > On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> Personally there are two thing I dont like about Spec >>> >>> a) There is quite a lot of setup just to start adding things together >>> making quite verbose for small GUIs. It may be just my lack of >>> understanding but I find Morphic much easier to use. >>> >> >> Can you give me an example of this setup for a small GUI? The examples I >> have seen so far only use some lines of code in #defaultSpec and some lines >> of code >> for wiring up the different models (like onSelectedDo, onChangedDo, ...) >> All of that are things you would do anyway. >> >> nicolai >> >> >> >>> >>> b) I have a deep dislike about the use of pragmas. I know they are >>> useful for primitives that cant be pure smalltalk objects like for example >>> Nativeboost but I still feel they brake the uniformity of smalltalk syntax >>> at least in my eyes. >>> >>> On the other hand having something that can quickly produce guis is >>> essential. But personal I prefer lego-like approaches which is what Morphic >>> uses. As side note I think designing GUI via code is a bad idea, at least >>> in my eyes, we need a designer for that, afterall most of the powerful IDEs >>> out there have GUI designers. Nonetheless wishful thinking is not >>> productive , Spec is here, it is certainly helpful and I hope it continues >>> to evolve and improve. >>> >>> >>> On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be> >>> wrote: >>> >>>> When one looks at the implementers of "defaultSpec" (lots of Adapters, >>>> tools), I find it more understandable to figure out how a tool is laid out. >>>> >>>> How to follow what messages are sent around, err... much less >>>> understandable indeed (So, sharing Sean's pain). >>>> >>>> Of course, this is different from inspecting morphs. But it shouldn't >>>> be so. If Morphs where isofunctional with the Adapters, it would be much >>>> more regular. >>>> >>>> It is glaring that the Morphs all have their own little view of the >>>> world with no unified set of protocols, which isn't helping. >>>> >>>> An example: MorphicRadioButtonAdapter >>>> >>>> defaultSpec >>>> <spec> >>>> ^ {#CheckboxMorph. >>>> #on:selected:changeSelected:. #model. #state. #state:. >>>> #label:. { #model. #label }. >>>> #labelClickable:. { #model. #labelClickable}. >>>> #beRadioButton. >>>> #hResizing:. #shrinkWrap. >>>> #vResizing:. #shrinkWrap. >>>> #setBalloonText:. #(model help). >>>> #dragEnabled:. #(model dragEnabled). >>>> #dropEnabled:. #(model dropEnabled). >>>> #dragEnabled:. #(model dragEnabled). >>>> #dropEnabled:. #(model dropEnabled). >>>> "#borderWidth:. #(model borderWidth). >>>> #borderColor:. #(model borderColor)"} >>>> >>>> A halo that would outline the SpecLayout bits and pieces would go a >>>> long way in helping people figure out what's going on. A project in itself. >>>> >>>> Now, can we both have a declarative UI and an easy to debug UI? As the >>>> declarative things has its own interpreter and engine? >>>> >>>> Phil >>>> >>>> >>>> >>>> >>>> On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>> >>>>> +1 to both of you :) >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>>> Hi sean >>>>>> >>>>>> >>>>>> I've been mulling this over for a while, and since we've been having >>>>>>> conversations about Spec's place in our future... >>>>>>> >>>>>> :) >>>>>> Good. This is important that everybody express itself. >>>>>> >>>>>> >>>>>>> DISCLAIMER: this is a visceral experience I've been having over a >>>>>>> long >>>>>>> period of time, so it may not be factually "true" or current, but I >>>>>>> present >>>>>>> it as a contribution, if only by someone saying "you're full of crap >>>>>>> because..." and we all learn something. >>>>>>> >>>>>>> The purpose of Spec as I understand it is to both come up with a nice >>>>>>> streamlined UI API, and to make multiple targets (e.g. Morphic, html) >>>>>>> possible with the same codebase. These are both important goals. And >>>>>>> it >>>>>>> seems we've made some progress at least in the first case. I >>>>>>> definitely >>>>>>> enjoy working with Spec's API far more that e.g. PolyMorph. >>>>>>> >>>>>>> Spec could be a very valuable application-level tool. If I want to >>>>>>> write a >>>>>>> business application, I can write once via a nice API and deploy >>>>>>> "anywhere". >>>>>>> Life is good. >>>>>>> >>>>>>> My discomfort is with making *all* our core tools Spec-based. >>>>>>> >>>>>> >>>>>> I agree this is why I started to write some little tool to be able to >>>>>> browse the system >>>>>> when Spec is shaking. >>>>>> >>>>>> Now when you see the code of the old browser this is not nice either. >>>>>> So we will see and learn. But I can tell you that nothing is curved >>>>>> in stone. >>>>>> We will introduce GT but again you will get the same because GT is a >>>>>> frameworks. >>>>>> >>>>>> >>>>>> While it is great from an "eating our own dog food perspective", one >>>>>>> of the great >>>>>>> principles of Morphic is exploration and discoverability. Many times >>>>>>> before >>>>>>> Spec I was able to poke around a tool, figure out how it worked, and >>>>>>> apply >>>>>>> that lesson to my own UI. However, with Spec I find it extremely >>>>>>> difficult >>>>>>> to figure out WTH is going on. Parsing of arrays of symbols seems to >>>>>>> have >>>>>>> replaced Smalltalk code, and each field/model piece of a Spec UI >>>>>>> seems to be >>>>>>> buried behind multiple ValueHolder/Adapter/whatever levels. Granted, >>>>>>> now >>>>>>> that we have e.g. specialized inspectors, we might be able to >>>>>>> alleviate >>>>>>> this. >>>>>>> >>>>>> >>>>>> We should iterate on it. >>>>>> May be another framework will be better in the future >>>>>> >>>>>> >>>>>>> My 2c. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/When- >>>>>>> all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html >>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>> Nabble.com. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >> >

Sept. 1, 2014