Live data from Hacker News

Imperative vs. Declarative

latentflip.com

51–53 of 53 posts

Re: Imperative vs. Declarative

#51

I really like SQL. Sure, the language has warts but the ability to concisely represent WHAT you want, not HOW you want it, makes it very readable once you understand the simple constructs and how to properly design tables and indexes (not very hard). For example, consider the problem of finding the second largest value in a set. In SQL, I'd do something like: SELECT MAX( col ) FROM table WHERE col It's pretty readabl…

FWIW here's a very similar Python version: max(col for col in table if col a fun one is this: first, second = max(permutations(table), 2) although its semantics are slightly different (if the maximum of the table is duplicated, it'll be returned for both slots) or using heapq which notaddicted mentioned.

I think the similitude is deceptive. Since declarative programming is side-effect free, the runtime can perform the operation in the most efficient way it knows. Python isn't, so it has to ensure some execution order that breaks possible optimizations.

In your example, if you replace max() with a function that prints something, you'll see it's executed for each value in 'table', which is extremely inefficient. This happens because Python can't guarantee that max() will return the same each time.

Similarly, while in a side-effect free context the runtime could, for example, slice 'table', perform the work using multiple concurrent threads and then join the result, Python has to guarantee that the execution is done sequentially, since a change in order could affect the result.

Unlike in SQL, in Python you're always telling it HOW you want it done.

Re: Imperative vs. Declarative

#52

Earlier quoted context omitted.

FWIW here's a very similar Python version: max(col for col in table if col a fun one is this: first, second = max(permutations(table), 2) although its semantics are slightly different (if the maximum of the table is duplicated, it'll be returned for both slots) or using heapq which notaddicted mentioned.

I think the similitude is deceptive. Since declarative programming is side-effect free, the runtime can perform the operation in the most efficient way it knows. Python isn't, so it has to ensure some execution order that breaks possible optimizations. In your example, if you replace max() with a function that prints something, you'll see it's executed for each value in 'table' , which is extremely inefficient. This…

> I think the similitude is deceptive.

It's not.

> Since declarative programming is side-effect free, the runtime can perform the operation in the most efficient way it knows.

The point of declarative programming is to declare what you want done. The runtime may turn it into greatness or crap, that's not really relevant.

> In your example, if you replace max() with a function that prints something, you'll see it's executed for each value in 'table', which is extremely inefficient.

It's also not relevant and an implementation detail, with a known max() on a known type the implementation would be free to lift the computation out since this expression doesn't have side-effects. Just as a crappy SQL DB would be free to run the subquery once for each result.

> This happens because Python can't guarantee that max() will return the same each time.

The runtime can know that all types and functions involved are their native side-effect-less versions and is free to optimize them if it wishes, that it does not is irrelevant.

> Unlike in SQL, in Python you're always telling it HOW you want it done.

Nope, sorry, you're wrong.

Re: Imperative vs. Declarative

#53

Earlier quoted context omitted.

I think the similitude is deceptive. Since declarative programming is side-effect free, the runtime can perform the operation in the most efficient way it knows. Python isn't, so it has to ensure some execution order that breaks possible optimizations. In your example, if you replace max() with a function that prints something, you'll see it's executed for each value in 'table' , which is extremely inefficient. This…

> I think the similitude is deceptive. It's not. > Since declarative programming is side-effect free, the runtime can perform the operation in the most efficient way it knows. The point of declarative programming is to declare what you want done. The runtime may turn it into greatness or crap, that's not really relevant. > In your example, if you replace max() with a function that prints something, you'll see it's ex…

> The point of declarative programming is to declare what you want done. The runtime may turn it into greatness or crap, that's not really relevant.

I didn't say the quality of the runtime was relevant. The point is that the runtime is free to achieve the goal you give it in any way it feels fit. In Python, the runtime isn't; it needs to ensure specific runtime guarantees.

>> In your example, if you replace max() with a function that prints something, you'll see it's executed for each value in 'table', which is extremely inefficient.

> It's also not relevant and an implementation detail, with a known max() on a known type the implementation would be free to lift the computation out since this expression doesn't have side-effects.

No, it can't. The Python reference specifies the semantics of generator expressions, and it says "Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run"[1].

A implementation that lifted the computation would not be implementing Python, but a derivative language.

Furthermore, your example didn't specify neither the type of neither 'table' nor 'max', so I still think it's deceptive.

> The runtime can know that all types and functions involved are their native side-effect-less versions and is free to optimize them if it wishes, that it does not is irrelevant.

See above. According to the language spec, it can't.

[1]: http://www.python.org/dev/peps/pep-0289/#the-details

Post reply on HN