5 ms·
I think "one way to do it" Java and Python philosophy is overrated. Sure, when it's presented that way, it sounds great! Why wouldn't we want one way to do thin
by tikhonj 14y ago
I think "one way to do it" Java and Python philosophy is overrated. Sure, when it's presented that way, it sounds great! Why wouldn't we want one way to do things?
I like to think about it differently: instead of trying to coerce my problem to fit the language, I want to mold my language to fit the problem. It's easier to think about the problem in its own terms--the terms of its domain--than in those terms filtered through a "one-size-fits-all" language design.
I want code that is declarative and closely reflects its underlying logic. And this means there will be more than one way to do things--while many problems are similar mechanically, their actual meaning is vastly different.
So there really is a benefit to having more than one way to do things: you can choose a way that's appropriate for the problem you're solving. Of course, this puts a bit of trust into programmers to have good taste: while it allows you to write far better code than a one-size-fits-all language, it also allows you to write far worse code. I personally think this is a worthy compromise.
Another interesting thing I've found is that having more than one way to do things naturally emerges when you have a distinct set of powerful primitives. This is most evident in math: for any given problem, there are often a ton of different ways to arrive at the same solution. Each of these ways emerges naturally from the fundamental building blocks of math.
Coincidentally, these different ways of looking at the same thing are not only natural but actively useful: they give you different perspectives on the same idea. An example I recently encountered was with lattices. There are two different ways to define a lattice--one in terms of partial orders and one in terms of algebras. The former gives you an intuition on the structure of a lattice; in a sense, it tells you what a lattice "looks like". The latter makes it easy to see relationships between lattices and other algebraic structures: for example, Boolean algebras are just a special kind of lattice. You can then even combine the two and start thinking about Boolean algebras in terms of orders.
So to me, having multiple different but equivalent ways to do things is both useful and natural, especially if these different ways emerge naturally. I much prefer this approach to something more prescriptive and monolithic, where the language designer has tried to guess exactly what and how I will be doing and explicitly provided a way to do it.
- tubbo 14y ago> I like to think about it differently: instead of trying to coerce my problem to fit the language, I want to mold my language to fit my problem. THIS is why I like Ruby so damn much! Typically, "one way to do things" breaks down when you need to be expressive about the conceptual nature of your program. Python is too rigid for me, it expects that all of my problems can be written in a mathematical and structured way. And realistically, that's just not how I think.
- fleitz 14y agoSure there are corner cases such as lattices where having more than one way of expressing a problem is beneficial, I think what the op is getting at are things like: if/else vs. the ternary operator in C. Blocks/Procs/Lambdas in Ruby. etc. The concepts are so close that the language might as well pick one way of doing it and just do that. I don't need 18 kinds of for/for-in/while/do/do/while loops each broken in it's own way, I need one that works. For myself in the above cases I'd make if/else an expression, and get rid of blocks/procs. Most of what is in today's languages shouldn't be spec'd as part of the language, but rather provided by the standard library. What is the point of async/await in C# but not monads? It does not empower programmers, it subjugates them to the will of Anders, these tasks are blessed, these are not.
- charliesome 14y agoEven if you made if/else an expression, the ternary is still useful for brevity. Compare: foo(a ? b : c) Versus: foo(if a then b else c end) Which do you think reads more clearly?
- ori_b 14y agoThe slightly less terse: if(a) foo(b) else foo(c)
- qu4z-2 14y agoMy only complaint with that version is that foo() is repeated now. It's not clear at a glance that you're definitely calling foo, and only deciding which argument to pass. (Well, in this simple case it's quite obvious, but...)
- zackelan 14y agoIf that's really a concern: if (a): arg = b else: arg = c foo(arg) In my experience, trying to optimize for brevity at the expense of clarity is almost always a bad idea.
- yen223 14y agoThat's Perl's philosophy isn't it -- there is always more than one way to do it. Of course, that's one of the reasons why Perl has notoriously poor readability.
- slurry 14y agoDistant second or third behind the sigils and other non-alphanumeric/non-punctuation characters.
- Sandman 14y agoWhile I agree with you that there should be more than one way to solve a problem (although I wouldn't say Java's philosophy is against that), when it comes to actually writing code, I want to have one clear and understandable way in which something should be written. That is to say, I prefer it when a language has strong opinions on what the code should look like. This is in stark contrast with, for example, Scala's philosophy. Scala is a language that tries to be everything for everybody and its syntax reflects that. There are a lot of situations where you can write the same thing in two or more different ways. Can it reduce verbosity? Sure, but it also ads complexity. In the end you get code that can be a real hodgepodge of different styles , depending on how many developers work on it, and can look really messy. Conventions can help that, but aren't conventions really only here to make up for a lack of proper syntax rules? This is why I prefer that a language has minimal syntax with clear rules and really, preferably, only one way to write something.
- driax 14y agoPython's philosophy is often said to be: "There should be one - and preferably only one - obvious way to do it." Which is not exactly the same as "one way to do it". There can be many ways to do it, if they are obvious from perspectives, just don't add to many since it will cloud the scene, and the programmer won't know which to use. It's all about having different developers come to the same simple solution when confronted by the same type of problem. But I agree with everything you said. Some times only having one way becomes a burden. Many times precisely because it's not the most obvious way in the specific situation.