Redundancy in Programming Languages

https://www.digitalmars.com/articles/b05.html

by pcr910303 • 6 years ago

54 30 6 years ago

kungato• 6 years ago

You use unit tests in Python and Javascript among other things to check for type/value in some places which can be easily avoided if you explicitly used types. Also I often see in imperative languages that unit tests are used to declaratively describe something which you had to imperatively implement. To me it often feels like declarative functional languages have these features immediately as you write the code but then you have to invest the mental effort up front so people rather do half the thinking first then wrap things up with unit tests. The problem is you have to go back to the initial code when wiritng unit tests which fail while you could have done the complete work the first time around. Often it feels like people don't want to do too much work so they choose the language which allows them to offload erorrs for later. It even makes business sense to finish sooner then charge for maintenance later. A shame really

graham_paul• 6 years ago

people don't want to do too much work so they choose the language which allows them to offload erors for later

Replace "people" with business and you are right. I feel many devs would prefer to invest the time once rather than hack it once then go back and add unit tests

userbinator2• 6 years ago

Programming languages extensively use this to reduce coding errors. If there was no redundancy at all in a language, then any random sequence of characters would be a valid program.

This is completely opposite to the philosophy of the APL-family languages, and those who have learned them seem to also argue strongly that the conciseness reduces errors and makes for higher productivity.

Probably the best example of redundancy in a programming language is unit tests.

Some of my worst experiences have been fighting unit tests that were "overspecified", i.e. testing for inputs which would otherwise be clearly impossible in the context of the whole system, with the result that any trivial change to the code can cause test failures that consume time to diagnose, despite zero change to the ultimate functionality of the system.

Supermancho2• 6 years ago

testing for inputs which would otherwise be clearly impossible in the context of the whole system

Off the top of my head...

1. When reusing code, unit tests that specify unexpected inputs are useful because you don't know the future use case. That's a rather weak reason to write the unit tests now, but a reason.

2. There is no way to enforce what is an expected input to a function, once a system grows large enough. Changes in the upstream dataflow being traced through the system by investigating every unit test is impractical. Being defensive up front, is reasonable.

cageface2• 6 years ago

There is no way to enforce what is an expected input to a function, once a system grows large enough.

This is exactly what typechecking does for you and is the reason I think trying to build any large system without them is a bad idea.

userbinator2• 6 years ago

because you don't know the future use case

...and thus you shouldn't care about it. I've seen enough problems caused by attempts at "futureproofing" to know that YAGNI is always a good choice. When/if it does matter, then you can do the work; but inevitably, requirements always seem to change in such a way that your attempts to anticipate them results in code that's structured to be flexible in exactly the wrong way, adding unnecessary complexity, or even hinders the desired changes.

constantine42• 6 years ago

Useful redundancy is a continuum. On one side is adding "unnecessary" null checks. On the other side re-implementing complex business logic checks. I like to strike a balance.

"Overspeced" unit tests? They should only be testing the API contracts and all edge cases. And refactoring your code should not result in changes to the unit tests as the purpose of the unit test is to tell you if your refactoring broke something. If you have to change your unit tests when you refactor, you're doing something wrong.

Fighting unit tests is a code smell for testing implementation details or poorly designed API that needs to keep changing.

I've been bitten by "clearly impossible in the context of the whole system" way too many times. That said, I'm not going to do horribly complex implementation detailed validation. But sanity checks are worth their weight in gold.

didibus• 6 years ago

And refactoring your code should not result in changes to the unit tests as the purpose of the unit test is to tell you if your refactoring broke something. If you have to change your unit tests when you refactor, you're doing something wrong

I disagree a bit here. Without getting pendantic about units and refactors, in practice, it is common to want to modify methods that have unit tests for them. Maybe you want to break out the method into two, or break the class into two classes, or you want to improve the method's interface, change the types it takes, its parameters, the structure it returns, etc.

All these changes will most likely break your unit tests. If they didn't break the unit tests for the method, I'd actually be curious what it was even testing.

Above this, people often in practice also unit tests private methods, so you've often got to deal with those type of unit tests as well even if you're only touching the inside of a class and leaving the public methods intact.

And beyond refactoring, sometimes you are simply adding a new feature or fixing a bug, and this will result in you maybe choosing to modify the behavior of some existing class and its methods. These changes will also break your unit tests.

What all the use cases I just listed have in common is that all of them have good reasons to break the unit tests, and will result in people simply going and changing the tests to reflect the new changes.

WalterBright4• 6 years ago

I have yet to see any language feature that cannot be used to create a steaming pile of parrot droppings by a well-meaning programmer ticking every box of "best practices".

einpoklum3• 6 years ago

APL is a wonderfully imaginative language. But - it is difficult to decipher, and I would imagine rather difficult to debug. (Not to mention requiring a specialty keyboard...)

ddevault• 6 years ago

There was some debate at an old job about whether or not to use semicolons in JavaScript. I would just like to remind everyone reading this that if you don't write semicolons in your JavaScript, you are doing it wrong, and we cannot be friends.

jakear3• 6 years ago

I’ve said it before, I’ll say it again. Semicolon-free JS is much easier to edit, and the typical foot-guns associated with it can be trivially avoided with a formatter/linter.

tylorr• 6 years ago

Semicolons can also be automated, which is what I currently do at work.

SPBS• 6 years ago

Semicolon JavaScript is trivially easy to write with a formatter -- just hit format and it inserts semicolons for you. And has no footguns.

throw_m2393392• 6 years ago

There was some debate at an old job about whether or not to use semicolons in JavaScript. I would just like to remind everyone reading this that if you don't write semicolons in your JavaScript, you are doing it wrong, and we cannot be friends.

Well the great thing with that issue is that you can use tools that will forcefully put semi-colons in code and no rely on automatic insertion at runtime.

There is no excuse today not to do that. Of course, sticking to a specific coding style and enforcing it automatically with QA tools during CI is also something easy to do and should be mandatory for any codebase.

WalterBright4• 6 years ago

Author here. AMA.

tsegratis• 6 years ago

I like your observations in this article, but I find them really hard to apply to design

Redundancy is evil... but also essential. What characteristics distinguish one end of redundancy from the other?

WalterBright4• 6 years ago

What characteristics distinguish one end of redundancy from the other?

Hard to say. Some call it simply "good taste".

scared2• 6 years ago

Why do you this authors of these programming languages try to creat a different set of keyword names and syntax. If google liked python why not follow the already familiarpython syntax to create go?

jhanschoo• 6 years ago

Different languages have different semantics, so the language designers choose to use a different syntax to reflect the different semantics.

throw_m2393392• 6 years ago

Just remove ++p or p++ from your language, problem solved ;)

Interesting blogpost though I do not agree on everything you say but I respect your perspective as a language designer and developer.

einpoklum3• 6 years ago

1. That article is short, clear and makes its (IMHO somewhat obvious) valid point well. 2. ... is the article at all about D?

closeparen• 6 years ago

There are similar stories for gendered articles and conjugation in natural languages. They don't convey any additional information, but in case you miss the word, they provide clues elsewhere in the sentence that significantly constrain what it could have been.

therealdrag0• 6 years ago

Reminds me of a bug I found in some Scala code.

  def getString: String = {
    "I am a value to be resolved"
  }
  
  def wrapper1(auth)(thunk: => String): String = {
    if(auth)
      thunk
  }
  
  def wrapper2(auth)(valueAlreadyResolved: String): String = {
    if(auth)
      valueAlreadyResolved. // Auth check did nothing, code already ran!!!
  }
  
  wrapper1(auth)(getString)
  wrapper2(auth)(getString)

These two method signatures/behavior are different but the syntax to call them is identical! One executes "getString" only when the parameter is referenced (v1), the other (v2) executes it before the wrapper is even entered.

This sort of flexibility can be handy, but it can also shoot you in the foot. Some languages like I think Java make you do something like "::getString" to pass a function pointer. That redundancy makes it explicit and prevents the mistake above which could have serious implications.

einpoklum3• 6 years ago

Eliminating redundancy is often viewed as a way to streamline productivity and reduce waste

AFAICT, that is much more often said about _programs_ (and perhaps libraries) than about programming _languages_.

Redundancy in Programming Languages

Related Stories