6 ms·

So imagine you define some amazing PSL (Problem/Solution Language). It let's you "Code" by defining the problem and solution, ie: Define SORT: Given SET(x)

So imagine you define some amazing PSL (Problem/Solution Language). It let's you "Code" by defining the problem and solution, ie: Define SORT: Given SET(x), Find SET(y) Where [For i in y] y[i]>y[i-1]. So now you're feeling all giddy because this amazing language is so awesome--you didn't have to specify how to do something step by step. You just declared what you wanted, and it gave it to you. Fantastic. But then, now that you have defined this "SORT" routine, you still need to use it. You end up with the following code: Prompt SET. SORT SET. Display SET. Shit! You're defining steps again. You ultimately can never achieve your goal, because you will always need to define some steps. All programs of significance are a composition of tasks which need to be identified, and executed.

timmaxw 15y ago
There's a bug in your definition of SORT. The OP complains that it's easy to write imperative and functional programs that contain bugs; I don't think that declarative programs are fundamentally better.
- giberson 15y ago
  Tongue in cheek, you don't know how PSL handles negative array bounds--perhaps it's smart enough to know how to handle the first element.
  - wccrawford 15y ago
    Actually, I don't see why it couldn't be 'smart' enough to know how to handle non-existant array locations. It just needs to know to handle all the valid cases, and ignore the invalid ones, and it's good to go.
  - omaranto 15y ago
    It has a much, much worse bug than the negative index: your definition of sort says "given x produce a y which is sorted and completely unrelated to x in any way". The implementation "given x return y=[1,2,3]" satisfies your specification...
    - giberson 15y ago
      The negative index issue is a valid bug concern because when I was typing out the _fictional_ PSL code I missed the negative index hence my reply that said language could be smart enough to handle that (ie, tongue in cheek). However, your bug is not legit, because you've introduced extra wording for an assumption you can't make since you're not the creator of my fictional language. For PSL, "Given SET(x), Find SET(y)" implies that SET(y) is a resultant set of SET(X). SET(y) could have a case where the elements are different than SET(x) but only where explicitly indicated by the requirements. The requirements specified by the where clause in this case do not dictate a transformation on the elements, only a re-ordering. So no, it's not a bug. It's funny that despite it being a passing pseudo example to make a point about programs being compositions of tasks that I'd be this vested in defending the code correctness of my pseudo code but I can't help it.
aphyr 15y ago
No. You're thinking imperatively. The pure form would express something like: "given the property sorted(s) defined in this way, let s be a set such that for all elements e of s, e is an element of the program input. Then let the output of the program be the list l such that sorted(l) is true.
- giberson 15y ago
  >No. You're thinking imperatively. The pure form would express something like: >given the property sorted(s) defined in this way "Prompt SET" >let s be a set such that for all elements e of s, e is an element of the program input. ... such that sorted(l) is true. "SORT SET" >Then let the output of the program be the list l Display SET. You've changed the wording and grammar, but you haven't stated anything different.
  - aphyr 15y ago
    What I'm pointing out is that "steps" are arbitrary; they're not intrinsic properties of the system. You can express the entire program as a definition tree without ordered expressions.

timmaxw 15y ago

There's a bug in your definition of SORT. The OP complains that it's easy to write imperative and functional programs that contain bugs; I don't think that declarative programs are fundamentally better.

giberson 15y ago
Tongue in cheek, you don't know how PSL handles negative array bounds--perhaps it's smart enough to know how to handle the first element.
- wccrawford 15y ago
  Actually, I don't see why it couldn't be 'smart' enough to know how to handle non-existant array locations. It just needs to know to handle all the valid cases, and ignore the invalid ones, and it's good to go.
- omaranto 15y ago
  It has a much, much worse bug than the negative index: your definition of sort says "given x produce a y which is sorted and completely unrelated to x in any way". The implementation "given x return y=[1,2,3]" satisfies your specification...
  - giberson 15y ago
    The negative index issue is a valid bug concern because when I was typing out the _fictional_ PSL code I missed the negative index hence my reply that said language could be smart enough to handle that (ie, tongue in cheek). However, your bug is not legit, because you've introduced extra wording for an assumption you can't make since you're not the creator of my fictional language. For PSL, "Given SET(x), Find SET(y)" implies that SET(y) is a resultant set of SET(X). SET(y) could have a case where the elements are different than SET(x) but only where explicitly indicated by the requirements. The requirements specified by the where clause in this case do not dictate a transformation on the elements, only a re-ordering. So no, it's not a bug. It's funny that despite it being a passing pseudo example to make a point about programs being compositions of tasks that I'd be this vested in defending the code correctness of my pseudo code but I can't help it.

aphyr 15y ago

No. You're thinking imperatively. The pure form would express something like: "given the property sorted(s) defined in this way, let s be a set such that for all elements e of s, e is an element of the program input. Then let the output of the program be the list l such that sorted(l) is true.

giberson 15y ago
>No. You're thinking imperatively. The pure form would express something like: >given the property sorted(s) defined in this way "Prompt SET" >let s be a set such that for all elements e of s, e is an element of the program input. ... such that sorted(l) is true. "SORT SET" >Then let the output of the program be the list l Display SET. You've changed the wording and grammar, but you haven't stated anything different.
- aphyr 15y ago
  What I'm pointing out is that "steps" are arbitrary; they're not intrinsic properties of the system. You can express the entire program as a definition tree without ordered expressions.