Hacker News Reader

Comment by Mithaldu | Hacker News Reader

I may be perceiving this wrong, but it appears to me that in more recently newly created languages lexical scoping and explicit variable declaration are conspicuously absent. In the face of these features' positive effects on software quality and maintainability, i have to suspect that their lack is usually a conscious decision.

However, probably due to my inexperience in creating programming languages, i cannot think of reasons for this kind of decisions.

What could these be?

View on HN

I'm no language designer either, but I would guess that since Crystal wants to be 100% type inferred, they feel that having to type "var" or "let" is just boilerplate.

Even in type inferred languages they serve some use, namely in avoiding mis-typed variable names. Languages which require "var" make a distinction between the intent of declaring a new variable vs setting the value of an existing variable, and so are able to catch instances where the programmer tries to set a non-existent variable.

Or more tersely use := and = to distinguish them.

That has nothing to do with the scoping. There's no way to know whether "left = right" means "Set 'left' to 'right'" or "Create a new variable 'left', with value 'right'".

How are they different? Both produce the same end result, Python manages this syntax just fine.

"Just fine" is papering over the fact that people get tripped up by this in Python all the time – sometimes you need to use the `global` or `nonlocal` statements to resolve the ambiguity.

https://docs.python.org/3/reference/simple_stmts.html#global

https://docs.python.org/3/reference/simple_stmts.html#nonloc...

Classic example: http://stackoverflow.com/questions/9264763/unboundlocalerror...

If you search for UnboundLocalError on StackOverflow, there are 918 results. Not all of them are due to this particular scoping ambiguity, but many of them are.

It's a mistake even in Python. It makes typos harder to catch. And a visible distinction between variables that change and values that don't makes code much easier to reason about.

> In the face of these features' positive effects on software quality and maintainability

are you sure about this for explicit variable declaration? In my experience the problem is more with autovivification than with declaration-is-initialization.

I can't think of any recently-designed languages that do not have lexical scoping - can you?

I'm not sure I can think of any languages at all that have dynamic scoping since the early lisps.

Features like Scala's implicit parameters could be argued to be a kind of "dynamic scope". True, the language is lexically scoped and most code is written expecting that, but it does allow you to "opt out" of this scoping mechanism and look for values to be specified in the environment.

Perl my/our/local is the most unusual scoping I know of[1]. But still lexical, except maybe local which is more like an alias?

[1] http://www.perlmonks.org/?node_id=66677

my is lexical, our is global, local is dynamic.

I'll premptively add a bit of precision before a pedant comes along: my is lexical all the way; our defines a lexical binding over a global variable, and local defines a dynamic binding (of lexical extent) over a global.

Are you sure the pedant hasn't already arrived? ;-)

The only ones I can think of are Python and Javascript, both were created in the 90's.

Python and JavaScript both have lexical scoping - e.g. http://www.ecma-international.org/ecma-262/5.1/#sec-10.2.

Ah my mistake then, I must be misunderstanding what lexical scoping is.

One mans maintainability is another mans mess.

Reply on news.ycombinator.com