Live data from Hacker News

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

latimes.com

91–100 of 108 posts

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

#91
I still use Visual FoxPro almost daily for a number of things. It really does have charm in it's simplicity and some very robust out of the box support in it's GUI and DB engines.

One thing that maybe a more technical person can explain is how exactly FoxPro accesses it's (free) tables over a network share. Given that there's no central server component, I have the impression that the whole table is loaded over the wire when it's first opened.

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

#92

Earlier quoted context omitted.

Yes. Access is a fantastic database modeling and prototyping tool. It just doesn't pay, and there just isn't the tooling for moving Access databases to the web that you'd expect.

Agreed I always thort it wierd that M$ don't have a tool to webify Access and scale it on sqlserver with no dev effort. You could charge what you like for that: if the data got big, the company got big. Great for lock-in. I'm glad, but always surprised, they didn't do it. If they had, appifying Access data would have been an earner a few years later too IMHO. Too late now: cool kids are app natives.

As others are pointing out, they have such a thing now in Power Apps (including "appifying") and the extended Power family.

But it's also not like Microsoft stopped trying to build such tools, they've had many fits and starts as priorities shifted and fads arrived and then faded away.

InfoPath tried to be it for the XML world (and preferably the XML world hosted by SharePoint).

SharePoint itself has always dabbled in trying to be a company's low dev solution for a lot information management/database stuff. The low dev stuff some companies have done in SharePoint Lists, for example, is wild. (A lot of the reason developers fear/hate SharePoint is the exact same "things I've seen" feeling from Access, with the added fun of upgrade issues of any modern CMS like WordPress. For most of its life Access maintained a lot of compatibility between versions until it stopped and changed file formats three times in a couple versions.)

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

#93
post #79

Earlier quoted context omitted.

Yes. Access is a fantastic database modeling and prototyping tool. It just doesn't pay, and there just isn't the tooling for moving Access databases to the web that you'd expect.

Since 2010 you could deploy Access as a web app to Sharepoint. It probably still works. https://support.microsoft.com/en-us/office/build-and-publish... Also you can use Access as a frontend to any ODBC database such as Postgres.

Yeah, in theory. Really, it would be fantastic to be able to develop CRUD web apps as quickly as Access allows desktop CRUD development.

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

#94

Earlier quoted context omitted.

Agreed I always thort it wierd that M$ don't have a tool to webify Access and scale it on sqlserver with no dev effort. You could charge what you like for that: if the data got big, the company got big. Great for lock-in. I'm glad, but always surprised, they didn't do it. If they had, appifying Access data would have been an earner a few years later too IMHO. Too late now: cool kids are app natives.

As others are pointing out, they have such a thing now in Power Apps (including "appifying") and the extended Power family. But it's also not like Microsoft stopped trying to build such tools, they've had many fits and starts as priorities shifted and fads arrived and then faded away. InfoPath tried to be it for the XML world (and preferably the XML world hosted by SharePoint). SharePoint itself has always dabbled in…

I tried appifying my sharepoint lists and it really didn't give a better user experience than just running the sharepoint app on my phone.

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

#95
I used FoxPro 2.6 back in the day. We used to ship machines to our clients, preloaded with our FoxPro application.

As computers got faster, passing the 300MHz mark, our application suddenly started crashing on startup. Apparently FoxPro tries to figure out how fast it can perform certain operations at startup time, and there's a divide-by-zero error on higher-powered machines. The machines literally got too fast!

An old discussion thread: http://computer-programming-forum.com/2-vfp/e6d3528c90cc45d2...

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

#96
post #53

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…

Are these things really better than just opening a sqlite3 database with python?

Access is essentially a GUI on top of random database system (so long as you have ODBC driver or later ADO driver, it could use it).

You can build impressive applications with it, and frankly it took web-first development era to do anything to it.

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

#97
post #10

Knew a guy who published a technical book, bigger than a phone book, and he wrote it all in FoxPro and that was 2010.

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…

It does seem odd, and yet, engineers still think it's a fantastic idea. This may depend on whether you think of a file system and a table both as just a form of key/value store.

For a hyper-modern example, here's a current and popular Electron-based Markdown editor, "Inkdrop":

https://www.inkdrop.app

From the FAQ, keeping in mind this is a Markdown notes editor:

Q: Can I sync my data with DropBox, GoogleDrive, etc?

A: No. You can only sync your data with a server compatible with CouchDB. Read the documentation to learn how to set up your own sync server.

And then from the docs:

Inkdrop lets you store your notes in your own database compatible with CouchDB API instead of Inkdrop's own service. CouchDB is just another open-source NoSQL database so you can deploy it on your environment for free. See CouchDB's installation guide for more informations. Using DBaaS instead of operating database by yourself is good choice. For instance, Cloudant is one of fully-managed DBaaS providers.

Also:

You can back up all your data to your local filesystem and restore it at anytime. Inkdrop stores them as JSON files continuously while you use it. ... Since the backup data is in JSON format, it is not useful in some cases. You can export all note data in Markdown format from the application menu File -> Export -> All Notes...

To be clear, I think storing markdown notes in CouchDB is fundamentally missing the point.

But I still want WinFS ( https://en.wikipedia.org/wiki/WinFS ) and JAMStack is a thing.

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

#98

Software definitely lost something when we gained the ability to ship it as separate components over the internet. If you "just" configure components A, B, C, and D, you too can have the equivalent of what FoxPro had in 1993! It may not be The Unix Way(TM), but having an all-in-one solution is very appealing even today.

I really miss tools like FoxPro or MS Access where you could whip up some pretty powerful solutions quickly. Back then I knew several small to medium sized businesses where the owner over time had created pretty intricate systems they ran their businesses on. I bet they would have had to pay six or seven figure amounts of money if they had let "professionals" do this for them. I don't think there is anything comparab…

Check out Servoy. It is the closest thing that I have seen to FoxPro in terms of productivity and development ecosystem for web stuff.

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

#99
post #45
post #26

Earlier quoted context omitted.

C # creator Anders Hejlsberg made a statement a few years after the .net platform came into being, recognizing that data was very important and admitting that they were developing linq.

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

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

#100
post #45
post #26

Earlier quoted context omitted.

C # creator Anders Hejlsberg made a statement a few years after the .net platform came into being, recognizing that data was very important and admitting that they were developing linq.

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 interesting thing is that the following sentence is said years after it was decided to eliminate vfp.

"It's my hope that in five to 10 years, programming languages simply will have queries as a concept"

Post reply on HN