Live data from Hacker News

Imperative vs. Declarative

latentflip.com

21–30 of 53 posts

Re: Imperative vs. Declarative

#21
post #4

Great article, but one thing that's sort of glossed over here, and that I half-disagree with, is this: >But we also get to think and operate at a higher level, up in the clouds of what we want to happen, and not down in the dirty of how it should happen. The author mentions this at the end, but I feel it should be stressed more strongly: The dirty of how is important . The author presents a big "if" here, which is: i…

The fact that map is fast and efficient isn't really its selling point to me, though. It's that it's a simple concept, so I use it when the concept applies, not when I need to worry about efficiency. So it doesn't matter to me how it works, as long as it does what I expect.

Re: Imperative vs. Declarative

#22
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 readable, and can almost be read in plain english: "Get the next biggest value from the table where it's smaller than the biggest value."

How might you do this in Java? http://stackoverflow.com/questions/2615712/finding-the-secon...

But look at all the other ways you can do it in that thread. None of them are very readable. And, they can hide subtle bugs that you won't find just by reviewing the code.

Ruby has a pretty concise example if you happen to know the trick, and that the sort performance isn't miserable (kind of a gotcha question): http://stackoverflow.com/questions/8544429/find-second-large...

This is a very simple example, but as you scale up to more complex problems I almost always find SQL is fewer lines of code, more readable, and far less buggy (SQL tends to either work or not work - I find much more subtle bugs in a 30 line Java algo than a 10 line SQL command).

Re: Imperative vs. Declarative

#23

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…

Aside: Python is similar to Ruby, albeit using the sorted() function rather than the sort() method.

    sorted(vals)[-2]

Re: Imperative vs. Declarative

#24
I don't think the author gets declarative right. It feels like he bolts a cool word onto some things he uses. Call me old fashioned, but I think Prolog is declarative, map() and reduce() are not.

Re: Imperative vs. Declarative

#25

I'm not sure I agree with some of the examples in the article. The examples used paint declarative programming as basically abstractions over details. The problem is that there is no line where an abstraction crosses the boundary into declarative programming. It's not really about abstractions but about control flow. If your code has a specific order it has to run in, then its imperative as you're still describing th…

I agree. I don't recognize the examples here as declarative programming. SQL and Prolog are both examples of declarative programming, so is Make to an extent. Using a map function doesn't make JavaScript a declarative programming language - it's a functional programming concept, not a declarative one.

it's a functional programming concept

That doesn't keep it from being a declarative thing.

Re: Imperative vs. Declarative

#26
post #9
post #6

Prolog is declarative programming take to the maximum (excluding things like Answer Set Programming/clingo etc). In Prolog you ask questions. For example: subset([1,2],[2]). then it goes away and says "yes". Or you want to know if any subsets exist: subset([1,2],B). B = [] B = [1] B = [2] This makes it really really nice for some surprising tasks (Windows NT used to ship with a prolog interpreter for setting up the n…

Or to take his doubling example... double([], []). double(H | T, H2 | T2) :- H2 is H * 2, double(T, T2).

That's a lower-level version of map in a language with destructuring: Haskell would let you say

    double numbers = map (\x -> x * 2) numbers
or

    double [] = []
    double (x:xs) = x * 2 : double xs
or

    double = map (*2)
I don't think #2 is more declarative than #1, let alone #3. Then again, I don't think any of these versions is very declarative.

Declarative would be numpy:

    doubled = numbers * 2

Re: Imperative vs. Declarative

#27

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.

Re: Imperative vs. Declarative

#28

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…

Aside: Python is similar to Ruby, albeit using the sorted() function rather than the sort() method. sorted(vals)[-2]

Also available in python:

  import heapq
  n = 2 
  heapq.nlargest(n, vals)[n-1]
Edit: and out of morbid curiosity, here is the same implemented by a scan. It could be arranged as a single statement.

  swapIfGt = lambda xs, q: xs if xs[0] >= q else sorted([q]+xs[1:])
  n = 2
  reduce(swapIfGt, vals, [None]*n)[0]
Edit2: rewrote swapIfGt

Re: Imperative vs. Declarative

#29
post #11

It is not just as programmers. Consider, most cookbooks. Then consider the directions that come with Ikea furniture. Of course, the real beauty of both of those examples, is that they are a mix of declarative and imperative instructions. For some reason, it seems we programmers are adamant that it must be one or the other. Consider all of the examples, either purely imperative or purely declarative. Why not both?

Ideally, we would all write programs by assembling declarations, imperative code would be limited to internal implementations. That's largely the reason it's good practice to abstract away implementation behind APIs - what you have left is almost a pure declarative language, or DSL, that maps 1:1 your problem domain, without looping or branching or I/O (which are computation details).

Taking the example from the original article, it would be more akin to:

    // Implementation
    function double(n) {
      return n * 2;
    }

    // Declaration
    [1,2,3,4,5].map(double)
    => [2,4,6,8,10]

Re: Imperative vs. Declarative

#30
post #6

Prolog is declarative programming take to the maximum (excluding things like Answer Set Programming/clingo etc). In Prolog you ask questions. For example: subset([1,2],[2]). then it goes away and says "yes". Or you want to know if any subsets exist: subset([1,2],B). B = [] B = [1] B = [2] This makes it really really nice for some surprising tasks (Windows NT used to ship with a prolog interpreter for setting up the n…

I would disagree - in a sense, Prolog is less declarative than Haskell. For example, the order of "procedure calls" matters in Prolog, a sign of imperative programming. There is no such thing in Haskell (unless imperative behavior is being simulated with Monads).
Post reply on HN