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

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.




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

Search: