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. -t
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.
CategoryHistory, CategoryStory
MarchTen JuneThirteen JanuaryFourteen

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