4 ms·

> 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 gen

by jolmg 8y ago

> 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.

nerdponx 8y ago
Out of curiosity, what don't you like about Python's packing/unpacking?
- Something1234 8y ago
  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.
- OJFord 8y ago
  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))
  - SirScrambly 8y ago
    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.
    - OJFord 8y ago
      Yes, it was an example of something you _can't_ do.
  - fiddlerwoaroof 8y ago
    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.
  - zephyrfalcon 8y ago
    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/ https://www.python.org/dev/peps/pep-3113/
- jolmg 8y ago
  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 = ...
  - zephyrfalcon 8y ago
    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...)
cousin_it 8y ago
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.

by jolmg 8y ago

nerdponx 8y ago

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

Something1234 8y ago
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.
OJFord 8y ago
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))
- SirScrambly 8y ago
  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.
  - OJFord 8y ago
    Yes, it was an example of something you _can't_ do.
- fiddlerwoaroof 8y ago
  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.
- zephyrfalcon 8y ago
  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/ https://www.python.org/dev/peps/pep-3113/
jolmg 8y ago
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 = ...
- zephyrfalcon 8y ago
  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...)

cousin_it 8y ago

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.