Homeless Content

The Island of Misfit Content

Instead of deleting others content on the wiki, which is often considered rude, place it here on the compost heap. This way others can re-use or recover as necessary.

It's not very diplomatic to call it a "compost heap".

Consider it like the "heap" in C (and other such languages) -- the place from which memory allocation is done. In this case, this is de-allocated "memory" of the wiki. --Mark Janssen

Inhabitants of the "Island of Misfit Toys" from the TV movie "Rudolph the Red-Nosed Reindeer".

This is content that has no current home. It may be temporary, or moved because a refactoring is desired, but the author is not around to comment such that the content is moved here instead of deleted, which is the polite way to do it. (There used to be another page like this, but I cannot find it.)

(Moved from Switch Case List Versus Hof)

I've noticed you often resort to insults -- e.g., "[m]aybe you are just a poor algorithm factorer" or "job-security is the primary goal" -- when you're feeling defensive. Apparently, you're run out of rational counter-arguments, especially as it's evident you're not reading what I've written. It's been pointed out very clearly above that there aren't "30 very different 'algorithms'". Anyway, this has all been discussed in detail and at great length in Hof Pattern. You might wish to reread it with an open mind, rather than starting from the arbitrary assumption that HOFs are inherently bad or to be avoided categorically. I see no point in discussing this further as long as you're going to resort to argumentum ad hominem. If that's all you've got, I'll take it as given that I've won the debate.

You guys accused me of something like not knowing how to use HOF's or "hating" them, and are thus a hypocrite for complaining about that. You even did it in the very paragraph where you complain about me doing it (and is not the first). I will remove the ad hominem stuff anyhow eventually because I don't want to stoop to your level. But not today because I am venting. (My apologies to Ward Cunningham for temporarily being an ahole.)

Is it inaccurate to state that you don't know how to use HOFs? In Ex Base, you wrote "... I'm not skilled at HOF's". Is it an ad hominem attack to suggest that you hate HOFs?

"Skilled at" and "know how to use" are different levels. I know how to use a drill, but I am not "skilled" at it because I've probably used one a total of like 10 hours in my life, while a professional carpenter has probably used it thousands of hours and knows short-cuts, accuracy tricks, subtle warning signs of a bad hole, etc. Further, echoing one's own statement about oneself does not necessarily "de-homimen" it. (If you were so skilled, I would expect better scenarios.)

The "not skilled at HOF's" comment was meant as a joke, not literal. It has a smiley next to it.

(Moved from Tag Free Typing Road Map)

Top thinks it's controversial. Some think it's (at best) a pointless notion.

Incorrect, I don't think that. Others treat it as a controversial topic is typically treated. I cannot read minds, but the behavior matches the pattern of "controversy". --top

[You've described it as controversial. The rest of us aren't debating it with each other; we're only "debating" it with you. The rest of us appear to agree that the notion is, at best, unnecessary.]

What quantities and ratios are necessary to qualify as "controversial"? Or are you making up your own vocabulary rules? I was just trying to convey to readers that the topic is contentious, heated, or something similar so they know what's ahead. Why are you bothered by the word "controversial"?

[Controversy means subject to general debate. This isn't a general debate -- it's just you vs everyone else. "Conservative" vs "liberal" is controversial. "Conservative" vs an individual's "foobism" (or whatever) is not controversy; it's a lone voice in the wilderness. It'll become a controversy when you can convince others to share your viewpoint, such that there is more than just you arguing with the rest of us.]

BS! And "everybody else" is one other like-minded dude and your dog. Most Wiki Zens don't give a fudge either way.

[What's "BS"? That's simply appropriate use of the term "controversy", and there's more of us here than you think.]

That many who wish to remain handle-less? I truly doubt it, it's a rare personality quirk that's very unlikely to occur in bunches.

[It seems so. Don't forget that you've been corrected on a number of occasions for attributing something to one correspondent that belonged to another. Perhaps anonymity is a trend rather than a personality trait.]

You want to reduce confusion AND increase anonymity. Nut.

[Try focusing on the content, not the content creator.]

If YOU followed that advice, you wouldn't have tweaked with the wording.

[What do you mean by "tweaked with wording"?]

Removed "controversial" (solely based on the quantity of "creator" instead of "content", violating your OWN rule, embarrassing yourself, and soiling your pants.)

[Why are you looking in my pants? I think it's sound advice to focus on the content rather than the creator, but it's clear that certain content has one and only one creator, and that creator thinks defending it makes it "controversial". It doesn't.]

The definition of "controversial" is controversial. I've never seen it being tied to quantity or ratio of participant opinions. Hitler is one guy. Tell me he was not the source of controversy. (Damn, did I just compare myself to Hitler? Self-Goodwinning?)

Somebody deleted the following from Design Patterns Book without asking author permission (jerk!). I don't have a copy of the original format such that italics etc. has been lost.

If they wanted to be explicit, it then should be "Elements of Reusable Only-Object-Oriented Software". Mentioning X does not automatically exclude non-X.

Are you serious? I suppose Converse & Park's "PHP Bible" should have been titled "PHP-only Bible" to exclude Lisp, too? Should "SQL All-in-One for Dummies" be renamed "SQL-but-not-other-query-languages All-in-One-not-Two-and-not-Three-Or-Any-Other-Number for Dummies-but-not-clever-people-and-definitely-not-dogs-or-other-animals?"

You are comparing apples to oranges. A language book is usually not a design book. Anyhow, I consider exclusion of consideration, or at least mention of other paradigms to be a "flaw". It's a multi-paradigm world; assumptions of isolation aren't practical. If you disagree, so be it. You can give your opinion and I can give mine. (Granted, GOF may have been written in the era where many thought 100% OOP was the way to go, but I'm judging its practicality based on today's environments. That may be "unfair" to the authors, but I'm not judging the authors, only the book in terms of somebody wondering whether it's worth reading today since studies prove time-machine owners don't read books.)

So "Web Design in Easy Steps" should have been named "Web (but not desktop application) Design in Easy Steps"? "Admire the Web" should be "Admire the Web But Not Other Stuff"?

"Design" for web often means graphics and presentation design, not software design. Anyhow I didn't recommend that as an actual title style, but rather to point out something about language and title choices.

So "Detail in Contemporary Residential Architecture" should have been named "Detail in Only-Contemporary Only-Residential Architecture"? Why not "Detail in Contemporary Residential Architecture (But Not Bridges or Department Stores or Towers or Skyscrapers or That Tiny Room In My Mum's Basement, If That's Okay With You?)"? Now really -- "Elements of Reusable Object-Oriented Software" is obviously intended to be sufficiently focused on object-oriented software to not be worth mentioning anything else, so it's obviously not functional software or logic-based software or pure procedural software or mixed-paradigm software. If it was, it would have said so. Stop quibbling; if you're bored, go watch a movie or something.

You claim all your arguments are "obvious". BS, and projection on the quibble quibbling.

What does "projection on the quibble quibbling" even mean?

Are you quibbling over my quibble about your quibble quibbling?

(Moved from Signatures And Soft Polymorphism. The philosophy of science related to the topic appeared to getting sidetracked.)

Huh? Science has steps. Why even question why one step is more important than another?

What does this have to do with the Scientific Method?

Scientific Method: 1. Observe phenomena and/or experiment, 2. propose model (explanation), 3. test model against observations, 4. adjust or replace said model based on feedback, etc.

"Model" and "explanation" (or hypothesis) are not the same thing.

For our purposes, they are pretty much the same (unless actual interpreter implementation is the target concern). We've had this philosophical debate already somewhere. I do not wish to repeat it.

How could they be the same? A model is an abstraction of a system. A hypothesis is a prediction about the behaviour of a system. A model is some sticks, a rubber band, and a plastic propeller in a certain arrangement. A hypothesis is that an aerofoil of a given size, shape and weight will lift against a gravitational force in a gas of a given density if pushed with a given force.

But we are not dealing with physical forces, thus your plane analogy is difficult to extrapolate for our needs. (We are mostly ignoring machine performance issues such as RAM usage and speed in our context.) Evaluating the model as a tool would be a better direction: what do we want the tool to do, and how do we objectively measure "success"?

Fine. A model is a set of structures and possible operations on them. A hypothesis is that when we apply the '+' operator to a delimited string "s" -- consisting solely of a numeric literal s -- with numeric literal p, the result will be s + p.

Yip, those kinds of hypotheses are part of the language experimentation stage, mentioned above.

The point here is that you've claimed a model and a hypothesis "are pretty much the same". Obviously, they are not, even "for our purposes".

Being that we are not concerned with specific interpreter implementations, all "working" models are essentially an "explanation".

A model isn't an explanation, it's an abstraction. A model is an arrangement of parts and rules governing their interaction. An explanation is a description of the causes of observations. A hypothesis is a prediction of observations. These three things are not equivalent.

An interpreter is an abstraction of an interpreter?

I don't understand the question.

(Content that used to be in a topic titled "IDE Encourages Bloat". May be resurrected in the future when better examples are created.)

IDE's tend to encourage bloat with their various "auto-code" features. Be careful.

The most important characteristic of code is readability by future maintainers (after running). Maintenance of existing code is typically about 2/3 of the long-term cost of software such that emphasizing the writing stage is the wrong target.

If an IDE generates verbose (bloated wind-bag) code, then it's counter to maintenance because it generally slows readability.

Code bloat should be reduced, not automated.

For example, good code will do something like this:

However, many IDE's make it too easy to create this instead (and/or don't recognize the shorter version):

Plus, the service object "path" often changes over time, and if we hard-wire the full path, we have more to change, which may also risk more errors. -t

What IDE does this with which language? I don't know of any "service object path" in (say) C# or Java, but there is certainly a package name. However, it almost never changes.

I'm not sure past history is a decent guide to future changes. Either way, repeating long paths like the second example hurts readability of code in my opinion, especially when the parameters are more complex, creating screen wrapping of code.

In the case of package names, past history is a decent guide to future changes. The package name convention in C# is .(|)[.][.], and in Java it's the company's domain name in reverse, followed by (usually) (|)[.][.]. How often do these change? In over a decade of daily Java coding, I can count the number of times I've redefined package names on one hand, and even then it's a trivial matter of using the IDE's (Eclipse, for example) rename facility.

I agree that repeating fully qualified package names is a bad idea -- in Java, using 'import' to avoid it is a good idea. Are there IDEs that still repeat fully qualified package names when using their wizards and whatnot?

I don't have any specific examples I can present right now, but in general "direct" paths seem to work smoother in IDE's I use. The more indirection (references to references), the more likely IDE's are to be get confused by something, "pressuring" one to use explicit paths. Maybe I was doing something wrong and didn't know about the Magic Fix Button, but I'm sure others wouldn't know about the Magic Fix Button either.

What do you mean you "don't have any specific examples"? Are you just making things up?

No, I did not document and record and save the code and conditions of the problem. And your wording is rather harsh. Brush up your People Skills bub. You can ask questions without sounding accusatory.

I find it curiously hypocritical that you can make sweeping statements like "IDE's tend to encourage bloat with their various 'auto-code' features", but get defensive when I take you to task for not providing any realistic evidence to back it up.

Then just say, "so far your evidence is weak" rather than "are you making things up?" Don't make stupid justifications for being a rude asshat, you asperger castoff!

But your evidence was worse than weak; it was nonexistent. Surely, if all this had some basis in reality, you would at least remember that you -- for example -- used Eclipse to generate a SOAP Web Service client in Java. Your lack of any specific content or context makes it sound like you are either making things up, or your experience is so narrow and limited that making reference to it would reveal details about a specific project. Either way, it appears you have no evidential basis for making a general assertion that "IDE's tend to encourage bloat."

For someone who is frequently so insistent on empirical evidence über alles, you seem peculiarly reluctant to provide it.

I only "insist" on it if one implies their argument is very strong. I don't claim my argument is strong. I was hoping to spark interest in the topic on IDE's and code bloat in general rather than to be insistent about my viewpoints on them. If you wish rename the topic to "Do IDE's encourage bloat?" or the like, I'd be happy to consider it. (Although, I can't make a decent wiki-name out of that particular arrangement.)

If your argument is weak, why bother mentioning it, then? Why can't you even give a remotely-realistic example?

I answered that already above.

Moved from Relational Gui Dilemma for possible future reevaluation.

Dynamic Relational can make columns and/or values required, if one wants. And normalization is an issue in any design. If we allow duplicate column names (duplicate name/value pairs), then we are not using "relational". If we want such in a relational system, then an extra table may be necessary, depending on the purpose of the alleged duplicates. I haven't seen a need to have duplicates yet to explore design options.

Dynamic Relational, as currently defined, provides a "unique row ID". Technically that makes each row unique. But, it does not "force" one to ask for a unique combination of columns in query results, which I think is silly and obsessive. I'm okay with requiring some kind of override flag when asking for "bags" to serve as a warning or reminder, but am against outright forcing it. Anyhow, we already have enough topics on the "bag debate" such that there is no need to repeat all that here. It has the same "bag flaw" that SQL does and thus is no worse in that regard than SQL. The goal here is to manage GUI info with known and familiar SQL-based or SQL-like tools and conventions, NOT overhaul or replace SQL. That's a different topic and goal. "Relational" is the common colloquial term for SQL-RDBMS's. Whether that conflicts with the "formal" definition is perhaps another topic. This wiki is not obligated to avoid colloquial terms in titles. -t

{Was the paragraph starting with "Dynamic Relational can make columns and/or values required ..." copied from somewhere?}

I don't recognize it from another source, but I don't remember the history of this topic. I don't think it's new. Perhaps I mistook it for a complaint about the usage of "relational" when that wasn't the intent. Maybe we can consider removing it. It's not clear to me what parts are about Dynamic Relational "cons" and RDBMS "cons" in general. -t

Category Wiki Maintenance

See original on c2.com