Hacker News Reader

Comment by jolmg | Hacker News Reader

> Prolog's lack of popularity suggests that viewing a computer program as a pure (first order predicate) logic construct isn't a powerful way of thinking in general.

No... it doesn't suggest that. If there's one thing I've learned all these years I've learned about various different softwares and languages, it's that popularity does not correlate with power.

I'll take Linux over Windows, Archlinux over Ubuntu, Haskell over Java, i3 over Gnome, CLI over GUI, vim and shell over IDEs like Eclipse. I've seen "modern" popular languages adopt features from "obsolete" unpopular languages in ways that pale with the originals, like Python's lambdas and assignment unpacking, which suck.

The rest of your post notwithstanding, I disagree with the logic of your first sentence.

View on HN

That seems like a misreading of grandparent. Their point was that thinking of programs as logic isn't a powerful way of thinking because it doesn't match the way computers work. That's different from power of programming languages per se.

A language could be very powerful in your sense, but abstract away from some important aspect of computation. (For example, Haskell is very powerful, but the space complexity of a Haskell program is hard to determine from the language spec.) Then such a language wouldn't be a "powerful way of thinking" in the sense of grandparent - in thinking about some aspects of computation it would hinder rather than help. The same is true for Prolog, I think.

Out of curiosity, what don't you like about Python's packing/unpacking?

If I had to say anything I would guess that the number you unpack has to match the number of things returned rather than being a head and tail.

Not GP, but it's _very_ limited.

Off the top of my head, things you can't do:

    # nested unpacking
    (a, b), c = ((1, 2), 3)

    # destructuring arguments
    (lambda (a, b): None)((1, 2))

For your second example, you need to unpack your parameters.

    (lambda x, y: None)(*(1, 2))

Unless you're saying you should be able to define the set size you pass in.

Yes, it was an example of something you _can't_ do.

Both of these were intentionally removed around Python 3, iirc: python 2.7 allows nested tuple/list destructuring as well as destructuring in function arg lists.

First example works fine in both Python 2 and 3. Second example works in Python 2.7 and earlier, but tuple unpacking for arguments was removed in Python 3. [1]

[1] https://www.python.org/dev/peps/pep-3113/

I feel it's meant to be a part of the features that try to make Python more viable for functional programming, but when you compare it to the equivalent in Haskell, for example:

* You can't nest, like it was mentioned

  ((x1, y1), (x2, y2)) = makeLine ...

* You can't use aliases

  line@(point1@(x1, y1), point2@(x2, y2)) = makeLine ...

* You can't use it on all objects/structures/datatypes

  Line (Point x1 y1) (Point x2 y2) = makeLine ...

* You can't pattern match on it

  case nextShape of
    Circle centerPoint radius -> ...
    Square width height -> ...
    Triangle point1 point2 point3 -> ...

* You can't use it on functions/lambdas

  \ Line (point1@(Point x1 y1) _) -> ...
  drawLine (Line (point1@(Point x1 y1) _)) = ...

* The syntax in Python 2 doesn't support unpacking the first few elements of a list of variable length. Python 3 added support, though.

  x1:x2:xs = ...

Tuple/list unpacking has been in Python for a long time and likely has nothing to do with catering to the functional crowd, which Guido isn't known for to begin with. Anyway...

> * You can't nest, like it was mentioned

    ((x1, y1), (x2, y2)) = makeLine ...

This works fine in Python:

    ((x1,y1), (x2,y2)) = ((1,2),(3,4))

I don't know what "makeLine ..." returns, but if it doesn't exactly match the tuples on the left hand side, it won't fly in Haskell either.

> * You can't use aliases

    line@(point1@(x1, y1), point2@(x2, y2)) = makeLine ...

No, but this works:

    line = p1, p2 = ((x1,y1), (x2,y2)) = ((1,2), (3,4))

and is more readable IMHO.

Point 3, 4 and 5 don't make sense in Python. This is pattern matching, not tuple/list unpacking. (One could argue that tuple unpacking is a form of pattern matching, but that is a different story...)

Reply on news.ycombinator.com