I am thinking to rewriting nim programming language. I want to make it Just like python and follow following zen principals:
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.[a]
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!
Heres some weird stuff I found porting code from Python 3.8 to Nim 1.4 https://dev.to/juancarlospaco/exotic-features-of-python3-1492
Maybe is useful to someone, the Nim behavior makes sense.
Explicit is better than implicit.
vs
There should be one—and preferably only one—obvious way to do it.
contradict each other. If you make things explicit, you specify things and you have a choice. Otherwise, these specifications would be redundant (boiler-plate). then, Your choice of specification => your choice of implementation. (Typically, you want and specify for speed). Python doesn't offer this. Python is designed as a scripting language. The flexibility of python relies on its runtime. Nim is extremely dynamic at compiletime (therefore "dynamic" or the dynamic feeling of the language) , but extremely static at runtime (machine code). To achieve this and to have them both, Nim provides clever runtime elision ("move semantics") and carefully selected (limited) type inference. The distinction runtime vs. compiletime is crucial for Nim. Python is the exact opposite. Therefore, if you want to make Nim more "pythonic", you'll end with a worse Nim (and a worse Python).
It would be interesting to redefine Python as a prototyped-base language though. Prototypes (with type parameters) would reflect compiletime, objects the runtime (with vtable-like lookup of methods in the prototype). JIT could be added. Something like Node.js for javascript.
It's also true that python has no case statement (yet), but seriously, tell me a single real-world situation where a case statement is so much better than ifs to make such a feature fundemental.
It's crucial for writing a compiler IMHO. Of course, full featured pattern matching might be even better.
The "lack of type safety" is not a flaw, the type system has been specifically designed this way, welcome into the world of dynamic languages (the same goes for stateful default parameters).
Well I did use enough Python and other dynamic languages to know it's a design mistake.
Have you ever looked at a truly badly designed language such as PHP or JS?
Yes I did, and right now I don't remember good reasons for why PHP or JS are designed worse than Python.
A last PS, the Zen of Python applies to more than one language for sure, but it has been indeed thought and written for Python.
"Explicit is better than implicit" is in direct violation of Python's dynamic typing. And also in violation of Python's rule that "assignment is declaration". The rest of the Zen is mostly blathering and to the extend that it can be seen as actionable design goals, also doesn't fit Python.
If you could elaborate on what you "know it's a design mistake" that would at least open a discussion rather than just saying "python bad!!".
Dynamic typing is a design mistake -- but even assuming it's not -- it's so heavily in violation of "explicit is better than implicit" that I think we can end the discussion right here. At least neither JS nor PHP bother with such a schizophrenic "Zen".
do we have to remember that they added a === operator in order to maintain backwards compatibility with the broken behavior of ==?
Python has == and is and 3 < "abc" is true.
PHP's general inconsistency for the naming scheme of its stdlib
That's a library design problem, not a language design problem. Besides, Python violates its own naming scheme too, isupper instead of is_upper etc.
Why is "The Zen of Python" taken so seriously?
Maybe read it in context "The Python Way" @ https://mail.python.org/pipermail/python-list/1999-June/thread.html#1951
Nice! Two remarks:
This one
(Leverage meta programming to keep the language small.)
could use some explanation (why the parens?) and
this one
There should be one and only one programming language for everything. That language is Nim.
some understatement.
I don't like these Zen Statements. They miss the bigger picture.
Like hammer and chisel for sculptures. The end goal is the Sculpture.
These statements say a lot about how to polish the hammer handle, or geometry of hammer head. And none about the sculptures or how this hammer could help to create better sculptures.
Now let's review these statements from the sculpture point of view:
Ok making hammer by copying bad hammer design is not good. How it's relevant to sclulpture?
How it's relevant to sculpture?
Ok, make sense, hammer shouldn't get into the way.
Somehow remotely related to building better programs by making it faster. But would be better to state it explicitly.
Somehow remotely related to building better programs by making it require less resources. But would be better to state it explicitly.
Ok.
Somehow remotely related to making language easier to use and extend. Although this statement is in conflict with Nim, as Nim is nether small nor simple.
Ok. Although at this point it's heavy biased, this is third statements related to program speed. And there were nothing mentioned about other aspects of program (like developer productivity or reliability of the program / server etc.)
There should be one and only one hammer for everything, well, ok. Although it's in conflict with the Optimization is specialization. Using same algorithm for everything is suboptimal, but using same language for everything is optimal? Look strange and dubious.
Copying bad design is not good design.
Ok making hammer by copying bad hammer design is not good. Seems like a some minor point that should not go as the first statement.
If the compiler cannot reason about the code, neither can the programmer.
In JS or Ruby there's no compiler at all, yet programmers are able to reason about the code.
compiler/interpreter/transpiler tomato/tomato. the point, i believe, is about when it's justified for the <box that turns words into electrons> to impose it's own limitations on a programmer's intent, and is an argument for a strong type system.
There should be one and only one programming language for everything. That language is Nim.
There should be one and only one hammer for everything...
yes, well, maybe the metaphor breaks down here. but if i had a meta-programmable hammer, able to adjust its own size, shape, and mass on command, I'd absolutely only use one.
Similarly pythonicity is assumed uninterrogatedly to be synonymous with ergonomicity
Just a side note... I didn't meant to promote Python. I don't like Python and its practices. Inconsistent names shortcuts, inconsistent function calling fn(obj), obj.fin(), np.fn(obj) etc.
but if i had a meta-programmable hammer
"If" - and it's quite a big "if", right now we don't have such "meta-programmable hammer".