Artikkelen siterer Lasse Ruud i Win.hlp, som mener at det er blitt et problem å skille mellom 3. og 4. generasjons verktøy, og dette skaper forvirring. Han har rett på en måte, selv om jeg ville anlagt en noe annen vinkling. 3. generasjons verktøy omfatter de "tradisjonelle" programmeringsspråkene, Cobol, Fortran, Pascal og Basic for å nevne de viktigste.
Artikkelen "Trangt om plassen" i CW nr. 15 var interessant. Undertegnede har også tenkt på hvordan alle tilbydere av utviklingsverktøy skal få plass i markedet, ordnede styringsfaktor. å kode en del trisom eventuelt vil være kritiske suksessfaktorer.
Alle disse tilhører den karakterbaserte verden. Etter hvert fikk vi 4. generasjons mer automatiserte løsninger, særlig innen skjermprosessering og rapportgenerering, men også prosedyreorientert kode kunne skrives på høyere nivå. Vi fikk verktøy som ProIV, Admins, Unique, dBase,DataEase, FoxPro osv., bare for å nevne noen. Fremdeles er vi i en karakterbasert verden, og fremdeles er programmets logikk den overordnede styringsfaktor. Spranget fra 3. til 4. generasjon er m.a.o. ikke så stort, den største forskjellen ligger i reduksjon i en del triviell koding.
Da Windows 3.0 kom må det være lov å si at vi fikk et paradigmeskifte. Plutselig var brukeren kongen på haugen: Det var hans valg av objekt å klikke på som avgjorde hvilke prosedyrer som ble iverksatt, og grensesnittet var blitt grafisk basert. Vi kan trygt si at problemstillingen innen programutvikling ble snudd på hodet: Borte var den overordnede styringslogikken som stilte brukeren overfor predefinerte valg. Nå valgte brukeren, og programmet rettet seg etter det.
Brukerens valg ble i programmet definert som en "hendelse", og programmeringen ble "hendelsesorintert". Samtidig fikk vi "objektorienteringen" som tok sikte på å legge en formell struktur på det hele, og finne konsistente løsninger på gjenbruk av kode, klassifisering av- og hierarkier for objektene. Innen objektorienteringen fikk datastrøm og programkode sideordnet betydning, mot før da programkoden var overordnet datastrømmen. Jeg tror ikke det er fruktbart å føre generasjonstekningen fra den karakterbaserte verden inn i den grafiske og objekt/hendelsesorienterte. Vi har vært igjennom en logisk revolusjon, og begynner på generasjon 1 igjen.
Det blir sikkert flere enn en "vinner". Men noen vil sannsynligvis takke for seg. Selv tviler jeg på Foxpros potensiale. Foxpro har hatt sin tid i DOS-verdenen, og Microsofts motiv for oppkjøpet må ha vært Rushmore-teknologien, som nå er implementert i Access 2.0 database. Visual Basic i kombinasjon med Access' egen utviklingsdel vil utvilsomt ta hånd om brukergrensesnittet, så hvorfor Foxpro?
Jeg tror at viktige vinneregenskaper til et grafisk 1.generasjons verktøy vil være rask (produktiv) applikasjonsutvikling, brukervennlig grensesnitt, lett å supportere, samt fleksibilitet mht. database- løsning. Jeg tror m.a.o. på utviklingsverktøy som kan kjøre applikasjoner mot de mest utbredte databasene: Oracle, SQL-server, Informix, dBase, Access. Et slikt verktøy gjør en (rimelig) uavhengig av databaseløsning, selv om databaseleverandørene kanskje ikke er så begeistret for akkurat det.
En klar vinnerkandidat må således bli Visual Basic. Basic er verdens mest utbredte programmeringsspråk. Det alene gjør at modus operandi på prosedyreplan er kjent for svært mange. Jeg tror ikke at man med det første vil slippe å skrive prosedyrer. Derfor tror jeg det er viktig at prosedyrespråket har klart 3. generasjons slektskap, dvs. at man kan skrive tradisjonelle strukturerte programmuduler, basert på grunnstrukturene enkel sekvens, alternering og repetisjon.
Poenget er å konsentrere kodeutvikling om den del av problemstillingen som vanskelig lar seg håndtere av automatiserte, predifinerte prosedyrer i 4GL-pakning. En god del 4GL "automatikk" kommer etter min erfaring til kort når problemstillingen blir kompleks. Demonstrasjonene begrenser seg til ofte den enkle del av verden.
Visual Basic byr på en god balanse av høyt 3.generajonsnivå kombinert med visse muligheter til bitfikling om man tvinges til det, og med API-kallene kommer man under huden på Windows. De grafiske utviklingsfasilitetene er svært bra, selv om det selvsagt er en del ting man kunne ønske seg i tillegg.
VB 3.0 opererer med kildekode i vanlig tekstformat, og inviterer dermed til å generere objektdefinisjoner med egenskaper man selv har valgt som default, i stedet for å akseptere VB's egne. Dette dreier seg om skrifttyper,størrelser og fethet, bakgrunnsfarver, forgrunnsfarver osv. Alt dette krever ellers tastetrykk, og det antall tastetrykk man er nødt til å utføre for å komme i mål er en tidskritisk faktor. VB har et brukergrensesnitt som neppe lar noe tilbake å ønske i forhold til andre Windows-produkter. At VB er lett å supportere har jeg erfart en rekke ganger, så den biten er tatt hånd om.
Microsofts ODBC-løsning er en god start, men ikke den endelige løsning. ODBC er i høyden en 0. generasjons åpen dør mot eksterne databaser. Det finnes 3. parts drivere som er spesifikke for den enkelte database, men dersom Microsoft mener alvor bør de fase ut ODBC og heller selv lansere spesialdrivere mot hver database, slik at Visual Basic kan håndtere dem like enkelt og greit som den håndterer Aksess. Da får vi en virkelig vinner.
Hva så med kravet til objektorientering? Her er jeg sannsynligvis for hedning å regne. Objektorientering må ikke bli en slags religiøs bekjennelse man ha for å få lov til å være med i det gode selskap. Jeg kjenner bare et godt selskap, og det er den fornøyde bruker. De som lever av fornøyde brukere, lever ikke av fornøyde frelste for en bestemt softwareteknologi. Spørsmålet er: Virker det? Visual Basics svar er: Ja, det virker.
Det samme var IBMs force i deres glansdager. Det fantes hardwareløsninger på markdet som gjorde jobben mer "avansert" og "tekologisk lekkert" enn IBM med sitt DOS eller OS eller MVS med tilhørende JCL-sekvenser, noe som egentlig var elektroniske hullkort. Men IBM var synonymt med trygghet og kundestøtte fra A til Z. IBM virket, IBM var på plass der det virkelig talte å være på plass, nemlig hos kunden.