Live data from Hacker News

Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

latimes.com

101–108 of 108 posts

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#101
post #31

Earlier quoted context omitted.

Also excellent built-in documentation, complete with samples and F1 context help. I pretty much learned FoxPro from scratch entirely from it.

how did we go from excellent software, with excellent documentation, that made regular people implement solutions, to the current situation?

I wouldn't say that FoxPro was the kind of tool that "made regular people implement solutions". It was still a fairly complicated PL and framework - in some respects, more so than low-level languages, actually. It was just particularly well-suited to the kind of CRUD-but-complex apps that are especially common when automating business workflows.

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#102
post #33

Great 80s video teaching an office worker to use DBASE 3 https://youtu.be/j0ng2Tp01Hc A great starting point for a young developer. So much of the early computer world was getting data in databases and spreadsheets. Covers a significant percentage of usecases (and still does with stuff like SharePoint or even SAP).

Wow! That was a nostalgia moment. My first professional gig was in 1988 when I took over writing dBase code for an NSF sponsored evaluation project. That taught me enough to work internationally for USAID writing dbBase code for all kinds of projects around the world, and still make it back to the US in time to catch the beginning of the dotCom boom, Linux, and all of the other great stuff over the past 30+ years.

It was an awesome time. Folks laugh at all of the tech now, but QuickBasic 4.5, Turbo C++, and dBase were amazing tools for building stuff that was very cool at the time.

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#103
post #33

Great 80s video teaching an office worker to use DBASE 3 https://youtu.be/j0ng2Tp01Hc A great starting point for a young developer. So much of the early computer world was getting data in databases and spreadsheets. Covers a significant percentage of usecases (and still does with stuff like SharePoint or even SAP).

Wow! That was a nostalgia moment. My first professional gig was in 1988 when I took over writing dBase code for an NSF sponsored evaluation project. That taught me enough to work internationally for USAID writing dbBase code for all kinds of projects around the world, and still make it back to the US in time to catch the beginning of the dotCom boom, Linux, and all of the other great stuff over the past 30+ years. It…

Makes you think there is always that niche of usecases between newbies and a full blown developer. And we've somewhat lost that today, you have to be a coder with knowledge of an esoteric language (hire one) or nothing.

Businesses have managed to fill this with some (sometimes crazy and fragile) uses of excel, the larger with over complicated ERP and entprise systems, and what not but the late 80s and early 90s were the hayday for the best tooling for this sort of thing. The Golden Era for the hacker sort, building a quick and effective system without anything fancy or boilerplate or requiring the equivalent to a CS degree.

The software that makes software without having to fully know programming has always been the pipe dream product I guess. Many have failed down this route.

The sort of incentive where every simple CRUD app eventually turns into a CMS. Or how B2B software just becoming data managling pipelines (like Zapier), each slightly customized for every industry and plugging into their wider system. There's probably a few small set of archetypes all software fits into, these being two I've come across most often in my career.

There's always plenty of overlap at a high abstraction like that with all of these apps, but the devil (and money) is often in the details (ie, making it accessible and relevant to their business use case with proper sales, documentation, and design).

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#104
post #99
post #45

Earlier quoted context omitted.

It would be interesting to get that statement, because .NET original plan was to be what WinRT is. A improvement over the COM runtime with better tooling, but then they pivoted the idea with J++, and had to reboot it with .NET for the reasons we all know. https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/p...

The article I read years ago. I could not find that article, I found a similar one. https://visualstudiomagazine.com/blogs/desmond-file/2007/03/...

Thing is, LINQ came into .NET via Cω and Erik Meyer's work, hence why I was curious about Anders Hejlsberg making such kind of statements.

"Confessions of a Used Programming Language SalesmanGetting the Masses Hooked on Haskell"

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72...

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#105
post #34

The whole xBase universe is quite fascinating. It might not have been as revolutionary as spreadsheets, but having databases on your homecomputer/PC covers a lot of use cases for regular people and small businesses. Heck, a lot of what we make way too much money with is basically "just" polishing that. (Or trying to sell you pills while you use that, but let's not digress) And dBase and its variants/rivals had that p…

> Heck, a lot of what we make way too much money with is basically "just" polishing that. No one wants to admit it, but 80% of "Enterprise IT" revolves around "CRUD app on top of a database". The other 20% mainly revolves around either running reports off the data in that database or interfacing it with some other system. Been this way for decades.

Maybe it is is "CRUD" in practice, but often it shouldn't. There ist way too much business software with ugly hacks like misused data fields, endless data repetition, manual steps and the like. That might be "good enough" in many cases, but it comes with risk and high costs. Software supporting actual business processes using "domain objects" would be way better.

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#106

Earlier quoted context omitted.

> The whole xBase/Clipper-verse almost seems like a unique dead end, in an industry that keeps pretty much every other technology afloat. Interestingly Claris's FileMaker is still in business: https://www.claris.com/filemaker/pro/ And of course many editions of MS Office include Microsoft Access, which undoubtedly had a role to play in killing dBase, Borland’s Paradox, and Lotus’s Approach. Access’s not quite as perv…

FileMaker's quiet, sustained success over the years makes you wonder why Microsoft didn't spin off FoxPro in the same way that Apple spun off Claris. Perhaps they were worried it would be too competitive with their own core products?

> why Microsoft didn't spin off FoxPro in the same way

They have Microsoft Access, which is the sort of spiritual heir to FoxPro, and is bundled with higher tiers of Microsoft Office. Access has lots of users across industries.

Access is bundled with 'Pro' editions of Office and [Office] 365 Business Standard.

Wikipedia has an interesting account of how post-acquisition FoxPro and Access were developed in parallel. Looking at both[1], it seems that the critical point was when Office 2007 was being developed, when Access got a new file format (presumably making it future-ready). FoxPro's demise was announced shortly after Office 2007 was released, although it was supported till Jan 2015.

[1] https://en.wikipedia.org/wiki/Microsoft_Access ; https://en.wikipedia.org/wiki/Visual_FoxPro

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#107
Hey all -- A friend mentioned this discussion, so I thought I'd drop in to say "Hi" and "Thanks" to those of you who've purchased my book, Foxtales. That was an interesting time to be alive. Now decades later, I still occasionally have dreams (nightmares?) where I'm back coding for Fox again. Hope you enjoy my experience. Kerry Nietz

Re: Microsoft's FoxPro 2.5 Is Fast and Easy to Use (1993)

#108
post #32
post #10

Earlier quoted context omitted.

I have a bit of experience with older verdions of DBase and Clipper and I find this extremely odd. Can you give us a bit more details? I am genuinely curious: maybe Foxpro had some fancy reporting capabilities that made it more feasible but the only type of "book" I could imagine writing with such a tool is some sort of catalog. I.e. each product has a page (maybe with part number, pictures and price, description, ma…

Think of web content in a CMS. All the assets are in a database and they get spat out through a pipeline giving a formatted end result. I've never written a book in a DBMS(!) but it seems plausible.

I honestly doubt that "a DBMS" (especially from the Foxbase era) is really a good choice because formatting, even very basic markdown (titles, bold...) would require custom code or extensive postprocessing.
Post reply on HN