Ex Base Rant

(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.]

[[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:

[[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 ]]

[[ 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 PointyHairedBosses 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".]

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.]

[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:

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 RelVars), trivial creation of local/temporary RelVars, 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 UsefulLies 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

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 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.)

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.

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. 

         EXTEND Customers ADD (getid() AS serial) {ALL BUT name, address, serial} 

         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;
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]

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.

Individual prompts!? Dire. In Access, create a form with text boxes for all four values and an Ok button. Define the button's OnClick 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 DiscontinuitySpikes 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.

[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 ]

"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:

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!

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.

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.

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 AdHominems 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 AdHominems. 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

EditText of this page (last edited October 26, 2014) or FindPage with title or text search