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…
“Screw it, I'll make my own” – The story of a new programming language
31–40 of 74 posts
Re: “Screw it, I'll make my own” – The story of a new programming language
#32> 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…
Re: “Screw it, I'll make my own” – The story of a new programming language
#33Ahem, cough, cough, er, ...
Re: “Screw it, I'll make my own” – The story of a new programming language
#34Re: “Screw it, I'll make my own” – The story of a new programming language
#35Curious. 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…
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.
Re: “Screw it, I'll make my own” – The story of a new programming language
#36> 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…
Major version switches not only don't retain backwards compatibility, but have in the past drastically changed the language. With v5.0 they finally seemed to hit on a good combination of features, syntax, and semantics, and the pace of new major releases has slowed noticeably.
Re: “Screw it, I'll make my own” – The story of a new programming language
#37Curious. 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…
Fortran was case-insensitive because it used early character encodings that did not support sensitivity.
Re: “Screw it, I'll make my own” – The story of a new programming language
#38Unfortunately, I can't say this is unexpected: http://breuleux.github.io/earl-grey/repl/
Re: “Screw it, I'll make my own” – The story of a new programming language
#39Curious. 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…
I found some more tidbits in these StackOverflow answers:
http://programmers.stackexchange.com/questions/145751/has-wh...
Re: “Screw it, I'll make my own” – The story of a new programming language
#40Earlier quoted context omitted.
Meta characters were also added for file, unit, record, and group separators. Some may correctly argue that using these chars to structure data in flat files is a more simple and technically superior solution to the alternatives. Still, people will stick to what they're familiar with despite the technical benefits. That's why we have CSV, TSV, JSON, etc. I'd argue that 'most practical' is whatever format most people…
"whatever format most people immediately understand at first glance" Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation. But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use…
While optimizing syntax/form makes sense in highly specialized domains where no useful alternative exists, I'd argue that the opposite holds true in domains where more 'natural' alternatives are abundant.
Can't say I'm familiar with all of those. For proofreading, meta chars are necessary to indicate edits without the ability to mutate the original text. Musical notation has widely been replaced by tabs for guitar. Shorthand may be useful for writing that isn't consumed by others.
Cursive is a perfect example of a form of language that was created for efficiency. Which, arguably, held true for handwriting. But it didn't add enough of a benefit above/beyond plain handwritten text and was very difficult to duplicate digitally.
Not to rag on Fourth, I'm sure it's probably a very good language but how widely is it used today?
Like I said, no amount of research proving that programmers choose languages based purely on their technical merits can disprove the writing on the wall.
People choose what feels natural to them based on previous experience and/or common convention. Whatever choice requires the least amount of context switching overhead and allows the lowest barrier of communication between devs will win in the end.
That's why Typescript is immensely popular for developers with a strong OOP background that prefer writing code in an IDE.
For C, the low level support for types and memory access make it a natural fit for systems development. I have written low level network code in C#, it's an extremely awkward and verbose mess.
Python wins when it comes to simplicity and the ability to write really powerful functionality with a minimum amount of code. The list slicing as well as comprehensions are easy to understand and increase productivity dramatically.