<p>For me, one of the best things to happen to FORTRAN was the introduction of the <code>LOGICAL*1</code> type.
I quickly discovered that putting <code>IMPLICIT LOGICAL*1 (A-Z)</code> at the top of every program was a life saver.</p>
<p>Knowing about this one line saved me hours of work debugging new code, where many typos resulted in defining a new variable rather than producing an error message.</p>
<p>The iconic example is:</p>
<pre><code>      INTEGER I
      INTEGER SUM

      SUM = 0
      DO 10 I=1,10
   10 SUM = SUM + I
      PRINT 11, SUM
   11 FORMAT (I10)

      SUM = 0
      DO 20 I=1.100
   20 SUM = SUM + I
      PRINT 21, SUM
   21 FORMAT(I10)

      STOP
      END
</code></pre>
<p>One would expect the output to be:</p>
<blockquote>
<pre><code>   55
 5050
</code></pre>
</blockquote>
<p>But in fact it is:</p>
<blockquote>
<pre><code>   55
   11
</code></pre>
</blockquote>
<p>The typo might be obvious to you now, but imagine that the line is written along the top edge of a punch card by a misaligned dot-matrix printer with a bad ribbon.
Then imagine that that one card is buried in a deck of thousands of cards, and rather than being part of an immediately following <code>PRINT</code>, the error doesn't become apparent until hundreds of lines later.</p>
<p>One could easily spend hours tracking down the typo.</p>
<p>But if we began the program with <code>IMPLICIT LOGICAL*1 (A-Z)</code>, the compiler would quickly report the problem:</p>
<blockquote>
<p>12 |       DO 20 I=1.100
|              1
Error: Cannot convert REAL(4) to LOGICAL(1) at (1)</p>
</blockquote>
<p>And the difference between a faint blurry comma and a faint blurry period becomes apparent.</p>
<p>But the <code>IMPLICITLOGICAL*1(A,Z)</code> was only a work-around (albeit a very useful one).
The underlying problem was that the implicit definition of variables created a large potential for hard to detect errors.</p>
<p>I later moved on to &quot;B&quot; and &quot;C&quot;, where every identifier had to be explicitly declared, and life was wonderful.</p>
<p>But then even newer languages appeared, and shockingly they had reverted back to implicit definitions.</p>
<p>Having seen the problems with FORTRAN, and their elimination with &quot;B&quot; and &quot;C&quot;, why would the designers of the newer languages think that implicit declarations were a good idea?</p>

<language-design><variables><declarations>
Why do newer languages allow implicit variable declarations?
<p>This is an issue of philosophy, and what the language is meant to be used for.</p>
<p>On the one hand there are languages which want to empower the programmer to write code which checks itself for correctness ─ the idea being that it saves time to catch bugs at compile-time instead of runtime, so the language should require the programmer to write in a way that allows mistakes to be detected at compile-time. This is the viewpoint espoused in your question; it leads to static type systems, <code>var</code> vs. <code>const</code> and readonly/immutable properties, visibility modifiers, and all sorts of other static analyses which will be checked but then erased by the compiler, and have no effect at runtime.</p>
<p>On the other hand there are languages which want to make it quicker and easier to write a program ─ the idea being that the programmer should only have to write code to say what the program does, and not have to write extra code to prove to the compiler that the program does what it is supposed to do. This viewpoint leads to dynamically typed languages, variables that don't need to be declared, all properties being mutable and public, and runtime errors for mistakes that would be compile-time errors in the other category.</p>
<p>Both viewpoints have their place. Generally speaking I think languages in the first camp are better suited for larger or more critical software projects, while languages in the second camp are good for smaller or more experimental projects ─ particularly simple programs that are unlikely to have many mistakes, scripts that will probably not be used more than a few times, or proof-of-concept prototypes where you just want to see if some idea will work.</p>
<p>It's worth adding that there's still a wide range of strictness in the first camp, with some languages even allowing the programmer to write preconditions, postconditions, invariants and formal proofs that the compiler can check. And languages in the second camp can still have tooling to detect some errors before runtime ─ for example, if you misspell a variable name, a linter might notice that the correctly-named variable is unused or has a <a href="https://en.wikipedia.org/wiki/Dead_store" rel="noreferrer">dead store</a>. So really there's a spectrum.</p>
<p>Additionally, as languages in the second camp mature, and start to be used for larger or more important projects, they typically add features which move them a bit in the direction of the first camp, e.g. <code>const</code> and private properties in Javascript, or optional type annotations in Python. So this might explain why &quot;newer&quot; languages are more likely to be closer to the second camp, although there are plenty of &quot;new&quot; languages like Rust which are firmly in the first and plenty of &quot;old&quot; languages like Lisp which are firmly in the second.</p>

CC BY-SA 4.0
2023-05-19T03:57:53.593Z
2023-05-19T05:05:41.253Z
2023-05-19T05:05:41.253Z
kaya3
<h1>JS: A weird consistency</h1>
<p>Consider these two rules in JavaScript:</p>
<ol>
<li>You may write a property that an object doesn’t already have.</li>
</ol>
<pre class="lang-js prettyprint-override"><code>let x = {};
x.a = 2;
</code></pre>
<ol start="2">
<li>If an identifier is not declared by <code>function</code> or <code>var</code> (or <code>let</code>, <code>const</code>, or <code>class</code> in modern JS), it references a property on the global object (e.g. <code>window</code> in a browser).</li>
</ol>
<pre class="lang-js prettyprint-override"><code>setTimeout(() =&gt; {}, 1000); // calls window.setTimeout
</code></pre>
<p>Therefore, assigning to an undeclared identifier will add a property to the global object.</p>

CC BY-SA 4.0
2023-05-19T03:33:46.527Z
2023-05-19T03:33:46.527Z
Bbrk24
CC BY-SA 4.0
2023-05-19T05:32:56.840Z
So are you saying that the developers of JS thought implicitly declared global variables were a *good idea*, because that behavior was consistent with the rest of the language? I'm experiencing a bit of cognitive dissonance here, since I'm so used to thinking of this feature as a *bad* thing to be avoided at all costs. I guess I assumed--perhaps incorrectly--that it must not have been an intentionally designed feature but rather something of an accident, with a later partial fix in the form of strict mode.
DLosc
CC BY-SA 4.0
2023-05-19T07:28:11.600Z
@DLosc I don't know about this specific point, but the initial design of Javascript was famously done under great time pressure, and many of the initial decisions were solely based on what the author could implement in the few days that he had, or were just the first thing he happened to write.
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-19T07:33:11.197Z
@DLosc I think "make everything implicitly global" is not so universally agreed as a bad idea for language design in all contexts; consider shell scripting languages, for example. Perl, PHP and other dynamic scripting languages designed in the late 80s/early 90s were arguably closer in spirit to shell scripts than they were to C or Java. These languages were not designed for writing large, complex software; it made sense to encourage globals because it made the language easy to use for its intended purposes.
kaya3
CC BY-SA 4.0
2023-05-19T11:22:33.137Z
I will point out that this behavior is disabled in strict mode, so clearly the maintainers of the language saw the drawbacks to this behavior.
Bbrk24
CC BY-SA 4.0
2023-11-15T22:55:19.777Z
IMHO, JavaScript could have benefited from having discrete assignment operators for "Modify field that must already exists", "Create field that must not exist", and "Create or modify field, based upon whether it exists", since a lot of code could use one of the first two forms, and use of such forms when applicable would make code much more robust.
supercat
# Why do newer languages allow implicit variable declarations?
Posted by: username_0 on 2023-05-19
For me, one of the best things to happen to FORTRAN was the introduction of the LOGICAL*1 type.
I quickly discovered that putting IMPLICIT LOGICAL*1 (A-Z) at the top of every program was a life saver.
Knowing about this one line saved me hours of work debugging new code, where many typos resulted in defining a new variable rather than producing an error message.
The iconic example is:
      INTEGER I
      INTEGER SUM

      SUM = 0
      DO 10 I=1,10
   10 SUM = SUM + I
      PRINT 11, SUM
   11 FORMAT (I10)

      SUM = 0
      DO 20 I=1.100
   20 SUM = SUM + I
      PRINT 21, SUM
   21 FORMAT(I10)

      STOP
      END

One would expect the output to be:

   55
 5050


But in fact it is:

   55
   11


The typo might be obvious to you now, but imagine that the line is written along the top edge of a punch card by a misaligned dot-matrix printer with a bad ribbon.
Then imagine that that one card is buried in a deck of thousands of cards, and rather than being part of an immediately following PRINT, the error doesn't become apparent until hundreds of lines later.
One could easily spend hours tracking down the typo.
But if we began the program with IMPLICIT LOGICAL*1 (A-Z), the compiler would quickly report the problem:

12 |       DO 20 I=1.100
|              1
Error: Cannot convert REAL(4) to LOGICAL(1) at (1)

And the difference between a faint blurry comma and a faint blurry period becomes apparent.
But the IMPLICITLOGICAL*1(A,Z) was only a work-around (albeit a very useful one).
The underlying problem was that the implicit definition of variables created a large potential for hard to detect errors.
I later moved on to "B" and "C", where every identifier had to be explicitly declared, and life was wonderful.
But then even newer languages appeared, and shockingly they had reverted back to implicit definitions.
Having seen the problems with FORTRAN, and their elimination with "B" and "C", why would the designers of the newer languages think that implicit declarations were a good idea?
**Tags:** language-design variables declarations
---
## 2 answers
### Answer by username_1 on 2023-05-19. Score: 7
This is an issue of philosophy, and what the language is meant to be used for.

On the one hand there are languages which want to empower the programmer to write code which checks itself for correctness ─ the idea being that it saves time to catch bugs at compile-time instead of runtime, so the language should require the programmer to write in a way that allows mistakes to be detected at compile-time. This is the viewpoint espoused in your question; it leads to static type systems, `var` vs. `const` and readonly/immutable properties, visibility modifiers, and all sorts of other static analyses which will be checked but then erased by the compiler, and have no effect at runtime.

On the other hand there are languages which want to make it quicker and easier to write a program ─ the idea being that the programmer should only have to write code to say what the program does, and not have to write extra code to prove to the compiler that the program does what it is supposed to do. This viewpoint leads to dynamically typed languages, variables that don't need to be declared, all properties being mutable and public, and runtime errors for mistakes that would be compile-time errors in the other category.

Both viewpoints have their place. Generally speaking I think languages in the first camp are better suited for larger or more critical software projects, while languages in the second camp are good for smaller or more experimental projects ─ particularly simple programs that are unlikely to have many mistakes, scripts that will probably not be used more than a few times, or proof-of-concept prototypes where you just want to see if some idea will work.

It's worth adding that there's still a wide range of strictness in the first camp, with some languages even allowing the programmer to write preconditions, postconditions, invariants and formal proofs that the compiler can check. And languages in the second camp can still have tooling to detect some errors before runtime ─ for example, if you misspell a variable name, a linter might notice that the correctly-named variable is unused or has a [dead store](https://en.wikipedia.org/wiki/Dead_store). So really there's a spectrum.

Additionally, as languages in the second camp mature, and start to be used for larger or more important projects, they typically add features which move them a bit in the direction of the first camp, e.g. `const` and private properties in Javascript, or optional type annotations in Python. So this might explain why "newer" languages are more likely to be closer to the second camp, although there are plenty of "new" languages like Rust which are firmly in the first and plenty of "old" languages like Lisp which are firmly in the second.
---
### Answer by username_2 on 2023-05-19. Score: 3
JS: A weird consistency
Consider these two rules in JavaScript:

You may write a property that an object doesn’t already have.

let x = {};
x.a = 2;


If an identifier is not declared by function or var (or let, const, or class in modern JS), it references a property on the global object (e.g. window in a browser).

setTimeout(() => {}, 1000); // calls window.setTimeout

Therefore, assigning to an undeclared identifier will add a property to the global object.
> **Comments:**
> **username_3** (2023-05-19): So are you saying that the developers of JS thought implicitly declared global variables were a *good idea*, because that behavior was consistent with the rest of the language? I'm experiencing a bit of cognitive dissonance here, since I'm so used to thinking of this feature as a *bad* thing to be avoided at all costs. I guess I assumed--perhaps incorrectly--that it must not have been an intentionally designed feature but rather something of an accident, with a later partial fix in the form of strict mode.  
> **username_4** (2023-05-19): @DLosc I don't know about this specific point, but the initial design of Javascript was famously done under great time pressure, and many of the initial decisions were solely based on what the author could implement in the few days that he had, or were just the first thing he happened to write.  
> **username_1** (2023-05-19): @DLosc I think "make everything implicitly global" is not so universally agreed as a bad idea for language design in all contexts; consider shell scripting languages, for example. Perl, PHP and other dynamic scripting languages designed in the late 80s/early 90s were arguably closer in spirit to shell scripts than they were to C or Java. These languages were not designed for writing large, complex software; it made sense to encourage globals because it made the language easy to use for its intended purposes.  
> **username_2** (2023-05-19): I will point out that this behavior is disabled in strict mode, so clearly the maintainers of the language saw the drawbacks to this behavior.  
> **username_5** (2023-11-15): IMHO, JavaScript could have benefited from having discrete assignment operators for "Modify field that must already exists", "Create field that must not exist", and "Create or modify field, based upon whether it exists", since a lot of code could use one of the first two forms, and use of such forms when applicable would make code much more robust.  
---
