-1

The more declarative code is, the less explicit technical details it contains and the closer it gets to requirements expressed in domain language.

In the extreme case, there is no more difference between requirements and code. My question is not about whether this is possible or not. But surely declarative programming makes the gap between requirements and code smaller.

I believe that this is quite obvious, but in the other hand I have not been able to find any material on this relationship between requirements and declarative code.

Therefore I am wondering:

  1. Is my assumption flawed?

  2. Is it just too obvious and trivial to be mentioned?

  3. Did I not search hard enough?

Improve this question
3
  • 1
    It is indeed the goal of some DSL's to express requirements as close to the domain language as possible. See for example 'Cucumber' which is supposed to read almost like English. Whether this is actually a good idea remains to be seen though. Even COBOL was supposed to be "English-like". I don't think such languages need to be declarative though - some requirements could be expressed as conditionals, sequential steps etc.
    – JacquesB
    Commented Feb 16, 2019 at 11:33
  • In any case, you are not really asking a clear question...are you looking for material about specifications-as-DSL?
    – JacquesB
    Commented Feb 16, 2019 at 13:15
  • This is not a function of language. This is a function of choosing good names. Any language that lets me hide complexity behind a name lets me do this. None of them ensure I will do this. Doing this is our job.
    – candied_orange
    Commented Feb 16, 2019 at 17:43

2 Answers 2

Reset to default
4

I believe that this is quite obvious

Well, I believe that it is quite obvious that this is wrong.

Requirements, no matter how declarative they are, describe a system only from the black box perspective. There are, however, infinite ways for a correct implementation of a system.

For example, if you are going to build a program to sort some data, you can precisely define the input format, the expected output, and some user interface, all in a 100% declarative manner, using simple tools from mathematics and UI building. However, that does not tell you anything about the internal sorting algorithm used inside the system (and I assume you know there literally dozens of different sorting algorithms invented by people smarter than me).

Of course, there have been many attempts in the past to create software environments where new applications can be created using purely declarative tools, without programming (so almost "directly" from the requirements). You may have heard of the more than 30 years old idea of "Fourth-generation programming languages", for example. This works to some degree for some restricted tasks like creating some standard CRUD software or report generation. However, these approaches have their limits, and I would recommend against overgeneralizing from them.

Improve this answer
2
  • Yes, there is an infinite number of ways to correctly implement a system. Implementation means splitting your system up into subsystems and defining requirements for these subsystems. There can be many levels of subsystems and accordingly many levels of requirements. (Some people use a different name for these subsystem requirements and call them contracts.) Concerning your sorting example, either the algorithm is irrelevant or you define a requirement for it, for example that it has to be O(n log n).
    – Frank Puffer
    Commented Feb 17, 2019 at 9:37
  • @FrankPuffer: any system has "innermost subsystems", and those will be black boxes. "big O" does not define one specific algorithm. And it is normally not a testable requirement, running time is. And expected running time is nothing you can "declare" in any kind of language, and then you get "automagically" a program which fullfills that time constraints.
    – Doc Brown
    Commented Feb 17, 2019 at 16:05
2

In a sense, a code in any programming is an executable specification. It is more detailed than conventional non-executable specifications, but it is just another level in the hierarchy of non-executable specifications.

If you consider a more conventional understanding of what is specification, there is important features which makes them unsuitable as code replacement:

  • they usually not that exactly define the behavior. They are still some open for interpretation natural language phrases.
  • they do not cover 100% of functionality. There are gaps between them which supposed to be filled with common sense.

As an example of something close to middle ground between both words, I think best to take a look at Prolog for example.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.