91–100 of 163 posts
So, over the years I've played with many things that claim to be "declarative", and here's why I now shy away from them like the plague. There's no such thing as "declarative". No matter what you type into the computer, at some point it's going to turn into instructions that do the thing you want done. Trying to create a declarative language is a way of making it extraordinarily opaque as to what the machine is actua…
Jon, you're looking for haskell. But there's a catch -- programming in haskell is HARD, and expert haskellers are the best of the best, thus EXPENSIVE. many customers don't want correct programs, they want cheap programs. Some people in finance care about correctness, maybe you should check them out.
Dusting, thanks for the suggestion, but I'm not looking for Haskell. It's not what I'm looking for. What I want is declarative, not functional. There is an inherent limitation in the functional approach, I hope to cover why that is in a further article in the series. I am not after correctness per-se. I am actually more after "cheapness" at least in programmer time. But I do think a lot of the programmer time is spen…
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, no…
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.
bubblesort(List, Sorted) :-
swap(List, List1), !,
bubblesort(List1, Sorted).
swap([X,Y|Rest], [Y,X|Rest) :-
gt(X,Y).
swap([Z|Rest], [Z|Rest1]) :-
swap(Rest, Rest1).Are you trying to reinvent prolog? Also, I don't really understand how a compiler for your language would actually figure out the efficient algorithms for getting the answer. EDIT: I see there's already a bunch of people talking about prolog here. Anyway, the second question is still open :)
I have a feeling the second question will stay open. :)
So, over the years I've played with many things that claim to be "declarative", and here's why I now shy away from them like the plague. There's no such thing as "declarative". No matter what you type into the computer, at some point it's going to turn into instructions that do the thing you want done. Trying to create a declarative language is a way of making it extraordinarily opaque as to what the machine is actua…
So long as the problem you are trying to solve is constrained by the ease with which you can express the problem, this will help. But it will not help when the constraints are elsewhere: memory, network, CPU, heterogeneous interoperability; all still relevant in these times of mobile and distributed computing. When you are operating to these other constraints, you need control - or rather, consistency and predictabil…
> I expect a good compiler will swamp you with the inconsistencies of your hidden, unstated assumptions.
Thank you, this is exactly what I came here to say.
The entire practice of programming is formally defining how everything works, and the devil is always in the details. The effort of going through those details thoroughly and defining exactly what you want to the program to do in all situations is, simply, the act of programming itself.
The best you can do is create languages, libraries, frameworks to help you do it more efficiently.
But so does a-historical thinking.
"Programming is broken. Completely broken."
The "software crisis" has existed since, oh, computers began, maybe fifty years ago. Which means that, in a sense programming couldn't possibly be "broken" since it never ... was ... working ...
A way to put to it is that programming has never been as amendable to planning, to the realizing one's intentions as ... we THINK it should be.
And there's the interesting part.There are lots of things that are hard for humans beings - say, flying supersonic jets or solving partial differential equations.
What's funny about programming is that we always have a hard time of it BUT we always, over and over again, think it should be easy.
There is something interesting, a study for psychologists.
I would claim that a factor is that since programs are like the natural language we normally use, we intuitively expect programs to be a "smart" as other human beings in understanding our intentions and so we wind-up disappointed over and over again.
Of this leaves "intentions" and "smartness" as defines in our model. Perhaps we can use this situation to get some clues as to their meaning...
Earlier quoted context omitted.
I have a feeling the second question will stay open. :)
I believe so too. To choose an efficient algorithm, you have to know things about the input data. Even with the sorting example, this is so; e.g. if you place a certain set of constraints on the input, its possible to sort in linear time. But the compiler has no way of knowing such things, unless, of course, the language has some means of expressing constraints on the input in a manner that is digestible by the compi…
From the sorting example, the compiler could recognize that the constraints given match the problem of sorting. If the input data also had the constraint of "integer between 0 and 10,000", it would recognize this as a subset of sorting that could be handled through a linear time algorithm.