41–50 of 74 posts
Unfortunately, I can't say this is unexpected: http://breuleux.github.io/earl-grey/repl/
> I chose to compile Earl Grey to JavaScript Some programming languages generate code much deeper down the abstraction stack, e.g. Haskell generating machine code, whereas others generate code to a much shallower depth, e.g. most languages generating JavaScript. A language generating lisp code from some syntax could even be shunting code up the abstraction stack. How deep does the generated code need to be down the s…
If you look at the code, and can't identify it as language X, then it probably deserves a new name.
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.
> 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…
Earlier quoted context omitted.
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…
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…
You would still need it to get uniform code. Spaces vs. tabs also doesn't matter but it's still in almost all style guides.
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 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.
> 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…
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…
(let ((|This variable has spaces| 1))
(print |This variable has spaces|))Earlier quoted context omitted.
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…
> 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…
It actually drives me a little nuts that I can't do the same thing in Elixir (compiler enforced lowercase) because so much of the code looks the same.
[deleted]
> I don't understand why people would use a dash "-" inside a symbol No need to use the shift key. At the levels of efficiency that a good language can reach, this matters. Also, dashes match established lexicographical conventions better than underscores because dashes look like hyphens.