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

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Stephane Ducasse

This is why three years ago a convinced Pablo Tesone and Nicolas Passerini to work on a Type Inferencer for Pharo. Now the economic situation in argentina pushed Pablo to take another grant. And this is why we proposed as a topic to new guy in our team to work on this topic. Unfortunately the system did not give him the position. For the record marcus was involved in the gradual typing phd with chilean colleague (and we do not like gradual typing) worked on PlugType an optional pluggable typer for Squeak long time ago. So if people wants to get a typeInferencer for Pharo and have money to pay a phd let me know. Or you are gifted and like types and are looking for a PhD contact me :) Stef On Tue, May 9, 2017 at 4:17 PM, Eric Velten de Melo <ericvmelo(a)gmail.com> wrote: > I think he forgets to mention Haskell, which is probably the reason behind > the shift of Swift towards optional values (Option type in Scala, Maybe > type in Haskell). You can't talk about modern type system without talking > about Haskell, Monads and Algebraic Data Types (Maybe is a monad). > > I don't believe the future is dynamic typing, I believe it is type > inference and optional typing. There is no need to be radical about it. One > great sadly forgotten example of this is Strongtalk, which was rumored to > be the fastest implementation of Smalltalk ever made (I don't know how it > compares to the latest Pharo VM, though) and included an optional strong > type system (http://www.strongtalk.org/) Strongtalk team was bought by > Sun before they could release the language and their advancements in > virtual machine development were taken by the Java Virtual Machine. It is > one of my dreams to see Strongtalk back into action or maybe a version of > Self with optional typing, but I unfortunately lack the required skills and > time to do so. > > 2017-05-09 10:26 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > >> Fantastic article. Very well rounded. I particularly liked "Meanwhile >> the Smalltalk programmers were scratching their heads wondering what the >> big deal was. You see, their language was also strongly typed; but their >> types were undeclared. In Smalltalk types were enforced at runtime." >> >> and..."You see, the Smalltalk programmers had solved the missile problem >> in their own unique way. They invented a discipline. Today we call that >> discipline: Test Driven Development. ... You see, when a Java programmer >> gets used to TDD, they start asking themselves a very important question: >> âWhy am I wasting time satisfying the type constraints of Java when my unit >> tests are already checking everything?â >> >> cheers -ben >> >> On Tue, May 9, 2017 at 2:49 PM, askoh <askoh(a)askoh.com> wrote: >> >>> This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong >>> Koh >>> >>> http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Smalltal >>> kers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> >

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Joachim Tuchel

+1 and ;-) Am 09.05.2017 um 18:59 schrieb Stephan Eggermont: > On 09/05/17 16:17, Eric Velten de Melo wrote: >> I think he forgets to mention Haskell, which is probably the reason >> behind the shift of Swift towards optional values (Option type in Scala, >> Maybe type in Haskell). You can't talk about modern type system without >> talking about Haskell, Monads and Algebraic Data Types (Maybe is a >> monad). > > I don't know. I do know that I can't use something with the ridiculous > compile times of Haskell or Swift. That just kills flow and productivity. > > Stephan > > > >

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Stephan Eggermont

On 09/05/17 16:17, Eric Velten de Melo wrote: > I think he forgets to mention Haskell, which is probably the reason > behind the shift of Swift towards optional values (Option type in Scala, > Maybe type in Haskell). You can't talk about modern type system without > talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad). I don't know. I do know that I can't use something with the ridiculous compile times of Haskell or Swift. That just kills flow and productivity. Stephan

May 9, 2017

Re: [Pharo-users] Remote Debugger bugs ?

by Denis Kudriashov

2017-05-09 17:22 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > I evaluated "1/0" in a playground in the remote image I found the issue. Debugging remote UI process is not supported well. When you close debugger remote UI process is terminated which makes remote image unresponsive. But it is not completely frozen. You can spawn new UI process remotely: remotePharo evaluate: [ UIManager default spawnNewProcess ]. Or from remote playground just evaluate it directly: UIManager default spawnNewProcess I will think how to support it properly. I wondering do you just play or you have real requirements for this scenario? (I not thought it is important) Best regards, Denis

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Dimitris Chloupis

On Tue, May 9, 2017 at 10:02 AM askoh <askoh(a)askoh.com> wrote: > This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > > > > -- > View this message in context: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > There is no war, nowadays you can mix languages together with ease, pick the one you prefer and do not make it a big deal.Personally I am indifferent when it comes to types, do not care if I declare them or not. Furthermore the choice of a language is 99% its libraries why bother with the 1%. If the library you want is on Smalltalk you will pick Smalltalk sadly C++ wins here with its vastness of libraries that have allowed such an ugly language to exist for so long. I do not see why its necessary for the type to be embedded in the language why not be meta data using a popular format like JSON and that will give you the freedom to limit the types or not depending on the situation. I love the smalltalk attitude of shifting the focus from the language to the libraries and IDE. A gigantic syntax like C++ is a gigantic problem. But to be fair C++ has come a long way, smart pointers have lifted the pain of manual memory management, templates have helped with implementing dynamic types. There is also a lot of talk of replacing the header system with a module system like python. So C++ is definitely evolving. The game engine I am using Unreal C++ has even further boosted the language not only by using templates to offer dynamism but also offers manual GC and a limited reflection system. However the source of the popularity of C++ has been Microsoft and Microsoft has been pushing a lot lately of its own language C# more aggressively lately by open sourcing .NET and investing on cross platform development. C++ will of course keep being the choice of top performance apps and libraries. When a new feature in C++ performance comes first because that where the language focus on. We have a different goal. So no I do not think Smalltalk will ever win on this one when it comes to performance C++ has demonstrated that its syntax though very problematic and quite annoying , it still is the No 1 choice.

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Raffaello Giulietti

I agree with Eric that some future programming environments will probably provide and encourage optional types + type inference. This doesn't necessarily contrast with late dynamic binding Ã la Smalltalk. If types are an entangled part of the language, like in virtually any statically typed programming language, it's hard to evolve them while maintaining backward compatibility with older code. This is one reason why a type system is perhaps best defined as an additional, optional component of a development environment. It is then up to the programmer to choose whether to use types and at which stage. Besides, optional pluggable type systems can evolve independently and perhaps even cohabit with others at the same time. With a sensible blend between type annotations and inference and between the language core and and a pluggable typing system, types should almost never hurt, while providing more benefits than costs. Sure, it all depends on how deeply they are enforced at all levels and phases of programming and how they are used. No doubts that in a complex and pervasive typing system as in C++, they are a real pain during the early phases of development and a burden at later stages, and make it harder to evolve software. When types are perceived simply as a means, not an end, they provide a really useful and well exploitable tool. Greetings Raffaello On 2017-05-09 16:17, Eric Velten de Melo wrote: > I think he forgets to mention Haskell, which is probably the reason > behind the shift of Swift towards optional values (Option type in > Scala, Maybe type in Haskell). You can't talk about modern type system > without talking about Haskell, Monads and Algebraic Data Types (Maybe > is a monad). > > I don't believe the future is dynamic typing, I believe it is type > inference and optional typing. There is no need to be radical about > it. One great sadly forgotten example of this is Strongtalk, which was > rumored to be the fastest implementation of Smalltalk ever made (I > don't know how it compares to the latest Pharo VM, though) and > included an optional strong type system (http://www.strongtalk.org/) > Strongtalk team was bought by Sun before they could release the > language and their advancements in virtual machine development were > taken by the Java Virtual Machine. It is one of my dreams to see > Strongtalk back into action or maybe a version of Self with optional > typing, but I unfortunately lack the required skills and time to do so. > > 2017-05-09 10:26 GMT-03:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > Fantastic article. Very well rounded. I particularly liked > "Meanwhile the Smalltalk programmers were scratching their heads > wondering what the big deal was. You see, their language was also > strongly typed; but their types were undeclared. In Smalltalk > types were enforced at runtime." > > and..."You see, the Smalltalk programmers had solved the missile > problem in their own unique way. They invented a discipline. Today > we call that discipline: Test Driven Development. ... You see, > when a Java programmer gets used to TDD, they start asking > themselves a very important question: âWhy am I wasting time > satisfying the type constraints of Java when my unit tests are > already checking everything?â > > cheers -ben > > On Tue, May 9, 2017 at 2:49 PM, askoh <askoh(a)askoh.com > <mailto:askoh@askoh.com>> wrote: > > This is a quote from Bob Martin of "Clean Code" fame. Enjoy, > Aik-Siong Koh > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > <http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html> > > > > -- > View this message in context: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… > <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p…> > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > >

May 9, 2017

Re: [Pharo-users] Remote Debugger bugs ?

by Steven Costiou

Hi Denis, > 2017-05-09 17:22 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> I evaluated "1/0" in a playground in the remote image, and the exception opens in my local image. Now if i clic "abandon", the local image is ok but the remote is frozen. If i clic "proceed", the local image is frozen and the remote is ok. > > Could you try just close window instead of abandon. I will check later but I never use this button in my workflow. Same problem. >> So using the remote browser from my local image, i created a test class with a test method that does "^'1', 0" and i execute it in the remote image. The debugger opens the local image and i can debug it "^'1', 0 printString", accept and proceed. The inspector opens with the return value in the remote image and the local image is frozen again. > Normally it should work. I will try your scenario. > > What the platform for local and remote images? both 32bits? And how bad is network connection? I use two images on the same computer (so its on localhost), using windows 7 64 bits but the two images are 32bits (pharo 6 60483). Steven.

May 9, 2017

Re: [Pharo-users] Remote Debugger bugs ?

by Denis Kudriashov

Hi. 2017-05-09 17:22 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > I evaluated "1/0" in a playground in the remote image, and the exception > opens in my local image. Now if i clic "abandon", the local image is ok but > the remote is frozen. If i clic "proceed", the local image is frozen and > the remote is ok. > > Could you try just close window instead of abandon. I will check later but I never use this button in my workflow. > > > So using the remote browser from my local image, i created a test class > with a test method that does "^'1', 0" and i execute it in the remote > image. The debugger opens the local image and i can debug it "^'1', 0 > printString", accept and proceed. The inspector opens with the return value > in the remote image and the local image is frozen again. > Normally it should work. I will try your scenario. What the platform for local and remote images? both 32bits? And how bad is network connection?

May 9, 2017

Remote Debugger bugs ?

by Steven Costiou

Hi, i'm confused with how to configure the remote debugger. I used this link to configure my images: http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.… I evaluated "1/0" in a playground in the remote image, and the exception opens in my local image. Now if i clic "abandon", the local image is ok but the remote is frozen. If i clic "proceed", the local image is frozen and the remote is ok. So using the remote browser from my local image, i created a test class with a test method that does "^'1', 0" and i execute it in the remote image. The debugger opens the local image and i can debug it "^'1', 0 printString", accept and proceed. The inspector opens with the return value in the remote image and the local image is frozen again. The only solution i have is to kill the image. I used Windows 7 for these tests. Is there anything i missed besides the configurations steps in the link above ? RemoteBrowser and RemotePlayground seem to work fine, except some problems with the contextual menus in the browser.

May 9, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by Esteban A. Maringolo

2017-05-09 5:59 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Great article. Thanks for sharing. > > Not that I or most people here need convincing, but it is nice to see others voicing this opinion. +1 Not only the opinion, but it is good to see somebody with such influence recognizing the merits of Smalltalk's approach. I do find myself scratching my head when looking at "problems" other developers have with their favorite toolset. Maybe I take too much for granted; I notice it every time I have to leave the smooth land of a live environment. Nice article, thanks for sharing. Regards! Esteban A. Maringolo

May 9, 2017