3 ms·

For long time, I have no idea that SQL & OO are not friends. I work in a language where such problems don't exist. And it have nice ways to move data between ta

by mamcx 12y ago

For long time, I have no idea that SQL & OO are not friends. I work in a language where such problems don't exist. And it have nice ways to move data between tables and data structures and objects (For example: SELECT..INTO Array NAME). Is FoxPro. Even the stored procedures were foxpro, all along the stack, from UI to inner DB actions. Is a shame that this kind of programming is "lost" today. This is kinda like work with the postgresql main language everywhere, but the language is not half-powerfull. You don't need a "database" language and a "application" language. In fact, the whole experience was very good, and even let some people to do his own apps (kinda like Acces) because the approach was not intimidating, like VB, C or Python is (ie: Torwards do database apps). So in short: Back them we don't use a ORM, we don't need it, we still have nice syntax and helpers. I still try to backport some of this to my own code, but the SQL is SOOOO restrictive that the effort stop fast.

makmanalp 12y ago
You know, I remember visual foxpro coming with microsoft visual studio 6.0, and not really understanding much about it. Care to expand upon what made it awesome? I found some stuff here but it doesn't really explain it well: http://www.foxprohistory.org/articles_4.htm http://www.foxprohistory.org/articles_4.htm
- th5 12y ago
  ah yes. foxpro! this is the first web language i ever learned. it was awesome because the db and application language live in the same space. You could run SQL directly inside the language... When i learned the "best practices" of the time (1996 ish)... i thought it was extremely inefficient to have to "formulate a sql statement", then call it then retreive the result...
- mamcx 12y ago
  It shine for business apps (aka: the most common of it). Is more "batteries included" than python. You can do a full app with just Fox, because it include reporting, database, database designer, form builder, menu builder, OO, procedural, SQL, a really good grid. Seriously, I have only know of 2 great grid controls: The VFP one and the DevExpress for Delphi one. Have a truly good grid was something damm useful. Manipulate data was easy, you could make a app only around the grid! But all of this included. And this could be made to work for the end user. So, your reports could be designed by a end-user. Or build forms. Or menus. Similar to lisp where everything are the "()" in fox everything was a table. A form? a table. A report? a table. A class? a table (if designed visually. You can make everything in text like a regular program too). You can make dynamic the whole app if the developer learn to use the language fully. Was also relatively easy to grasp. A power user could work on fox with a dozen of commands (and remember: The grid, like a excel spreadsheet, was enough for a lot of task), but in contrast with acces, you can "upgrade" the mess to be more professional. Is simple for a programmer, too. My first programming class was with foxpro, and at the end of it we have made a FULL app with menus, forms, tables, reports and mini programs. The closet thing today? Perhaps the django admin, but it is far less powerful and constrained. The weak of fox was that MS prefer to push Acces (and both fight for the same kind of user), it neglect the DB engine pushing for sql server and, well, neglect the language.
steverb 12y ago
Dear Lord in heaven, no. Yes, the data language and the application language were all the same language, which led to some awful spaghetti code where data access was strewn all over the place. Then you also get to deal with scaling issues because your db and application logic all run on the same box. But hey, you can still download and run Visual FoxPro from MSDN if want, Source: My team is in the process of slowly strangling a FoxPro application whose only system spec is "what it does".
- mamcx 12y ago
  That is the description of almost all apps out there. Only with the popularization of MVC is started to be cool to decouple things. I see the same behavior in several codebases and languages (I do mainly business apps and code cleanup). But then, in the case of VFP, you still have a single kind of mess to clean, and a language/API small enough to fit in the head. Now, we are talking for several kind of languages, APIs and paradigms intermixed all around a project (like for example, mix a ORM, Sql, OO, not only python+js+html+css)

by mamcx 12y ago

makmanalp 12y ago

You know, I remember visual foxpro coming with microsoft visual studio 6.0, and not really understanding much about it. Care to expand upon what made it awesome? I found some stuff here but it doesn't really explain it well: http://www.foxprohistory.org/articles_4.htm http://www.foxprohistory.org/articles_4.htm

th5 12y ago
ah yes. foxpro! this is the first web language i ever learned. it was awesome because the db and application language live in the same space. You could run SQL directly inside the language... When i learned the "best practices" of the time (1996 ish)... i thought it was extremely inefficient to have to "formulate a sql statement", then call it then retreive the result...
mamcx 12y ago
It shine for business apps (aka: the most common of it). Is more "batteries included" than python. You can do a full app with just Fox, because it include reporting, database, database designer, form builder, menu builder, OO, procedural, SQL, a really good grid. Seriously, I have only know of 2 great grid controls: The VFP one and the DevExpress for Delphi one. Have a truly good grid was something damm useful. Manipulate data was easy, you could make a app only around the grid! But all of this included. And this could be made to work for the end user. So, your reports could be designed by a end-user. Or build forms. Or menus. Similar to lisp where everything are the "()" in fox everything was a table. A form? a table. A report? a table. A class? a table (if designed visually. You can make everything in text like a regular program too). You can make dynamic the whole app if the developer learn to use the language fully. Was also relatively easy to grasp. A power user could work on fox with a dozen of commands (and remember: The grid, like a excel spreadsheet, was enough for a lot of task), but in contrast with acces, you can "upgrade" the mess to be more professional. Is simple for a programmer, too. My first programming class was with foxpro, and at the end of it we have made a FULL app with menus, forms, tables, reports and mini programs. The closet thing today? Perhaps the django admin, but it is far less powerful and constrained. The weak of fox was that MS prefer to push Acces (and both fight for the same kind of user), it neglect the DB engine pushing for sql server and, well, neglect the language.

steverb 12y ago

Dear Lord in heaven, no. Yes, the data language and the application language were all the same language, which led to some awful spaghetti code where data access was strewn all over the place. Then you also get to deal with scaling issues because your db and application logic all run on the same box. But hey, you can still download and run Visual FoxPro from MSDN if want, Source: My team is in the process of slowly strangling a FoxPro application whose only system spec is "what it does".

mamcx 12y ago
That is the description of almost all apps out there. Only with the popularization of MVC is started to be cool to decouple things. I see the same behavior in several codebases and languages (I do mainly business apps and code cleanup). But then, in the case of VFP, you still have a single kind of mess to clean, and a language/API small enough to fit in the head. Now, we are talking for several kind of languages, APIs and paradigms intermixed all around a project (like for example, mix a ORM, Sql, OO, not only python+js+html+css)