4 ms·

It already has, unfortunately it's not too popular. This is why Prolog gives most folks a case of headache. My moment of enlightenment while studying Prolog ha

It already has, unfortunately it's not too popular. This is why Prolog gives most folks a case of headache. My moment of enlightenment while studying Prolog happened when I realized that I wasn't logical, but trying to solve the problem in Von Neumann style. I was humbled to see simple logic solutions in place of my overly complicated solutions. This has made me such a better developer, I keep my code as declarative as possible.

honnix 10y ago
thumb up!
catnaroek 10y ago
Prolog is rather imperative. If it were declarative and pure, it wouldn't mandate a specific execution strategy, but rather leave it as an implementation detail - a user-adjustable one, even. In an imperative language (including all functional ones), optimizing a program is rewriting it. In a declarative language, optimizing a program is adjusting the language implementation (e.g., making a smarter SQL query planner). A better argument for declarative languages is the Haskell technique of decoupling the abstract syntax of a DSL (usually a free monad) from its possible interpreters (monad morphisms).
- _yosefk 10y ago
  SQL is not Prolog though. SQL, at least the parts mapping to relational algebra, is not Turing-complete, Prolog is. I'm pretty sure Prolog not specifying an execution strategy would mean that your program terminates under one interpreter but not under another, not to mention their asymptotic complexity, which I think is not as bad with SQL. In other words, it's not a lie to promise that you can specify a query over tables in a declarative way, but it's sort of a lie to promise that you can spell out predicates describing a solution and the machine will find a solution satisfying these predicates, because sometimes it can't. Specifying an execution strategy doesn't make it less of a lie but it lets you write a working program kinda looking as if it weren't a lie.
  - catnaroek 10y ago
    > I'm pretty sure Prolog not specifying an execution strategy would mean that your program terminates under one interpreter but not under another, not to mention their asymptotic complexity, which I think is not as bad with SQL. Yup! But it's not as bad as it seems. In a pure logic language, the changing the execution strategy can only change three things: (0) Whether a query terminates, in which case it returns the entire soution set. (1) If the query doesn't terminate, which subset of the solution set is returned. (2) How fast it runs, of course. Which is a lot better than the subtle things that can go wrong when optimizing imperative programs by hand. Selecting an execution strategy for a declarative program is no different from tuning a garbage collector: if you do it wrong, bad things can still happen, but they won't be as bad as if you manage things by hand and do it wrong. > it's sort of a lie to promise that you can spell out predicates describing a solution and the machine will find a solution satisfying these predicates, because sometimes it can't. Yup! Which leads (IMO) to the conclusion that general-purpose languages must always include some imperative (explicit control) component. Declarative languages really shine as DSLs, though.
  - garyclarke27 10y ago
    SQL is turing complete, at least on Postgres. Case statements provide control of flow and WITH Recursive CTEs provide looping/iteration/recursion. Pure SQL functions can accomplish nearly anything (except dynamic execution, think macros) that procedural PL/pgSQL can, WITH statements provide variables and temp tables. SQL is the most declarative language I'm aware of.
agumonkey 10y ago
I have the feeling many schools try to convey the imperative, functional, logic progression scheme, but very few people will either get the love or the wit to follow. FP and Prolog flipped my mind around computing twice. The notion of tasks, stack, processes, programs, function, properties, sets, space, graph traversal, continuations, etc etc all fit in a small framework it's maddening.
Animats 10y ago
Oh, Prolog. I once wrote a hardware configuration in Prolog. (Dependency resolution - rules like "An A requires a B or a C".) The configuration part was fine. Trying to write a menu system in pure Prolog, though... Most of the troubles with functional programming come when you actually have to do something. The imperative/functional boundary remains a problem.
- agumonkey 10y ago
  That was Backus conclusion after his FP forray.
- tome 10y ago
  > Most of the troubles with functional programming come when you actually have to do something. The imperative/functional boundary remains a problem. How does it remain a problem? I've been writing commercial Haskell programs that do something for years now.
  - Animats 10y ago
    Monads are kind of a hack.[1] [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
    - dllthomas 10y ago
      "X is a solution to problem Y" doesn't imply that X is a hack. You'll need to be more verbose if you were making a more specific argument.
  - pron 10y ago
    (User-visible, generic) monads are absolutely terrible for expressing effects. That so many people have a hard time understanding them fully shows that it's a real problem of the most serious kind (aside from their inherent shortcomings). That just a vanishingly small portion of developers enjoys working with them is not an indication of a lack of a problem, but rather of its presence. That people in PL research are actively trying to find alternatives to monads (and you have people like Martin Odersky publicly saying they don't like monads) is yet another (though less powerful) indication. That some pure languages like Haskell decided to treat mutation as a side-effect like IO (requiring monads) only exacerbates matters.
ktRolster 10y ago
That's really cool to hear.

honnix 10y ago

thumb up!

catnaroek 10y ago

Prolog is rather imperative. If it were declarative and pure, it wouldn't mandate a specific execution strategy, but rather leave it as an implementation detail - a user-adjustable one, even. In an imperative language (including all functional ones), optimizing a program is rewriting it. In a declarative language, optimizing a program is adjusting the language implementation (e.g., making a smarter SQL query planner). A better argument for declarative languages is the Haskell technique of decoupling the abstract syntax of a DSL (usually a free monad) from its possible interpreters (monad morphisms).

_yosefk 10y ago
SQL is not Prolog though. SQL, at least the parts mapping to relational algebra, is not Turing-complete, Prolog is. I'm pretty sure Prolog not specifying an execution strategy would mean that your program terminates under one interpreter but not under another, not to mention their asymptotic complexity, which I think is not as bad with SQL. In other words, it's not a lie to promise that you can specify a query over tables in a declarative way, but it's sort of a lie to promise that you can spell out predicates describing a solution and the machine will find a solution satisfying these predicates, because sometimes it can't. Specifying an execution strategy doesn't make it less of a lie but it lets you write a working program kinda looking as if it weren't a lie.
- catnaroek 10y ago
  > I'm pretty sure Prolog not specifying an execution strategy would mean that your program terminates under one interpreter but not under another, not to mention their asymptotic complexity, which I think is not as bad with SQL. Yup! But it's not as bad as it seems. In a pure logic language, the changing the execution strategy can only change three things: (0) Whether a query terminates, in which case it returns the entire soution set. (1) If the query doesn't terminate, which subset of the solution set is returned. (2) How fast it runs, of course. Which is a lot better than the subtle things that can go wrong when optimizing imperative programs by hand. Selecting an execution strategy for a declarative program is no different from tuning a garbage collector: if you do it wrong, bad things can still happen, but they won't be as bad as if you manage things by hand and do it wrong. > it's sort of a lie to promise that you can spell out predicates describing a solution and the machine will find a solution satisfying these predicates, because sometimes it can't. Yup! Which leads (IMO) to the conclusion that general-purpose languages must always include some imperative (explicit control) component. Declarative languages really shine as DSLs, though.
- garyclarke27 10y ago
  SQL is turing complete, at least on Postgres. Case statements provide control of flow and WITH Recursive CTEs provide looping/iteration/recursion. Pure SQL functions can accomplish nearly anything (except dynamic execution, think macros) that procedural PL/pgSQL can, WITH statements provide variables and temp tables. SQL is the most declarative language I'm aware of.

agumonkey 10y ago

I have the feeling many schools try to convey the imperative, functional, logic progression scheme, but very few people will either get the love or the wit to follow. FP and Prolog flipped my mind around computing twice. The notion of tasks, stack, processes, programs, function, properties, sets, space, graph traversal, continuations, etc etc all fit in a small framework it's maddening.

Animats 10y ago

Oh, Prolog. I once wrote a hardware configuration in Prolog. (Dependency resolution - rules like "An A requires a B or a C".) The configuration part was fine. Trying to write a menu system in pure Prolog, though... Most of the troubles with functional programming come when you actually have to do something. The imperative/functional boundary remains a problem.

agumonkey 10y ago
That was Backus conclusion after his FP forray.
tome 10y ago
> Most of the troubles with functional programming come when you actually have to do something. The imperative/functional boundary remains a problem. How does it remain a problem? I've been writing commercial Haskell programs that do something for years now.
- Animats 10y ago
  Monads are kind of a hack.[1] [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
  - dllthomas 10y ago
    "X is a solution to problem Y" doesn't imply that X is a hack. You'll need to be more verbose if you were making a more specific argument.
- pron 10y ago
  (User-visible, generic) monads are absolutely terrible for expressing effects. That so many people have a hard time understanding them fully shows that it's a real problem of the most serious kind (aside from their inherent shortcomings). That just a vanishingly small portion of developers enjoys working with them is not an indication of a lack of a problem, but rather of its presence. That people in PL research are actively trying to find alternatives to monads (and you have people like Martin Odersky publicly saying they don't like monads) is yet another (though less powerful) indication. That some pure languages like Haskell decided to treat mutation as a side-effect like IO (requiring monads) only exacerbates matters.

ktRolster 10y ago

That's really cool to hear.