5 ms·

IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). You have to invoke the name of every function twice while

by trott 10y ago

IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). You have to invoke the name of every function twice while defining it, etc. The language seems to be designed for multi-page blocks, which are a bad idea to begin with. It also lacks memory safety, despite being a safety-oriented language. If someone added a better syntax to Ada (probably easy) and Rust-like memory safety (probably hard), that would make it a higher-value proposition. EDIT: There's also an article demonstrating a hole in Ada type safety: http://www.enyo.de/fw/notes/ada-type-safety.html http://www.enyo.de/fw/notes/ada-type-safety.html

bitwize 10y ago
I'm a big believer in RYINTBDIMOTB (Repeating Yourself Is Not The Big Deal It's Made Out To Be). In a safety-oriented language, checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. If you're restricting yourself to access types you have good memory safety. Access types cannot be aliased unless declared so, and are subject to accessibility checks to verify that they are "live". Unsafe stuff in Ada must be used explicitly; you cannot, in general, accidentally the whole stack or heap unless you are using a pathological coding style.
- wyager 10y ago
  > checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. I shouldn't have to make such checks in the first place. Not making a mistake in the first place is preferable to detecting it later on.
  - jacques_chester 10y ago
    > Not making a mistake in the first place is preferable to detecting it later on. Not trying to detect a mistake is a great way to form the impression that you're not making them in the first place.
    - wyager 10y ago
      Perhaps I was not clear. A preferable alternative to detecting mistakes is to ensure that they are impossible to make in the first place.
  - asimuvPR 10y ago
    We should also consider the mistakes of others and runtime errors.
  - bitwize 10y ago
    If you're a human, you make mistakes. It's what you do. Having the compiler check your work for mistakes and flagging them up early is better than letting them slide.
    - wyager 10y ago
      >If you're a human, you make mistakes. Unless you can design your compiler to make a class of mistake impossible, as we were discussing.
EdwardCoffin 10y ago
I think there's a huge gulf between repeating oneself with multiple snippets of code which would cause problems if not kept in sync (prone to people changing one without realizing there are others that must be updated too) and merely repeating the name of something at the termination of its definition in addition to naming it at the start. I regard the latter as a species of Poka-yoke [1], and am relatively happy to accept the extremely minor cost of repetition. [1] https://en.wikipedia.org/wiki/Poka-yoke https://en.wikipedia.org/wiki/Poka-yoke
- 205guy 10y ago
  And Ada's repetition could easily be automated in the IDE or smart editor (does sublime have an Ada-syntax--and I probably don't even need to ask for emacs). The repetition is there for readability and maintainability, so the author loses nothing if it is automated.
agumonkey 10y ago
ADA wasn't made for the average human, in large project a DRY means dozens of duplicated content, not just a small name redundancy. For the DOD I'm sure this wasn't even a question.
dozzie 10y ago
> IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). DRY is far from being "most fundamental". Much more fundamental and important are keeping modules composable, not mixing things of different abstraction level in the same block of code, avoiding circular dependencies, or avoiding unnecessary dependencies are more fundamental. DRY is just most easily enforcable, that's why it's so popular.
- trott 10y ago
  > keeping modules composable, To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. > not mixing things of different abstraction level in the same block of code Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. > avoiding circular dependencies Probably a good principle, but not fundamental: https://en.wikipedia.org/wiki/Meta-circular_evaluator https://en.wikipedia.org/wiki/Meta-circular_evaluator > avoiding unnecessary dependencies are more fundamental Avoiding anything that's unnecessary is generally a good idea.
  - dozzie 10y ago
    >> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition". DRY is just a different thing than composability. >> not mixing things of different abstraction level in the same block of code > Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection. >> avoiding circular dependencies > Probably a good principle, but not fundamental Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.
lobster_johnson 10y ago
Ada requiring the redundant name after "end" isn't a violation of DRY at all. The DRY principle is about the codebase as a whole, where repetition can lead to elements getting out of sync. For example, instead of having an ORM define a mapping between classes and tables in, say, XML, DRY dictates that the mapping ought to be where it belongs, namely in the class declaration itself. Ada's repetition is really more about readability. If you see an "end", you always knows what it matches. (Personally, I think it's useless.)
- trott 10y ago
  > Ada requiring the redundant name after "end" isn't a violation of DRY at all. Yours is an arbitrarily narrow interpretation of the principle. To quote Dave Thomas, DRY states that "Every piece of knowledge in the development of something should have a single representation." The name of your function or block is one such piece. I agree that having the compiler check the consistency of the redundant statements ameliorates the situation somewhat, but it would be better if the problem wasn't there at all. [1] http://www.artima.com/intv/dry.html http://www.artima.com/intv/dry.html
  - deleted 10y ago
    [deleted]
  - lobster_johnson 10y ago
    The page you linked to directly refutes your claim of narrowness: Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that. [...] DRY says that every piece of system knowledge should have one authoritative, unambiguous representation Note the terms knowledge and representation. He's referring to things like declarations, data models, schemas, facts. Duplicate source code symbols has nothing to do with it. DRY is not "be terse". For example, turning a literal into a constant is DRY, because it reduces to a single "authorative, unambiguous representation". But "x = x + 1" (which certainly looks redundant) is not anti-DRY, nor is "end Foo;".

by trott 10y ago

bitwize 10y ago

I'm a big believer in RYINTBDIMOTB (Repeating Yourself Is Not The Big Deal It's Made Out To Be). In a safety-oriented language, checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. If you're restricting yourself to access types you have good memory safety. Access types cannot be aliased unless declared so, and are subject to accessibility checks to verify that they are "live". Unsafe stuff in Ada must be used explicitly; you cannot, in general, accidentally the whole stack or heap unless you are using a pathological coding style.

wyager 10y ago
> checking for consistency in all of the repeated instances of a thing is one form of low-hanging-fruit safety check. I shouldn't have to make such checks in the first place. Not making a mistake in the first place is preferable to detecting it later on.
- jacques_chester 10y ago
  > Not making a mistake in the first place is preferable to detecting it later on. Not trying to detect a mistake is a great way to form the impression that you're not making them in the first place.
  - wyager 10y ago
    Perhaps I was not clear. A preferable alternative to detecting mistakes is to ensure that they are impossible to make in the first place.
- asimuvPR 10y ago
  We should also consider the mistakes of others and runtime errors.
- bitwize 10y ago
  If you're a human, you make mistakes. It's what you do. Having the compiler check your work for mistakes and flagging them up early is better than letting them slide.
  - wyager 10y ago
    >If you're a human, you make mistakes. Unless you can design your compiler to make a class of mistake impossible, as we were discussing.

EdwardCoffin 10y ago

I think there's a huge gulf between repeating oneself with multiple snippets of code which would cause problems if not kept in sync (prone to people changing one without realizing there are others that must be updated too) and merely repeating the name of something at the termination of its definition in addition to naming it at the start. I regard the latter as a species of Poka-yoke [1], and am relatively happy to accept the extremely minor cost of repetition. [1] https://en.wikipedia.org/wiki/Poka-yoke https://en.wikipedia.org/wiki/Poka-yoke

205guy 10y ago
And Ada's repetition could easily be automated in the IDE or smart editor (does sublime have an Ada-syntax--and I probably don't even need to ask for emacs). The repetition is there for readability and maintainability, so the author loses nothing if it is automated.

agumonkey 10y ago

ADA wasn't made for the average human, in large project a DRY means dozens of duplicated content, not just a small name redundancy. For the DOD I'm sure this wasn't even a question.

dozzie 10y ago

> IMHO Ada violated the most fundamental principle of programming, which is DRY (Don't repeat yourself). DRY is far from being "most fundamental". Much more fundamental and important are keeping modules composable, not mixing things of different abstraction level in the same block of code, avoiding circular dependencies, or avoiding unnecessary dependencies are more fundamental. DRY is just most easily enforcable, that's why it's so popular.

trott 10y ago
> keeping modules composable, To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. > not mixing things of different abstraction level in the same block of code Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. > avoiding circular dependencies Probably a good principle, but not fundamental: https://en.wikipedia.org/wiki/Meta-circular_evaluator https://en.wikipedia.org/wiki/Meta-circular_evaluator > avoiding unnecessary dependencies are more fundamental Avoiding anything that's unnecessary is generally a good idea.
- dozzie 10y ago
  >> keeping modules composable, > To my mind, this is a corollary of DRY: if you are not repeating yourself, then you are reusing code, which, by definition will have made it composable. You don't get composability from DRY, as merely extracting common snippet of code into a function doesn't make magically the function easy to put somewhere else. Just "reusing code" doesn't make it composable. You can reuse body of a car for something different, but it doesn't make it composable, so there's no "by definition". DRY is just a different thing than composability. >> not mixing things of different abstraction level in the same block of code > Never heard this one, frankly. I happily mix addition (arithmetic, machine-level operation) and, say, Dice Coefficient in the same line of code. It's a practical thing. You don't put opening TCP connection to a database service in the same chunk of code as building SQL query to be sent through the connection. >> avoiding circular dependencies > Probably a good principle, but not fundamental Oh yes it is. If code doesn't adhere to it, it ends up being a tangled, monolitic mess of brittleness. As with every rule, there are cases when it makes sense not to apply it, but this doesn't make it less fundamental than DRY.

lobster_johnson 10y ago

Ada requiring the redundant name after "end" isn't a violation of DRY at all. The DRY principle is about the codebase as a whole, where repetition can lead to elements getting out of sync. For example, instead of having an ORM define a mapping between classes and tables in, say, XML, DRY dictates that the mapping ought to be where it belongs, namely in the class declaration itself. Ada's repetition is really more about readability. If you see an "end", you always knows what it matches. (Personally, I think it's useless.)

trott 10y ago
> Ada requiring the redundant name after "end" isn't a violation of DRY at all. Yours is an arbitrarily narrow interpretation of the principle. To quote Dave Thomas, DRY states that "Every piece of knowledge in the development of something should have a single representation." The name of your function or block is one such piece. I agree that having the compiler check the consistency of the redundant statements ameliorates the situation somewhat, but it would be better if the problem wasn't there at all. [1] http://www.artima.com/intv/dry.html http://www.artima.com/intv/dry.html
- deleted 10y ago
  [deleted]
- lobster_johnson 10y ago
  The page you linked to directly refutes your claim of narrowness: Most people take DRY to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that. [...] DRY says that every piece of system knowledge should have one authoritative, unambiguous representation Note the terms knowledge and representation. He's referring to things like declarations, data models, schemas, facts. Duplicate source code symbols has nothing to do with it. DRY is not "be terse". For example, turning a literal into a constant is DRY, because it reduces to a single "authorative, unambiguous representation". But "x = x + 1" (which certainly looks redundant) is not anti-DRY, nor is "end Foo;".