Smalltalk › Pharo › Pharo Smalltalk Users

type checking in Smalltalk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Pharo Smalltalk Users mailing list

type checking in Smalltalk

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 ;-)

In Pharo By Example 5, Page 308, in the Chapter "Introspection", it is written:

"Although these features (type inspection) are especially useful for imple-

menting development tools, they are normally not appropriate for typical

applications. Asking an object for its class, or querying it to discover which

messages it understands, are typical signs of design problems, since they

violate the principle of encapsulation."

It is advised not to use the message isKindOf: in applications.

I do understand that it is not a good idea to do different operations depending on the kind of an object in one method. But in my (Javascript) production code I do a lot of checking if an argument to a function is "instanceof" someObject. When it is not the expected type of object, an exception is thrown. I do this to ensure that someone (=another developer) does not by accident passes a wrong type into my method.

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?

Thanks for any advice :-)

Marc

Stephan Eggermont-3

Re: type checking in Smalltalk

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.

Instead of adding a test method, there are also empty implementations
or ones that return self or an appropriate null-value.

Stephan

abergel

Re: type checking in Smalltalk

In reply to this post by Pharo Smalltalk Users mailing list

Hi Marc,

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?

I have carefully studied the topic of type checking in the past. I came to the conclusion that type errors are too easy to fix to justify a support in the language. There are always exceptions, for example, if you wish to provide guaranties and proof on some aspect of the language, interesting to hardware driver developers and critical software developers. In that case, you may want to have type annotation, maybe.

But all in all, static type checking is more a distraction than a real benefit for practitioners in my opinion.

Cheers,

Alexandre

Denis Kudriashov

Re: type checking in Smalltalk

In reply to this post by Pharo Smalltalk Users mailing list

2017-03-30 16:03 GMT+02:00 Marc Hanisch via Pharo-users <[hidden email]>:

It is advised not to use the message isKindOf: in applications.

I do understand that it is not a good idea to do different operations depending on the kind of an object in one method. But in my (Javascript) production code I do a lot of checking if an argument to a function is "instanceof" someObject. When it is not the expected type of object, an exception is thrown. I do this to ensure that someone (=another developer) does not by accident passes a wrong type into my method.

Reading this, I realized, that I never saw such type-checking in Pharo production code.

In Pharo you will got DNU error automatically when object will receive message which it does not understands. Then Pharo will show debugger to investigate and fix the problem.

This is called dynamic typing and I guess JS will do something similar. So I wonder why you need custom error when program breaks types.

Ben Coman

Re: type checking in Smalltalk

In reply to this post by Stephan Eggermont-3

On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <[hidden email]> 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

Igor Stasenko

Re: type checking in Smalltalk

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 <[hidden email]> wrote:

On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <[hidden email]> 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.

Pharo Smalltalk Users mailing list

Re: type checking in Smalltalk

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 <[hidden email]>:

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 <[hidden email]> wrote:

On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <[hidden email]> 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.

jtuchel

Re: type checking in Smalltalk

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:[hidden email]
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

kilon.alios

Re: type checking in Smalltalk

In reply to this post by Pharo Smalltalk Users mailing list

On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users <[hidden email]> 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.

Sven Van Caekenberghe-2

Re: type checking in Smalltalk

if you copy/paste something you should give a reference

> On 31 Mar 2017, at 16:40, Dimitris Chloupis <[hidden email]> wrote:
>
>
>
> On Thu, Mar 30, 2017 at 5:04 PM Marc Hanisch via Pharo-users <[hidden email]> 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.
>
>
>

kilon.alios

Re: type checking in Smalltalk

On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <[hidden email]> wrote:

if you copy/paste something you should give a reference

I did not copy paste anything, 100 % mine. What part you think it's copy ?

Sven Van Caekenberghe-2

Re: type checking in Smalltalk

> On 31 Mar 2017, at 19:38, Dimitris Chloupis <[hidden email]> wrote:
>
>
> On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <[hidden email]> wrote:
> if you copy/paste something you should give a reference
>
>
> I did not copy paste anything, 100 % mine. What part you think it's copy ?

Ah, sorry then, the formatting seemed to suggest it came from somewhere else.

BTW, I don't think the hybrid part is a real thing.

Although I understand that static typed languages like C, C++, Java and so many others have their place and use, people in those languages spend an awful amount of time and code dealing with the types they love so much. The modern static languages with all their magic are even worse. And even in a nice static typed program that compiles with no warnings, there are still dynamic errors lurking everywhere. The world cannot be defined in a static way.

The dynamic type errors that you get in Pharo during development are 95% plain logic errors, once you fix those and write some unit tests, a Pharo program is just as stable and reliable as anything else that is well written, tested and debugged.

And I love Igor's "Don't ask, tell" idea - right on target.

Anyway, that is my personal opinion, I don't want to convince you.

Sven

kilon.alios

Re: type checking in Smalltalk

Hehe yeah I love nice formatting :)

You don't need to convince me , I prefer coding dynamically

Ironically enough is the static that is not a real thing anymore. I am coding C++ and Unreal uses templates for pretty much everything. Templates the equivalent of dynamic types, kinda.

However when performance is concerned anything dynamic must go, which in C++ means templates and smart pointers. One for dynamic types and the other for dynamic memory management.

Generally however templates and generics are super popular and coders are frowned upon if they do not use them because falling back to pure static coding is considered bad coding practice.

C++ is on route of becoming even more hybrid, the new hot potato being modules a replacement to header files , similar to Python modules. It was to be included in the next iteration of C++ but was postponed. Probably will get included in the one after the next. In Python a module is a source code file that is treated as an object. So a global variable is equivalent to class variable, the source file being the class. If the module is a package (file folder) then it's class variables are the sub modules.

Nowadays people use static languages not because they want to but because the have to for legacy code and performance reasons.

Still modern projects usually mix dynamic with static languages. The static plays the role of the kernel providing high performance the dynamic the role of easy to use , beginner friendly, scripting interface.

Java and C# support out of the box any dynamic language out there. So the lines nowadays are extremely blurry.

It's 2017 , great time to live in when you can choose among so many choices.

On Fri, 31 Mar 2017 at 21:35, Sven Van Caekenberghe <[hidden email]> wrote:

> On 31 Mar 2017, at 19:38, Dimitris Chloupis <[hidden email]> wrote:
>
>
> On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <[hidden email]> wrote:
> if you copy/paste something you should give a reference
>
>
> I did not copy paste anything, 100 % mine. What part you think it's copy ?

Ah, sorry then, the formatting seemed to suggest it came from somewhere else.

BTW, I don't think the hybrid part is a real thing.

Although I understand that static typed languages like C, C++, Java and so many others have their place and use, people in those languages spend an awful amount of time and code dealing with the types they love so much. The modern static languages with all their magic are even worse. And even in a nice static typed program that compiles with no warnings, there are still dynamic errors lurking everywhere. The world cannot be defined in a static way.

The dynamic type errors that you get in Pharo during development are 95% plain logic errors, once you fix those and write some unit tests, a Pharo program is just as stable and reliable as anything else that is well written, tested and debugged.

And I love Igor's "Don't ask, tell" idea - right on target.

Anyway, that is my personal opinion, I don't want to convince you.

Sven

Ben Coman

Re: type checking in Smalltalk

In reply to this post by Sven Van Caekenberghe-2

On Sat, Apr 1, 2017 at 2:34 AM, Sven Van Caekenberghe <[hidden email]> wrote:

> On 31 Mar 2017, at 19:38, Dimitris Chloupis <[hidden email]> wrote:
>
>
> On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <[hidden email]> wrote:
> if you copy/paste something you should give a reference
>
>
> I did not copy paste anything, 100 % mine. What part you think it's copy ?

Ah, sorry then, the formatting seemed to suggest it came from somewhere else.

BTW, I don't think the hybrid part is a real thing.

Although I understand that static typed languages like C, C++, Java and so many others have their place and use, people in those languages spend an awful amount of time and code dealing with the types they love so much. The modern static languages with all their magic are even worse. And even in a nice static typed program that compiles with no warnings, there are still dynamic errors lurking everywhere. The world cannot be defined in a static way.

The dynamic type errors that you get in Pharo during development are 95% plain logic errors, once you fix those and write some unit tests, a Pharo program is just as stable and reliable as anything else that is well written, tested and debugged.

And I love Igor's "Don't ask, tell" idea - right on target.

This would make a good name for a book on OO.

cheers -ben

Anyway, that is my personal opinion, I don't want to convince you.

Sven

Igor Stasenko

Re: type checking in Smalltalk

In reply to this post by Sven Van Caekenberghe-2

On 31 March 2017 at 21:34, Sven Van Caekenberghe <[hidden email]> wrote:

> On 31 Mar 2017, at 19:38, Dimitris Chloupis <[hidden email]> wrote:
>
>
> On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <[hidden email]> wrote:
> if you copy/paste something you should give a reference
>
>
> I did not copy paste anything, 100 % mine. What part you think it's copy ?

Ah, sorry then, the formatting seemed to suggest it came from somewhere else.

BTW, I don't think the hybrid part is a real thing.

Although I understand that static typed languages like C, C++, Java and so many others have their place and use, people in those languages spend an awful amount of time and code dealing with the types they love so much. The modern static languages with all their magic are even worse. And even in a nice static typed program that compiles with no warnings, there are still dynamic errors lurking everywhere. The world cannot be defined in a static way.

The dynamic type errors that you get in Pharo during development are 95% plain logic errors, once you fix those and write some unit tests, a Pharo program is just as stable and reliable as anything else that is well written, tested and debugged.

And I love Igor's "Don't ask, tell" idea - right on target.

Hey, hey.. These words, originally, definitely are not mine.. It is something i learned, being among wise people of smalltalk family.

Anyway, that is my personal opinion, I don't want to convince you.

Sven

Best regards,
Igor Stasenko.