Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the canonical examples of goal oriented programming would be sorting a list.

Rather than expressing how to take an arbitrary list and rearrange the elements so that they're sorted you express what means for a list to be sorted and let the algorithm figure out how to get there.

* An empty list is sorted.

* A single element is sorted.

* If one splits the list into its first element and its remainder then it is sorted if the remainder is sorted and the first element is less than or equal to the head of the remainder.

This doesn't lead to an efficient sort but it is enough for an algorithm to take any list and produce its sorted form. You can, with the right constraints, get a goal oriented system to carry just about every sorting algorithm and the benefit is that they're really concise and they read like the high level pseudocode you might see in an algorithms class.



if this was true, why would we have so many sorting algorithms in the first place?

It's not enough to express the desired result. We would also need to express our preferences for all the other decisions and trade-offs that are made during software development. Do we need this sort to be fast or use as little memory as possible? Synchronous? Does it need an index? Are we optimising for writes or reads? Persistence? What language are we sorting by?

That's for a simple sort. By the time you get into actual problems then it all gets more complex and the trade-offs become something you need to understand before making a decision on. Having an expert to make those decisions is good.


One advantage could be ease of refactoring. Imagine starting with "goal: the list is sorted", but the resulting program is uses too much space to achieve it. It could be a lot easier to add "goal: the list is sorted in O(n) space" than it is to rewrite your sorting algorithm.


I deleted all members of the list. It is now sorted as per the first axiom. Goal achieved, job complete.


You're absolutely right, there is one condition that I've swept under the rug which is necessary.

* The resulting list must be a permutation of the original list.


i dont see how this is different from any other built in function, or external library really. perhaps it seems different because there are alot of well known sorting algorithms that have different strengths and weaknesses? there are any number of ways of summing a list (most of them stupid), does sum() qualify as goal oriented? i dont think what your saying is without merit, but i do think the taxonomy needs to be discarded if thats what its referring to.


The difference is that those three statements encapsulate the entire source code required to perform a sort. It's not calling any kind of built-in sorting function. From those constraints the system is able to logically derive the sorted list.


> those three statements encapsulate the entire source code required to perform a sort.

It is calling the resolver system though and all the accompanying functions that actually do the sorting.

Not sure what is your definition of "source code", but I'm pretty sure nobody counts external library function implementations as source code for the program. Same as you don't count OS kernel as part of your program's source code.


Yes, but the resolver is not specific to sorting. The runtime of Prolog contains no list sorting code. (Or if it does, it does so as an optimization.)


When you use a library to sort an array, you're not telling the computer how to sort an array, nor are you telling the computer what a sorted array is. That distinction is for the person implementing the sort, not really as relevant for someone just using it.


interesting. So merge sort might be something like? * empty list is sorted * a single element is sorted * merging two sorted lists results in a sorted list

Are there languages that could take this and do merge sort?


Absolutely! Here's a bunch of sorting implementations in prolog.

http://kti.ms.mff.cuni.cz/~bartak/prolog/sorting.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: