(A rant about ExBase moved from GuiMachineLanguage)

''"I'm sniping GuiMachineLanguage as though TopMind's mouth is a clay-pigeon shooting machine... it's fun! join in."''

[I did some sniping above, a while back. It was a bit like using an M198 howitzer to shoot an obese, sluggish fish in a small, almost-empty barrel; it seemed unsporting to take shots at such an easy target. I sometimes wonder if Top even belongs to the same IT world as, well, anyone else. I ''do'', however, vaguely remember views like his causing a certain degree of irritation in the late 80s, when hordes of dBaseIII [ExBase] "programmers" (I use the term loosely), uninformed in computer science, descended on the developer world like noisy, opinionated, ill-informed, irrational, illogical lemmings. Most of them -- driven mad by their own coding inability combined with stressful incomprehension of rising ideas like object-oriented programming -- plunged suicidally over the proverbial cliff years ago. Top seems to be the last of that breed. His sheer tenacity, against all reason (literally), accounts for how he survived.]

[[ I think the reason you don't see anyone support ExBase here, other than Top, isn't that they thought ExBase was bad. They just don't want to be associated with Top's many other silly and ill-informed opinions.]]

[It's got nothing to do with Top.  Most of us here are long-term professional programmers, and a significant number of us are professional programmers who lived through the ExBase era and had to professionally endure the fact that ExBase -- in all its various clones and incarnations -- wasn't just bad, it was awful.]

[[ Professional programmers use the best tool for the job. ExBase language/database programs were like a DSL for business applications. How would you compare a Visual FoxPro (VFP) database to Access? (If you say Access, you have never touched FoxPro.) If you think that Java or C#, with some third party libraries plus a RDBMS from another company is a quicker development environment, than VFP, you aren't much of a professional programmer. I would estimate that up to 1992 (Windows introduction), at least 90% of all small business custom software was developed in ExBase products but they were obviously all wrong? ]]

[They were all wrong, but not necessarily intentionally so.  The majority of ExBase programmers didn't come from a professional PC programming background -- they were former middle managers, or "kitchen table" amateurs, or accountants interested in (or driven to) technology, or (at best) former mainframe COBOL programmers -- so they didn't learn anything except ExBase because they were unable to use anything except ExBase.  That wasn't their fault, really -- they just weren't really programmers.]

[I've used a variety of ExBase implementations -- dBaseII, dBaseIII, dBaseIV, dbXL, Quicksilver, FoxBase, Clipper, and Visual FoxPro.  They were all crap.  Access was (and still is) crap, too.  Asking which bit of crap is better than another -- like asking me to compare VFP to Access -- is like asking which turd I think smells better.  They all reek.]

[[I think people calling other people's languages and development techniques names is quite unprofessional. There are many languages I would never use for reasons that seem important to me but I wouldn't call into question the professionalism of somebody who thought otherwise. That's just "unprofessional"!]]

[Normally, I wouldn't call other people's languages and development techniques names, except ExBase. It was so unutterably dire that anyone who defends it is beneath contempt.  If we're going to talk about what "unprofessional" is, I'll state this for the record: "Unprofessional" doesn't even begin to touch the level of deliberate incompetence that defence of ExBase clearly represents.]

* [[Your comments would be unacceptable if you were an ignorant, immature teenager. For a professional programmer, they are unacceptable. Your comments are obviously not worth further comment.]] -- DavidClarkd

[[Would you say that somebody like myself, who wrote over 1,000 applications in ExBase languages, wouldn't know about the strengths and weaknesses of those systems? ]] -- DavidClarkd

[For any but an ExBase programmer, 1000 applications would be 1000 applications worth of experience.  For an ExBase programmer, that's 1 application worth of experience taken 1000 times.]

[[ExBase lost to RDBMS in the 1990's because:

* It wasn't automatically multi-user (you had to implement locks yourself)
* It was file based so lacked some security that was inherent in RDBMS
* It processed all data on the client computer rather than the server and so didn't scale as well as RDBMS
* It couldn't or wouldn't compete with the UI libraries for Windows that came from Java in the mid 1990's and later from C# and .Net
* ExBase didn't make the transition from text based to graphical UI quickly enough (Windows 3.1 was only sold in 1992)

* ''Note that the ExBase topic covers most of these flaws in more detail. Also, I agree it had flaws, but they either mattered less in areas where xBase does well, or most could be "fixed" without taking away what made xBase nice. --Top''
* I agree. I think you missed the point of my points above. Thousands of developers (including you and me) successfully developed custom software ''in spite'' of the above deficits compared to RDBMS. ExBase had many good points that relational didn't have but that wasn't enough for most developers. They decided that other solutions were better on balance for their development work but that doesn't mean that ExBase didn't have many good points that where better than other solutions. -- DavidClarkd
* ''What do you consider ExBase's good points that relational (do you mean the RelationalModel?  SQL products?) didn't have, and/or that were better than other solutions?''
* ''For my views on this, see "What ExBase Taught Me" at ExBase. Mileage may vary, as everyone's WetWare is different. --top''

[[If you think that custom business software circa 1990 was done with Relational Databases, you don't know much about '''Micro Computer Development History.''']]

[[In fact, your rant (above) is just as ridiculous (if not worse) than the rants posted by Top. I remember like yesterday, people just like you, who said all micro computers were just toys and '''real software''' could only be written for mainframes. Where are those mainframes now? I remember when most Mathematicians and Database big shots said Relational Table based databases '''wasn't''' backed by enough Mathematical rigor and would never scale like the Network and Hierarchical databases of "big iron". That has also proved laughably quite wrong.]]

[[I wrote at least 1,000 projects in ExBase (big and small) and my customers got bug fixes, custom reports etc in minutes rather than weeks.]]

[[The quality of ExBase programs was dependent on the quality and skill of the designer/programmer just like any other language. ExBase was '''very''' good at creating custom programs quickly for small companies with 50 or less users and a single programmer/designer.]]

[[If you want to call Top names, he probably deserves it '''but''' somebody should point out how much your rants sound just like him.  --- DavidClarkd ]]

* [Actually, I don't want to call Top names, haven't done so, and he doesn't deserve it.  I'm not sure where you got the idea that I thought "[microcomputer] custom business software circa 1990 was done with Relational Databases", "micro computers were just toys" or that "'real software' could only be written for mainframes", but the reality was that whilst it was indeed possible to churn out brittle, inflexible, un-reusable code rather quickly using ExBase, it was also possible to churn out flexible, reliable, reusable code even faster using in-house custom tools.  That's what my company did, and we were very successful at it.  Within our market area, we put the ExBase coders out of business; they couldn't compete with us.  Of course, it didn't hurt us that the average ExBase coder knew little to nothing about ComputerScience, SoftwareEngineering, business, bookkeeping, accounting, finance, social agility, marketing, or any other useful skill -- indeed, many of them were "downsized" middle managers and ex-government employees, with at best a smattering of project management experience and a lot of useless knowledge of bureaucracy -- so it didn't take much to help them be the architects of their own undoing.]

[[ Read this whole rant and tell me it wasn't a direct attack against Top. If you didn't write the personal aspersions then my comment didn't apply to you, obviously. ]]

[It wasn't a direct attack against Top; it was partly an attack against Top's defence of ExBase.  That's something very, very different from an attack on Top himself.]

[[ Your comments just show how ignorant you are about ExBase and professional programmers that successfully used it to make great programs. I have a link under my Wiki name that links to my website. I have a short history of my experience with database products for all to see. Check it out. Your characterization of ExBase developers is so ridiculous, I understand why you wouldn't put your name on it. -- DavidClarkd ]]

[I have seen thousands of programs created using ExBase.  I have never seen one that I would call a "great program".  They were typically abominations, yet their authors invariably thought they were amazing.  For some reason, ExBase programmers were unique in their common and peculiar combination of arrogance, ignorance, and delusional belief in their own abilities.  I've never met an ExBase defender that I would call a "professional programmer".  Every one of them who didn't lift him or herself out of the ExBase morass was incompetent.  There are many good reasons why ExBase has almost vanished, and good riddance to it.]

The ExBase programmers were 3 times more productive than the bloat-creating OO fans. They just didn't know how to debunk OOP properly in front of the PHB's, who were hypnotized by the BertrandMeyer-driven buzzword machine that sound like ''Legos for Software'' to the ignorant PHB's. The pressure from FoxPro programmers has forced MS to include the LINQ hack in their OO languages. OO may be okay for SystemsSoftware, but it gave business applications indigestion. OO fans used to chant "reuse reuse reuse". After a while it became apparent that it wasn't increasing reuse, and then the OO fans changed their story to vague, hard-to-measure, and inconsistent alleged benefits. -t

[ExBase programmers were so irritatingly boastful, and yet so staggeringly unproductive (as they drowned under a seething, spaghetti-like mass of unmaintainable ExBase code and unmet requirements) that the PointyHairedBoss''''''es rejected ExBase and ExBase programmers en-masse and switched to ObjectOriented programming, VisualBasic, and MicrosoftAccess out of sheer desperation. Top, it's ironic that the very thing you rail against -- ObjectOriented programming for business applications -- is ''exactly'' what you and your ilk ''drove'' the PHBs to advocate. Your ignorance, arrogance, and inability to deliver value made them do it. Even an ounce of ComputerScience knowledge would have shown you the folly of relying on ExBase, a staggeringly flawed language and environment that was inherently unstable, unscalable and unmaintainable beyond trivial toy applications. Earlier tonight, I asked a room full of 100+ database students if any of them had heard of DBaseIII. One hand went up. Then I asked them how many had heard of Java, C#, C++, Python and so on, each in turn. Every hand went up. There's a reason ExBase is almost unknown: It's because it '''sucked'''. Good riddance to bad rubbish...] 

That's different generations. You are ignorant about it. There's a reason Microsoft has maintained FoxPro until just a year or so ago. I agree that ExBase failed to modernize, and tried to become more C++-like when it should have tried to take advantage of it's table-orientation. That being said, I've talk to multiple managers who agreed that ExBase programmers were more productive than OOP fans. OOP sucks for most biz apps. But we're getting off topic here. GuiMachineLanguage has almost nothing to do with ExBase. If you want to rant about ExBase, then take it to ExBase or ExBaseDiscussion. - t

[That's my point: ExBase is the ''old'' generation. Indeed, it's the ''dead'' generation. What is significant about FoxPro is not that Microsoft maintained it until recently, but that its last full release was in late 2004 and there won't be more. That should tell you something right there. There's a reason Microsoft dumped it, and that's because it's crap. Furthermore, it's unprofitable crap, because no one except a few lingering, aged desperados want anything to do with it. The problem with ExBase was not its lack of, uh, "table-orientation", but the fact that it was slow, unreliable, based on a ghastly scripting language, incapable of scaling, unmaintainable, unsupportable, and was surrounded by ignorant, arrogant fanboys who didn't have the education or perspective to realise their pet environment was a dire, festering blight on the information technology landscape. Flawed as they are/were, VisualBasic, BorlandDelphi, PowerBuilder, MicrosoftAccess, etc all were so superior to ExBase that they wiped it off the map. Thankfully. Congratulations on finding the "multiple" managers (what? all two of them?) who lived in fantasy-land along with you deluded ExBase developers. The majority of IT managers who endured the ExBase era still shudder, uncontrollably, when it's mentioned.]

[Now then: You may think ExBase has almost nothing to do with GuiMachineLanguage, and in technical terms you're right, but your ''defense'' of ExBase has everything to do with GuiMachineLanguage. It goes straight to the heart of your credibility. Anyone who defends ExBase is clearly deluded and mentally deficient in some profoundly incurable way. Therefore, how can we trust your opinions about GuiMachineLanguage to be anything but the gibbering rants of a slack-jawed chest-drooling madman? We can't, can we?]

That's ArgumentByIntimidation, not facts. It's purely a personal attack devoid of technical specifics. If you can offer realistic code examples (not shapes, animals and device drivers) of ExBase being difficult, then be my guest. Maybe you just don't know how to use ExBase properly. Just because you are ignorant with it does not mean everyone is. Kill me with science, not vague personal impressions.

[I believe the phrase you're looking for is "AdHominem attack". Yes, it is. But if the foo shits, wear it. There is, by the way, no such thing as "use ExBase properly", any more than there is a "drive a motorcycle with a flat tyre and no handlebars properly".]

* If it sucked that bad, then a coded demonstration of its suckage should be easy. Kill me with science, not with names.

* [If it's that good, then a coded demonstration of its goodness should be easy. Otherwise, the default assessment for all Information Technology -- that it sucks royally until proven otherwise -- shall hold true. Though it should be noted that ExBase sucked ''particularly''. ExBase '''excelled''' at sucking. That's why it's gone now. Not because of fashion, misfortune, or mentality, but because it sucked. It. Sucked. It was a language with '''modes''' for chrissakes! The behaviour of local lookups could be changed (often fatally, if you weren't fully aware of it) depending on the value of a '''global variable'''. What kind of mind-puddling idiocy was that?]

* Every language has LanguageGotchas. One learns to work around them and/or be careful in the problem areas. It's a fallacy to say that because a language A has flaw B, language A is completely flawed. I don't like every feature of ExBase either (see ModernizingExBase); but its benefits outweighed the drawbacks in its niche. COBOL has some horrible flaws in my opinion, but somehow manages to serve it's niche sufficiently well to last 50 years. There may be a common lesson: sometimes fitting the domain/niche well is perhaps more important than having the latest language fads/conventions/innovations in them. - t

* [True, every language has LanguageGotchas. ExBase was notable for being constructed entirely from LanguageGotchas. It had no benefits in its niche, and was only popular because it was cheap enough to attract non-programmers who naively were deluded into thinking it was, well, good. Competing products like DataFlex (http://en.wikipedia.org/wiki/DataFlex) were, and still are, superior in every respect.]

* You seem to over-focus on little language issues that irk you in particular. The frog may have warts, but it can still out-jump the lizards. One has to weigh the total problems and total benefits together. Once you got used to the gotcha's, they ceased being a significant problem. VB had triple the gotcha's of ExBase in my experience. Just because they trip you doesn't mean they trip everybody else. PersonalChoiceElevatedToMoralImperative. DataFlex is an old language also, I would note. (Whether DataFlex is better or not is a separate issue.) They "bother you", fine. I'm not you. I'm sure your verbose, pathy, convoluted OOP code bothers me.

* [They weren't "little language issues" The ''whole language'' was a festival of suck. For every identifiable language feature, there was a contemporary competitor that implemented it better. Most of them implemented ''every'' language feature better. ExBase was made popular by a bargain price and an illusion of simplicity and accessibility that made every second-rate downsized middle-management goofball with half-assed typing skills think he could become Bill Gates by writing unreliable video store rental apps from his kitchen table. That doesn't mean ExBase was ''good'', by any conceivable stretch of the imagination.]

* I don't remember it being a bargain. Only after FoxPro gave it serious competition did I see any discounting. And being easily-learned by itself does not make it "bad". MS-Access has far more easier-trumps-coherency features, such as the need for mass replication of "column lists" for each query layer. They didn't remove redundancy, but instead made it easy to drag-and-copy. ExBase is based on a BigIron query product called Retrieve. Retrieve was not designed for week-end hobbyists. - t

* [Serious business application development tools like DataFlex cost thousands. ExBase, even prior to discounting, cost hundreds. For the time, it was cheap software. That's the only good thing you could say about it. Let's remember that DBaseIII implemented multi-user concurrency via ''file sharing''. Dire, dire, dire. DBaseII may have been remotely influenced by RETRIEVE, but they have as much in common as a roller skate has with a Sherman tank.]

* Comparable tools are MicrosoftAccess, Paradox, and perhaps MS-SQL-Server-Lite and FileMakerPro, which have a similar price or lower. DataFlex turns up less Google links than dBASE and clones, so your claim that it's more popular is flat. Does exaggeration release endorphins in you? You seem to get off on it.

* {Since when does a claim of superiority equal a claim of popularity? Does being irrational and illogical release endorphins in you? There must be some cause for you to place WishfulThinking and HandWaving above reason and critical thinking.}

* I remember one of you saying you asked your/a class what "dBASE" was and then gloated because nobody allegedly raised their hand. I cannot find that passage anymore. It got deleted or lost in the shuffle. I interpreted that as a claim that "popular equals good". If you meant something different, I apologize for the alternative interpretation.

* {That wasn't a claim of "popular equals good". That was: "It was popular once but went extinct in the face of competition..." followed by ''explanation''. You should apologize more often for being simple-minded and doing simple-minded OverSimplification.}

* You didn't state that explicitly. I cannot read your mind. Argument-by-vote is a valid interpretation path based on the text given. I agreed in ExBase that it failed to "keep up", but does not mean it doesn't contain good ideas or doesn't have useful niches. People also tend to hop from things to things fairly quick in this biz, not all of it for good reasons. (See PerlPopularityLull). - t

* [The notion that ExBase might have "good ideas" or "useful niches" is like suggesting that in advanced cookery, or even in home cookery, there exists a valid role for a rusty, dull chopping knife scabbed with rotting botulism-infused ichor and festering with toxic mould spores and featuring a broken, jagged grip that invariably causes deep wounds on its user's hand, and then claiming it is a "good idea" or has a "useful niche". ExBase is, was, and will always be a ghastly language and environment by any standard; something that probably did more to harm the burgeoning personal-computing business revolution in the late 80s and early 90s than help it. Only the most naive, stubborn, and idiotic of adherents would claim ExBase is or was anything but a vast, sloshing pail of suck.]

* That's not usable information, only generic ranty insults.

* [It's immutable, indubitable truth, recognised as such by anyone and everyone with sense and reason who has ever endured ExBase, which was a festering stink-hole of hairy doom and a stomach-churningly vile example of idiotic language mis-design. The only good thing about it was... Nope, nothing.]

* I expected your reply to contain the word "putrid". Slipping.

As far as "incapable of scaling", to some extent I actually agree with there. But PickTheRightToolForTheJob. For relatively small custom applications, it kicked ass. MS-Access still can't touch it. However, if you want to write boxed accounting software for 5,000 remote customers, then something like Delphi would be a better fit. - t

[Having used both ExBase and MicrosoftAccess in a professional capacity, I would choose MicrosoftAccess over ExBase every single time. Every. Single. Time. There is nothing, and I mean '''absolutely nothing''' that ExBase can do that something else (and in many cases, almost ''everything'' else) can't do much, much, much, much, much better.]

Well, I have to dissagree. My experience tells me otherwise. Although I agree that ExBase vendors never quite got the GUI relationship to the language right, as a language it fit custom biz programming like a glove, whereas MS-Access has a forced verbose marriage between tables and VBA. Once you needed something past what mousing alone could do in Access, VBA is ugly and takes about 3 times the code that ExBase does. 

Many ideas dwindle because they are not in style, not because they are inherently bad. Old=Bad is short-sighted. ExBase had several vendor-induced misfortunes and a copy-cat mentality. (The topic goes into more detail.) '''Most languages don't survive more than a decade''' as "current" anyhow. Java and Perl are already started to be considered "legacy". ExBase had a typical run. It was killed by excess OO hype and vendor bungling, but it still has '''ideas''' that are very useful and productive. - t

[3 times the code??? What are you ''doing''? Maybe you just don't know how to use VBA properly. As a language, ExBase didn't fit "custom biz programming" at all, unless you ''thought'' it did because you were one of the million odd kitchen-table "programmers" who got DBaseIII as a christmas present from your sister, uncle, mum, concerned neighbour[1], etc., you knew nothing of SoftwareEngineering or ComputerScience, and you simply didn't know any better.]

You are just a typical web-troll with too much testosterone blowing hot air. I'm forced to use MS-Access all the time these days, and it sucks. It's mouse-candy for drooling morons. You have to open-and-close, open-and-close over and over related queries. In ExBase the same logic would fit nicely on half-a-page without the open/close dance. "Computer Science" NEVER proved that OOP was objectively better. No such proof exists, but you are too '''brainwashed''' to realize that. LINQ is an early sign that collection-orientation is returning to mainstream languages. Now they just have to realize that encapsulation has to go too because it creates poor InterfaceFactoring.

[Where did I claim OOP was objectively better? I've made no such claims. I have, however, trivially demonstrated ExBase to be objectively ''worse''. See above re "The behaviour of local lookups could be changed (often fatally, if you weren't fully aware of it) depending on the value of a '''global variable'''." The mind, as it were, boggles.]

* The raising of that issue here is relatively new, it wasn't there when I wrote the above (or added shortly before). 

* [Liar! Yes it was.]

* I honestly remember it differently.

* [Your memory is rife with faultitude.]

* Your mind is rife with projectitude.

[And what, pray tell, are you on about re encapsulation and InterfaceFactoring?]

--

[1] I never met a male DBaseIII programmer who had a wife or girlfriend. Although women can be amazingly tolerant of physical foibles, the majority of DBaseIII programmers were more smelly, obese, and possessed of unpleasant habits and vile personality flaws than any potential life-partner could endure.

''You are the Rush Limbaugh of bloated pathy OOP. No real facts nor deep analysis, just AdHominem attacks and too many commercials.''

Nyah, nyah, nyah. I know you are, but what am I?

''Bend over in front of a mirror, and the answer will reveal itself.''

Only if I pin your picture to my ass...

''You are the type who likes pins in your ass.''

You make it sound like a '''bad''' thing!

''TMI''
-------
'''LINQ Influence'''

I believe Microsoft LINQ (LanguageIntegratedQueryProject) to be in large part fueled by MS FoxPro fans wanting query/table-centric features in app languages. This is based on personal observations and MS product conventions where FoxPro is often mentioned, as in, "I think you FoxPro fans out there will like this part of the demo...". And now Java and other languages are starting to get on the band-wagon. While there are some big warts in LINQ, it's a good start in the right direction; a refreshing refrain from 18 years of "everything must be an object". You can thank ExBase for influencing LINQ. '''Good ideas never die, only take long naps'''. I'm not a fan of MS, but sometimes they accidentally get it almost right because they have their fingers in so many pies. - TopMind

''You're making a wild speculation that is not supported by evidence. That LINQ is mentioned to FoxPro fans is hardly evidence of LINQ's origins, but ample evidence of Microsoft's reasonable attempts to market a new feature to a notably irrascible developer community. Actually, attempts to overcome the so-called ImpedanceMismatch between imperative application development languages and database query languages are older than the RelationalModel itself. LINQ, FoxPro and ExBase, TheThirdManifesto, EmbeddedSql (a close relative of LINQ, and its most likely inspiration), ORMs, and so on, are all attempts at addressing this. LINQ was not inspired by FoxPro/ExBase. Rather, both were inspired by the divide between databases and programming languages that has been noted since CODASYL, and that has arguably only really been addressed by TheThirdManifesto.''

It is more optimized (interface-wise) for internal data structures than for communication with outside RDBMS. It would be the other way around if what you claim is true. Most likely Microsoft will favor integration with it's own SQL-based products, and it could be argued that's what they are after. But neither of us can dissect the neurons of the person(s) who made the final decision inside MS, so it's speculation either way. There are rumors that FoxPro fans had an influence, but I have no OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to prove it.

''What do you mean by "[i]t is more optimized (interface-wise) for internal data structures than for communication with outside RDBMS"? Arguably, the person "who made the final decision inside MS" is Anders Hejlsberg; given that he's an experienced language designer, it's highly unlikely ExBase was his inspiration. It's far more likely he was inspired by the same well-understood limitations of the application-language/database-language division that led to the creation of FoxPro/ExBase. As for there being "rumors that FoxPro fans had an influence", obviously no "official double-blind certified peer-reviewed published study" exists to prove it, but '''some''' evidence would help. Got any?'' 

I heard it through the grapevine, and the grapevine may be wrong. The only way to know for sure is to interview those who brought about Linq.

-------

'''Frustration'''

It's frustrating not being able to communicate what I like about ExBase and I continue to find current tools and languages lacking, taking me twice as long or more to do the same things. People seem to think old means bad. I'm all for finding a modern version or something that '''borrows the good ideas''' into an updated language, we just have to make sure modernizing it doesn't strip what was good about it. The '''three biggest factors''' that make it special are:

* Smaller granularity than SQL, assisting with DivideAndConquer
* Easy integration/mixing of relational operators with procedural scripting so that each does what it does best without verbose mapping between them.
* Ability to (optionally) see and/or use the intermediate results for trouble-shooting and OnceAndOnlyOnce reduction. (This is partly facilitated by smaller granularity.)

My theory is that being used outside of what it is suited for is what mostly gave it a bad reputation. As a primary data repository (AKA "master tables") or as a heavy-duty app development platform, it is not well suited (at least in its current form). That I don't dispute. But for extraction for custom and "local" reports and statistics, and for ad-hoc data chomping, it's hard to beat.

It just has the feel of something designed by practical people doing actual work. It's like that long lost love that left you ten years ago that you keep remembering because the current gal is a pain in the. 

-- top

''Your choice of analogy is interesting, and perhaps revealing. There is no long lost gal I pine for; my current love by far the most amazing woman I've ever met. Every moment I'm with her, and every time I think of her, I'm ecstatic '''not''' to be with any of my ex-wives or lovers. Likewise ExBase. I'm glad it's gone and I don't want it back. I'd rather make a living licking bus-depot toilet seats than use it to write another business application, or use it for "local" reports & statistics or ad-hoc data-chomping. If there were good things in ExBase, like finer-grained operators than SQL, they are found in emerging but embryonic efforts like TutorialDee. My implementation of it, the RelProject, is increasingly being explored by students, researchers and organisations for use in research projects and small-scale practical applications. Like me, they see its potential. Each update adds functionality or fixes that bring it closer to the inevitable point where it will be a serious contender against the major database-driven-application development environments. I'm working now on facilities to connect it to external data sources (text files, Excel-format spreadsheets, and external SQL DBMSes) and exploring adding a user-friendly front-end -- including reporting, graphing and data-analysis facilities -- to its currently-crude desktop client. It will get better and better and better, but ExBase is frozen in the past and won't be back.''

''Maybe it's time to look to the future. If you feel the future should include elements of the ExBase, then please consider joining the effort to produce '''better''' tools, rather than merely repeating the past.''

RelProject is too "type anal" in my opinion. Maybe for medical, bank, or space apps that approach is worth the type fastidiousness tax, but I'm thinking '''scripty tables''' while you are thinking "Ada tables". If this is going to turn into another "type fight", then we can just acknowledge existing topics that war over that rather than reinvent them here. I'm happy to have a marketplace with both kinds of tools/approaches. Nothing wrong with "repeating the past" if there are good things about the past. '''Lisp is an example of something that is conceptually brilliant and has useful niches despite it's age''' (and still being refined, such as the Arc project). And again, I'm not against modernizing ExBase or something like it. -- top

''I think you're projecting your own negative fantasies here. Have you tried Rel? It is no more "type anal" than SQL -- or ExBase -- if you like. You can easily create user-defined types, but nothing forces you to do so. I certainly have nothing against good things from the past -- indeed, my PhD work is based on a paper written in 1968 -- but ExBase wasn't a good thing from the past. It certainly wasn't conceptually brilliant. It's simply a thing you knew and nostalgia supplied the rest.''

I don't buy the nostalgia argument. I've used MS-Access for about the same amount of time now along with some other DB tools, and they are just missing something. They all have different things that I like, but just have a big conceptual gap that they cannot fill well.

''What conceptual gap?''

Other than a cleaner relational and typing model, what does RelProject do significantly better than PL/SQL (Oracle's SQL-procedural-bridging language)?

''Cleaner syntax, familiar programming language "variable" semantics for "tables" (better known as RelVar''''''s), trivial creation of local/temporary RelVar''''''s, explicit RelationalAlgebra operators for finer-grained operations, it's a general-purpose programming language with DBMS capabilities rather than just a DBMS with internal procedural scripting, support for nested relations, no NULLs, no dependency on column order, support for true database constraints, etc. Future RelProject extensions include desktop DBMS capability (a la MicrosoftAccess), connections to external data sources, data analysis & reporting/graphing plugins, etc.''

I applaud the finer granularity, but column order and nulls are often UsefulLie''''''s that simplify certain things the same way that positional parameters often are more reader-friendly than named (key-word) parameters (ideally a language allows a mix).

'' positional parameters might be '''writer''' friendly, but absolutely not '''reader''' friendly (just try to find out which values match with field in a list with 10 or 20 of them'' (some examples of code with and without parameters here http://en.wikipedia.org/wiki/Named_parameter ). Would be really interested to read an example of positional parameters being better for the reader (with the explanation of why, of course). -- LuxSpes

* See PositionalVersusNamedParameters

Column order does not "violate" relational if you think of positions as syntactical shortcuts for dummy/temp column names like "column_3".

''And names like "column_3" what is their purpose other than help obfuscate code....? I have had to give maintanance to database code written by others that relied on the order of columns... it was a nightmare, specially when inserts started to break when somone added a new column at the begining of a table (and legibility is of course, far worse,no easy way to see what value matches what column.... I think column order is not only against relational, it is even against DomainDrivenDesign because it destroys the ability to use the UbiquitousLanguage in your queries) '' -- LuxSpes

* I beleive you misunderstood me. I did not promote actually explicitly naming columns "column_3". And again, I am not saying to always rely on positions. For the "internal" parts of an SQL statement, it can be useful. That's different than the app side relying on it, which I am generally against also. -- top

I didn't say ''always'' use positional parameters. You are using somewhat extreme cases. PickTheRightToolForTheJob. As far as function calls, my general rule of thumb is limit the quantity of positional parameters to 4 if infrequently called and 7 for frequently-called functions/methods. If I am doing a UNION to a bunch of thin tables, such as a heavily-selected set of tables split by year, then positional can simplify life. (Whether it's good to split tables by years may not always be a good practice, but users of the data don't always have that design choice.)

* [''Positionality in UNION is a SQL thing. In TutorialDee, the UNION of (for example) three tables might be '''UNION {YearData2008, YearData2009, YearData2010}'''. There is no dependence on position, because columns are matched by name and type, not position.'']

* That could lead to a lot of aliasing verbage.

* [''In practice, it doesn't.'']

* I practice, judicial use of positionals doesn't kill puppies and trigger earthquakes either. Positional is a handy syntactic tool when used properly.

''Positional parameters might simplify life for the '''writer''' (less keystrokes), but never for the '''reader''' (it is always harder to understand what is being done) ''

And real-world reports have Nulls, or at least "empty cells" and that's the way the customer wants them and will fire you if you don't deliver or spend too much time working around that gap. 

* I think you are confusing Null with None. See NullVersusNone

You seem more driven by idealism and desire for "purity" than practical issues. I'm sure you believe that adherence to "purity" results in better end-results, but I don't want to start up that long messy debate again.

* [''What experience do you have of theoretically-"pure" relational systems that leads you to believe they are impractical? Or are you speculating, without empirical evidence?'']

* What leads you to believe the opposite?

* [''I work with theoretically-"pure" relational systems, and they are practical.'']

* So is assembler language, but it may not be competitive.

* [''What practical experience do you have of '''theoretically-"pure" relational systems''' that leads you to believe they are either impractical or uncompetitive?'']

* I've worked with purity-obsessed people who waste too much time "protecting" purity. There has to be a smart balance. - t

* [''You've not answered the question.'']

* Suppose you are requested to give customer data to a marketing research firm, but strip off customer name, address, and ID to protect privacy. A "pure" relational result would require fuzting around to get the necessary uniqueness. (Although SMEQL can use it's orderBy operation to assign dummy unique numbers, but that's a lucky break by using something meant for other purposes.) - t

* [''I don't know what kind of futzing you have in mind, but in '''Tutorial D''' the query is simply 'SUMMARIZE Customers BY {ALL BUT name, address, id} ADD (COUNT() AS N)'. It even gives you a nice count, N, of the duplicates.'']

* '' Say you have a irrational customer (irrational customers are, unfortunately, very common), one of those that does not get the advantage of having a column with the number of duplicates (N), what would have to be done in Rel then? (is there an easy way to add a meaningless sequential id to the resulting dataset so that it "preserves" duplicates?) '' -- LuxSpes (Playing DevilsAdvocate)

* I don't know if I would go as far as calling them "irrational", they may not buy into a pure relational model of the world. But I agree that they likely may want "actual" rows instead of a count. Evangelizing your world view on to customers is a high-risk endeavor. - t

* Do not run to conclusions, there might be an easy way to do it in Rel... -- LuxSpes

* [''It's easy in standard TutorialDee (and Rel). The basic query is this:'']

         EXTEND Customers ADD (getid() AS serial) {ALL BUT name, address, serial} 
* [''The above assumes you've created the following:'']

         VAR unique_id REAL INIT(RELATION {TUPLE {id 0}}) KEY {};

         OPERATOR getid() RETURNS INTEGER; 
          BEGIN;
           UPDATE unique_id (id := id + 1);
           RETURN id FROM TUPLE FROM unique_id; 
          END; 
         END OPERATOR;
* [''I'm intending to provide a built-in getid() as a Rel-specific extension in a future Rel update.'']

* Like I said before: 'A "pure" relational result would require '''fuzting around''' to get the necessary uniqueness.' I didn't say it wasn't possible. And remember that any dummy ID must be stripped off when the result finally goes to the client. It's not clear to me that such is happening. How are you doing it without producing an "impure" result set (table)? Or does one have to load it into a different "impure" product to strip off the dummy ID? LifeIsaBigMessyGraph, and impurity often merely reflects this. Obsession with purity often results in AddingEpicycles to force the model to conform to the messy real world. The customer wants non-circles and all you have is circles. - t

* [''Well, yes. I admit it: A "pure" relational result '''does''' require futzing around to get the "necessary" uniqueness '''in this particular case'''. To strip the 'serial' attribute, I'd do so in the code where the data is written to a file. But, the example is obviously contrived to the point of being questionable. In over twenty years of professional data processing, I've never been asked to produce a file that must deliberately include duplicate records '''but''' must not have any unique identifier. I suspect the number of real-world requests for such a thing must be '''vanishingly small'''. The need, however, to process '''facts''' where duplicates are meaningless and/or erroneous represents the '''vast majority''' of data processing and data management applications. See DatabaseIsRepresenterOfFacts. Therefore, I'd rather have a system that works to avoid duplicates, rather than one that encourages duplicates (or at least fails to avoid them) like SQL, which forces the developer to carefully specify DISTINCT, GROUP BY, etc., (and woe unto you if you forget to do so!) in order to avoid erroneous duplicates.'']

** I disagree that such is rare. I used to work at shops that produced various marketing-related data-sets and often we were given a specific layout by the customer and/or legal/security review panels and had very little negotiating leverage. A show-stopper? No, but my point is that obsessive adherence to purity can bog things down, and I've given at least one example scenario, and possibly two (cross-tab). - t

** [''Even if you work in a domain that requires non-unique collections of duplicate records on a daily basis, we're talking about a trivial line or two of code to produce the required output. Identifying "missing" values for crosstabs and the like is similarly minimal effort. However, use of a database language like SQL that works in duplicates by default, and that requires explicit mechanisms to eliminate duplicates, demands ongoing work and attention to maintain. It clearly favours using database systems like TutorialDee; which represents a choice between making minimal effort to produce duplicates in the database output vs making considerable effort to eliminate duplicates in the database applications.'']

** After many years of using SQL, I have not found the "duplication problem" a significant problem. It probably wouldn't even make my top 10 complaint list. (Although better Nulls may be in the middle.) I believe you have a psychological desire to see "purity" as the solution to problems because you gravitate toward it such that your brain '''magnifies the importance''' of small issues related to "purity". Sorry, I can't bring myself to care much on that one. - t

*** I am curious what is your TopTenListComplaintListOfSql ? -- LuxSpes
*** ''Top has contributed more than a little to SqlFlaws.''
*** I have contributed to SqlFlaws too, but I have no way to know how many of the flaws in SqlFlaws are TopTen according to Top criteria... -- LuxSpes

** [''Like many casual SQL developers, you're probably either not aware of the problems caused by duplication and have left it for the users to fix, or you've been creating straightforward data entry and retrieval (i.e., data-in data-out) applications instead of the complex data-crunching systems that seriously stretch the SQL developer's ability (and patience) to guarantee valid reports. You could well be introducing duplicates and generating incorrect results and not know it. Indeed, how '''would''' you know? It's not like SQL will tell you.'']

** You are full of shit. It's not like I never hear user complaints. I *have* made a fair amount of Null-related errors, for example, that were eventually discovered. Why would Null-related errors be discovered and reported but rarely duplication errors? I ponder proportions and patterns of mistakes all the time. If you want people to care about your pet tools, then '''listen to their problems''' instead of dictate them. '''YOUR LOVE AFFAIR WITH PURITY IS BLINDING YOU TO REALITY.''' -- top

** [''You are correct that I am, at this moment, "full of shit." Thank you for monitoring the fecal load in my large intestine and rectum. You have accurately identified the fact that I have not yet engaged in my morning defecation ritual. You probably don't hear user complaints because they either (a) think duplicates are their responsibility to deal with, or (b) they believe the erroneous results are correct because they trust the software to be correct. It's interesting that you note duplication errors are encountered "rarely". They shouldn't be encountered '''at all.''' As for being "blinded" to reality, I've been developing business applications for over 25 years. My selection, development, promotion and deprecation of tools is based on that experience. I deprecate nulls, SQL and duplicates, and promote typeful, true relational database systems '''because''' of my real-world experience.'']

** Knowing you, your mind remembers purity-related errors over non-purity-related ones: selective forgetting via HobbyHorse bias. And you still have not explained why I've made and seen many more Null-related errors than duplication-related errors. Why would users notice one but not the other? I've worked on a lot of projects where the numbers ''had'' to add up.

** [''"HobbyHorse bias"??? I'm not the one whose moniker stands for "Table Oriented Programming". :-P You've made and seen many more null-related errors than duplication-related errors because null-related errors are more common in CRUD-screen oriented business applications. If you were doing complex data analysis and reporting, you might well be encountering more duplication-related errors. Or you might not. What's important is that '''neither''' error need occur '''at all''' in a true relational system.'']

*** And possibly introduce other or related unintended consequences as a result. Different people are tripped up by different things. SQL can probably be fixed without being tossed out. The market probably would prefer that right now. - t

*** [''What sort of "related unintended consequences" are you expecting? Strange errors that result from difficult-to-predict behaviour? That's unlikely with a consistent implementation of the RelationalModel, since that's specifically and explicitly what it's intended to avoid, but that's '''exactly''' what you get with SQL. Are you aware of any efforts to improve SQL? I'm not. I'm aware of a number of efforts to replace it. The market might prefer a SQL that's a better SQL without changing SQL, but the market would also like a big green button labelled "You Know What I Want, Do It" instead of a keyboard. Developers, it seems, are more interested in replacing SQL than improving it. Since it is ultimately developers that lead development and adoption of languages (despite IT managers thinking otherwise), it's clear where things are going to go.'']

*** No, it's not clear. The best way to improve query languages would be to document the problems well and analyze the fixes well both in terms of SQL and outside of it. Purists may gravitate toward something, for there are always the MIT'ers as found in WorseIsBetter, but that doesn't mean there are other groups or forces about.

*** [''TheThirdManifesto is three published editions of "document the problems well and analyze the fixes well". Of course, it's outside SQL. It explicitly rejects SQL. Given the state of the industry, rejecting SQL is a way forward. It is unlikely any major DBMS vendor, whether open or closed source, is going to overhaul SQL on any basis, let alone the basis of postings here. However, new languages have the usual new-language chance of capturing the zeitgeist and becoming popular. I.e., slim, but possible. A revised SQL has no chance anywhere.'']

*** I somewhat agree with you, but IF a serious challenger to SQL emerges, the established vendors will simply improve their dialects to take a lot of steam out of the flow. Whether that kills off the challenger or slow it way down is hard to say. It may also trigger a wave of new query languages, which is not necessarily a bad thing. Who knows how the future works.

*** [''Who knows how the future works? I do. I come from the future. It is beautiful and horrible, like a rusty Ferrari Daytona or vagina dentata. Cling to your ExBase while you can, young Luddite, for things to come will make you crave mere object orientation like water in a desert.'']

*** ExBase will probably come back some day in a different form. It will be a "new" language with a different name but fresh hype, maybe LINQscript++ or the like, but people will like it and some dying fogey will try it and point out that, "Hey, that looks an alwful lot like that xBase language family from the 1980's!" The younglings will reply, "xWhat? Whatever. It does the job well."

** And you probably have the inverse bias non-purity-related errors over purity-related ones.... are you going to talk about your TopTenListComplaintListOfSql or not? (Preferably with concrete SQL examples so that they can be translated to TutorialDee to see if it helps or not to alleviate them) -- LuxSpes

** You want them listed out? I'll get back to you on that. And, I'm sure we're all biased. Humans tend to be by nature. - t

* ''Actually, it does not if I do not remember incorrectly, TheThirdManifesto explicitly says that it should be possible for a Dee to load the data of a relation in to an Array. So, just add that code, and challenge defeated! It would of course be better if you could show a way to make that code generic, so that in can be used any time something like this is needed, that would make (in my opinion) its futzingness irrelevant''

* [''An ARRAY can hold duplicate tuples, but creating the duplicates to hold in an ARRAY requires the same "futzing" as creating the duplicates for any other destination.'']

** I still think it's poor feature distribution for a relational language to have arrays. (NonOrthogonalLanguageFeatures). - t

** [''It's not a general-purpose array type. The RelProject implementation, for example, only allows you to declare ARRAYs of tuples. Its closest living relative is a SQL cursor, but since it supports random access -- i.e., you can obtain or set a tuple via a numeric index -- it '''is''' an array-like thing, hence the name.'']

* ''If the futzing not inconvenient, it irrelevant. The point here is the end result, if what is needed to satisfy the requirements does not feel awkward, it is not (in my dictionary) futzing around...'' -- LuxSpes.

* [''I agree. I used "futzing" only to reference Top's application of the term, not because I believe it is actually futzing. I'd argue that the process required to produce an unusual and peculiar output (duplicate tuples with no unique identifier) is entirely reasonable, especially given that manipulating collections of non-duplicate tuples with a unique identifier (i.e., relations) is the usual case.'']

''And... Rel is OpenSource. It's cool, it's hip, it's got the future-flo. Rel dates hot women and drives a fast sports car. Rel is smooth. Oracle is the nerdy, awkward kid in blackframe glasses who wears a striped tie to class and rides a bicycle with a green plastic basket.''

''Actually, the only thing that prevents me from using Rel, is that I can not query existing SQL databases using Rel language... (that is why, while in my opinon Rel query language are far better than, for example JpaQl, I do use JpaQl for the projects I can'' -- LuxSpes

[''Support for external data sources, including existing SQL databases, is an active work-in-progress. I'm back to working on it as '''the''' main development area (as of this writing) after a long delay to focus on implementing DateAndDarwensTypeSystem.'']

------

It was also easy to prompt for values for use in internal scripts. MS-Access sort of has this for values, but you can only see one prompt at a time unless you mix in VBA, which is bloated in comparison. And it's a bear to prompt for values in say commands and table name.

  INPUT "Enter Target Year:" to targYear
  INPUT "Enter Store ID:" to targStore
  INPUT "Enter criteria:" to targFilter
  INPUT "Enter result file name:" to targName
  USE sales_&targStore._&targYear. // Open table, ex name: sales_57_2008
  SET FILTER TO &targFilter
  IF ! empty(targName)
    COPY TO &targName
  END IF
Here the table name is made up of both store ID and year. (It may be poor normalization, but remember one often doesn't have the luxury of designing from scratch. The dots end the string substitution if adjacent to other characters. Also, I've used some conventions from later dialects for reader familiarity.)

[See ArchiveTable]

* [Forget about normalization, think about the potential attacks with SqlInjection. This is absolutely insecure!] -- LuxSpes
* Like it says in the statement, it's an ''internal'' script.
* [Yes, but in my experience, in the RealWorld, this ''internal'' scripts have the tendency to become ''external'' (specially when the PHB wants something exactly like what the script does, but for the end user, and for yesterday)] -- Luxspes
* I've written thousands of little side scripts that ''stayed'' little side scripts. Some YagNi needs to apply, or one wastes time GoldPlating every nook and cranny. And it's easy to add a GUI in newer dialects. (It used to be my job to write little side-scripts.)
* [Well, I have seen the opposite, little scripts becoming little apps, and little apps becoming huge apps (coded with the programming practices that were good enough for little scripts). They were maintenance nightmares that eventually crumbled into pieces (but until that happened, they provided the development team responsible for them (often not the original authors) with a good amount of pain).]
* Sure, a small percent, but does GoldPlating them all in case one "grows up" worth it? I'd like to see a stronger DecisionMathAndYagni analysis done on that. What is the grow-up percent threashold that justifies carefully crafting all scripts? Further, one cannot predict the future changes and cannot prepare for a good number of unknown change paths anyhow. In my experience, it's more economical to wait until a fairly major revision-cycle to overhaul messy scripts for bigger uses rather than heavily engineer them up-front. GoldPlating is ''not'' a substitute for poor discipline or poorly-timed discipline. - t

For informal internal scripts, such as things you might only use once every 6 months or make custom alterations to for ad-hoc requests, I've never seen anything as compact and natural.

* [Might be very convenient for those cases, but the sad truth is that this kind of code is a big security hole, and in a big system, with thousands of lines built like this... think of the DiscontinuitySpike your would experience trying to make it secure!] -- LuxSpes

* [OTOH I can see the advantage of not having to deal with pixel coordinates...] -- LuxSpes

''Individual prompts!? Dire. In Access, create a form with text boxes for all four values and an Ok button. Define the button's O''''''nClick event handler to execute a query that selects the relevant table's data, then export it to a file. It's no more code than your example (actually, it's probably a tad less) and it allows the user to revise the blanks before submitting the form. In your example, what happens if the user reaches the 'Enter criteria' blank and realizes she's entered the wrong year or store ID? Furthermore, in Access you can trivially use drop-down comboboxes or listboxes to select the target year and store ID, thereby restricting those selections to values that actually exist, rather than requiring the user to know them beforehand and type them out.''

[Well, yes, but you have to deal with X/Y coordinates in Access... and do things graphically... and sometimes code is just more convenient... I really would love to be able to describe my screens in very simple terms (and then be able to use that work as a foundation for advanced UI desing... but then again the DiscontinuitySpike''''s would end up killing my productivity later... ] -- LuxSpes

In FoxPro you could make a GUI also. However, it's 10 times quicker to write command prompts. '''Keep simple things simple!''' It's "@" syntax also makes it easy to make semi-formal forms with input templates etc.

[Yes, it is simpler, but it is also uglier... and users love pretty shiny stuff... would be intersting to have a way to describe the UI in very simple terms, and have the result look like a WindowsPresentationFoundation (or a MacOSX AquaUI) application...] -- LuxSpes

By "internal" I meant inside the IT shop, something ran by the programmers or an IT staff clerk.
----
Just thought I'd clear up a few points about Visual Foxpro (VFP). The discussion here suggests that the participants aren't really aware of some things about this development system.

ExBase is one of *two* languages implemented in Visual Foxpro (VFP). The other is a variant of SQL. With the last version of VFP (VFP 9), many limits on SQL expressions present in previous versions were removed. It's not a complete implementation of the ANSI standard current at the time of release, but it has the most common features. 

When discussing ExBase, it's important to make a distinction between its flat-file table storage system, and the accompanying (often very rich) programming language. There are clear limitations to the aging flat-file table design, in terms of both security and scaling. However, the programming language remains a very viable tool for middleware, and, in the case of VFP, for GUIs. VFP can talk to any separate RDMS that provides an ODBC driver. And once it has its hands on the data, its internal RDMS can do things with that data quickly and easily (in both design-time and run-time terms) that users of other languages can only dream about.

* ''What do you mean by "flat file" here? Do you mean lacking "automatic" indexes? Almost every vendor eventually added real indexing, it's just that they didn't follow a universal standard, splitting the dialects.''

[I was a designer/developer of an ExBase product in the 1980's and I never saw any ExBase program (including dBaseII) that didn't have "automatic indexes". ExBase products were created by many competing companies and they had an ExBase flavor but were never designed to be 100% compatible with each other. --- DavidClarkd ]

** Most ExBase products did not have "automatic indexes".  They had to be specified explicitly by the developer.  Once specified, they were automatically updated as their associated tables were updated.

** I'm sorry. I'm probably not using the term correctly. I meant to differentiate VFP tables from "set-based" relational database management systems that have "self-contained" data storage. VFP is relational, and is capable of SQL-type manipulation as well as ExBase-style operations. It also has a system for linking separate tables into a "database" and incorporating some advanced database features, such as referential integrity, constraints, stored procedures, triggers, and security rules, into them. Use of those features is optional. And, unlike "big-iron" databases, in VFP every table is a separate file, and the database linkage metadata for them is stored in a separate control table called a "database container". FoxBase and FoxPro used the same stand-alone index files (.idx) that dBase used. Later VFP added both non-structural and structural compound index files (.cdx). Both of these combine all indexes for a single table in one file. The former requires manual updating; the latter updates automatically with changes to the table. These index files are separate from the table files. Also, VFP tables have a "memo" data type, a text field whose width is "unlimited" (except by the rest of the table structure and the 2 GB single-file-size limit). Memo data for a table is stored in a separate file named for the table but with an .fpt extension; the table contains a pointer to the field in the .fpt file that stores the actual contents of the field.
 
"Console"-style interfaces can still be (more or less) implemented in Visual Foxpro. The default, though, is a Windows GUI, implemented using visual control classes internal to VFP rather than the Windows native controls. (Many, many businesses are still using console-style interfaces though, regardless of what it is said that users like. In fact, purchasers of custom, or "bespoke", software still often demand that the interface at least look like an old-style console, even if it has to be faked using modern GUI controls. Nor is ExBase dead; thousands of business applications developed in very old versions of ExBase languages are still in constant use around the world, and still being maintained and extended. This is because these applications work very well and continue to meet the needs for which they were designed, in some cases decades after they were created. To suggest otherwise is to demonstrate parochial ignorance. Er... :-) )

[ As a former VisualFoxPro developer, VFP came with an interactive console interface that was used by developers. The program produced .EXE programs that end users ran which provided a modern multi-window, menu, mouseable Windows interface for clients.  --- DavidClarkd ]

Procedural and object-oriented programming are both supported by VFP. The OO system is pretty elegant and mostly complete. Missing pieces that I'd like to have are the ability to create one's own base classes not based on a member of the VFP baseclass library, and multiple inheritance. On the other hand, VFP OO does not suffer from the runaway "everything-is-an-object" cancer found in some other languages. 

Oh..and VFP is still formally supported by Microsoft, and will be until 2015. -- KenDibble

''Gee, it might outlive Microsoft itself, the way things are going.''
-------
'''CRUD God'''

I agree that ExBase products were not well-suited for "fancy" or "dazzling" UI's. However, I grew well versed in CUI techniques (character or command-based interfaces) over time and was often thanked by the users for streamlining their work. They were more efficient in them than modern GUI's for most CRUD I'd argue. Know the tool, users, and domain well, the strength and weaknesses of each, and you master productivity. 

They had standard list-style menus for newbies, but I also included various keyboard short-cut techniques for the most common operations and used consistent conventions to improve "finger reuse". Often they '''didn't even have to look at the damned screen''' to get what they wanted because they memorized the keyboard shortcuts. Thus, it was straight-forward to newbies with the conventional menus, yet had a second-tier command/keyboard interface for experienced users that became second-nature.

I agree that if you are selling products to multiple clients, which some of the above detractors seemed to have been doing, then the ugliness of such interfaces probably would produce "anti-sell" vibes.  But my apps were mostly in-house apps and '''I made them hum like nobody's mother''' and was loved by the users so much that one introduced me to her daughter, ''despite'' my clunky personal skills. When some of it was replaced via a mandate from PHB's, they had to hire extra staff (users) to do the same job; there was a noticeable profit dip on the charts. The CEO even sent out a memo to every department that we re-interpreted as:

* ''Dear staff, quit complaining about the new software. I don't want to hear about it anymore. I realize it seems difficult now, but trust us that it will ''eventually'' pay off by allowing us to centralize productivity auditing in order to more quickly and easily verify[1] that the new software is fucking up the company. -Your Friendly CEO''


I miss being a CRUD God. The new shit is too bloated and consists of too many '''poorly-integrated languages/conventions/APIs''' etc. to crank out and tune stuff quickly and cheaply. And get off my xLawn!

http://starchild.gsfc.nasa.gov/Images/StarChild/space_level2/apollo11_lem_big.gif
'' '''Ugly doesn't mean it's not useful.''' ''

 --top

''Introduced you to her daughter?  That's so...  Something.  It explains much about you.  I don't know whether to consider it revealing or revolting.  Maybe it's both.  Did you marry the daughter?''

That's not what I meant by "finger reuse" :-) Seriously though, we didn't click (keyboard pun not intended). Her mom wanted her to marry something like a "Mormon accountant", but she wanted somebody with party skills.

''Are you a Mormon accountant?  That too would explain much about you.''

Quiet, or I'll send you to Kolob!

''That's my home planet.''

Well, it's being targeted for destruction due to excess wanking off. Mormons track that, you know, in ExBase.
-------
Oh, and as far as user interface, I did something that was snazzy for its time when GUI's were new on the block: a flow-chart like screen in Visual FoxPro in which each "box" on the chart was either a button for the task and/or a mini-form. That got a lot of oooohs and aaaaahs. And it was relatively easy to do. (The back-end was more involved, but the interface side was easy.) -t
----------------
As far as the anecdote that somebody made boatloads of money using C++ to replace FoxPro, here's a FoxPro money anecdote:

http://developers.slashdot.org/comments.pl?sid=5675165&cid=47862143

"a friend of mine started working with Foxpro back when it was popular, and unlike everyone else, stuck with it. She makes egregious amounts of money maintaining the small number of things still using it. In her words: 'keep laughing, it paid for my house'."

For the record, I did not enter this post nor know who did. -t

''I'm not sure whether she should get kudos for having the perseverance to achieve success through attrition or a FacePalm for putting up with Foxpro for that long.  Either way, good for her.''

If your code is as poorly factored and commented as your writing, at least she was spared that.

''My writing is poorly commented?  How does that work, exactly?''

No, you see, your writing does NOT work.

''What does that mean, exactly?  Are you attempting some sort of insult?''
-------

'''Tools versus Tool User Confusion'''

Maybe your team were top-end C++ coders (assuming your story is true). Top-end C++ coders of course are going to flatten average ExBase coders in the market-place (especially areas drifting away from ExBase's advantages). Top-end X-ers will almost always beat average Y-ers (if their products compete in the same market more or less). I've seen C++ teams struggle to match the productivity of ExBase coders myself. Perhaps they were low-end C++ coders competing with medium or top-level ExBase coders. It's hard to know without wider detailed surveys. I believe you are '''over-extrapolating''' a limited situation. -t

''I only related an anecdote, so I'm not sure what you think I was "over-extrapolating" given I made no extrapolations at all.''

"...hordes of...[ExBase]..."programmers" (I use the term loosely), uninformed in computer science, descended on the developer world like noisy, opinionated, ill-informed, irrational, illogical lemmings..." If that's not extrapolation, then I don't know what is.

''That's not the anecdote you were referring to, is it?''

''It's not extrapolation.  It's hyperbole.''

Those are not necessarily mutually exclusive.

''True.  But in this case, they are.''

That's not clear as written, but, to avoid drama, I will not request that it be fixed.

''Given that you switched anecdotes, you'd have no basis upon which to request that anything be fixed.''

What anecdotes were switched?

''The C++/ExBase anecdote is not what you quoted above.''

The relationships and/or non-relationships between them are not clear. You may know what YOU intended, but I cannot read your mind.

''It '''should''' be clear, because the C++/ExBase anecdote -- in which I subjugated the weaker ExBase competition by developing superior C++ tools -- to which you referred isn't even on this page.  It's toward the top of IfFooIsSoGreatHowComeYouAreNotRich.''

{Are you sure? I can find it at the top of this page but not on IfFooIsSoGreatHowComeYouAreNotRich. It's still clearly not an extrapolation, so I guess we can add "extrapolation" to the many things Top is ignorant about but still feels compelled to argue.}

''See the paragraph starting with "I'm not the author of the 'blow out of the water' comment -- at least I don't recall writing it ..." on IfFooIsSoGreatHowComeYouAreNotRich. On this page, there's only a glancing mention of that anecdote.''

If you happen to be a C++ whiz (for the sake of argument) and you run circles around average xBasers, you may conclude that all xBasers and/or all of xBase is crap, as the anti-xBase rant implies. But what you are failing to consider is sub-par C++ coders out there. (Like I said above, I've seen xBase teams clearly out-produce C++ teams.) Thus, it appears you are extrapolating your '''own''' C++ whizness to all of C++ land. Is that clearer? Further, you seem to be extrapolating ExBase's weakness in machine-level and fine-tuned graphics control to the entire worth of the tool. It's a form of , "X is bad at A and B, and therefore X is bad in general". That is a form of (poor) extrapolation. -t

''My only claim on IfFooIsSoGreatHowComeYouAreNotRich was that with a good tool, you can blow your competition out of the water. I made no claims as to why that is the case -- other than that we specifically sought to address the limitations we recognised in ExBase -- so any extrapolations are your own.''

''As for ExBase being bad, it was bad in every possible area: The language was badly designed and badly implemented.  I had no issue with its "weakness in machine-level and fine-tuned graphics control" -- I'm not even sure what that means.  I had a problem with its modal behaviour, its poor performance, its file-sharing concurrency model, its verbosity, its awkward syntax that resulted in an almost perverse obstruction to re-use, etc.''

It depends on what kind of reuse we are talking about. If you want to re-write all the lower-level interfaces to your or the customer's whims, then I agree with you 100%. However, I've seen nothing in it that hindered business-logic-level reuse.

''What hindered business-logic-level reuse was the inability to parametrise table references or make them generic in any but the most awkward (and slow) ways, and the modality of the language required that modes be preserved at the entry to a routine and restored at the exit.  This was awkward, failure-prone (forgetting a 'preserve' or 'restore' was easy), and slow.  I'm sure there were other roadblocks, but I forget them now.''

Macros allowed one to parametrise just about anything. Such would not typically be in a "tight" loop such that I don't know why it would make the app "slow". I agree that "modality" was a problem, but if you establish conventions you minimize them. C++ has its own gotcha's.

''It did, but we had no problems with those.  We all agreed that ExBase was dire, for many reasons.  I'm sure I've forgotten most of them, but I do remember that dropping ExBase was not a decision made lightly -- we were well aware of what it might mean in terms of leaving a well-known, accepted platform for an unknown approach.  Fortunately, it worked.''

-------
'''Meta Analysis'''

I think this topic is interesting on a level beyond just ExBase itself. C++ and ExBase are very different languages and tools with very different design philosophies. ExBase is a semi-dynamic DomainSpecificLanguage intended for smaller custom CRUD-centric projects. If you stick with its conventions and "flavor", you can achieve a lot of functionality with little code, typing, and library preparation. Whether C++ can compete in that arena is hard to say. To me it appears it couldn't based on my observations, at least at the '''hands of average coders'''. I suspect one could make a nice C++ library to compete in xBase's core niche, but coders coming in from the outside would have to learn that library before they become productive. By packaging the DSL into a widely-known language (set), xBase made PlugCompatibleInterchangeableEngineers possible. If that C++ library became popular, perhaps it too could achieve the same swappability, but the reality is that it didn't during xBase's hay-day. Some of it is QwertySyndrome. (One could argue that xBase was ''too'' specifically tuned to domain/style, and that's why it shrank in popularity during the GUI era, while C++ retained about the same market share.) -t

''One of the reasons I think we were successful with C and C++ libraries and tools was that we could specifically target limitations in ExBase.  ExBase was essentially static.  Fixing its limitations required either a new version of ExBase (rare) or in-house and/or third-party tools and libraries.  However, the ExBase language itself made building generic add-ons so difficult that constructing good quality tools or libraries was a dire effort (and the results tended to be painfully slow) and good third-party tools were rare.''

''Our C and C++ libraries and tools had no such limitation.  The built-in ExBase report facilities were too limiting, and coding reports from scratch was too slow and error-prone, so we built C++ tools and libraries that made complex reports easy to create.  Creating complex forms in ExBase was also too slow and painful, so we created an event-driven forms library, a C++-based forms painter, and a forms sublanguage.  Creating drop-down menus and popup windows was slow and awkward in the ExBase clone we were using, so we defined menu-and-dialog routines in C++ to make it easier.  The locking-based concurrency approach used by ExBase proved too failure-prone and complex, so we built a new database engine in C++ that sheltered the developer from the complexities of handling concurrency.  And so on.''

''In short, the advantage of C/C++ was that it was easily extensible, so we could continuously improve our tools.  In ExBase, the language itself fought back against tool-based continuous improvement.  Whilst we could make our tools better, our ExBase-using competitors were essentially stuck with whatever their ExBase implementations gave them.  It made a significant difference, to the point that even our weakest C++ programmer -- using our libraries and tools -- could outperform a strong ExBase programmer.  Using raw C++ and a typical project development timeframe, I'm sure a good ExBase programmer would run circles around even an expert C++ programmer.  However, using carefully honed C++ libraries that were iteratively developed specifically to address ExBase's limitations, we gained a competitive advantage that even the best ExBase programmers couldn't beat.''

In short, you were "using it wrong". It facilitated PlugCompatibleInterchangeableEngineers per above. Your approach does not (outside of your org or staff). You gain finer-grain fiddle-ability AT THE EXPENSE OF PlugCompatibleInterchangeableEngineers. You are judging it on '''potential power instead of practical power''' in the typical business staffing environments as they actually existed.

''I don't recall there being a "Use only for ..." on the dBaseIII box.  Our clients didn't care whether we used PlugCompatibleInterchangeableEngineers or not.  They only cared whether or not we delivered high quality software on time and under budget.''

* Reasonably experienced IT shops did consider maintainability per staffing. C/C++ coders typically didn't work on small or narrow-niche custom biz apps, period, but rather packaged commercial apps.

* ''I'm sure that was typical.  As C/C++ programmers, we thought we could gain a competitive advantage using C/C++ for custom business applications, and we did.''

As far as pop-up menus/dialogs, I agree earlier versions often made pop-up dialogs difficult; but in the earlier DOS & CUI days you were not expected to make pop-ups, and users were often confused by them if you gave them one. They were used to keyboards, not GUI's. 

There were different ways to go about pop-up equivalents, depending on the typical work-flow. (I'd generally learn the work-flow of the customer (user) before designing an interface.) For example, take this typical form:

 ISSUE TRACKER SCREEN (Form 7a)
    Ticket ID: 1234  // auto-generated
    Event Date: [12/29/1989]
    Ticket Log Date: [12/31/1989]
    Status Code:  [_] A=active,N=new,H=on-hold,C=canceled,R=resolved,O=other
    Store (City): [_______] // look-up 
    Issue Category: [_______] // look-up
    Complaint Source:  [________________]  // free-form
    Issue Description: [_________________________...]
    Finish Command: [S] S=save,P=save&print,C=cancel,D=Delete
"//" means an internal comment. For "short" lists like the Status Code field, entering abbreviated codes was acceptable back in the day[2]. (A printed report could display the full title instead of the abbreviations if necessary.)

For more involved lookup lists, such as Store City and Issue Category, the best approach typically depends on how often they change (on an instance form). Here is one approach:

On the main menu(s) you'd typically have something like "A - Add new record" and "C - Change record". If the user selects "A" for Add, then the lookup lists would come up first and would typically look like:
  STORE (CITY) SELECTION MENU
  CH - Chicago
  HO - Houston
  LA - Los Angeles
  NY - New York  
  PH - Philadelphia
  SA - San Antonio
  SD - San Diego // etc...
  ------------------
  UN - Unknown
  NA - Not Applicable (Ex: operations or admin)
  HE - Help & Search Tips
  (Blank for Back)
  ------------------
  Enter Code: _
Each list would be presented in a sequence for such new records before taking the user to the "regular" field form. Thus, when the user is done entering city, the Issue Category menu comes up, and then the general form (Form 7a above).

Longer lists that don't fit on one screen would typically have some kind of pattern matching or partial lookup. For example, if the user enters one letter instead of 2, then a list of all cities starting with that letter would be given. Maybe typing "\TEN" would show every city containing the sub-string "TEN".

To change existing records, the original menu above may be expanded to resemble:
   ISSUE TRACKER MENU
   A - Add a ticket
   C - Change or delete a ticket
   Y - change store citY code
   I - change Issue category
   F - Find existing issue tickets
   R - Reports
   (Blank for Back)
      Enter Code: _
A prompt for the Ticket ID may come up for some of these choices. Typically it would be pre-populated with the prior entered ID so that one didn't have to keep re-entering it if working on the same record via multiple menu options.

Also on the regular form, they could optionally go ahead and enter the abbreviation codes directly without going through the selection screen(s). Experienced users memorized the codes. (This would be for changing an existing code. For new tickets, going through the code menus doesn't cost extra key-strokes anyhow.)

Another or additional approach to look-up lists is to have a "Menu?" prompt after each code field. If "Y" (Yes) is given, then the menu list is displayed after they save the form.
    Issue Category: [__] Menu? Y/N [N]
A variation on this is to show the code menus (afterwards) if an asterisk(s) is entered. This reduces having another field to tab through (Enter-through back then):
    Issue Category: [__] (* for later menu)
'''I had no trouble making a library of routines to handle (reuse) these kinds of conventions.''' Most of my time was spent fiddling with very domain-specific processing and reporting requirements, not UI's such as above. Often I'd bang out the general menus and base entity screens in a couple of days, and the weeks that followed were spent on specialized needs and iterative customer feedback.

If you make it so single-letter menus don't need to press Enter, then many users are '''quite productive''' with such CUI interfaces, often even better than with GUI's. (If they didn't have a slow PC.) GUI's are not really optimized for productivity, but rather ease of learning for newbies.

''We won contracts by demonstrating that our interfaces were far slicker than the above, which were typical of ExBase applications.  It doesn't matter whether our interfaces were actually faster/easier/etc. or not -- just being able to pop up a list of options without changing screen or requiring code books was often sufficient to make a sale.''

Well, I saw no evidence that swarms of C++ programmers were doing that on a wide scale for a '''decent price'''. That your particular team was able to pull it off is great, but apparently it was something other C/C++ contractors were not able to re-create. Your personal experience does not scale. (And finding maintenance programmers who can navigate your custom libraries is still an open issue.)

''It wasn't done on a wide scale.  We were computer scientists with a keen interest in programming, which we genuinely loved for its own sake.  Most of our competitors were accountants and former middle managers or ex-mainframe coders with a deep loathing of programming.  They did it because management thought it was a source of easy revenue.  As for navigating custom libraries, we had connections with the local university and our libraries were used for the practical portion of a course.  That provided us with a steady stream of developers pre-trained to use our tools.''

How would that work in a non-university town?

''I have no idea.  That's not my problem.''

It's pretty obvious from that statement that you do not wish to look at the issue of tool selection from a general business perspective. "Let me play with my fancy bits, for financing and finding future maintenance programmers are SomebodyElsesProblem."

'''I rest my case.''' --top

''How do you infer that from my statement?  We were in a university town. We had contacts in the university, and leveraged them to our business advantage.  It was of advantage to the students, too, because they got to work for us and learned a lot.  I can't speak for non-university towns, because I didn't live in one.  How does that generalise to some arbitrary statement about maintenance programmers?''

It doesn't generalize, and that's the problem. You appear to admit that your observations/experience about programmer knowledge and availability may not apply to non-university towns per "I can't speak for non-university towns...". That's '''important info''' for anybody considering recreating your (alleged) situation and/or selecting contractors and programming stacks. Plus, if every contractor did it, it may dry up the supply of students and/or recent graduates. There are '''staff scalability questions''' both in a U town and out. -t

''No, that particular issue doesn't generalise.  What generalises is using a better tool than the one your competitor uses to beat your competitor.  The definition of "better tool" may vary.  In our case, at that time, it was C/C++.  Under a different time and set of circumstances, it might have been something different.''

* Also note that the managers making the final decisions mostly cared about what's on their '''printed reports'''. They themselves often didn't do the screen-work, but rather lower-level staff (this balance has since changed to a large degree). If you wanted to '''dazzle that level''', then give them the fancy reports they want. That's often where I spent most of my UI work, not screens. I made loved reports, not loved screens.

* ''Our tools put strong emphasis on input -- forms -- and on being able to easily and rapidly create complex printed reports.''

* I don't see how xBase was weak on report customization; most of it was string fiddling; other than maybe being a bit slow.

* ''Really?  It was terrible.  For example, how do you create a report that nests other reports?  How do you create a mixed columnar and free-format report?  More than the default (two?) nested grouping levels?  Dynamic headers and footers?  Grid reports (e.g., calendars)?  Etc.''

** As far as 3-or-more-level nested reports, typically I'd create a work-table with character columns for the visible report columns (cells formatted by another process), and have hidden "level control" and "sort control" columns. I'd pre-generate all the summary rows with the appropriate level control codes, add in the detail rows (if applicable), and then sort the work table on the level- and sorting- control columns to make it appear in the proper order in the output report. DivideAndConquer. I had subroutine libraries for such, using the all the nice table-oriented features of ExBase to do most of the DatabaseVerbs-related grunt work. I even got a DataDictionary to handle most of the column formatting (width, format template strings, summary handling codes, key grouping participation, etc.) such that I use BROWSE at the command line to fill in the DataDictionary for a given report. -t

** ''That's exactly the complexity and awkwardness we avoided by creating a better report generator.''

** That's not complex; I bet the alternative is more lines of code. Note that commercial report writing software already existed and read DBF files such that it was often not economical to re-invent the report writing wheel. Typically xBase was used where the requirement were one-off fidgety-fudgety to a particular company or department. Excessive abstraction is often a waste for such because the chance of reuse is low.

** ''We looked at the commercial report-writing software available at the time, and it was either inadequate or involved costly run-time licenses.  Our reports were defined using a report language or library routines; both were very lean.  A DataDictionary, etc., would certainly have involved more effort if nothing else.''

** How would a DataDictionary be worse? You are telling me it's easier to enter report column specifications as C++ code instead of filling in a table via a TableBrowser grid? (It was also easy to turn an existing table schema into column-to-row-based table so that one can pre-fill the table based on an existing table as a starting point.)

** ''How would a DataDictionary allow you to specify nested reports, mixed columnar and free-format reports, dynamic headers and footers, and grid reports, easier than C++ code?''

** I never claimed it did everything for every kind of report (although I haven't tested the limits). For a typical multi-nested report (totals, sub-totals, sub-sub-totals..., detail) it's generally easier to specify column info via a TableBrowser input grid than via application code. (At least for my eyes.) Typical info put into the DD may be source table row-name/source/formula, column title, format type/category, max width (or fill width), zero/blank/null handling method, overflow handling method (truncate, warning footnote, error-stop, scoot right, multi-line, etc.), summary usage (none, total, count, average, weighted average, etc.) -t

* There may have been a fair amount of projects, shops, or management personalities that wanted or needed more sophisticated or snappier screen UI's. Being that ExBase was overall weak in that area, there indeed may have been a solid niche in screen-centric development. HOWEVER, that does not mean that C/C++ is a replacement for ALL of xBASE's ninche(s). For example, a good leather shop, say Bob's Upholstery, may be able to take away a lot of customization biz away from nearby car dealers. However, that does not mean Bob's Upholstery can take over all the functions of a car dealer. The car dealer may still do better on integrated service, one-stop servicing, and bundled deals. For customers in which upholstery matters more than the other factors, Bob's Upholstery is the way to go. Your viewpoint appears to be rather narrow.

* ''My viewpoint is neither narrow nor wide.  I make no comment on whether our approach was or was not applicable to anyone else.  It worked for us, and that was enough.  I've given my reasons why I thought it worked, too, and I see no contradiction to my points.''

* The fact that you have almost no observations or comments about ''other'' C/C++ shops suggests you don't pay much attention to the general market.

* ''Why would my observations or comments about other C/C++ shops have anything to do with this?  It hasn't come up.''

* Any conclusions you draw may only be applicable the circle within a 20-foot radius of YOU, which excludes something like 99.99% of the planet Earth.

* ''I'm not sure how you derive that from my statement.''

* I believe it would be pretty obvious to most readers. I'm at a loss at this point to think of a better way to say it, but will ponder alternatives.

* ''If you're trying to say my circumstances applied to me, that's trivially true.  My point was not that C/C++ is the solution to everything, or even that C/C++ always beats ExBase.  As I pointed out above, my point is using a better tool than your competitor can be used to beat your competitor.''

* For certain situations in certain circumstances, I don't disagree. PaulGraham made big with Lisp, but nobody has been able to consistently replicate that. A small group of skilled ninja's can probably knock a big blow to a superpower at the right time and right place and with a little luck. '''Replication seems to always be the hard part''' of such occurrences. Nobody can bottle the lightning.

* ''I agree.''

Clipper eventually added fairly good pop-up menu commands around the time that pop-ups became common. I don't remember about other CUI dialects.

''Later on, all of them provided some mechanism for pop-ups, drop-downs, dialogue boxes and the like.''

True, but in the Windows 3.1 era when fancier UI's became expected, MS-Access, VB, Delphi, and Paradox were the main competitors to ExBase, not C++.

''This is true.  Our C/C++ tools were character mode.  When Windows became popular, we used MS-Access and Delphi for quite a few things, then the Web came along and we seized onto it like a, uh, seizey thing.''

I've seen no evidence of wide adoption of C/C++ for smaller custom biz apps in ANY of those 3 eras (DOS/Windows/Web). Lightening only struck once.

''I've seen no evidence of it either.  However, in the time and place where we used it, it was the right tool for the job.''

Your initial rant implies a big general problem. Now you are slipping into nuance-ville. 

''My initial rant was intended to mainly be entertaining, but the ExBase language was unquestionably the worst programming language I've ever used, by a long shot.''

You've done a poor job of making your case because you used or looked at a very '''small sample size''' of shops/teams. Your little group may just have been lucky with team chemistry and timing. (Assuming your "I got rich with FP!" story is really true. I personally don't trust you.)

''I'm not trying to make a case; I have only related my personal experience.  As for not trusting my story (FP? I assume you meant C/C++?) to be true, I think you're just jealous.''

I know some high-end xBasers who made really good money. If one is a master of a tool, has FastEyes, a good memory for variable and API call names, etc. they can do really well. I just know you have a tendency to "Rorschach" the world into your personal preference in other topics, and thus may likely due the same to IT history. You claim to be a teacher, but are one of the shittiest tech writers I've ever encountered (other than raw newbies, perhaps). Nobody can write and explain that bad and be a paid university teacher (unless you bribed somebody with your C++ fortune).

''Yup, jealous.  The spew of AdHominem''''''s is proof.  There's absolutely nothing here about technical writing, but apparently insults were called for.  Feel better now?''

You started the AH with "I think you're just jealous". True, I shouldn't have followed suit, but due to being an imperfect human being, I shoot back.

''How is identifying jealousy an AdHominem attack?  If it looks like jealousy, it probably is.''

How is identifying poor writing an AdHominem attack? If it looks like you are lying about professor-hood or nepotism because of crappy writing ability, it probably is. Further, if one does not personally trust your story because of other issues related to trust and bias and apparent hallucinations, how does that make it "jealousy"?

''That's just more AdHominem''''''s.  E.g., "apparent hallucinations".  Do you have any evidence to back up your assertions?'' 

''If not, it looks like even your accusation of my "crappy writing ability" might be attributable to -- for example -- poor comprehension skills on your part, or perhaps an unwillingness to acquire foundation knowledge.  The number of difficult discussions you've had with various people here over the last decade -- in which you consistently demonstrate a significant lack of knowledge of common undergrad-level ComputerScience topics like ObjectOrientedProgramming or FunctionalProgramming -- would tend to suggest either explanation, or both.''

''The last time you mentioned my "crappy writing ability", your only evidence of it was supposed FractalVagueness.  FractalVagueness uses a fictional dialogue to make its case.  That's hardly an indictment of my writing, as you've provided no real examples of it that demonstrate any flaws.''

-------
'''Prototyping'''

The above suggests that your team often rewrote EXISTING xBase projects to make them faster and visually snazzier.

''What suggests that?  We did some of that, true, but it was not our main source of business.''

This would mean that you don't incur the costs of analysis because somebody already did it. Getting the customer's requirements right is often the bottleneck, not technology. Customers are not IT experts and often either don't know what to ask for, or ask for something they don't really need because they saw an ad but don't know better. It takes '''experience''' and often some trial and error to tease out the requirements and ask the right questions via a kind of SocraticMethod. 

I doubt your "army of students/graduates" would be decent analysts; they'd be too green. Thus, if one was starting from scratch, they'd need to hire an analyst also, not JUST coder. For smaller projects this would mean hiring an analyst and a separate coder since somebody adept in both is relatively rare. xBase is easier for an analyst to pick up so that an org is less likely to have hire two people.

Therefor, I doubt your approach would be effective for new projects. But it may also suggest that it's '''not an either/or situation''': the best approach may be to prototype the project in xBase, tune it to fit requirements, and then later convert it to C/C++ to get speed and visual dazzle (if a co wants to pay for dazzle).

''Senior people, e.g. me, did the analysis for that style of development.''

''Prototyping in ExBase was unnecessary.  We were early adopters of an agile approach that -- where appropriate -- involved developing code onsite, on a portable computer and later a laptop, using our tools and libraries, then handing it to the user for evaluation and (eventually) production use.''

Being you discovered the off-the-shelf PC report writers didn't provide very good choices, why didn't you go into that business instead? It's the area that C/C++ is generally used for, unlike smallish custom biz apps (per general actual penetration patterns). If you had success "off niche", then perhaps you could have really made a killing on-niche.

''We considered it.  We didn't have the desire to take it "on the road" doing corporate sales, so it would have meant selling our C/C++ libraries and tools out of the back of (say) Byte or PC Magazine -- same as Ctrieve, C-Tree, Quick Reports (later, Crystal Reports) and the like -- and at that time we were forming a partnership with a national franchise to develop and support their office automation software (with a percentage-of-sales-revenue funding arrangement) and that looked like a better long-term opportunity.  It probably was.''

-------
Footnotes

[1] One of the alleged selling points of the new software was that it would integrate and centralize CEO-level reporting of general operations to get a better big picture. Before, each division had their own systems. While it may have been true that the CEO-level reporting may have been improved, it came at the cost of lost productivity at the staff level. Is the more timely summary info really worth staff-level productivity dips? This is why we started joking that the new system allowed them to better verify that they screwed up by picking the new system. Suckage Recursion. I'd estimate it would have taken about 10 extra clerk-level people to match the productivity of the ExBase software. However, the company only hired about 5 new, meaning productivity slumped AND they had a bigger staff than before. I suspect they did this because they would have to admit they really screwed up big-time if they hired 10, so 5 was their ugly ego compromise. Two yellow flags "looks better" than one red flag.

[2] Screen real-estate was very limited back then such that the shown list may end up looking more like: "A=actv,N=new,H=onHold,C=canc,R=reslvd,O=othr". A manual was written to explain them.
------
See also TopNoiseFilter (has more ExBase ranting)
------
CategoryHistory, CategoryStory, CategoryGetOffMyLawn
----
MarchTen JuneThirteen JanuaryFourteen