Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

breuleux.net

Post reply on HN
Print view View original

51–60 of 74 posts

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

#51

Post by breuleux »

legulere wrote: post #22
Learn2win wrote: post #4

In Racket, you can use "-" and "?" in variable names and I love it.

x-y and x - y meaning different things seems like a great source of errors to me

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.

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

#52

Post by Uncompetative »

breuleux wrote: post #51
legulere wrote: post #22

Earlier quoted context omitted.

x-y and x - y meaning different things seems like a great source of errors to me

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 subtr…

I don't have a problem with "x - y" and approve of hyphenated names if you can't support spaces within names.

I had initially jumped to the conclusion that your language would use a postfix notation and be more influenced by Forth than LISP. This is because I assumed it's name alluded to the way that Captain Jean Luc Picard would program his replicator.

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

#53

Post by kevin_thibedeau »

joliv wrote: post #47
akavel wrote: post #24

Earlier quoted context omitted.

A nice solution was used during development of the Go language: a tool for code rewriting (it was called "go fix"). It allowed the language authors to quickly and easily transform large swaths of code in the standard library, and also let everybody execute the same transformations in any third-party code. Thus enabling rapid and extremely painless iterations. [I'm consciously simplifying the story a bit to make it sh…

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.

I find it very useful but it does help to write forward compatible 2.x code and test frequently with 2to3 to catch what it misses.

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

#54

Post by kevin_thibedeau »

xjay wrote: post #13

Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used fir…

VHDL allows arbitrary text in its extended identifiers. The feature was added for easier interop with other tools that have less restrictive rules than VHDLs normal identifiers.

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

#55

Post by bhrgunatha »

zem wrote: post #8
adrusi wrote: post #5

Earlier quoted context omitted.

Well camel-case does reduce the length of the identifier without sacrificing clarity. This can help reduce line length, which, in turn, allows more files to be viewed on a single screen in splits, without wrapping or scrolling. I think this solidifies camel-case as the most practical style, if you ignore aesthetics. The underscore was invented to allow people using typewriters to underline text. I think that the hyph…

why would you ignore aesthetics? I'd much rather spend my time poring over pleasant looking code than ugly looking code.

Beauty is in the eye of the beholder?

Look at the never-ending discussions about s-expressions in Lisp and all its variants.

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

#56

Post by Uncompetative »

legulere wrote: post #21
xjay wrote: post #13

Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used fir…

Case-sensitivity makes sense because it enforces uniformity of code. Case insensitivity only matters when you want to write identifiers differently at different locations. The only place where I see this could be useful is when you use a library that uses a different convention. The IMO better way to solve this is to set a convention for your programming language and enforce it with the compiler (at least with warnin…

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.

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

#57

Post by bhrgunatha »

It's not surprising that changing a language would be difficult. It does, after all, include a software component, and pretty much all large software projects suffer the same. It can be easy to change minor technical details, but a deep, far-reaching design decision is very often fixed in place. Even with a good test-suite, that kind of change is rarely undertaken. At least in my experience.

I suspect we've all worked on software that you would desperately love to change something fundamental in the design but no matter how painful leaving it alone is, it is preferable to live with the pain than to tear it all down.

I've known a few writers for example that say they wish they could change their characters, but it's too late. I wonder if that's analogous.

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

#58

Post by labster »

MatthewMcDonald wrote: post #43
z92 wrote: post #32

Earlier quoted context omitted.

If you look at the code, and can't identify it as language X, then it probably deserves a new name.

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.

Under that definition, Perl and Python have finally merged, given Perl 6's Inline::Python. Peace at last!

I'd probably go with a definition more like "mutual intelligibility" like for natural languages, but that doesn't seem right either. Sometimes I have to turn on the subtitles for British TV.

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

#59

Post by 6502nerdface »

GregBuchholz wrote: post #48
xjay wrote: post #13

Curious. Are there examples of programming languages that allow spaces in identifiers? Obviously, it would need to be designed for that. I'm against the case-sensitive nature of some programming languages, and file systems for that matter. While it makes sense in a computing context (faster), you invent a new mode, just for the computer.. (Fortran was probably case-insensitive because upper-case letters were used fir…

Common Lisp allows spaces in identifiers and symbols names, but you have to quote it with vertical bars: (let ((|This variable has spaces| 1)) (print |This variable has spaces|))

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.

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

#60

Post by stepanhruda »

akavel wrote: post #24
lmm wrote: post #18

> There is a bit of a catch-22 in language design where the more a language is used, the clearer it becomes which parts of it are problematic and should change, but the harder it gets to actually change them. To hone a language you must use it, but applications require that a language's features remain stable, robust, set in stone, and therefore as imperfect as they were at that moment. Furthermore, the more delays a…

A nice solution was used during development of the Go language: a tool for code rewriting (it was called "go fix"). It allowed the language authors to quickly and easily transform large swaths of code in the standard library, and also let everybody execute the same transformations in any third-party code. Thus enabling rapid and extremely painless iterations. [I'm consciously simplifying the story a bit to make it sh…

Xcode/llvm has this with fixits.
Post reply on HN