- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Marcus Denker

I have removed the sender from the list. The pharo board decided already last year (from the time when the mails that he is answering now) were written that these emails are just disturbing our work, with no positive value whatsoever. Marcus > On 01 Aug 2015, at 16:29, Kjell Godo <squeaklist(a)gmail.com> wrote: > > > > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de <mailto:a.wacknitz@gmx.de>> wrote: > >> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>>: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. > Why do you expect that? Many people here are using Smalltalk for years. > Just because you have been silent for some time doesnât mean everybody will forget about you :) > >> >> I don't know if you want this crap in here but I have decided not to wait for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> The debugger is my staff I use to whack the state. And TestCase is my sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of development Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one point most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. > > First, there are no good definitions of what is an object oriented language and what is a functional language. > Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalkâs. > The same problem exists in the functional language world: Some consider LISP being functional, some deny that. > > Second, for some years I am constantly seeking for âthe bestâ language to solve my problems in. Alas I wasnât successful yet and donât expect > to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. > So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the > best fitting language for your problem at hand. > > Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine > the best characteristics. In my eyes all of them failed because what always have been created is Frankensteinâs monster. When you combine > paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. > > I had an idea > > BorgLisp > > where different dialects of Lisp > > coexist > > in a single language > > and these dialects can be > > combined > > as in the > > Cola and Maru languages > > developed by > > Alan Kay's institute . > > Hopefully this would satisfy your objection to multi paradigm languages > because each dialect is pure in itself > and can be combined with another dialect > or left alone and used by itself . > > And there would be Lisp dialects made > that are isomorphic to all the existing languages > like C C++ C# Java Scala Clojure Prolog Haskell Lua > CommonLisp Scheme Perl Smalltalk etc > > And all these Lisp dialects can be combined > like in Cola but like ... ( haskell-- ...AHaskellLispDialectExpression... ) ... > which can have other dialects inside or be used in its seperate pureness > > and there is one or more functional OOP Macro systems > and Haskell like category theories of composition > across all the dialects > > image based or generating seperate small executables > > This kind of a manoeuvre is designed to kill off the original languages > eventually > by assimilation into the BorgLisp collective > > each isomorphic language dialect need not be as phabulous > as its original inspiration as whatever it lacks can be gotten > from one of the other dialects > so not isomorphic but subset isomorphic > or isomorphic to a subset > of the original language > > these isomorphic dialects > are designed like sirens > to drive programmers of those languages mad with desire > so they get ship wrecked > on the rocks > of their dialect in the BorgLisp pleasure dome > never to return > > to what do you object to that > kind of thing > > how can Smalltalk mix with anything else? that's oil and water? > > BorgLisp is image based > > but it can generate seperate executables > > it can generate itself > > using the Cola Maru bootstrapping process > > to what do you object? > > how should it be modified > > > Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. Itâs the whole system: the language, duck typing, > the image (object world), the tools, the VM, the simplicity, the elegance, â¦ And last but not least the communities around. > > Regards > Andreas > > PS: If you are interested in functional programming and donât like static typing you should have a look at Clojure. It has some nice ideas about > how to deal with state concurrently. > > > >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>>: > > This is off topic. > > I tried to post it as a top level thread but I have become unknown. > > Why do you expect that? Many people here are using Smalltalk for years. > Just because you have been silent for some time doesnât mean everybody > will forget about you :) > > > I don't know if you want this crap in here but I have decided not to wait > for the > > postmaster to get back to me on the subject of becoming known. Feel free. > > > > > > ( Original-SUBJECT: "( picoVerse-:( what about state , is state really > evil? ) )" ) > > > > > > > I am a Smalltalker. > > But in the past few months i have been running with the Haskellers. > > The Haskellers hate state. > > This seemed strange at first because as a Smalltalker i love(d) state. > State iswas my friend. > > 90% of my life as a Smalltalker is state wrangling. I am a state herder. > > The debugger is my staff I use to whack the state. And TestCase is my > sheep dog. > > But to the Haskellers > > state is > > the evil trinity > > of > > satan the anti christ and the false prophet > > all rolled into one. > > State is the true dev incarnation of the total catastrophe of development > Armageddon. > > Blood up to the bridles for hundreds of miles. Dogs and cats living > together. Mass hysteria. > > They say. > > I'm not sure i quite get it yet but they keep preaching on this one point > most of all. > > State is evil. > > You must keep all state in a Monad. As many methods/functions m as > possible > > must be 100% dependent on the input parameters ONLY. > > No hidden instance variables affecting the return value of m are allowed. > > The only effect m can have is to return a value. > > If all this is true then m is pure. > > And pure is good. Pure is very good. And the wind says > > very. > > So i wonder if any of you fellow > > Smalltalkers > > have thought about this at all. > > First, there are no good definitions of what is an object oriented > language and what is a functional language. > Thus, languages like C++, C#, Java are being considered object oriented. > But their object orientation is not the same like Smalltalkâs. > The same problem exists in the functional language world: Some consider > LISP being functional, some deny that. > > Second, for some years I am constantly seeking for âthe bestâ language to > solve my problems in. Alas I wasnât successful yet and donât expect > to be successful in the future. Every programming paradigm has its > strengths and weaknesses when it comes to real world problems. > So in my eyes it is best to know the different programming paradigms and > its representative languages in order to be able to choose the > best fitting language for your problem at hand. > > Third, there have been many attempts to create multi-paradigm languages > (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine > the best characteristics. In my eyes all of them failed because what > always have been created is Frankensteinâs monster. When you combine > paradigms you will may get some advantages of all but sure you will get a > lot of additional complexity. > I had an idea BorgLisp where different dialects of Lisp coexist in a single language and these dialects can be combined as in the Cola and Maru languages developed by Alan Kay's institute . Hopefully this would satisfy your objection to multi paradigm languages because each dialect is pure in itself and can be combined with another dialect or left alone and used by itself . And there would be Lisp dialects made that are isomorphic to all the existing languages like C C++ C# Java Scala Clojure Prolog Haskell Lua CommonLisp Scheme Perl Smalltalk etc And all these Lisp dialects can be combined like in Cola but like ... ( haskell-- ...AHaskellLispDialectExpression... ) ... which can have other dialects inside or be used in its seperate pureness and there is one or more functional OOP Macro systems and Haskell like category theories of composition across all the dialects image based or generating seperate small executables This kind of a manoeuvre is designed to kill off the original languages eventually by assimilation into the BorgLisp collective each isomorphic language dialect need not be as phabulous as its original inspiration as whatever it lacks can be gotten from one of the other dialects so not isomorphic but subset isomorphic or isomorphic to a subset of the original language these isomorphic dialects are designed like sirens to drive programmers of those languages mad with desire so they get ship wrecked on the rocks of their dialect in the BorgLisp pleasure dome never to return to what do you object to that kind of thing how can Smalltalk mix with anything else? that's oil and water? BorgLisp is image based but it can generate seperate executables it can generate itself using the Cola Maru bootstrapping process to what do you object? how should it be modified > Fourth, it has been said many times before: What makes Smalltalk so nice > is not only the language. Itâs the whole system: the language, duck typing, > the image (object world), the tools, the VM, the simplicity, the elegance, > â¦ And last but not least the communities around. > > Regards > Andreas > > PS: If you are interested in functional programming and donât like static > typing you should have a look at Clojure. It has some nice ideas about > how to deal with state concurrently. > > > > Thanks > > Kjell E GodÃ¸ > > > > > > > > > > (((((((((( Maybe Smalltalk should be called Statewalk > > as in yak it up fuzz ball. )))))))))) > > >

Aug. 1, 2015

ESUG2015 Photos

by Yuriy Tymchuk

Hi all! Photos from ESUG 2015 made by me and Natalia are available at: https://goo.gl/photos/Z15Fc7QpM4kPHRno9 <https://goo.gl/photos/Z15Fc7QpM4kPHRno9> Cheers! Uko

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Marcus Denker

We will kick you out if you send crap to this list. One more mail like that and you are out. > On 01 Aug 2015, at 15:41, Kjell Godo <squeaklist(a)gmail.com> wrote: > > is there anybody > > here > > who knows both > > Haskell and Smalltalk ? > > Can Smalltalk benefit from > > functional ideas > > and > > Haskell's ideas about > > Immutability > > Currying > > Function composition and > > the State and IO Monads ? > > I like the way Haskell is now based on > > Category Theory > > which is the mathematics of > > function composition . > > Haskell was not always thus > > it had a > > pre Category Theory > > epoch . > > which apparently > > was a UM or > > Ugly Mess . > > Can these ideas be applied to > > Smalltalk? > > And would it be good? > > Can Smalltalk have a way of making a > > framework > > that has an > > API > > and is statically typed inside > > using a Haskell like type system? > > On Saturday, August 1, 2015, Kjell Godo <squeaklist(a)gmail.com <mailto:squeaklist@gmail.com>> wrote: > > > On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com <javascript:_e(%7B%7D,'cvml','eliot.miranda(a)gmail.com');>> wrote: > Hi Kjell, > > On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com <>> wrote: > >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? > > The Pharo & Squeak dialects, along with most others, now have closures, so blocks are fully recursive. > >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler > > The compiler already inlines closures in a few key control messages such as ifTrue: whileTrue: and:. > > > I recommend spending some time reading the code for the core execution classes and the compiler, and running examples interactively to learn how the system works. It's a fun process and well supported by the tools. Remember that the debugger includes a meta circular interpreter for executing the system's bytecode, and that the compiler compiles source to bytecode in the firm of CompiledMethod instances you can inspect, decompile and list their bytecode. > > All the questions you have above you can answer for yourself by running examples and using the tools to observe what happens. This is a route to mastering the system; IMNERHO the best. > > > is there any tutorial? > > how do i do this? > > >> Thank you > > Eliot (phone) > > >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de <>> wrote: >> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com <>>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody will forget about you :) >> >>> >>> I don't know if you want this crap in here but I have decided not to wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

is there anybody here who knows both Haskell and Smalltalk ? Can Smalltalk benefit from functional ideas and Haskell's ideas about Immutability Currying Function composition and the State and IO Monads ? I like the way Haskell is now based on Category Theory which is the mathematics of function composition . Haskell was not always thus it had a pre Category Theory epoch . which apparently was a UM or Ugly Mess . Can these ideas be applied to Smalltalk? And would it be good? Can Smalltalk have a way of making a framework that has an API and is statically typed inside using a Haskell like type system? On Saturday, August 1, 2015, Kjell Godo <squeaklist(a)gmail.com> wrote: > > > On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com > <javascript:_e(%7B%7D,'cvml','eliot.miranda(a)gmail.com');>> wrote: > >> Hi Kjell, >> >> On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com> wrote: >> >> Thank you for the detailed reply Andreas >> >> >> >> Are there any Smalltalk packages implementing >> >> Category Theory based >> >> functional programming constructs >> >> for function composition like >> >> functors , applicatives , monads , arrows , etc ? >> >> >> >> Do people have opinions about whether or not >> >> these plus immutable data structures would be good for managing state >> >> in Smalltalk like they do it in Haskell etc? i know that monads are not >> built >> >> into Haskell but are implemented as addons via Haskell packages. >> >> My Haskell friend said all you need to do functional programming is >> >> first class functions >> >> which Smalltalk Block contexts almost are except they lack their own >> stack? >> >> if you wrap a Block in a Function Object do you then get the stack >> >> effect so you can essentially call the Block recursively? >> >> >> The Pharo & Squeak dialects, along with most others, now have closures, >> so blocks are fully recursive. >> >> >> i have been wondering about taking a crack at implementing these >> >> in Smalltalk and i wonder if it would be >> >> theoretically possible >> >> to speed them up by inlining them via the Smalltalk compiler >> >> >> The compiler already inlines closures in a few key control messages such >> as ifTrue: whileTrue: and:. >> >> >> I recommend spending some time reading the code for the core execution >> classes and the compiler, and running examples interactively to learn how >> the system works. It's a fun process and well supported by the tools. >> Remember that the debugger includes a meta circular interpreter for >> executing the system's bytecode, and that the compiler compiles source to >> bytecode in the firm of CompiledMethod instances you can inspect, decompile >> and list their bytecode. >> >> All the questions you have above you can answer for yourself by running >> examples and using the tools to observe what happens. This is a route to >> mastering the system; IMNERHO the best. >> >> > is there any tutorial? > > how do i do this? > > >> >> Thank you >> >> >> Eliot (phone) >> > > >> >> On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de> >> wrote: >> >>> >>> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >>> >>> This is off topic. >>> >>> I tried to post it as a top level thread but I have become unknown. >>> >>> Why do you expect that? Many people here are using Smalltalk for years. >>> Just because you have been silent for some time doesnât mean everybody >>> will forget about you :) >>> >>> >>> I don't know if you want this crap in here but I have decided not to >>> wait for the >>> >>> postmaster to get back to me on the subject of becoming known. Feel >>> free. >>> >>> >>> >>> >>> >>> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >>> really evil? ) )" ) >>> >>> >>> >>> >>> >>> >>> I am a Smalltalker. >>> >>> But in the past few months i have been running with the Haskellers. >>> >>> The Haskellers hate state. >>> >>> This seemed strange at first because as a Smalltalker i love(d) state. >>> State iswas my friend. >>> >>> 90% of my life as a Smalltalker is state wrangling. I am a state >>> herder. >>> >>> The debugger is my staff I use to whack the state. And TestCase is my >>> sheep dog. >>> >>> But to the Haskellers >>> >>> state is >>> >>> the evil trinity >>> >>> of >>> >>> satan the anti christ and the false prophet >>> >>> all rolled into one. >>> >>> State is the true dev incarnation of the total catastrophe of >>> development Armageddon. >>> >>> Blood up to the bridles for hundreds of miles. Dogs and cats living >>> together. Mass hysteria. >>> >>> They say. >>> >>> I'm not sure i quite get it yet but they keep preaching on this one >>> point most of all. >>> >>> State is evil. >>> >>> You must keep all state in a Monad. As many methods/functions m as >>> possible >>> >>> must be 100% dependent on the input parameters ONLY. >>> >>> No hidden instance variables affecting the return value of m are allowed. >>> >>> The only effect m can have is to return a value. >>> >>> If all this is true then m is pure. >>> >>> And pure is good. Pure is very good. And the wind says >>> >>> very. >>> >>> So i wonder if any of you fellow >>> >>> Smalltalkers >>> >>> have thought about this at all. >>> >>> First, there are no good definitions of what is an object oriented >>> language and what is a functional language. >>> Thus, languages like C++, C#, Java are being considered object oriented. >>> But their object orientation is not the same like Smalltalkâs. >>> The same problem exists in the functional language world: Some consider >>> LISP being functional, some deny that. >>> >>> Second, for some years I am constantly seeking for âthe bestâ language >>> to solve my problems in. Alas I wasnât successful yet and donât expect >>> to be successful in the future. Every programming paradigm has its >>> strengths and weaknesses when it comes to real world problems. >>> So in my eyes it is best to know the different programming paradigms and >>> its representative languages in order to be able to choose the >>> best fitting language for your problem at hand. >>> >>> Third, there have been many attempts to create multi-paradigm languages >>> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >>> the best characteristics. In my eyes all of them failed because what >>> always have been created is Frankensteinâs monster. When you combine >>> paradigms you will may get some advantages of all but sure you will get >>> a lot of additional complexity. >>> >>> Fourth, it has been said many times before: What makes Smalltalk so nice >>> is not only the language. Itâs the whole system: the language, duck typing, >>> the image (object world), the tools, the VM, the simplicity, the >>> elegance, â¦ And last but not least the communities around. >>> >>> Regards >>> Andreas >>> >>> PS: If you are interested in functional programming and donât like >>> static typing you should have a look at Clojure. It has some nice ideas >>> about >>> how to deal with state concurrently. >>> >>> >>> >>> Thanks >>> >>> Kjell E GodÃ¸ >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (((((((((( Maybe Smalltalk should be called Statewalk >>> >>> as in yak it up fuzz ball. )))))))))) >>> >>> >>>

Aug. 1, 2015

Re: [Pharo-dev] Musings (Was: NAtiveBoost error)

by Kjell Godo

On Monday, July 6, 2015, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Kjell, > > On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)gmail.com');>> wrote: > > Thank you for the detailed reply Andreas > > > > Are there any Smalltalk packages implementing > > Category Theory based > > functional programming constructs > > for function composition like > > functors , applicatives , monads , arrows , etc ? > > > > Do people have opinions about whether or not > > these plus immutable data structures would be good for managing state > > in Smalltalk like they do it in Haskell etc? i know that monads are not > built > > into Haskell but are implemented as addons via Haskell packages. > > My Haskell friend said all you need to do functional programming is > > first class functions > > which Smalltalk Block contexts almost are except they lack their own stack? > > if you wrap a Block in a Function Object do you then get the stack > > effect so you can essentially call the Block recursively? > > > The Pharo & Squeak dialects, along with most others, now have closures, so > blocks are fully recursive. > > > i have been wondering about taking a crack at implementing these > > in Smalltalk and i wonder if it would be > > theoretically possible > > to speed them up by inlining them via the Smalltalk compiler > > > The compiler already inlines closures in a few key control messages such > as ifTrue: whileTrue: and:. > > > I recommend spending some time reading the code for the core execution > classes and the compiler, and running examples interactively to learn how > the system works. It's a fun process and well supported by the tools. > Remember that the debugger includes a meta circular interpreter for > executing the system's bytecode, and that the compiler compiles source to > bytecode in the firm of CompiledMethod instances you can inspect, decompile > and list their bytecode. > > All the questions you have above you can answer for yourself by running > examples and using the tools to observe what happens. This is a route to > mastering the system; IMNERHO the best. > > is there any tutorial? how do i do this? > > Thank you > > > Eliot (phone) > > > On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz(a)gmx.de > <javascript:_e(%7B%7D,'cvml','a.wacknitz(a)gmx.de');>> wrote: > >> >> Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist(a)gmail.com>: >> >> This is off topic. >> >> I tried to post it as a top level thread but I have become unknown. >> >> Why do you expect that? Many people here are using Smalltalk for years. >> Just because you have been silent for some time doesnât mean everybody >> will forget about you :) >> >> >> I don't know if you want this crap in here but I have decided not to wait >> for the >> >> postmaster to get back to me on the subject of becoming known. Feel free. >> >> >> >> >> >> ( Original-SUBJECT: "( picoVerse-:( what about state , is state >> really evil? ) )" ) >> >> >> >> >> >> >> I am a Smalltalker. >> >> But in the past few months i have been running with the Haskellers. >> >> The Haskellers hate state. >> >> This seemed strange at first because as a Smalltalker i love(d) state. >> State iswas my friend. >> >> 90% of my life as a Smalltalker is state wrangling. I am a state herder. >> >> >> The debugger is my staff I use to whack the state. And TestCase is my >> sheep dog. >> >> But to the Haskellers >> >> state is >> >> the evil trinity >> >> of >> >> satan the anti christ and the false prophet >> >> all rolled into one. >> >> State is the true dev incarnation of the total catastrophe of development >> Armageddon. >> >> Blood up to the bridles for hundreds of miles. Dogs and cats living >> together. Mass hysteria. >> >> They say. >> >> I'm not sure i quite get it yet but they keep preaching on this one point >> most of all. >> >> State is evil. >> >> You must keep all state in a Monad. As many methods/functions m as >> possible >> >> must be 100% dependent on the input parameters ONLY. >> >> No hidden instance variables affecting the return value of m are allowed. >> >> The only effect m can have is to return a value. >> >> If all this is true then m is pure. >> >> And pure is good. Pure is very good. And the wind says >> >> very. >> >> So i wonder if any of you fellow >> >> Smalltalkers >> >> have thought about this at all. >> >> First, there are no good definitions of what is an object oriented >> language and what is a functional language. >> Thus, languages like C++, C#, Java are being considered object oriented. >> But their object orientation is not the same like Smalltalkâs. >> The same problem exists in the functional language world: Some consider >> LISP being functional, some deny that. >> >> Second, for some years I am constantly seeking for âthe bestâ language to >> solve my problems in. Alas I wasnât successful yet and donât expect >> to be successful in the future. Every programming paradigm has its >> strengths and weaknesses when it comes to real world problems. >> So in my eyes it is best to know the different programming paradigms and >> its representative languages in order to be able to choose the >> best fitting language for your problem at hand. >> >> Third, there have been many attempts to create multi-paradigm languages >> (like C++, C#, Java, Scala, â¦). The idea behind is simple: combine >> the best characteristics. In my eyes all of them failed because what >> always have been created is Frankensteinâs monster. When you combine >> paradigms you will may get some advantages of all but sure you will get a >> lot of additional complexity. >> >> Fourth, it has been said many times before: What makes Smalltalk so nice >> is not only the language. Itâs the whole system: the language, duck typing, >> the image (object world), the tools, the VM, the simplicity, the >> elegance, â¦ And last but not least the communities around. >> >> Regards >> Andreas >> >> PS: If you are interested in functional programming and donât like static >> typing you should have a look at Clojure. It has some nice ideas about >> how to deal with state concurrently. >> >> >> >> Thanks >> >> Kjell E GodÃ¸ >> >> >> >> >> >> >> >> >> >> (((((((((( Maybe Smalltalk should be called Statewalk >> >> as in yak it up fuzz ball. )))))))))) >> >> >>

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by stepharo

Yes I think that we should do something to make sure that we understand that this is a button. Stef

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Esteban Lorenzano

> On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > Hello, > > Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. but they are buttons, then they should look like one. alsoâ¦ âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)â¦ it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like thatâ¦ but as it is now it does not work. Esteban > > I agree about the class side button. > > Franck > > Date: Sat, 1 Aug 2015 12:26:02 +0200 > From: i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com> > To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? > > Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. > And since everyone is used to it by now nobody will want to change it. :) > > > On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > Hi, > > why are the new nautilus buttons not buttons? > > <2015-08-01_122023.png> > â > They look like labels which is confusing. > > Peter

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Peter UhnÃ¡k

Well my point is that if I see a button I know it will do something. If I see a label I will ignore it, because it's just a label. I don't think it's a good UX to make it clickable. (The only reason why Class side can get away with it is because there's checkbox next to it). On Sat, Aug 1, 2015 at 1:25 PM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > Hello, > > Yes it looks a little bit 'lite' but we did not want to have 2 buttons > with the same look but two different kinds of actions. Hierarchy button > changes the window itself and variable and scoped open a new menu or > window. > > I agree about the class side button. > > Franck > > ------------------------------ > Date: Sat, 1 Aug 2015 12:26:02 +0200 > From: i.uhnak(a)gmail.com > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? > > > Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't > entirely consistent either. > And since everyone is used to it by now nobody will want to change it. :) > > > On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > why are the new nautilus buttons not buttons? > > > â > They look like labels which is confusing. > > Peter > > >

Aug. 1, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Franck Warlouzet

Hello, Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. I agree about the class side button. Franck Date: Sat, 1 Aug 2015 12:26:02 +0200 From: i.uhnak(a)gmail.com To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either.And since everyone is used to it by now nobody will want to change it. :) On Sat, Aug 1, 2015 at 12:21 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: Hi, why are the new nautilus buttons not buttons? â They look like labels which is confusing. Peter

Aug. 1, 2015