Hacker News Reader

Hacker News

Comment by navane | Hacker News Reader

Full thread

navane

Why can't we just have spaces in our variable names? These are both work arounds.

View on HN

What about other identifiers? For example class names.

ThisClass thisVariable = null

The above is "obvious", as is the below:

this_class this_variable = null

However what is

this class this variable = null

Is it a variable named "variable" of type "this class this"? Is it a variable named "this variable" of type "this class"? Is it a variable named "class this variable" of type "this"?

Even in languages where you can have spaces, only jerks do that. Do you really want to type [Some stupid variable name].[some Stupid function]?

These are false time savers. We’re writing code, just recognize that and do what’s natural, snake_case. Any conventions to make code “more readable” to make it like written language seem like fool’s errands to me.

In languages without infix function calls, that should be possible, but I'm not sure how readable it would be.

    var initial factory = abstract configuration factory factory. configure new factory()

   var search result = users. find all by name (name);

   if (search result. is present()) { 
      return ok(search result. get());
   } else return not found();

It’s weird and syntax highlighting is absolutely necessary to read this.

Using something else than a dot is better, same as using a slightly different syntax:

   search result := users @ find all by name (name)

   if search result @ is present() { 
      return ok(search result @ get())
   } else {
     return not found()
   }

I still think the space adds more readability than the dot dectracts. If you don't like the dot though, I would use a comma. We have been writing for a couple centuries now, and the comma is well known and used.

   search result := users, find all by name (name)

   if search result, is present() { 
      return ok(search result, get())
   } else {
     return not found()
   }

I have to confess I rather like that comma!

Then we could use . instead of ; for line endings, and we're almost writing prose :)

Few more improvements:

   // comma is optional, used for disambiguation
   search result := users, find all by name. // omitted parameters match words

   if search result is present,  // empty brackets can be omitted
      return ok(search result value); // API change for better readability 
   else
      return: not found. // colon is another optional delimiter

I actually like it so much, I would try to write a transpiler to Java…

PowerShell yet again proves itself to be an enlightened language:

    PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.} = $True
    PS> ${Valid characters for an identifier? Eh, ¯\_(ツ)_/¯ whatever (`}) you want.}
    True

Jesting aside, I have actually used that syntax before to prefix variable names with '&' and '@' to differentiate between virtual and physical addresses in some code for patching a binary.

SQL gets this right. You can quote table and field names, so they can be arbitrary strings. I want to see this in more programming languages.

It would make languages like Python quite unreadable as it would be hard to distinguish between variables and keywords!

Colors/fonts/styles still exist?

So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.

I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol)

The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.

Removing keywords from variables is a big sacrifice when they are often such common glue words, like `and`, `or`, `if`, etc. Say `and` is the keyword and you want a variable called foo_and_bar. To get such words back you would need to add something so that the parser knows if

  foo and bar == true

means

  foo && bar == true

  foo_and_bar == true

You could fix it with ugliness like making the keyword `@and` or some such, or the variable `foo @and bar` but that's not an improvement.

Yes, it is, but it would also change the language, it is funny I forget c++ has “and” because && is so ubiquitous. Likely you will get changes so “if” is ? Or something. (Like we wee with ternary operator)

Like I said, I can’t picture the requirement, but am not sure it is a good idea.

That's not necessary at all, even FORTRAN managed to parse

   DO 10 I = 1.100

   DO10I = 1.1

and

   DO 10 I = 1,100

as the beginning of a loop ;)

We are already not allowed to use keywords as variables, this wouldn't change that.

I've never written a compiler, but I don't see how the last lines are harder to parse:

  if ( thisLooksAppealing )
  {
      youLikeCamelCase = true;
      votePoll( camelCaseFormatting );
  }
  else if ( this_looks_appealing )
  {
      you_like_underscores = true;
      vote_poll( underscore_formatting );
  }
  else if ( this looks appealing )
  {
      you like spaces = true;
      vote poll ( space formatting );
  }

You can parse the whole expression / statement and decide what it is.

You have to be careful with infix operators, but there is always Haskell's solution of adding backticks for infix names.

So add(a, b) is the same as a `add` b

But without joking, a _real_ solution to infix operator names would be a backslash as prefix, as pseudo-Latex-style, so a \add b

> Without spaces allowed you would need some other way to tell it where they start and end

That's not a problem at all, as long a a newline isn't treated as space and you don't use ML style function application, where a space is used to separate the argument(s) from the function name - `f x` instead of `f(x)`.

Crockford makes it work in his toy language in <https://www.amazon.com/How-JavaScript-Works-Douglas-Crockfor...>.

There is no reason to not do it, as it has been done in the past (Fortran for example changed that only with Fortran 90).

Two space bars?

tab where tab = 1 space

Note: this is not a good idea

Reply on news.ycombinator.com