Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I want to fix programming

jonbho.net

Post reply on HN
Print view View original

131–140 of 163 posts

Re: I want to fix programming

#131

Post by rue »

jacktoole1 wrote: post #119
nandemo wrote: post #110

Earlier quoted context omitted.

> Trying to create a declarative language is a way of making it extraordinarily opaque as to what the machine is actually going to do. It looks great in four lines, it crashes and burn on any real sized problem, Erlang, Haskell and Ocaml are examples of declarative languages, and they all have been used to solve very real-sized problems: telecommunication switches, compilers, trading systems, a window manager, etc. I…

I love OCaml, but I would hardly call it a declarative language. You still describe the steps to perform an algorithm, rather than the result of the algorithm. The article poster references Haskell and explicitly says "The functional approach brings indeed several improvements over regular imperative or object-oriented programming. But still it’s not the solution."

The argument forwarded for considering them declarative is that their compilers perform transforms on the source code, and that there are no side-effects.

I certainly agree with your interpretation more. Typical functional programming isn't really declarative (though, yes, moreso than imperative programs are) and those waters shouldn't be muddied.

Re: I want to fix programming

#132

Post by raganwald »

jerf wrote: post #55

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…

SQL is declarative, and that's it's strength. The optimization, indexing, and other tweaking of the implementation is separated from the code that declares the result needed.

Re: I want to fix programming

#133

Post by nickik »

I think it is possible to write something better then prolog but I dont think we will ever write all programmes this way. Dont get me wrong using declerativ systems to help you is often helpful but I doute we will ever programm everything like this.

Even if we did we would still have many of the same bugs, many bugs we have to day are not details of algorithems the are problems in our own head, you can divine a system the way you want it an still get the wrong answer.

Re: I want to fix programming

#134

Post by bjornsing »

javadyan wrote: post #95
balloot wrote: post #86

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…

The compiler could also be an interpretor. ;) What could be a better way to chose the algorithm than to try them all on the actual data runtime (or in "training mode")?

Re: I want to fix programming

#135

Post by bjornsing »

bfrs wrote: post #104

Relevant stuff from SICP [1]: "The contrast between [a mathematical] function and [a computing] procedure is a reflection of the general distinction between describing properties of things and describing how to do things, or, as it is sometimes referred to, the distinction between declarative knowledge and imperative knowledge. In mathematics we are usually concerned with declarative (what is) descriptions, whereas in…

Yea, you will invariably run into the halting problem and similar. But I think academics are too held back by that in general. The "program space" is very large, and there's of course a lot of strange beasts out there, but only a very small subset of all possible programs are meaningful to create (in the sense that people want them or their output).

Re: I want to fix programming

#136

Post by zimbatm »

jamesrcole wrote: post #111
jerf wrote: post #55

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…

I don't think there's any inherent problem with stuff being declarative. We just need the software to be smart enough to handle it well. We might have a long way to go till we can do this effectively. I'd suggest looking at 'declarative' from the point of view of delegation (not in the technical sense, but the usual sense of getting someone else to do a task for you). Ideally you want to specify what you want to be d…

"We just need the software to be smart enough to handle it well."

You just shifted the complexity with one sentence, it doesn't make it any easier.

Re: I want to fix programming

#137

Post by jseban »

jerf wrote: post #55

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…

You have a point, declarative approaches almost never delivers as promised, which is "you don't have to worry about implementation".

In reality, as you say, you end up with edge cases where you still need to dive into the implementation in order to find out what's happening.

I don't think it's a good enough argument to dismiss the whole paradigm though. Im prefectly happy with my declarative regular expressions that work 90% of the time, and rather take the hit debugging those hairy 10% that end up not working well, than writing my own imperative parser every time and repeatedly deal with those off by one errors etc..

When you say "it never works" I suspect you really mean "it never works in 100% on the cases".

Re: I want to fix programming

#138

Post by overgard »

raganwald wrote: post #132
jerf wrote: post #55

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…

SQL is declarative, and that's it's strength. The optimization, indexing, and other tweaking of the implementation is separated from the code that declares the result needed.

I'm not convinced you can really separate those things in a practical context. Inevitably you end up with a leaky abstraction and the opaqueness of what's actually going on makes it harder to diagnose.

I think declarative is the right default, since it shows the intent over the mechanics, but I deeply distrust any system that won't let me be very specific about the mechanics if I need to be.

Re: I want to fix programming

#139

Post by jng »

jerf wrote: post #55

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…

Jerf, thanks so much for sharing your thoughts. I think I agree with all your views. They are taken from the real experience of trying those approaches. And I am grateful that you provide the feedback. I and anyone tackling this steep mountain need all the help we can get.

I am sure that inspectability/debuggability are two of the big issues with such an approach. When things fail, the more magic there is, the more difficult it is to fix it. It's even difficult to understand what's happening!

I do think that there is a gap there. You can specify things and have the environment apply your spec. If it's totally naive, like Prolog's "slowsort", it will take exponential time and be impractical for real-world cases. But if strategies can be found and/or devised, and applied, which get some efficiency, it can be practical for many things. When things fall apart, it's clear that powerful debuggers will be needed. A lot of work will be needed on the tools, similar to SQL Query Strategy Inspectors, etc... maybe even professionals specializing just in this. But I think that it will finally allow us to write code in a sane way. Even if armies of professionals have to come after the fact to tweak it so that it's usable, the same as for SQL.

I totally understand what you see as adavantageous in Haskell. I think that same "it's turtles all the way down", where you can inspect and debug every step, is the reason that Haskell cannot gain the power that I am after. Prolog can't either, for other reasons.

I believe a fundamentally different approach is needed. And that's what I'm trying to sketch out.

And thanks to you and many other people hopefully we can learn whether there is something there or there isn't, and if there is, hopefully reach some useful result!

Post reply on HN