hi,
saw this on twitter today:
http://guide.python-distribute.org/introduction.html#current-state-of-packaging
where he was making a point that "it sure is complicated for a
language having one way of doing things"
It is good to have multiple options, find the best solution to a
problem by applying common sense and good taste, take feedback/
benchmark and iterate.
Not really sure how the python zen works. Maybe having no choice in
indentation, multi-line lambdas etc are obvious. i dunno. If it comes
with experience and then it is no better than having options and
discovering the best option through experience, irc, mail-group,
benchmarks, awesome community, pretty ok docs and your own common
sense and good taste.
cheers,
deepak
On Nov 29, 2:57 pm, Robert Klemme <***@googlemail.com> wrote:
> On Mon, Nov 29, 2010 at 5:40 AM, Tim Roberts <***@probo.com> wrote:
> > Shadowfirebird <***@gmail.com> wrote:
>
> >>> Ruby: "There is more than one way to do it."
> >>> Python: "There should be one - and preferably only one - obvious way to
> >>> do it."
>
> >>Programming languages -- at least, good programming languages -- shouldn't
> >>try to make programmers into better programmers, or force them to work in
> >>a certain way in order to get results. (Imagine a toolbox that told you
> >>off for using the wrong screwdriver!)
>
> > I believe that's almost 100% wrong. A programming language that doesn't
> > try to make better programmers ends up enabling poor programming practices,
> > which ends up producing poor programs. That results in programs and web
> > sites that crash, which brings on a bad reputation for programmers in
> > general.
>
> > PHP is a great example. It is possible to write good programs in PHP, but
> > it's also very, very easy to write bad programs in PHP. The result is that
> > most of the PHP samples you find on the web are absolute crap -- delicate,
> > unsafe, unmaintainable. The programmers don't realize this, and so the
> > crap reproduces like a virus.
>
> After all those years I am unsure how big the impact of a language is.
> What I'd consider facts (in no particular order):
>
> 1. A programming language can do little to nothing to help you decide
> how you lay out functionality across program code artifacts
> (functions, procedures, methods, classes). But this (along with
> naming of things) has a dramatic impact on readability and
> reusability.
>
> 2. Good libraries which enforce particular usage patterns can do a
> great deal to guide their users to a proper code structure. - But they
> cannot prevent creating a mess if one tries to.
>
> 3. A key factor for writing good code is the person doing the writing.
> People not interested to learn or otherwise improve their work are
> unlikely to write better code. The same holds for people who do not
> have a chance to improve because they are constantly buried under
> loads of work since they lack the time needed for reflection.
>
> 4. Removing obstacles to writing good code (compare for example Ruby's
> OO with Perl's) certainly helps people writing better code.
>
> My 0.02 EUR.
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/