Case sensitivity in any programming language is crazy. I can't for the life of me see a valid engineering principal that accepts IsTheOne() and istheone() being different bits of code. Oh sure at a technical level the computer has no problem with... the problem is restricted to those oh so error prone humans.
Can anyone here honestly say that if they were doing a code review they'd agree that solely a difference in case would get their approval?
And don't even get me started on filenames that only differ by case. If that's a good idea then I think trailing whitespace should be significant too!!!
There are languages that use lowercased names for constants (Erlang's atoms) and uppercased Names for variables, which are immutable and quasi constants anyway. This is uncommon but many other languages use uppercase for classes (Person) and lowercase for variables such as Person person = new Person(). That last example is one reson for having case sensitive languages. I can't think of any language I used in the last 30 years that was case insensitive. Maybe some BASIC interpreters on home computers in the 80s? But not all of them had upper and lower case characters to start with.
Linux has a notoriously case sensitive file system, with trailing significant spaces (they are not special characters). Mac and Windows also have case sensitive file systems but that feature is turned off by default.
I don't know why you've been downvoted, but anyone who disagrees with you needs to explain in what situation it would make sense to have two different functions or files with names differing only in case.
I have used all-uppercase to make a distinction like class vs. instance in variables (in case-sensitive languages in which the class might be an ordinary held-in-a-variable value, like Javascript), and I might do it again. But it's very unusual, and it's also the kind of practice that is more suitable for a 1KLOC project that will receive 100 hours of effort from a single maintainer over its lifetime than for a bigger project with many maintainers and a highly motivated community of attackers.
I don't think there was ever a case when I was tempted to name two functions with different cases, but if I ever had to write a modest-sized 1-maintainer system in which many functions came in exactly two different flavors, I might be tempted. (Perhaps threadsafe locked vs. raw? or some C++-like distinction between raw functions and closure-like class instances which can be used in a function-call context? or raw functions vs. wrappers with the extra plumbing required to let them be invoked from a scripting language?)
afterthought: And now that I think of it, in old C code I think I vaguely remember working with macro vs. function implementations of the same operation distinguished by capitalizing the name, and I don't think the name convention was an urgent problem. C macros can breed various errors, but I think bitbang_macro vs. bitbang would breed pretty much the same errors as BITBANG vs. bitbang.
In those situations, it would have been much more readable to have classFoo vs foo, foo() vs nonThreadSafeFoo(), etc.
The bigger point is that while you can come up with creative ways to take advantage of case-sensitivity, it's not that you would have missed it if the language was case-insensitive. From that point of view, case-sensitivity has no benefit, but only a cost: leads to irritating errors from the compiler, or runtime errors in dynamically typed languages.
If something has no benefit, and only a cost, we should get rid of it.
It's not that it would make sense. It is more like it is the programmer's fault.
Next week's stupid but expensive typo will be received() instead of receive(). What will you demand then? That the compiler refuses names based on the Levenshtein distance?
It's the job of a style checking tool, not the job of the compiler.
Saying it's the programmer's fault is another circular argument. It is, only in languages that make it the programmer's fault, but I would say that it's actually the language designers' fault.
That's a circular argument. They are different only because the language says they are different, while the post you've responded to says (correctly) that that's bad language design.
Assuming you are not trolling: yes they are indeed represented with different bits, which doesn't matter since these bits are not the bits executed by the CPU in the end. The "words" and not the bits are interpreted or compiled into machine code. Which is where bits matter.
Some computer languages are case-sensitive for their identifiers (C, C++, Java, C#, Verilog, Ruby and XML). Others are case-insensitive (i.e., not case-sensitive), such as Ada, most BASICs (an exception being BBC BASIC), Fortran, SQL and Pascal.
I couldn't agree more with this sentiment. I haven't spent too much time on Ethereum contracts but this is such a ridiculous language/platform design issue.
Funny thing is, it reminds me of implicit typing of int/float based on the first letter of the variable name that ye olde FORTRAN77 had as a major footgun.
The problem is one of trust. Contracts that can either be formally verified, or by nature of the language they are written in are mathematically guaranteed to be free of certain bugs and behaviors can be 'TRUSTED'.
It's a very bad thing to not be able to trust that your money can't be trivially stolen.
Are we sure that case sensitivity is the culprit? As others have noted, the function being called takes (and is given) 3 arguments but the function that is supposed to be called takes only 2.
For any language that allows non-ASCII identifiers, trying to define "case insensitive" is a minefield best avoided. For example, with general Unicode characters, "case-insensitive" comparison doesn't give you an equivalence relation on identifiers because transitivity fails.
Of course you can define things to be case-insensitive only in the ASCII range, and treat your non-ASCII stuff as second-class citizens...
What a shitshow. These people don't need "advanced static analysis tools" [1], they need a big old bag of clue.
1:
Developers, cryptographers and computer scientists should note that any high-level tools (including IDEs, formal verification, debuggers, symbolic execution) that make it easy to write safe smart contracts on Ethereum are prime candidates for DevGrants, Blockchain Labs grants and String’s autonomous finance grants.
OpenSSL had some code cruft too, and god knows that didn't stop it from being deployed in production. People use code because it works, not code that's perfect.
That's not good enough for software that's meant to be money. Besides, OpenSSL has the excuse of being old. Why would you design a new system to be crufty from day one?
I wouldn't design any system to be crufty or have bugs. I was just pointing out that it happens. And honestly probably gives us a lot cooler stuff than were software production restricted to developers who were certified to produce best practices code.
I feel like without weird blood we'd only ever get enterprise-approved spreadsheet software.
PS: Caveat. Personally, of course I'd never use stuff like that for mission critical deployments until it's been battle tested.
Major fuck-up there.
That should have never passed the concept stage, nor the review stage.
Function names should describe what a function does.