Hacker News Reader

Comment by ErikCorry | Hacker News Reader

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

View on HN

I dont think that's the same kind of thing. Your example is a tradeoff that anyone who uses a language that doesn't require explicit variable declaration faces, and it's pretty tough to argue such languages really shouldn't exist.

Missing an operator resulting in explicit behavior is much more subtle and not even obvious behavior. For those who use python, it is worse.

  it's pretty tough to argue such languages really shouldn't exist

Well, I agree with OP so that is at least two people. I really don't see it as a good trade.

> ...it's pretty tough to argue such languages really shouldn't exist.

"Shouldn't exist" is too strong.

Dynamic languages that let you create a new variable via assignment shouldn't be used to create non-trivial software. How about that?

Scripting languages have a place. That place is 100% in creating quick-and-dirty scripts and tools. Or in doing some kind of one-off data transform (as is common in machine learning scenarios). Anything that has a life span of two weeks or less, or a code length of fewer than a hundred lines? Yeah, script languages rock for that.

Explicit/static typing adds vastly more value to large projects than the cost of the overhead. The fact that you can't really gain that value in Python means that Python should be relegated to quick and dirty scripts.

Same for JavaScript, Ruby, and other completely dynamic languages.

You'll note that all of these languages are getting types one way or another, meaning that there are a lot of people who do recognize their value. Though TypeScript is years ahead of the rest in the completeness and sophisticated of its type system; bugs like the comma bug detailed by OP, along with simply every JavaScript "wat" bug, simply can't happen in TypeScript in strict mode. And static types enables entire other categories of bugs to be detectable via a linter as well.

I've been building non-trivial software in dynamic languages for twenty years. They work great.

I'd take a project in a dynamic language with a decent test suite over a project without tests in a statically typed language any day of the week.

> I'd take a project in a dynamic language with a decent test suite over a project without tests in a statically typed language any day of the week.

I'd take the opposite. I've read too many useless tests in python codebases that can be accomplished by a static type checker. "Decent" does a lot of heavy lifting in your comment. And what about a dynamically typed codebase without any tests? I'm sure they exist.

I'd rather dive into a big ball of mud with a compiler that will help point me to my mistakes before I release them, than having to sift through a ball of mud trying to find that mistake with production services flailing.

That all being said I've worked with both types of languages in successful projects. But I prefer the development experience of the statically typed variety.

But a dynamic language needs all the tests a compiled language needs AND type/syntax tests (that are handled by the compiler in a static language).

There are reasons dynamic language (or specifically Python), but I haven't heard one explanation how it helps writing fewer tests.

Explicit variable declaration is just adding a keyword (such as var or let) when you're declaring a new variable instead of modifying one.

The cognitive burden of having to memorize and look for which variables are new vs which are being modified is simply not worth it in my opinion, even for a scripting language. Maybe for esolangs, simple math or first time learning programming.

In any case, it's a short coming of the language (IMO) but not a deal breaker. We learn to live with it.

I'd say unexpected behavior is always worse than expected one.

Yes, you'll certainly find somebody who doesn't know what 'not statically typed' means, but ... And yes, there are also C(++) users, that expect strings to be concatenated like that.

You seem to also not know what "not statically typed" means. It certainly does not mean "not properly scoped".

Yes, of course. But you see that no scope keywords exist in Python. But there exists `+` to concatenate strings (too).

Keywords like namespace, no; but functions and classes and modules provide for a lot of scoping opportunities.

The problem is `fop` should be `foo`:

    foo = 5
    fop = 6

Keywords like `let` solve this problem:

   let foo = 5
   fop = 6 # error

Or := for declaration like Go and Toit

Yes, or another symbol instead of `=` for assignment, like `<-` (F#)

Not entirely:

  let foo = a();
  let foo = b(foo);
  let fop = c(foo);
  let foo = d(foo);

(Which is valid, e.g., in Rust.)

You do get a warning, though. And most Rust projects I've seen usually adhere to 0 warnings.

I hate variables shadowing, I'm very surprised that they allowed it in Rust, I saw an unpected behaviour caused by variable shadowing in C++ (global variable hidden by member variable) just last week..

A good IDE has many other safety nets for that error.

Auto completion, highlight matching variable, gray out unread variables and warning of unused assignment.

I’ve written lots of python and can’t recall ever having this issue. More likely is a logic typo of two similar variables like length_x vs length_y, where a “let” wouldn’t have saved you anyway if both are already defined.

JavaScript, pre strict TS, on the other hand, where missing var implied global was a real motherload of bugs. Or kotlins “val” vs “var” changing semantics completely…wow. But those are different concepts from basic definition I know.

I left python around the times of 2/3 drama, are nonlocal and global not there anymore?

While I agree, this is somehow something I expect. Implicit string concatenation without operator or function around it sounds just like a terrible idea. It breaks the basic syntax concept of `foo X bar`. On the other hand it is probably very handy with DSLs and things like that.

Not so much DSLs, it's probably something as banal and ancient as

  usage = (
    'usage: foo [options] filenames...\n'
    '  -f force concatenation\n'
    '  -c for convenience\n'
  )
  print usage

Edit: forgot to add parentheses

Isn't that common for all/most languages that don't require explicit typing?

It would be impossible in any language that requires either explicit typing or some kind of 'let' keyword. (Or, in the fringe case, a language like Go which uses a different operator for initialisation-plus-assignment.)

Exactly. That's why I asked about languages that don't require explicit typing. My point is that it's a feature of many languages rather than a Python idiosyncrasy.

JavaScript (strict mode) doesn't have explicit typing, but it still requires variables to be declared.

Same for Perl.

Uh? Perl optionally requires you to declare variables, which is a good idea IMHO, no noise for small script and any experimented Perl programmer will have learned that 'use strict' is a really good idea for big scripts..

Declaration and explicit typing are logically orthogonal, but few if any languages require typing but not declaration. Lots require declaration but not typing.

This is a scoping rule, not typing. Scoping is a mechanism of symbol resolution, i.e. what do you mean by `foo` at line N. Is it a local, an argument, a global, or addresses a symbol defined in an enclosing scope? Most languages use explicit local definitions, searching implicit ones in outer scopes bottom-up, ending at the global scope. Python was the first popular non-basic language which made implicit assignments to be local and shadowing and function-scoped:

  global x = 1
  def setx():
    if True:
      x = 2 # completely different x
    print x # prints 2, visible outside of `if`
  setx()
  print x # prints 1

This led to a funny keyword 'nonlocal', because you can't simply ignore scoping and pretend that you're BASIC in any serious program.

(To my opinion, python had a good start, but lost in the woods for no clear reason. It's a movie mutant of a language, which tried to appeal to non-programmers and somehow succeed, and then realized that non-programmers eventually become ones, and it's not hard. Now it's too late to fix this mess. End of opinion.)

It is common tonall languages that have the same syntax for definitions and mutation.

In Scheme, for example, this is not an issue.

That’s a complaint against the entire type system, nothing to do with misspelling.

It has nothing to do with the type system? It's an issue with implicit declaration. You could very easily require explicit declaration while retaining the selfsame type system.

Huh, you're right. It would be bizarre to see something like this in Python though. I've never even thought of it as being implicit declaration.

Reply on news.ycombinator.com