“Screw it, I'll make my own” – The story of a new programming language

The formal definition of a version of Perl 6 corresponds to (a frozen version of) the Perl 6 test suite (currently around 120K unit tests).

A compiler declares its claimed compliance by reference to these test suites:

  > perl6 -v
  This is Rakudo version 2016.01.1
  built on MoarVM version 2016.01
  implementing Perl 6.c.

6.c labels a frozen version of the Perl 6 test suite and thus a version of the Perl 6 language.

All serious users of the language are encouraged to check/improve the language test suite to ensure it covers what they want covered in either an existing version or an upcoming one.

I think that's a neat idea. I've thought about it, but I've never used Go personally and I wasn't sure just how much it would help. I imagine it works best for languages with good static properties/tools for code analysis.

Yeah, Python tried this as well with their 2to3 tool (https://docs.python.org/3.5/library/2to3.html), but their release bump was a little bigger than the Go prerelease changes (and the users not as flexible) so it wasn't much of a magic bullet.

Xcode/llvm has this with fixits.

go fix didn't worked all the time. there were some edge cases where it failed. also syntax of go didn't changed much.

As you say, it's about conventions, but with a case-Sensitive system you are more likely going to HAVE TO enforce naming conventions, because there's a distinction now. Otherwise you'd write "MidiPort"/"MIDIPort"/"midiPort" or what have you.

Keep in mind we wouldn't need to care about enforcing case in a style guide, if case didn't matter, because there are no distinctions, and you'd be more inclined to write it the natural way; no camelCase to overrule ambiguation in writing "MIDI Port" as midiPort, or MidiPort, MIDIport, etc.

Case-sensitivity only creates unnecessary dissonance, and leads to clever uses of that system, adding even more choice; and as we know from The Matrix, the problem is choice. ;)

So if we keep it closer to how we would normally read and write words, I think there would be less dissonance about that aspect of programming, or naming files for that matter.

> Case-sensitivity makes sense because it enforces uniformity of code.

I don't see that case-sensitivity helps to achieve uniformity of code that much. Factors like code structure, common design patterns, and source code formatting are more important. The approach to the structure and design of an application or library is something that each individual development group decides for themselves. Source code formatting can (and should) be enforced by formatting tools.

Having used a case-insensitive language for a while (Object Pascal) I find that developers tend to follow the case convention of a given software project anyway and if they don't the case-sensitive typos aren't an issue. They don't make the code harder to understand and it all compiles.

I approve of case-sensitivity where an initial Capital letter indicates that Something is Publically accessible and it really doesn't matter what happens after that. Hence, we could have:

  Newton-Raphson Runge-Kutta Fast-Fourier-Transform

  Class-ID IO-Channel MIDI-port 

  Freudian-Id Io-Channel

In contrast to this, I feel it makes sense to have lowercase mean that something is private. Hence, no camelCase:

  x y z variable longer-variable-name

I've never been that comfortable about appending numerals to the end of identifiers to disambiguate them as I feel that this is a sign that they ideally ought to be subscripted and implemented as arrays. I much prefer hyphens to underscores but would ideally like to use individual words separated by spaces. This can only work if you have an IDE that hides all the underscores (which are incredibly ugly and serve no useful purpose in printed material these days) as you input them and outputs NBSPs instead and then uses similarly suppressed prefix sigils to style your raw input text into an output which conforms to traditional Mathematical notation. Hence, we could have:

  /foo_bar + /bar_qux

become:

foo bar + bar qux

similarly, the following is not a problem if you take advantage of the syntax rule that requires at least one space either side of an operator. Hence, we could have:

  /foo_bar / /bar-qux

become:

foo bar / bar-qux

i.e. the / sign isn't echoed when you initially type it as it is expecting a letter, but when the IDE receives whitespace it belatedly echoes it as the operator symbol as it is now sure that it isn't a suppressed sigil.

Yes, I alluded to that by way of the sixth bit, I just had no reference to whether it was something they chose to do, or had no other choice at the time.

Similarly, R (which is basically a Lisp with C-like syntax) allows spaces in identifiers, though you'll have to construct usages of such identifiers using quote() or backticks.

That's not a problem because subtraction in Racket, as in any Lisp-like, looks like this:

    (- x y)

It depends on a couple of factors. Personally I always write subtraction as "x - y", so I never have any issues. Also, if undeclared variables are a compile-time error, the compiler will (probably) complain loudly about "x-y". So you can fix that quickly and easily, it's not too bad.

The one error that might be problematic depending on the language's semantics is if you write something like "x.y-z" intending to subtract "z" from "x.y", but in fact you are going to get the "y-z" property of "x". I must say that in Earl Grey you'll unfortunately end up with "undefined" as the result of that expression (saner languages would raise an exception on a missing property). I have never had that issue in practice, but then again, I always space subtraction.

This sounds pretty similar to the definition of a species.

If two organisms of appropriate gender can't reproduce with each other, then they probably aren't the same species.

If code from two samples can't be interspersed, then it's probably not the same language.