|
Forth
South or southwest 3 to 5, increasing 6 for a time, becoming variable 2 to 4 later. Slight or moderate. Mainly fair. Good, occasionally moderate.
Tyne, Dogger
South or southeast, 3 to 5. Slight or moderate. Fair. Good.
Fisher
Westerly or southwesterly 3 to 5, occasionally 6 in northeast. Slight or moderate, occasionally rough in northeast. Mainly fair. Moderate or good.
German Bight
Variable 2 to 4, becoming south or southeast 3 to 5. Slight or moderate. Fair. Good.
As close as the British every got to chanting a mantra, sadly no Charlotte Green for the real aficionados.
|
|
|
|
|
|
I take it the dog refuses to go walkies?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It is an old dog, as you know 
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
You can't count on it!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes I can! Even if I have to cheat.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
With a hey, and a ho, stop the show!
|
|
|
|
|
How about a paraphrasing quatrain from "Rubaiyat of Omar Khayyam", by Alfred E. Neuman (Mad Magazine).
A loaf of bread;
A jug of wine;
And thou beside me.
So here I am;
An hour later;
Fat, drunk, and in trouble.
| 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 |
|
|
|
|
|
King Lear hath lost, he and his daughter ta'en.
|
|
|
|
|
Is it, or is it not, that is the question.
|
|
|
|
|
I'll pluck you out and cast you with the waters that you loose to temper clay!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
While tip-toeing through the tulips of LLVM, I came across a section of C++ code that follows:
//===--------------------------------------------------------------------===//
// Instruction creation methods: Compare Instructions
//===--------------------------------------------------------------------===//
Value *CreateICmpEQ(Value *LHS, Value *RHS, const Twine &Name = "") {
return CreateICmp(ICmpInst::ICMP_EQ, LHS, RHS, Name);
}
Value *CreateICmpNE(Value *LHS, Value *RHS, const Twine &Name = "") {
return CreateICmp(ICmpInst::ICMP_NE, LHS, RHS, Name);
}
Value *CreateICmpUGT(Value *LHS, Value *RHS, const Twine &Name = "") {
return CreateICmp(ICmpInst::ICMP_UGT, LHS, RHS, Name);
}
.... And there are about 20 or so similar functions.
My point is not about the code, but rather the "layering" of one-line functions.
Relatively recently, someone made a comment in another about function size (I apologize--I don't remember the thread) and it reminded me of days gone by when we had a recommended function size of 40-60 lines of code.
The reason for the function size at that time was so that a complete function would fit on ONE printed page (maybe two pages for a really complex function).
Paper size was commonly 66 lines x 132 columns. The idea was that each function would be printed on a separate page and you would be able to look at a page to see the complete processing of the function.
Looking at the above code, where a uniquely named function is created for each parameter type adds unnecessary complexity to the code.
Further, these functions, along with many other more complex functions, are in a C++ header file.
IMO, this is the type of coding practice that I personally do not like because it adds a layer of unnecessary complexity.
Just my thoughts....
|
|
|
|
|
Written before compilers didn't inline one-liners unless in a .h?
Converted from some macro shite?
An optimization for when the operator is known?
Widely agreed to be swill but a culture of not deprecating and deleting?
|
|
|
|
|
This is code from the current version of LLVM--the back end to clang, julia and a few other languages.
|
|
|
|
|
I think the "page size" was more to do with getting people to think "modular" than to do with printing.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Says someone who has never had to print out a twenty page long function on greenbar tractor feed paper to figure out the convoluted logic.
Goto's including one FORWARD Goto.
C code circa 1993
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
At that time, HIPO was the "in" thing.
|
|
|
|
|
I agree with you completely, but then people also tell me my functions are too long. 
Real programmers use butterflies
|
|
|
|
|
Probably because most people view code on screens that in IDE's that have maybe 12-20 lines visible.
My own preference is to see the whole function without having to scroll up/down.
|
|
|
|
|
The screen I do my coding on is a 22" portrait monitor so I can get at least vertical 66 lines at once; I also have about 100 characters width which is enough for most purposes. I despair when I see colleagues using big wide monitors in landscape mode with just 20 lines of code tucked at the left side in the first 25% of the screen and a huge swath of blank space over most of the screen. 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Well- looking at the first argument of the function they all call - I would say you have a 'case' to be made here... 
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I think you should try to look at a bit bigger picture. This code by itself is rather ugly BUT it is likely to greatly simplify things downstream from it so it can work in a more uniform manner. I have had to resort to layers of ugliness like this on occasion and I only did it because the pay-off later was worth it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
My preference is to look at a piece of code and understand the what's, why's, and how's very, very quickly.
Looking at the above LLVM code (and I see this coding style in a lot of other code nowadays) makes it very difficult to understand what is going on. Why did the author of this code feel it was necessary to write 4 lines of a function call that simply added one parameter based on the function name to another function call?
I can imagine situations where something like this might be appropriate for reliability, efficiency, clarity, etc. but in this case, these functions are called two times in the complete LLVM package. Maybe it would be appropriate if there where thousands of calls, but I don't see the need here.
|
|
|
|
|
Why? That's what I was trying to guess at in my post above.
|
|
|
|
|
The "why" is understanding why the author did something a particular way or in a particular sequence.
Example: A lookup table might be searched sequentially, hashed, keyed, b-tree'd, linked list, etc. It would make little sense to use a b-tree or hash algorithm on a table that never exceeds 10 items. Likewise, it might make sense to use a hash algorithm on a sparsely populated table.
I once wrote a an algorithm that used the first alphabetic character as an index into a 26 element table of linked lists where each major link list entry had sub-linked lists (almost a b-tree with sub-entries). This table of approximately 15,000 entries was accessed 1,000's of times per second and was dynamically updated with entries to be inserted and deleted.
The processing sequence had to be very clear and understandable.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
