|
 It takes a bit of contemplation to realize how beautiful snakes are.
|
|
|
|
|
Don't mind me. I'm playing anyway. I use that case when I'm developing templates libraries in C++
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I could be playing as well. 
This liking for 'all-smalls-snake' could be a momentary satisfaction about doing things differently.
|
|
|
|
|
|
The cartoon that goes with that is just too good!
|
|
|
|
|
Actually, I didn't look that far down - thanks for pointing it out.
Nor did I notice that this web page claims that it is Hell, Michigan. It is not, it is Hell, Norway.
(For those who have gone by air to Værnes Airport, Hell is the village next to it.)
The style of the sign is distincly Norwegian, European, rather than American.
I drive past it regularly; it certainly has been frozen over this way quite a few times.
|
|
|
|
|
Shouldn't it be called Helvete then?
Ja, jeg kan snakke litt norsk.
|
|
|
|
|
The Norwegian name Hell has no relationship to Helvete, but comes from "helle" or "heller".
A "helle" is a flat stone, like a slab of slate, or any stone that is "flat", or even a flat surface on a large stone that is not so flat.
A "heller" is a stone that sticks out from a mountain so that it serves as a shield against rain and snow. In the stone age (and even hunters in more modern times) could make a dwelling under a "heller". This is probably the origin of the name of the place, being much older than Christianity and its hell, certainly in Norway, but the name may be as old as Christianity itself.
For the place outside Bergen, called Paradis, there is no similar old explanation; that is a Christian name. Unfortunately, the train stop at Paradis was closed down several years ago, so you no longer can buy a train ticket from Paradis to Hell, or from Hell to Paradis. I suspect that quite a few of those tickets were never used.
Hell - Gods-Expedition[^] uses a 100+ year old spelling for "cargo handling" ("gods", cargo, is unchanged, but today we write "ekspedisjon"), but everybody loves the old sign, so they will probably keep it for another hundred years...
|
|
|
|
|
If I remember correctly, the Norse settlers in Greenland called Baffin Island Helluland, derived from the same word.
|
|
|
|
|
Otherwise known as snake case.
|
|
|
|
|
Wonderful. What a perfect name! 
|
|
|
|
|
Because it comes back to bite you...
I am so old that I remember when we made printouts of our source code. Several of the printers I used placed the underscore so low down - I guess that it shouldn't interfere with the descenders of lower case letters - that it visually certainly did not tie together the parts making up the identifier.
We even had zebra paper in my first years as a programmer, ane when the underscores from the white lines printed halfway into the top of the grey line, they were very easy to overlook, especially in identifiers starting or ending with an underscore.
So I came to hate underscores.
|
|
|
|
|
And for 2021 and you going back to "6 alphanumeric characters, must not start with a digit"? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Will give it a try 
|
|
|
|
|
OriginalGriff wrote: And for 2021 and you going back to "6 alphanumeric characters, must not start with a digit"?
and must be uppercase with first letters in the range I to N being integers; A to H and O to Z being reals unless declared otherwise. Welcome to FORTRAN IV (aka FORTRAN 66).
Then in 2022 you can progress to only 52 identifiers: A to Z for numbers and A$ to Z$ for strings. I expect a lot of CPers will remember those.
|
|
|
|
|
Ah ... implicit typing. One of the delights of FORTRAN. Along with COMMON which allowed you to declare a single character variable and use it as a three dimensional array of integers. Handy for OS mods on GEC 4070's as I recall. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
"GOD is real unless declared in an IMPLICIT or explicit declaration"
|
|
|
|
|
I think it's just a sign of how repetitive our jobs can be. We find joy from even the slightest change of practice just because it's something different.
I always look forward to having to use a constant, because then I get to use something other than camel for the naming
|
|
|
|
|
Yep, kinda.
|
|
|
|
|
And there I was going to congratulate you on your New Year's resolution to give up smoking.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
An extra keystroke... THE HORROR!
|
|
|
|
|
Nand32 wrote: I've found new love for all small case separated by underscores
Ewwwww!
|
|
|
|
|
Typing in underscores suck.
|
|
|
|
|
Why restrict yourself to an alternate restriction?
I do what I want to do when I want to do it because I can.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Okay, so I don't like to use goto, but it is sometimes if not necessary, then efficient.
I'm running into a problem right now that is very similar to the problem of supporting multiple optional parameters in a stored proc.
Basically for an LL(k) parse in a recursive descent parser, for every k>1 value the number of IFs grows exponentially.
if(firstSym==lparen)
{
if(secondSym==rbracket) {
} else if(secondSym==intLiteral || secondSym==floatLiteral || secondSym==identifier) {
} else if(secondSym==...) {
...
} else ...
} else if(firstSym==lbracket) {
else if(firstSym==...) {
....
} else ...
...
}
for each additional k value i need to add a thirdSym, fourthSym, and accompanying nested ifs.
Meanwhile, if I rewrite this as a state machine I can use gotos, and then recycle similar paths.
This is really hard to show you an example of because the result is spaghetti but it's easy to generate programmatically, or to graph visually. (i don't want to break out graphviz right now though - it's late)
However, being able to recycle those paths as they converge can dramatically reduce the amount of code you need, but you have to be able to bounce between the different branches, the way an if won't.
You can do similar using goto case albeit less efficiently than a goto based baked state machine overall.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
