Hacker News Reader

Comment by giberson | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

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.

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

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.

Reply on news.ycombinator.com