|
There's a clever, yet lysdexic programmer I know that had lots of typos in his code. Things like refrance, heder, etc.
ps, I sometimes type double letters as weell. 
|
|
|
|
|
A long time ago, in a company(*) far, far, away...
I once spent three days changing the product line name from "VersaMark" to "Versamark" in... everything: UI text, application folder and file names, registry keys, source file names, comments, and so on. For a long time our installer scripts included code to rename things.
This was after I had spent weeks haranguing the Marketing yabbos to decide which version it was. In a meeting they finally settled on "VersaMark". Three months later they took the product to a show and got their underwear severely twisted because all of their paraphernalia said "Versamark".
(*) actually, it's still right here, just been bought and sold a couple times
Software Zen: delete this;
|
|
|
|
|
Marc does have a dilemma, he needs to future proof in case they do correct the typo later!
We have a good one. unigue for unique. We never changed it, intent is clear and testing is already completed.
I blame it on the font designers as it was a person who is very fluent in English, but English was their second language. Probably only ever "read" the word unique in text with a font like this that shows little q without the right facing tail.
qgqg
qgqg
|
|
|
|
|
In case you can't sleep, this is legal:
public enum MangledEnglish {
Completeed = 2,
Completed = 2
}
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
Back in 2000, I encountered "delimeter", but the code had nothing to do with the length of a subway sandwich.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
It was not exactly a typo that went into a small document browser which was rushedly sent out for the U.N..
The day before I had added a toolbar and a menu item with the text 'Toolbar ein' or 'Toolbar aus' (= show toolbar, hide toolbar). At least I should have written that. Instead, I wrote 'Einbartool' and 'Ausbartool', just for fun.
Then, the next day, it was released in a hurry and my nonsense texts were still in it. Within an hour we had a mail with the following question: 'Qu'est-ce que un Einbartool?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
It's unacceptable!
Any self respecting French person should instantly understand this hybrid German-English word!
Instead I wonder, why not Zweibartool? What has Australia to do with it?! 
|
|
|
|
|
If you do native iOS (Swift) and native Android (Kotlin now) and web dev (JavaScript), you will find that Swift, Kotlin and JavaScript will have you going crazy in their choice of usage of : let, var, and val
They use similar keywords all in different ways.
Swift
let pi = 3.14
var randValue = 55;
Of course, let does something different in JavaScript. Of course...
JavaScript
let x = 1;
var y = 7;
if (x === 1) {
let x = 2;
var y = 107;
console.log(x);
console.log(y);
}
console.log(x)
console.log(y);
Kotlin Note: CP doesn't have a choice for Kotlin yet, so val keyword isn't blue.
val pi = 3.14
var randValue = 55;
var is used by all three.
let is used by Swift and JavaScript differently.
val is only used by Kotlin.
Language Design Ideas
We know everyone steals design ideas from each other, so why didn't the designers of these languages steal from each other and make let and var mean the same darn things?!? 
|
|
|
|
|
raddevus wrote: We know everyone steals design ideas from each other, so why didn't the designers of these languages steal from each other and make let and var mean the same darn things?!?
Because, according to marketing-ideas, the language needs its own "identity".
In a few years, C# will have more keywords than those three languages combined 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Because, according to marketing-ideas, the language needs its own "identity".
Yeah, I guess so. Everyone says, "Our let is the best let of all."
Eddy Vluggen wrote: In a few years, C# will have more keywords than those three languages combined
|
|
|
|
|
raddevus wrote:
I'd wish it wasn't so.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
C++/30 will consist entirely of keywords and variables will be inferred by the context.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: C++/30 will consist entirely of keywords and variables will be inferred by the context.
This is the new movement on the Serverless front and will be referred to as Codeless code.
|
|
|
|
|
Recently, I stumbled over C# and C++ meaning rather different concepts with their "array". While I may seem rather snarky here, I think that language designers more often than not explicitly try to remain different from the existing stuff for the sake of, I guess, differentiation for the sake of it.
|
|
|
|
|
Wait until you see VB.NET's array declarations. They still use the upper bound instead of the length because that's what VB6 did, despite the fact that the reason it did that no longer applies to VB.NET! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Wait until you see VB.NET's array declarations. They still use the upper bound instead of the length because that's what VB6 did, despite the fact that the reason it did that no longer applies to VB.NET!
I haven't used an upper bound in a VB.Net array declaration for several years. The upper bound is optional and only really useful if you know ahead of time how big your array will be. Almost all the dotNet framework collection classes support this feature as well. There are times when it's useful but generally you don't need this feature.
|
|
|
|
|
Member 9167057 wrote: I think that language designers more often than not explicitly try to remain different from the existing stuff for the sake of, I guess, differentiation for the sake of it.
I think you may be correct.
The two languages which are extremely similar are Java & C#.
I wrote an app as a C# desktop app and then wrote it as a Android app (Java) and there was a lot of code that translated without any changes -- the pure language stuff / syntax.
|
|
|
|
|
When I learned the way C# understands arrays, it gave me a deja-vu to Algol 68.
In those days (the language definition was published in 1968), hardware wasn't fast enough to make such complex language very useful. Experience with optimizing such constructs were limited, too. So Algol 68 never made it into the mainstream. When I learned about it 10-12 years later (we didn't have a compiler, but studied its concepts, in the university compiler course) we saw it as a collection of great ideas that couldn't be realized in practice, in any useful way.
So when I saw C# actually realizing those array concepts, it was sort of like a dream from my student days coming true.
|
|
|
|
|
What concepts are those? Because automatically managed dynamic generic type-safe arrays by themselves don't wow me as much, I've been using them extensively in Delphi as well and they're just as comfortable as in C#.
|
|
|
|
|
First and foremost, ragged arrays - a vector of vectors (of vectors of ...), each of a different size. That requires a radically different memory allocation strategy and address calculation strategy. (Algol 68 also allowed arbitrary lower bounds, which unfortunately has not been carried over to C#.)
Also, a function argument could be an array of any dimension; it was transferred by a descriptor stating the dimension of the actual argument. I am not sure if the actual argument could be dimensioned at runtime - with all the other mechanisms required for array handling, dynamic sizing woudln't add that much extra .
Lots of the things you see in Algol 68 (in addition to ragged, dynamically sized arrays) are present / common in languages of today. But Algol 68 preceeded Pascal by two years, it appeared at roughly the same time as Fortran IV. While we were using named COMMON in Fortran, Algol 68 offered dynamic, ragged arrays, with index checks. And pointers. And user defined operators. And threads with semaphore synchronization. And ...
It was like a brainstorming language. All the crazy ideas thrown out on the table at the same time. It took quite a few years to mold those ideas into something useful, and learn how they could be realized efficiently. Today we know how. But fifty plus years ago, the ideas seemed rather crazy to those who worried about the different address calculation whether you lay out fixed size, rectangular arrays by row (Pascal) or by column (Fortran). Algol 68 was in a completely different world, at that time.
|
|
|
|
|
Thank you for the explanation.
|
|
|
|
|
Just let it go 
|
|
|
|
|
Sander Rossel wrote: Just let it go
Yeah, it is the best way. Acceptance.
But, it's a lot more fun to gripe about it. 
|
|
|
|
|
Remember the old times of Basic and VisualBasic, where Let assigned the result of an arithmetical expression (luckily became optional) but if you needed to set a reference in VB you'd better remember it wanted the Set...To keyword or it would crash at the first execution.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
VB6 and earlier needed Set and Let because of non-indexed default properties, which thankfully went away when .NET was first released.
For example:
Dim rst As ADODB.Recordset
Set rst = ...
Dim foo As Variant
foo = rst["Bar"]
- The
Recordset class doesn't have an indexer, but it has a default property called Fields which does. - The indexer returns an
ADODB.Field object, with a non-indexed default property called Value. - At this point, the compiler wouldn't know whether you want the variable to contain the field object or the field's value.
- Therefore you have to use
Set if you want the field object, and Let (or nothing) if you want the value.
Fun times!
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
