Post #59,580
10/25/02 10:58:23 PM
|
Divorce the GUI builder and language
Which means I don't much care for it on a conceptual level. Hmph, yeah, well... What am I supposed to say to that? What you're saying is basically, "My mind is made up, because my mind is made up" -- sounds rather Tablizer, actually... The only reply that comes to mind is, "Your loss". [emph. added]
What are you implying here? That I am "stubburn"?
I am OPEN to inspecting any open evidence you have. So far you only give vague philosophy that does not translate to anything real. It makes you feel comfy inside, that is all I can get out of you.
The more OO code I see, the more I am convinced that OO fans actually enjoy inventing (crippled) databases from scratch. Almost half the methods in some designs are things that using a DB would make *unnecessary*. Your API's are thus bloated. For example, a table-oriented listbox (dropdown) would grab its list from a table or query. However, OO API's have metheds like addItem, deleteItem, sortItems, findItem, findDescription, etc. A "micro-DB" if you will. And, respected OO books often encourage people to use arrays to manage links between classes. Hand-built indexing. They are reinventing the database from scratch. (That approach is similar to "network databases" that fell out of style after relational proved more logical and virtual. You guys are stuck in the 1960's. You are using Beatle-era technology.)
If Delphi is so fricken great, then SHOW some Delphi code objectively kicking procedural/relational code (or tables) in the nuts with things like code size, change-impact analsys, etc. Why is that so hard and why do you get huffy when I ask for it? Should I just roll over and take your authoritarian-based claims in the arse?
Personally I think Delphi made the VB and Java mistake of *tying* the GUI to a particular language. A table-oriented approach can *divorce* the two so that any language can talk to the GUI simply by setting table-based attributes and responding to events (using either an event table or dispatching code, your choice).
If we divorce the two, then not only is the learning curve smaller (only one GUI builder to learn), but people don't have to switch languages to get a decent GUI builder. And, GUI builder vendors can spend more effort on getting that part right because their audience will be larger.
With tables, you can have your cake and eat it to. (There are procedural and OO libraries for similar things also, but the API's still tend to be language-specific and have problems managing state.)
________________ oop.ismad.com
|
Post #59,752
10/27/02 10:40:15 AM
|
Dr. Dialog (OS/2) does that
While it's oriented around using REXX as it's event language, you can in fact use any language... Peter Moylan uses Modula for its events, for example.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #59,813
10/28/02 1:58:54 AM
|
Any ports to OS's with more than 1 percent market share?
________________ oop.ismad.com
|
Post #59,845
10/28/02 9:51:51 AM
|
No.
Of course, for my personal use, marketshare is irrelevant.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #60,065
10/29/02 2:57:12 PM
|
Re: Divorce the GUI builder and language
The more OO code I see, the more I am convinced that OO fans actually enjoy inventing (crippled) databases from scratch...
Still spreading the same old FUD I see...
If we divorce the two, then not only is the learning curve smaller (only one GUI builder to learn), but people don't have to switch languages to get a decent GUI builder.
Take a look at XUL. Here's a few links:
[link|http://www.mozilla.org/xpfe/xptoolkit/xulintro.html|http://www.mozilla.o...kit/xulintro.html] [link|http://www.xulplanet.com/|http://www.xulplanet.com/] [link|http://luxor-xul.sourceforge.net/|http://luxor-xul.sourceforge.net/]
I really want to use luxor-xul, but it's GPL :(. I'm stuck with nasty code generating GUI builders for now.
Regards, John
|
Post #60,101
10/29/02 6:40:29 PM
|
Re: Divorce the GUI builder and language
Yeah, Bryce marches out of time to a different drum.
-drl
|
Post #60,751
11/2/02 2:41:36 PM
|
Not original enuf to have new FUD I guess
Still spreading the same old FUD I see...
Yeah, unlike OO fanatics, I cannot come up with *new* FUD as fast.
I especially dig their "refactoring" to cover up what is really going on: Code *rework* because OO *failed* at its change-friendly goals. "I got an idea: since we failed at reducing code rework that we originally promised, we will just give code rework a fancy techy name." A vocab cloak worthy of MS.
________________ oop.ismad.com
|
Post #60,758
11/2/02 3:00:15 PM
|
...and here's why.
You're too busy trying to refactor the English language to come up with anything interesting to say.
Your prose makes my eyes bleed.
Peter [link|http://www.debian.org|Shill For Hire] [link|http://www.kuro5hin.org|There is no K5 Cabal] [link|http://guildenstern.dyndns.org|Blog]
|
Post #60,770
11/2/02 3:36:16 PM
|
I'm confused...
I especially dig their "refactoring" to cover up what is really going on: Code *rework* because OO *failed* at its change-friendly goals...
So you argue that since OO failed at it's change-friendly goals, they invented refactoring (which is changing the structure of code without changing it's behavior). If OO is so change unfriendly, why would changing OO code (refactoring) be so popular?
Regards, John
|
Post #61,016
11/4/02 1:55:32 PM
|
Inertia
If OO is so change unfriendly, why would changing OO code (refactoring) be so popular?
You seem to be suggesting that something that requires more effort should disappear from the market place. However, there is often *inertia* in the industry which prevents this. QWERTY, COBOL, and Microsoft servers are an example of things that were *more* effort than alternatives, but organizations just did not want to change for whatever reason. Job security, perhaps. Good auto mechanics have fewer repeat customers, it is sometimes said.
Futher, OO gurus did not want to admit failure, so they just renamed failure to make it sound more pleasent.
BTW, I did not say that OO fans "invented" the term or concept of refactoring. I don't know its true origins. I am saying that OOP has popularized or mainstream-ized the concept. Rather than admit it failed to make code change-friendly, they made code rework into a standard corporate function or step.
________________ oop.ismad.com
|
Post #61,135
11/5/02 8:42:36 AM
|
My head hurts
Let's try this one last time:
You argue that OO failed to make code change-friendly.
You then argue OO gurus brought out refactoring to cover up that failure.
How could that possibly be since refactoring is about changing code? Wouldn't refactoring OO code be impossible if OO was not change-friendly?
Regards, John Urberg
|
Post #61,144
11/5/02 9:52:42 AM
|
That's normal when you talk to Tablizer. Get used to it.
--
We have only 2 things to worry about: That things will never get back to normal, and that they already have.
|
Post #61,228
11/5/02 5:07:00 PM
|
ROFL! Thanks, Doc.
Alex
"I have a truly marvelous demonstration of this proposition which this margin is too narrow to contain. -- Pierre de Fermat (1601-1665)
|
Post #61,555
11/7/02 1:32:15 AM
|
Misunderstanding "change friendly"
Okay okay, now I see the problem I think.
There is a big misunderstanding WRT "change friendly".
I meant how the code as a whole weathers changes, not each individual peice of code. Change-friendly design is a design that requires the fewest code changes upon a given application requirements change.
It is *not* the *ability* of the code to morph, but the NEED to undergo change or morphing in the first place. It would be roughly analogous to a plumbing design that avoids the need to bend pipes, and NOT the maluability (bendability) of the pipes themselves.
Is that clear now? This kind of reminds me of when John Lennon said, "The Beatles are bigger than Jesus Christ now" in the 60's (IIRC radio story). Religious groups went crazy and held mass record burnings. What they did not understand is that John was comparing their *popularity* to Jesus, and not their value as beings. Some preists came forward and even agreed with John, saying that "young people don't pay enough attention to religion and too much to pop stars" (paraphrased). John tried to explain the comment to the press, but it didn't seem to come out right.
________________ oop.ismad.com
|
Post #61,573
11/7/02 8:24:09 AM
|
Where's the "tablizer dictionary"?
You need one with all the terms you make up.
Regards, John Urberg
|
Post #61,576
11/7/02 8:49:04 AM
|
oopsismad.com, it makes good reading and helps
understanding some points that Bryce makes. thanx, bill oops is tops
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
"Money for jobs? No first you get the job, then you get the money" Raimondo
|
Post #61,685
11/7/02 2:41:09 PM
|
re: Where's the "tablizer dictionary"?
I thought it was self-explanatory, but I was wrong. It seems there are multiple valid (or semi-valid) interpretations that I failed to anticipate. I am sorry. I will avoid its usage for now on.
How about "maintenance friendly" instead?
________________ oop.ismad.com
|
Post #61,800
11/8/02 2:40:56 AM
|
But then... Easy re-factoring IS "maintenance-friendly"!
A lot more "maintenance-friendly" than DIFFICULT re-factoring, anyway...
|
Post #61,942
11/8/02 10:05:05 PM
|
Are you saying OOP is easier to refactor?
________________ oop.ismad.com
|
Post #62,037
11/10/02 10:20:00 AM
|
The real Tablizer dictionary
Change friendly = p/r code Maintenance friendly = p/r code
OO code != p/r code therefore OO is by definition not change friendly or mainentance friendly
Refactoring = something OO gurus made up/stole to hide the fact that OO is not change and maintenance friendly
|
Post #62,043
11/10/02 10:55:15 AM
|
OMFG! ROFLMAO! LOL2!
[link|mailto:curley95@attbi.com|greg] - Grand-Master Artist in IT [link|http://www.iwethey.org/ed_curry/|REMEMBER ED CURRY!!!]
Your friendly Homeland Security Officer reminds: Hold Thumbprint to Screen for 5 seconds, we'll take the imprint, or Just continue to type on your keyboard, and we'll just sample your DNA.
|
Post #61,770
11/7/02 10:42:18 PM
|
You're referring to the design of the code.
IOW, I understand your qualification to mean a well though out design will tend to only need changes to it's meta-data than in the actual code.
Wade.
"Ah. One of the difficult questions."
|
Post #61,793
11/8/02 1:01:50 AM
11/8/02 1:06:34 AM
|
re: You're referring to the design of the code.
IOW, I understand your qualification to mean a well though out design will tend to only need changes to it's meta-data than in the actual code
Well, that is certainly part of it. But it also has to do with how much code rework is needed per change. For example, in program A, a given requirements change may result in splitting 2 classes and moving 2 methods to another class; but in program B, the same change may only result in altering 2 classes in place. The second one would probably get a higher "change-friendly" score. (There are finer granularity counting techniques, I would note.)
It is based on the total effort of rework you could say, regardless of whether it is code or tables that have to be altered. (Note that meta-data alteration may require a less skilled person, and thus less money expended by the company.)
________________ oop.ismad.com
Edited by tablizer
Nov. 8, 2002, 01:06:34 AM EST
|