What I tried to say here was that it was a mistake to blame the language
itself for code design. Sure a language may have some ugly sides to it, it
may even make it not so easy to create clean code but in the end of the day
clean and readable code is up to the coder at least 90% .
I would not say that there are subtle differences between Python and Java ,
Ruby and Scala just by themselves. The differences are quite big actually.
My point was that good design is something that many if not most languages
promote. Why ? Because nobody likes ugly code. Actually most java
developers hate long names for methods, there is even a quora question on
the subject that many Java coders express their frustration on the subject.
For example your naming issues is pretty much the foundation of design of
Python's Standard Library , one of the most respected included libraries in
the programming world.
This is the zen of python :
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
As you can see obviously from this Zen , long names and monolithic
approaches are out of the door.
So if you think that python would motivate you to use long names for
methods , then you are easily mistaken and you better ask some python
coders what they think a "pythonic" code really looks like. You will
be suprized how much common ground you will find with Pharo people. I
am willing to bet Ruby folks will be even more inclined to follow
smalltalk values since their language was largely based on smalltalk.
Ignacio, I think its a great idea to have a Zen as a community. In the
python world its started as a joke, then it was viewed as a serious
joke, currently is viewed as something so serious, that if a library
does not follow it its regarded as "unpythonic" and believe me no
python coder wants his code to be called unpythonic. So even though
the zen is not very specific I think it clearly shows the direction of
what python community considers as good code.
Should Pharo have something similar ? its certainly should have. I
think its important to have values, to aspire to create better
designed code, to not repeat the mistakes of the past or mistakes of
others, to pass knowledge and experience around.
The trend for modern coding is to move closer to this area, smaller
libraries are in favor instead of large libs, documentation plays a
much more important role, OO mixed with other paradigms like
functional programming etc gives even more freedom of choice, the rule
of least surprise is followed more and more. Where some see smalltalk
as a dead or niche language, I see it being used everywhere and by
everyone to lesser or bigger degree. This is is our future.
On Wed, Nov 13, 2013 at 5:29 PM, Bahman Movaqar <bah...@bahmanm.com> wrote:
> Kilon, I believe there's a subtle difference between Python, Java, Ruby
> and Scala on one side and Smalltalk on the other:
> All those 4 languages are more or less implemented as OO languages with
> the famous statement "everything is an object". However they are
> syntactically and semantically designed in a way that they allow a not OO
> design to be coded. Just imagine the small problem I shared in this
> thread; in any of those languages I can do it with one class and a couple
> of static methods and the code will definitely *read and work naturally
> correct*.
>
> On the other hand, consider Smalltalk: "everything is an object", but the
> syntax and semantics of the language is different. Yes, it allows a not OO
> design to be coded but there's a difference: think about my small problem
> again. The moment I thought about coding it the old style (single class
> with static methods) something started to smell. It smelled so bad that I
> had to consult you folks.
>
> That's what I'm talking about: a tiny but subtle and well thought out
> difference in the syntax and semantics and it makes a huge difference.
>
> Another example:
> I -like all of you- had studied, heard, read and practiced bottom-to-top
> design and I thought I knew what it meant. However, the moment I started
> coding in Lisp I found out I knew little about that paradigm. The natural
> subtle semantic design of Lisp made it a natural bottom-to-top platform
> nothing like any other platform I had seen until then.
>
>
>
> On 11/13/2013 18:27, kilon alios wrote:
>
> I dont know exactly what you mean by eforced OOP by design. Pharo design
> principles are not written in stone, just good habits people picked along
> the way and they are to be found in python as well. Python actually takes
> OO very deply , sure if , else, while are language constructs but rest
> assured that everything else is an object. For example unlike Pharo ,
> python allows to do procedural programming , but python functions are
> objects in disguise . You could say that python functions work similarly
> (but not the same , since closures are not supported in python) to Pharo
> blocks.
>
> Ruby is even closer to Pharo, supporting blocks, message passing etc.
> Also those kind of languages take clean design in code, very seriously.
> Just go to python interpreter console and do "import this" and you will see
> the zen of python unfold before your eyes emphasizing the good design
> principles you will find many smalltalkers talking about. Another language
> taking these principles very seriously is Lisp, actually Smalltalk took a
> lot from lisp in terms of overall design and direction.
>
> Of course clean code in the end is a choice , there is no enforcement,
> you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There
> is no capital punishment for coders that don't follow these principles.
> Many coders care only for getting the job done and feel like they dont have
> time to worry about how clean their code is. Its a free world, or so we
> hope.
>
> On the other hand everything should be put into context and never taken
> as the Holy Bible or Holy Grail.
>
>
> On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <bah...@bahmanm.com>wrote:
>
>> @Sven
>> > There is not necessarily a right and a wrong way. Design is hard to
>> > explain, I am not going to try. Sorry ;-)
>>
>> Of course! I was just trying to find out the design *norm* for a small
>> problem; to become familiar with the popular way of thought among
>> Smalltalk'ers.
>>
>> @kilon
>> Thanks. I think that may be what I need: real world examples.
>>
>> As I have already admitted, I am not used to Smalltalk way of thinking.
>> This is the first language I know, that enforces OOP by design, none of
>> Java, Python, C++ or Scala does. It's ironic; OOP concepts and
>> techniques were among the first things I was taught back in University
>> but now the more I think about Smalltalk's syntax and design, the more I
>> get closer to the conclusion that I didn't use pure OOP many times
>> during my career. And, I believe, it was simply because the development
>> platforms never enforced it the way Smalltalk does: in a clever and
>> camouflaged way.
>>
>> > But please do have a look at the Chronos library, it even has a
>> PersianCalender, among many others.
>>
>> I knew about Chronos. Someone here, kindly suggested it about 6 months
>> ago when I asked about such a thing. I'm not trying to re-write
>> something like Chronos rather I'm trying to get my hands dirty with
>> Pharo and also re-visit my OOP skills. Thanks.
>>
>>
> --
> Bahman Movaqar (http://BahmanM.com)
>
> ERP Evaluation, Implementation & Deployment Consultant
> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
>
>
