4 ms·

You move the complexity to the system instead of the automaton. An ant is an easily understood organism behaviorally, however, when working in unison according

by fleitz 16y ago

You move the complexity to the system instead of the automaton. An ant is an easily understood organism behaviorally, however, when working in unison according to a very simple set of operating conditions they generate incredibly complex behavior. Most people want to design complex automatons that understand the entire solution space instead of designing simple automatons that interact with other simple automatons to converge on a reasonable approximation of the solution. You can see this in the article itself where the article describes C code as clear. Yes, it's very clear to anyone reading C exactly what assembly instructions will be produced but it's about as clear as mud as to what the code is actually accomplishing. I tend to care more what the code does as opposed to how it does it which is why I prefer functional languages where I have no clue as to what assembly will be produced but have a good idea of what is actually being accomplished. Apparently C supports something called a string but all I ever see is a pointer to a char.

becomevocal 16y ago
"I tend to care more what the code does as opposed to how it does it" Exactly. Lets focus on solving the problems and not letting the solutions become problems themselves.
sbochins 16y ago
Agreed. If a language is more expressive, it becomes simpler. I don't think being low level is the same as being simple. Declarative languages tend to look more like English than C or Assembly does. Looking more like English seems like a pretty powerful indicator of simplicity. It is certainly easier to read.
chipsy 16y ago
The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames. A similar tenet holds for the opposite direction - the performance junkies; the tendency with experience to move away from locking in specs early and doing heavy micro-optimization, towards writing the initial code in a way that tries intentionally to make it easy to modify.
- HelloBeautiful 16y ago
  >> Aim for C-style abstractions in Python. Worst programming advice ever IMHO. As Sir Isaac Newton used to say: "If I have seen further it is only by standing on the shoulders of giants." If you think and program in simple abstractions, you'll be unable to solve complex problems.
  - fleitz 16y ago
    Newton is a great choice to use in the example as he invented calculus which is an incredible abstraction. I tend to look at the lambda calculus in the same way. Yes, calculus is more complex than algebra but once you understand it you can solve much more challenging problems because of the abstraction inherent in the notation.
- paganel 16y ago
  > The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames. Amen to that. I've been programming in Python for 7 years now, but lately I had started to see more and more of my fellow Pythonistas dropping "yields" all over the place, using "generator this / generator that" etc. I thought I was either getting too old or maybe I was not smart enough, because to me Python it's 99% about writing and manipulating nice hash tables (dictionaries, as they are called) and lists (I love those list comprehensions). Again, maybe is just me, I just felt that adding another layer of abstraction would get between me and the data I'm trying to manipulate when I write my programs.
ra 16y ago
It's not about the language. To me, the author is spot on here. It is only through experience that you begin to see all the ways in which complexity can creep into a system, and why each and every one of them is bad. Unfortunately, almost every codebase I work on right now is more complex than it needs to be. To me, the zenith, "The simplest possible solution that does what is needed, but no more", helps a lot.
andrewcooke 16y ago
he's not saying c code is clear; he's saying that using c code can help you avoid complexity because many things you might attempt in another language are simply too expensive. nor is he saying (as someone else said) that you should avoid higher level constructs in other languages. its quite ok to use those, as long as you keep things simple. simplicity does not map 1-to-1 on language features and is hard to explain because it's very context dependent. it's more "YAGNI" than "avoid yield in python". for example, here's an example from Python i noticed just yesterday. i had some code that expanded a particular kind of data and i wanted to let the user do something with the data. so i added a callback - on each step in the expansion i pass the user the relevant chunk of data through the callback. but how do i handle errors? i had a use-case that needed to handle errors, but they didn't fit with the callback. so my first thought was to make the callback an object and have a method to handle exceptions. but that looked complicated. then i realised that i was passing the callback a list of values. if, instead, i passed a generator, then the exceptions, when they occurred, would be raised inside the callback! so by "using yield" i kept things simple.

by fleitz 16y ago

becomevocal 16y ago

"I tend to care more what the code does as opposed to how it does it" Exactly. Lets focus on solving the problems and not letting the solutions become problems themselves.

sbochins 16y ago

Agreed. If a language is more expressive, it becomes simpler. I don't think being low level is the same as being simple. Declarative languages tend to look more like English than C or Assembly does. Looking more like English seems like a pretty powerful indicator of simplicity. It is certainly easier to read.

chipsy 16y ago

The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames. A similar tenet holds for the opposite direction - the performance junkies; the tendency with experience to move away from locking in specs early and doing heavy micro-optimization, towards writing the initial code in a way that tries intentionally to make it easy to modify.

HelloBeautiful 16y ago
>> Aim for C-style abstractions in Python. Worst programming advice ever IMHO. As Sir Isaac Newton used to say: "If I have seen further it is only by standing on the shoulders of giants." If you think and program in simple abstractions, you'll be unable to solve complex problems.
- fleitz 16y ago
  Newton is a great choice to use in the example as he invented calculus which is an incredible abstraction. I tend to look at the lambda calculus in the same way. Yes, calculus is more complex than algebra but once you understand it you can solve much more challenging problems because of the abstraction inherent in the notation.
paganel 16y ago
> The author is not saying "write C in Python," he's saying "Aim for C-style abstractions in Python." i.e. build the codebase around the bread-and-butter: function calls, iteration, reference-passing and mutability, and not around abuse of the numerous higher-level abstractions available(meta-programming, yield, exec()...). It's a lesson learned regularly by programmers as they gain experience and move towards conservativism, after having seen all their silver bullet attempts go up in flames. Amen to that. I've been programming in Python for 7 years now, but lately I had started to see more and more of my fellow Pythonistas dropping "yields" all over the place, using "generator this / generator that" etc. I thought I was either getting too old or maybe I was not smart enough, because to me Python it's 99% about writing and manipulating nice hash tables (dictionaries, as they are called) and lists (I love those list comprehensions). Again, maybe is just me, I just felt that adding another layer of abstraction would get between me and the data I'm trying to manipulate when I write my programs.

ra 16y ago

It's not about the language. To me, the author is spot on here. It is only through experience that you begin to see all the ways in which complexity can creep into a system, and why each and every one of them is bad. Unfortunately, almost every codebase I work on right now is more complex than it needs to be. To me, the zenith, "The simplest possible solution that does what is needed, but no more", helps a lot.

andrewcooke 16y ago

he's not saying c code is clear; he's saying that using c code can help you avoid complexity because many things you might attempt in another language are simply too expensive. nor is he saying (as someone else said) that you should avoid higher level constructs in other languages. its quite ok to use those, as long as you keep things simple. simplicity does not map 1-to-1 on language features and is hard to explain because it's very context dependent. it's more "YAGNI" than "avoid yield in python". for example, here's an example from Python i noticed just yesterday. i had some code that expanded a particular kind of data and i wanted to let the user do something with the data. so i added a callback - on each step in the expansion i pass the user the relevant chunk of data through the callback. but how do i handle errors? i had a use-case that needed to handle errors, but they didn't fit with the callback. so my first thought was to make the callback an object and have a method to handle exceptions. but that looked complicated. then i realised that i was passing the callback a list of values. if, instead, i passed a generator, then the exceptions, when they occurred, would be raised inside the callback! so by "using yield" i kept things simple.