Gradle
From APIDesign
(→Declarative vs. Imperative) |
(→Declarative vs. Imperative) |
||
| Line 11: | Line 11: | ||
== Declarative vs. Imperative == | == Declarative vs. Imperative == | ||
| - | Restricted [[language]] is in my opinion the biggest difference between [[wikipedia:Imperative_programming|imperative]] and [[wikipedia:Declarative_programming|declarative]] specification of actions (and by [[wikipedia:Declarative_programming|declarative]] [[I]] don't mean functional as such [[language]]s suffer from [[wikipedia:Halting_problem|halting problem]] presence as well). | + | Restricted [[language]] is in my opinion the biggest difference between [[wikipedia:Imperative_programming|imperative]] and [[wikipedia:Declarative_programming|declarative]] specification of actions (and by [[wikipedia:Declarative_programming|declarative]] [[I]] don't mean functional as such [[language]]s suffer from [[wikipedia:Halting_problem|halting problem]] presence as well). One should not be able to express everything that is possible in imperatively in declarative [[language]]. |
Btw. the important element that needs to be avoided is '''while''' construct - e.g. repeating some code block indefinitely - repeating something via '''for''' cycle - e.g. given number of times is OK. [[Language]]s that have just '''for'''s fall into the [[wikipedia:Primitive_recursive_function]] definition and are not subject to [[wikipedia:Halting_problem|halting problem]] - all of them halt. | Btw. the important element that needs to be avoided is '''while''' construct - e.g. repeating some code block indefinitely - repeating something via '''for''' cycle - e.g. given number of times is OK. [[Language]]s that have just '''for'''s fall into the [[wikipedia:Primitive_recursive_function]] definition and are not subject to [[wikipedia:Halting_problem|halting problem]] - all of them halt. | ||
Revision as of 17:14, 9 March 2015
These days it is common to praise Apache's Gradle and dishonest Maven. It is hard to find articles like Maven's Inflexibility Is Its Best Feature that would try to put some balance into the build tool flamewar raging around.
It is true that Maven is far from perfect, and possibly Gradle learned from Maven mistakes in many areas, but there is one thing where Gradle regressed totally - and which I consider far bigger problem than any shortcomings of Maven: Gradle brought halting problem into your build job!
Contents |
Why Should I Care about halting problem?
If you don't know what a halting problem is, you may belong into the camp of people who believe one can write program to solve any (digitalizable) problem. Well, you cannot - there are (digitalized) problems that computer's cannot solve - halting problem is core one. Its implications are huge. As a result of halting problem existence it is impossible to write a program that would completely understand behavior of all other programs.
That of course won't stop people from trying to write such program (as illustrated in the essay about finite automaton), but the only way to really analyse what a program does is to restrict language in which it is written!
Declarative vs. Imperative
Restricted language is in my opinion the biggest difference between imperative and declarative specification of actions (and by declarative I don't mean functional as such languages suffer from halting problem presence as well). One should not be able to express everything that is possible in imperatively in declarative language.
Btw. the important element that needs to be avoided is while construct - e.g. repeating some code block indefinitely - repeating something via for cycle - e.g. given number of times is OK. Languages that have just fors fall into the wikipedia:Primitive_recursive_function definition and are not subject to halting problem - all of them halt.
As such, if you want a computer program to understand some language, it is important to make the language declarative - e.g. to make it at most as complex as wikipedia:Primitive_recursive_function.
Follow
