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

Re: [Pharo-users] Voyage, DateAndTime and UTC

by Paul DeBruicker

Or just store as ISO8601 string. NorbertHartl wrote > Hi, > >> Am 31.03.2017 um 17:16 schrieb Hilaire < > hilaire@ > >: >> >> Hi, >> >> As far as I see when I store a DateAndTime with local time, >> "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC >> DateAndTime "2017-03-31T15:10:46.137086+00:00". >> >> Am I doing something wrong or do I need to use a mongo description to >> correct that. But wait, even so, I will not know what was the initial >> local time. >> >> How do you usually deal such issue? >> > it's a pitty. BSON only supports a date type which is date and time in > UTC. So the offset information is stripped off and that is the reason why > you get it this way. I fell over this a lot. Especially when you use a > local midnight DateAndTime store it in mongo, read it and then do #asDate > you will end up having one day before. Very annoying. > I think we shouldn't store DateAndTime as BSON date. We should create a > custom type that includes timezone offset information. > > Norbert -- View this message in context: http://forum.world.st/Voyage-DateAndTime-and-UTC-tp4940779p4940811.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by Sven Van Caekenberghe

if you copy/paste something you should give a reference > On 31 Mar 2017, at 16:40, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > > On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello, > > I have a question which is more related to software engineering than to Pharo, but I hope that someone can give me an useful hint ;-) > > > Thanks for any advice :-) > Marc > > There are three schools of thought > Static programming , Dynamic programming and Hybrid Programming > > School of Static Programming > > The school of Static Programming which has been originating from compiled languages (turn code from source code to machine code before execution) it follows a static approach to the code. This means everything is clearly predefined, planned ahead and follows strict rules. > > Pros: > > 1) because compilers have specific code that its intentions are clear its much easier for them to optimize performance, hence code tends to run much faster eg C code tends to be 100s to 1000s times faster than Python code > > 2) Certain bugs can be captured at compile time which makes code safer to deploy to client. The compiler usually can capture such bugs and display relevant warning and errors again because the compiler is more strict to what goes in and what gets out. > > Cons: > > 1) Changing code on the fly, while the code runs can be notorious hard to do because of these restrictions. This means it does not work well with coders that love to experiment and try new ideas on the fly. > > 2) Finding bugs also can be harder because of these restrictions, the coder cannot easily change code on the fly on execution and generally the programming language is much less forgiving not only when coding but also when trying to inspect code and debug it. > > 3) Overall design can be quite ugly in the shake of increased performance and safety and that may affect the design of code as well > > School of Dynamic Programming > > The school of Dynamic Programming originates from interpreted languages , though modern implementations have compilers that compile source code to byte code and an interpreter that converts byte code to machine code on execution. There is no need for planning ahead in dynamic coding, instead dynamic coding works on the basis of abstractions and its proud to be the father and mother of OOP. OOP is an abstraction based , dynamic coding workflow that dominates dynamic language and even modern statically compiled languages. > > Pros: > 1) Code can change on the fly making coding much easier and beginner friendly > 2) No need to plan ahead > 3) more dynamic workflow also when debugging code that allows to interact and communicate with code real time > > Cons: > > 1) Performance is sacrificed, thats not obvious for code that executes at once but for code that repeats thousands to millions of times the slow downs depending on the implementation of the language can be anywhere between 10s of times to 1000s of times slower that a static language > > 2) Using the wrong data / object will not be easily reported beforehand and at times it can be hard to detect such problems. Other bugs can also be hard to be detected even under the use of helping tools that examine and evaluate code because of the generic nature of the code. > > Hybrid Programming > > Even though static languages give us static programming outside the box and dynamic languages give us dynamic programming outside the box, modern implementation allow for repetitively easily to mix these two workflows. Its also possible for the coder to implement his/her own features with a language. > > For example C language does not support OOP outside the box, but OOP implementations for C do exist most popular being GObjects used by the GTK+ library > > C++ and Java although statically typed languages support also more dynamic types through the use of templates and generics > > Dynamic languages also can come with a variety of tools that perform checks during runtime or even compile time. Also test driven development is very popular for performing this task allowing the coder to create code , launch with a single command thousands of tests and make sure his code passes even more strict guidelines than an average compiler for a statically compiled language. > > The catch however is that in both cases there are compromises, sub standard implementations and plain weird behavior. > > Summary: > > There is no right and wrong, whether we talk about types or other features whether you will follow the dynamic school or the static school is up to you and you preferences. Both approaches have pros and cons and both will make you waste time while coding. > > The future however looks more bright and promising for the dynamic school with the rise of AI. Compilers and developer tools in the future may be smarter not only detecting errors and common bugs but actually analyzing coder intentions and even coding philosophies. AI is already used for code analysis but its still on early stage but is none the less our very close future. > > Funny irony: > > The most popular scenario for future technology is quantum computing. Hardware by nature is "static" , you have to design it before hand and make sure it works almost perfectly before selling it. This is reflected to the basis of digital architecture where the smaller unit is bit which is always a number and always either 1 or 0. But with quantum computing the bit can inherit quantum properties and be both 1 and 0 at the same time. This will allow in the future for more flexible design of "dynamic" hardware allowing for hardware to also deal with abstractions directly. > > >

March 31, 2017

Re: [Pharo-users] Voyage, DateAndTime and UTC

by Norbert Hartl

Hi, > Am 31.03.2017 um 17:16 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Hi, > > As far as I see when I store a DateAndTime with local time, > "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC > DateAndTime "2017-03-31T15:10:46.137086+00:00". > > Am I doing something wrong or do I need to use a mongo description to > correct that. But wait, even so, I will not know what was the initial > local time. > > How do you usually deal such issue? > it's a pitty. BSON only supports a date type which is date and time in UTC. So the offset information is stripped off and that is the reason why you get it this way. I fell over this a lot. Especially when you use a local midnight DateAndTime store it in mongo, read it and then do #asDate you will end up having one day before. Very annoying. I think we shouldn't store DateAndTime as BSON date. We should create a custom type that includes timezone offset information. Norbert

March 31, 2017

Re: [Pharo-users] New chapter for new book

by Hilaire

This is not exactly true. Pharo By Example was already there, and preceeded by Squeak By Exemple, which the former is an adaptation. Le 31/03/2017 Ã 16:47, Dimitris Chloupis a Ã©crit : > when I joined back in 2011 there was not even basic documentation -- Dr. Geo http://drgeo.eu

March 31, 2017

Voyage, DateAndTime and UTC

by Hilaire

Hi, As far as I see when I store a DateAndTime with local time, "2017-03-31T17:10:46.137086+02:00", then I fetch it back, I got an UTC DateAndTime "2017-03-31T15:10:46.137086+00:00". Am I doing something wrong or do I need to use a mongo description to correct that. But wait, even so, I will not know what was the initial local time. How do you usually deal such issue? Thanks Hilaire -- Dr. Geo http://drgeo.eu

March 31, 2017

Re: [Pharo-users] New chapter for new book

by Dimitris Chloupis

Awesome to see Pharo doing so great on documentation front, when I joined back in 2011 there was not even basic documentation now there so many new useful books that is fun to read like this one. Great work !!!! :) On Fri, Mar 31, 2017 at 5:06 PM Marc Hanisch via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Wow, thats amazing! > > Thank you Stephane! > > 2017-03-31 15:51 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > I attached a new chapter for my forthcoming book. > > Stef > > >

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by Dimitris Chloupis

On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello, > > I have a question which is more related to software engineering than to > Pharo, but I hope that someone can give me an useful hint ;-) > > > Thanks for any advice :-) > Marc > There are three schools of thought Static programming , Dynamic programming and Hybrid Programming *School of Static Programming * The school of Static Programming which has been originating from compiled languages (turn code from source code to machine code before execution) it follows a static approach to the code. This means everything is clearly predefined, planned ahead and follows strict rules. *Pros: * 1) because compilers have specific code that its intentions are clear its much easier for them to optimize performance, hence code tends to run much faster eg C code tends to be 100s to 1000s times faster than Python code 2) Certain bugs can be captured at compile time which makes code safer to deploy to client. The compiler usually can capture such bugs and display relevant warning and errors again because the compiler is more strict to what goes in and what gets out. *Cons:* 1) Changing code on the fly, while the code runs can be notorious hard to do because of these restrictions. This means it does not work well with coders that love to experiment and try new ideas on the fly. 2) Finding bugs also can be harder because of these restrictions, the coder cannot easily change code on the fly on execution and generally the programming language is much less forgiving not only when coding but also when trying to inspect code and debug it. 3) Overall design can be quite ugly in the shake of increased performance and safety and that may affect the design of code as well *School of Dynamic Programming* The school of Dynamic Programming originates from interpreted languages , though modern implementations have compilers that compile source code to byte code and an interpreter that converts byte code to machine code on execution. There is no need for planning ahead in dynamic coding, instead dynamic coding works on the basis of abstractions and its proud to be the father and mother of OOP. OOP is an abstraction based , dynamic coding workflow that dominates dynamic language and even modern statically compiled languages. *Pros:* 1) Code can change on the fly making coding much easier and beginner friendly 2) No need to plan ahead 3) more dynamic workflow also when debugging code that allows to interact and communicate with code real time *Cons:* 1) Performance is sacrificed, thats not obvious for code that executes at once but for code that repeats thousands to millions of times the slow downs depending on the implementation of the language can be anywhere between 10s of times to 1000s of times slower that a static language 2) Using the wrong data / object will not be easily reported beforehand and at times it can be hard to detect such problems. Other bugs can also be hard to be detected even under the use of helping tools that examine and evaluate code because of the generic nature of the code. *Hybrid Programming* Even though static languages give us static programming outside the box and dynamic languages give us dynamic programming outside the box, modern implementation allow for repetitively easily to mix these two workflows. Its also possible for the coder to implement his/her own features with a language. For example C language does not support OOP outside the box, but OOP implementations for C do exist most popular being GObjects used by the GTK+ library C++ and Java although statically typed languages support also more dynamic types through the use of templates and generics Dynamic languages also can come with a variety of tools that perform checks during runtime or even compile time. Also test driven development is very popular for performing this task allowing the coder to create code , launch with a single command thousands of tests and make sure his code passes even more strict guidelines than an average compiler for a statically compiled language. The catch however is that in both cases there are compromises, sub standard implementations and plain weird behavior. *Summary:* *There is no right and wrong, whether we talk about types or other features whether you will follow the dynamic school or the static school is up to you and you preferences.* Both approaches have pros and cons and both will make you waste time while coding. The future however looks more bright and promising for the dynamic school with the rise of AI. Compilers and developer tools in the future may be smarter not only detecting errors and common bugs but actually analyzing coder intentions and even coding philosophies. AI is already used for code analysis but its still on early stage but is none the less our very close future. Funny irony: The most popular scenario for future technology is quantum computing. Hardware by nature is "static" , you have to design it before hand and make sure it works almost perfectly before selling it. This is reflected to the basis of digital architecture where the smaller unit is bit which is always a number and always either 1 or 0. But with quantum computing the bit can inherit quantum properties and be both 1 and 0 at the same time. This will allow in the future for more flexible design of "dynamic" hardware allowing for hardware to also deal with abstractions directly.

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by jtuchel＠objektfabrik.de

Marc, you should definitely go and understand method lookup and handling of unknown messages. This is the fun part of Smalltalk ;-) Just don't overuse it, because you can do things that are so cool you won't be able to understand your own code any more ;-) Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 31, 2017

Re: [Pharo-users] New chapter for new book

by Marc Hanisch

Wow, thats amazing! Thank you Stephane! 2017-03-31 15:51 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > I attached a new chapter for my forthcoming book. > > Stef > >

March 31, 2017

Re: [Pharo-users] type checking in Smalltalk

by Marc Hanisch

Thanks for that many responses! :-) I think I get the picture! In JavaScript I do that type checking because although I get an error, when requesting a method that is not defined, I do not get one when requesting or setting a property that does not exists. Much more worse in PHP before version 7.0 I get an error, which can not be handled by try / except - but not an exception object. Great to know that I can keep the code clean in Smalltalk as I get an exception every time I try to send a message that is unknow to the receiver! Best regards, Marc 2017-03-31 12:31 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > In other words: don't ask - tell. > Instead of writing something like: > > object isSomething ifTrue: [ object doSomething ] ifFalse: [ object > doSomethingElse ] > > just write it: > object doSomething > > that gives you much less code bloat, and much clear view of your intent(s) > and even in case of exception , you can always interpret DNU as "object > are missing feature, you asked for", which is again, reveals your intent. > > Also things like: > > object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ > self doSomethingElseWith: object ] > > in general considered as anti-pattern, because you basically implementing > polymorphic behavior in wrong place i.e. in code that using object, instead > of code that belongs to the object itself. > > > On 31 March 2017 at 03:05, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> > On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: >> >> >> >> Reading this, I realized, that I never saw such type-checking in >> >> Pharo production code. So the question is, what are recommended >> >> design principles for that problem in Smalltalk? Do you use what is >> >> called duck typing? >> > >> > >> > Normally I'm not interested in what an object is, but what it can do. >> > So a test on #respondsTo: can tell me if the object knows how to do >> > something. >> > >> > In smalltalk, I can add methods to existing classes, so there are a lot >> of >> > extension methods on Object isXYZ, returning false. Morph returns true >> to >> > isMorph, so all subclasses of Morph can be recognized that way. >> >> Many people also technically frown on isXYZ is a similar way to isKindOf:, >> but it is a lesser evil and pragmatically is used reasonably often. >> >> > >> > Instead of adding a test method, there are also empty implementations >> >> Like this, what you can do is refactor that guarded code into a method >> #myAction >> and add Object>>myAction which throws the exception. >> Thus you condense multiple condition statements into >> one location and your application code becomes much cleaner. >> >> Object may end up loaded with a lot of methods not of interest to every >> object, >> but the trade-off of cleaner application code is generally worth it. >> >> btw, Here you start to see how using Pharo/Smalltalk "changes the way you >> think about programming". >> >> Further, the exception thrown by Object>>myAction >> should signal the error on a custom error object, similar to ZeroDivide >> for example. >> >> >> > or ones that return self or an appropriate null-value. >> >> Within your framework where you control all the objects >> the Null-object pattern is probably the cleanest OO approach, >> but it can't control what the user passes across the public API. >> https://en.wikipedia.org/wiki/Null_Object_pattern >> >> btw, you can search null-object pattern in Spotter using " Null #c " >> >> >> cheers -ben >> >> > > > -- > Best regards, > Igor Stasenko. >

March 31, 2017