Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Anyone try using Grok AI to write FoxPro code? It actually works 1

Joe Crescenzi

Programmer
Mar 14, 2024
163
US
I've never been impressed by the hype over AI, and until recently every time I've tested AI by asking it to write code, I've never actually been given code that actually works.

I did two recent tests to see if Grok could write something that mirrors something simple, then something more complex. In both cases, I gave it explicit instructions about what I needed and within seconds, I got code that not only worked the first time, but it even gave me sample calls that I could use to test it.

Here's what I asked Grok to do a few minutes ago:
I need to build a foxpro function that can calculate depreciation for fixed assests up to a given date . I would like the function to accept parameters for the initial price (Price), Date of Purchase (PurchDate), Lifespan in years (Life), the effective date, and the method of calculation (CalcMethod). The calculation methods are either "SL" for StraightLine, "ACRS" for Accelerated Cost Recovery System, or "DDB" for Diminishing Balance Method.

To be honest, I thought that one would be too abstract to get an answer without it asking for more information, but a few seconds later, this is what it gave me:
Code:
FUNCTION CalcDepreciation
    PARAMETERS Price, PurchDate, Life, EffDate, CalcMethod
    
    * Validate parameters
    IF TYPE('Price') != 'N' OR TYPE('PurchDate') != 'D' OR ;
       TYPE('Life') != 'N' OR TYPE('EffDate') != 'D' OR ;
       TYPE('CalcMethod') != 'C'
        RETURN "Invalid parameter type"
    ENDIF
    
    IF Price < 0 OR Life <= 0
        RETURN "Invalid parameter value"
    ENDIF
    
    * Convert CalcMethod to uppercase for consistency
    CalcMethod = UPPER(CalcMethod)
    
    * Calculate total days between purchase and effective date
    LOCAL lnDays, lnYears, lnDepreciation
    lnDays = EffDate - PurchDate
    lnYears = lnDays / 365.25  && Accounting for leap years
    
    * If effective date is before purchase date, return 0
    IF lnDays < 0
        RETURN 0
    ENDIF
    
    * Calculate depreciation based on method
    DO CASE
        CASE CalcMethod = "SL"  && Straight Line
            * Annual depreciation = Price / Life
            * Total depreciation = Annual depreciation * years
            lnDepreciation = MIN(Price, (Price / Life) * lnYears)
            
        CASE CalcMethod = "ACRS"  && Accelerated Cost Recovery System
            * Simple ACRS implementation (using sample percentages)
            LOCAL lnRate
            DO CASE
                CASE Life <= 3
                    lnRate = 0.3333  && 3-year property
                CASE Life <= 5
                    lnRate = 0.20    && 5-year property
                CASE Life <= 10
                    lnRate = 0.10    && 10-year property
                OTHERWISE
                    lnRate = 0.05    && 15-year+ property
            ENDCASE
            lnDepreciation = MIN(Price, Price * lnRate * lnYears)
            
        CASE CalcMethod = "DDB"  && Double Declining Balance
            * Double declining rate = 2 / Life
            LOCAL lnRate, lnBookValue
            lnRate = 2 / Life
            lnBookValue = Price
            lnDepreciation = 0
            
            * Calculate for each year up to effective date
            FOR i = 1 TO FLOOR(lnYears)
                lnDepreciation = lnDepreciation + (lnBookValue * lnRate)
                lnBookValue = lnBookValue - (lnBookValue * lnRate)
            ENDFOR
            
            * Add partial year if needed
            IF lnYears > FLOOR(lnYears)
                lnDepreciation = lnDepreciation + ;
                    (lnBookValue * lnRate * (lnYears - FLOOR(lnYears)))
            ENDIF
            
            lnDepreciation = MIN(Price, lnDepreciation)
            
        OTHERWISE
            RETURN "Invalid calculation method"
    ENDCASE
    
    * Ensure depreciation doesn't exceed original price
    RETURN ROUND(lnDepreciation, 2)
ENDFUNC

As I said, it even gave me test code:
Code:
* Example usage:
? CalcDepreciation(10000, DATE(2023,1,1), 5, DATE(2025,3,11), "SL")
* Returns straight-line depreciation for $10,000 asset over 5 years

? CalcDepreciation(5000, DATE(2022,6,1), 3, DATE(2025,3,11), "ACRS")
* Returns ACRS depreciation for $5,000 asset over 3 years

? CalcDepreciation(20000, DATE(2024,1,1), 10, DATE(2025,3,11), "DDB")
* Returns double declining balance depreciation for $20,000 asset

I saved both parts to PRGs, then ran it and the numbers were accurate.

The second program was even more complex, and once again, it worked without any modifications.

All I can say is I'm no longer a doubter. AI can actually write code, provided you know how to properly request what you want, which makes me wonder if the programmers of the future will focus entirely on writing good specifications, rather than the code itself.

Just keep in mind that bad specifications and bad design will still yield bad results.

Anyone else try AI lately?
 
By the way, it also documented the specific features of the function.

Here's what it wrote:
Let's create a FoxPro function to calculate depreciation based on your requirements. Here's a function that handles the three depreciation methods you specified:
Key features of this function:
  1. Parameter Validation:
    • Checks for correct data types (numeric for Price and Life, date for dates, character for method)
    • Ensures Price and Life are positive
  2. Depreciation Methods:
    • Straight Line (SL): Divides cost evenly over life
    • ACRS: Uses simplified percentage rates based on asset life
    • Double Declining Balance (DDB): Applies double the straight-line rate to remaining book value
  3. Features:
    • Handles partial years using 365.25 days per year
    • Caps depreciation at original price
    • Returns 0 if effective date is before purchase date
    • Rounds result to 2 decimal places
  4. Notes:
    • ACRS implementation is simplified; real ACRS uses IRS tables
    • DDB doesn't switch to straight-line (some implementations do)
    • Salvage value is assumed to be 0
You can modify the ACRS rates or add more sophistication (like monthly calculations or salvage value) based on your specific needs. Would you like me to adjust any part of this or add additional features?
 
I've used it to create responsive HTML with CSS for a project I'm working on. It's been working well. I've had to modify the requests a few times, usually, to get them to work better. I can say "modify the last solution so that . . ." and it works quite well. I'm not sure it could write a full VFP application with all the features I have already built into my framework and I'm not sure it could design a good interface in VFP, but maybe I'm wrong. I don't need it to write VFP code, since I know how to do that. However, for things like this, where I'm no expert in depreciation of fixed assets, I could use it. I'd modify that code to better fit my style, but it'd take me 95% of the way there.
 
In this particular case, I already wrote code to do those 3 types of calculations back in 1990, except back then the function used the fields in an existing table rather than as parameters, so I decided to refactor it so it could be used in other places and with other potential tables and field names.

So, just for kicks I asked Grok and without giving it any idea what my old code looked like, it generated the same calculations. It even added comments and code to validate parameters. That's far better than expected.

This was Grok 3. Grok 2 and Microsoft CoPilot would generate laughably bad code.

It would mess up fundamentals like using // instead of && for inline comments, and declaring arrays the wrong way. I would say things like "By the way, in the future you should know that inline comments in FoxPro are &&, or that code can't work because this, that, and the other thing..." It would say "Sorry, you're right. I should've used this or that..." then it would generate code that looked better, but still couldn't possibly run. Ditto for C# code. Simply stated, I NEVER got a single AI generated function to work.

Then Grok 3 came out and I expected subtle improvements that still wouldn't work, but to my surprise, it's 2 for 2 in my tests. Both functions did exactly what I asked. Bothe were just tests, I already coded my own versions of those things years ago, but it was fun to see if it would actually generate something that works this time.

Perhaps next time I need to write something that's time consuming, I'll spec it out and see if I can let it do the grunt work.

What I REALLY hope to see in the future is a local AI that I can train with my past projects, so it can learn my systems and my programming style, so I could say something like "My customer wants a new tab on the Dispatch Manager page to track repairs and damages over time. Design a page that summarizes all the repairs by type and year... etc." Writing generic functions is one thing, but an AI can't do things like that without understanding the entire project and how the existing tables are being used.
 
I am impressed.

I told Grok to design a simple 2-box input screen without telling it what language to use.

It whipped up an HTML screen with Javascript and CSS and it worked.

Then I told it to recode the input screen using FoxPro 2.6 code.

It assumed for DOS and it whipped out another working screen.

Then told it to use Motorola 6502 for coding so it whipped up code for the Commodore 64 which looks good, but I am unable to test.

Next I told Grok to reform the 6502 code to work on an Apple II+ machine.

At that point Grok choked in an endless loop.

I see lots of potential there for grunt type work. I might even use it to help code FPM 2.6 functions that I can massage to my coding style.
 

Part and Inventory Search

Sponsor

Back
Top