Mit einer von mir bisher wenig gebrauchten PS. Ocaml aka F#. Warum? Nun ich würde gerne Smalltalk benutzen, aber ich möchte auch so viel wie möglich Compilerunterstützung gegen Typos und andere Fehler nutzen. Ich denke mir, was der Computer testen kann, soll er auch testen. Ich mag es weiterhin nicht, mich zu wiederholen, als wäre ich eine gesprungene Schallplatte:

LongPathToSomeJavaClass<withTemplate1, withTemplate2> = myClass = new LongPathToSomeJavaClass<withTemplate1, withTemplate2>()

Ja, ich weiß, man braucht es nach dem New nicht mehr so zu schreiben. Was mir auch nicht so gefällt, wenn ich die Methoden in OO-Weise aufliste MyList.map(some function).filter(someCondition) …

Und ja, seiteneffektfreie Funktionen sind auch schön zu haben. IM Vergleich sieht
F# so aus:

let mutable i = 1
in
    let rec loop() =
        printf "i= %d >" i 
        let input = Console.ReadLine()
        if input = "exit" then 
            exit(0)
        else 
            printfn "You typed: %s" input
            i <- i + 1
            loop()


loop()

Es ist typsicher, ohne dass man es deklarieren muß. Man kann aber:
Also kann ich auch schreiben let mutable i:int = 1. Auf der anderen Seite ist e s nicht so jerkish wie Haskell: http://learnyouahaskell.com/input-and-output.

Ich finde, man kann es ziemlich „locker runter lesen – und verstehen. Mir gefällt vor allem auch ein Schlüsselwort wie ‚mutable‘, damit teilt man F# mit, hey ich werde das ändern und man macht es dann einfach (i <- i+1)

Und vor allem mag ich es, wenn man Daten auch in Objekte packen kann, mit Polymorphismus (die Haskellianer verstehen etwas anderes als der Rest der Welt darunter) . Ich sehe hier wirklich eine Obermenge von Programmerweisen.

1. Simpel und „dumm“ prozedural let a … let b let c
2. funktional (keine Seiteneffekte, keine Überraschungen bei Aufruf von Funktionen
3. objektorientiert (da kenne ich mich nun mal am besten aus und mir kommt es in meinem Programm am weitesten entgegen.
   

Ich schrieb ja oben von Smalltalk, ich kann viel von OCaml auch in Smalltalk bekommen (schließlich sind Blöcke nicht anderes als Funktionen. Aber nichts warnt mich während der Entwicklung ,wenn so was passiert (pseudo code)

aHouse := aCrodocile
.
.
.
aHouse openDoor. 

Ja, die IDES werden einen vielleicht warnen, aber im Endeffekt, wird uns zur Laufzeit mitgeteilt, da liegst’e mit dem Typ aber daneben. Das kann einem in Ocaml, F# und Haskell nicht passieren. Weithin passt F# komplett in die .NET Welt. Mir wäre kein Smalltalk bekannt, für das das gilt, ja es gab mal ich glaube IronSmalltalk oder so, aber AFAIK gibt es derzeit keine Unterstütztes auf Windows. Ich glaube eine Kombination in einer Sprache, die einen nicht bevormundet ist eine der besten Lösungen. Ich werde mal sehen, wohin mich dieser Trip führt, vielleicht liege ich falsch.

Es wäre nicht das erste Mal und nicht das letzte Mal. Ich werde mal sehen wie’s läuft und ich denke, man kann in diesem Blog auch nachlesen, wenn ich meine Meinung zu etwas geändert habe. Vielleicht passiert es wieder mit F#, vielleicht auch nicht …

Für mich als Einzelprogrammierer gibt es ein paar Wege. Ich kann wie Millionen von andere auf die großen Spieler setzen, ich kann etwas nehmen, was für meinen Bereich am besten zu gebrauchen ist und ich kann nehmen, was mir eher gefällt und auch wenn ich es von Eiffel anders kenne, sehe ich durchaus einen Punkt in dem Sprichwort: „In der Kürze liegt die Würze“

Man kann den Code ja mal in Java, C# oder C++ programmieren und schauen, wie es dann aussieht …

wie schnell ich eine Seite nicht mehr mag:
https://www.axon.dev/about-us

Meine Güte, muß das so sein. Ja, man sieht, sie lieben JavaScript. Aber viel hilft nicht immer viel …

Speziell, wie wahnsinnig und menschenverachtend die inzwischen geworden ist.

Es ist aber nicht mein einziges Steckenpferd ;-). Es klang sicher schon gelegentlich an, daß ich Programmierer bin. Ich pflege seit mehr als 10 Jahren eine Branchenlösung für Abfallbetriebe, Containerdienste. Das Ganze ist für kleine Betriebe mit weniger als sagen wir mal 5 AP für die EDV. Das sind nach meinem Wissen so ca maximal so um die 50 Leute die mit der Software bedient werden. Die meisten Dateneinträge dürften Wiegungen sein. Für jede komplette Wiegung braucht es, so gut wie immer zwei Wiegungen. Ich denke, die Software wurde schon zu DOS Zeiten entwickelt, vielleicht liege ich damit aber auch schief. Wie auch immer, die Programmiere haben m.E. a) relativ typisch in MS Access programmiert und b) wenig über die Menge an Code nachgedacht. Im Zweifel lief es wohl so. Da läuft was, wir kopieren es und passen es halt an. So gibt es Redundanzen noch und nöcher, aber natürlich nicht komplett, das wäre ja zu einfach. Wo man die Redundanzen sehr gut sehen kann, ist an folgendem Code:

Private Sub DruckAngeboSum_Click()
On Error GoTo Err_DruckAngeboSum_Click

Dim objOut As CMediaOutput
    
    Set objOut = generateMediaOutputObjects(ActiveControl.Name)
    objOut.doOutput

'Dim intAntwort As Integer
'Dim strNeueZeile As String
'strNeueZeile = Chr$(10) & Chr$(13)
'
'Dim intSchleife As Integer
'Dim lngNr As Long
'Dim lngDrucker As Long, strBericht As String
'
'Dim WSP1 As Workspace, DB1 As Database, Tabelle1 As Recordset
'Set WSP1 = DBEngine.Workspaces(0)
'Set DB1 = WSP1.OpenDatabase(strDatenbankGlo)
'
'Set Tabelle1 = DB1.OpenRecordset("HT_Nummernkreise", DB_OPEN_TABLE)     ' Tabelle öffnen.
'
'If Forms!HF_AuftrAnkErz!AngebotKz = True Then
'    ' Rückfrage mit Speicherung der Antwort
'    intAntwort = MsgBox("Für diesen Auftrag wurde bereits ein Angebot gedruckt!" & strNeueZeile & "Wollen Sie diesen Ausdruck wiederholen?", 33, "Angebot drucken?")
'    If intAntwort = 2 Then
'        GoTo Exit_DruckAngeboSum_Click
'    End If
'End If
'
'' Firma Beller
'If strKundeNr = "143" Then
'    strBericht = "BR_DruckAngebotAnkErzoSum_Bel"
'Else
'    strBericht = "BR_DruckAngebotAnkErzoSum"
'End If
'
'ordneDruckerZu "Angebot", strBericht, HAUPT_DRUCKER
'
'' Prüfen ob Kontrollkästchen für Seitenansicht aktiviert
'' wenn aktiviert dann Seitenansicht, ansonsten Ausdruck auf Drucker
'If Me!Seitenansicht = True Then
'    If strKundeNr = "143" Then
'        strBericht = "BR_DruckLiefschAuftrAnkErzNot_Bel"
'    Else
'        strBericht = "BR_DruckLiefschAuftrAnkErzNot"
'    End If
'    DoCmd.OpenReport strBericht, acViewPreview
'Else
'    Tabelle1.MoveLast ' Letzten Datensatz suchen.
'    setzeFelder Forms!HF_AuftrAnkErz, Tabelle1, DRUCK_BEREICH_ANGEBOT
'    erhoeheNummer Tabelle1, "AngebotNr"
'
'
'    druckeBericht "Angebot", strBericht, Me!AnzahlDrucke
'
'
'    Forms!HF_AuftrAnkErz!AngebotKz = True   ' Setzen der Druckkennziffer
'    Forms!HF_AuftrAnkErz.Refresh
'
'    ' Logbucheintrag
'    If DLookup("[Benutzerverwaltung]", "HT_SysParameter") = True Then
'        Call SetzeBenutzerLog("Drucke Angebot o. Summen Ankauf Erz.-Preis! Auftrag Nr: " & CStr(Forms!HF_AuftrAnkErz!AuftragNr) & ", Angebot Nr: " & CStr(Forms!HF_AuftrAnkErz!AngebotNr))
'    End If
'End If
  
Exit_DruckAngeboSum_Click:
    On Error Resume Next
'    Tabelle1.Close
'    DB1.Close
    Exit Sub

Err_DruckAngeboSum_Click:
    If err = 2501 Then
        Me!Schließen.SetFocus
    Else
        MsgBox Error$
    End If
    Resume Exit_DruckAngeboSum_Click

End Sub

Die drei Zeilen Code oder so sind das was nach dem Überarbeiten bleibt.
Ein paar Dinge dürften Programmierer in neueren Sprachen durchaus verunsichern, das sind die Label zu denen man springt. Ja, das kann man inzwischen anders lösen und nein, es ist recht typisch für VBA. Man sieht, nur für die Fehlerbehandlung kommen „locker“ 5- 10 Zeilen Code zu jeder Funktion. Insgesamt sind es über 500 000 Zeilen an Code und viele Methoden gehen über mehrere Seiten.

Wie man sehen kann, gibt es keine Trennung der Bereiche. In einer Methode/Funktion gibt es Zugriffe auf die Datenbank, Manipulation der UI und Interaktion mit dem Benutzer. Ich befürchte, daß ist immer noch Stand der Dinge bei sehr vielen Access Programmen. Als wirklich ernsthaftes Problem sehe ich das Fehlen von brauchbaren Testmöglichkeiten an. AFAIK gibt es AccUnit zum Testen, das bekomme ich hier nicht installiert und ich bin derzeit immer noch zu faul um mich dahinterzuklemmen.

Die Klasse, in der ich es auslagerte, sieht der Code nun so aus:

Public Sub doOutput()
    Dim bAdjustNumber As Boolean
    Dim objControl As CControlNummernKreise
    
    

On Error GoTo HandleError
    Dim iAuswahl As Integer
    If outputMedia = outMediumPreview Then
        outputPreview
        GoTo HandleExit
    End If
    
    
    bAdjustNumber = True
    If NZ(actForm(textFieldNumberName), "") <> "" Then
        iAuswahl = askToReprintIfPrintedBefore()
        If iAuswahl = vbNo Then
            GoTo HandleExit
        Else
            bAdjustNumber = False
        End If
    End If
   
    Set objControl = actualizeFormDataBeforePrint()
         actualizeNumberCircle objControl, bAdjustNumber
         Set objControl = Nothing
        
         actionBeforePrint
             If outputMedia = outMediumPrinter Then
                 outputPrinter
             Else
                 outputEmail
             End If
         actionAfterPrint
    actualizeFormDataAfterPrint
    writeLog

    
    
HandleExit:
    On Error Resume Next
    Exit Sub


HandleError:
    If err.Number <> 0 Then
       MsgBox "Error " & err.Number & " (" & err.Description & ") in procedure doOutput."
    End If
    GoTo HandleExit


End Sub

Sicher noch reichlich zu kritisieren, aber ich denke, eine Verbesserung ist zu erkennen.
Der Witz an dieser einen Methode ist: Die kann ich so an ungefähr 8 Stellen so benutzen und muß da nichts mehr anfassen. Ich muß die Daten entsprechend vorbelegen

Case FRM_AUFTRAG_ANKAUF_ERZ
If sKundeNr = "143" Then
objResult.reportName = "BR_DruckAngebotAnkErz_Bel"
Else
objResult.reportName = "BR_DruckAngebotAnkErz"
End If            
objResult.logEntry = "Druck Angebot Ankauf Erz. m. Summen Auftrag Nr: " & NZ(objResult.orderNo, 0) & _
                                 ", Angebot Nr: " & NZ(objResult.actForm(objResult.textFieldNumberName), "")

            objResult.lblFuerKLNr = "Lieferant Nr:"

            Set objParameterAngebot = parDruckAngebot_WH()
            objParameterAngebot.mainTableName = "HT_AuftragAnkaufErz"
            objParameterAngebot.subTableName = "UT_AuftragAnkaufErz_Positionen"
            objParameterAngebot.fieldNameKLNo = "LieferantNr"

gen, aber die Logik dieses Teils geht nicht verloren. Ich denke, daß ist einer meiner Lieblingstechniken, einen Algorithmus austüfteln und dann möglichst nicht mehr anfassen zu müssen. Sollte was schiefgehen, dann habe ich hier eine zentrale Anlaufstelle, um es zu korrigieren und muß nicht die Korrektur 8 mal wiederholen.
Leider macht es einem VBA unglaublich schwer Code wiederzuverwenden, denn obwohl das hier eine Klasse ist, kann ich nicht einfach davon ableiten und nur die Sachen umschreiben, die ich brauche. Ja, es gibt Interfaces, aber die muß man dann von a-z in allen Klassen implementieren, das ist einfach schlecht und dürfte Leuten, die mit Java, Python, Ruby oder so gut wie jeder anderen OO-Sprache programmieren, die Tränen in die Augen treiben. Die Dinge sind aber nun mal, wie sie sind. Modularer bekäme man es nur hin, wenn man jede Methode in ein eigenes Interface auslagerte und dann die Interfaces implementierte, die einzige zugängliche Methode wäre dann z.B. für

 If outputMedia = outMediumPreview Then
        outputPreview
        GoTo HandleExit
    End If

outputTo aber man müsste halt all notwendigen Daten in diesem Interface hinterlegen und bräuchte zumindest ein paar Parameter oder ein Parameter Objekt.

Dann könnte man ein Interface haben für eine Klasse mit dem Namen OutputPreview
und den Wert so setzen

objIf as OutputInterface
if Test_If_Angebot then
  set objIf = new OutputInterfaceAngebot 
...
:..

und riefe es so auf
objIf.outputTo

Es geht leider nicht anders und dann bekommt man eben auch so etwas:

Case FRM_AUFTRAG_ANKAUF_ERZ
            If sKundeNr = "143" Then
                    objResult.reportName = "BR_DruckAngebotAnkErz_Bel"
                Else
                    objResult.reportName = "BR_DruckAngebotAnkErz"
                End If
               
                objResult.logEntry = "Druck Angebot Ankauf Erz. m. Summen Auftrag Nr: " & NZ(objResult.orderNo, 0) & _
                                     ", Angebot Nr: " & NZ(objResult.actForm(objResult.textFieldNumberName), "")
                                     
                objResult.lblFuerKLNr = "Lieferant Nr:"
            
                Set objParameterAngebot = parDruckAngebot_WH()
                objParameterAngebot.mainTableName = "HT_AuftragAnkaufErz"
                objParameterAngebot.subTableName = "UT_AuftragAnkaufErz_Positionen"
                objParameterAngebot.fieldNameKLNo = "LieferantNr"

Hier muß ich einfach festhalten MS hat sich einiges bei VBA gedacht aber a) nicht zu Ende und b) mangelhaft an bestimmten Stellen.

Es gibt durchaus eine Menge Fans von Access. Vom Standpunkt von guter OO-Programmierung ist VBA ein Sanierungsfall. Dabei könnte es so einfach sein. VBA als Mitglied der .NET Sprachfamilie und gut wär’s. Ich verstehe nicht, warum es MS nicht macht. Die Unterstützung durch Werkzeuge ist so in den 80 er Jahren des letzten Jahrtausends hängen geblieben. Ja, man kann in VBA auch riesige Programme schreiben, es tut aber weh ….

Wo MS-Access (mit VBA) vollkommen mangelhaft ist
1) Keine integrierten Tests
2) An Objekten orientiert, aber nicht OO-mässig zu programmieren
3) Grauenhafte Benutzung in einem RCS (hier benutze ich TortoiseGit) , Problem: Groß/Kleinschreibung geht munter durcheinander, es gibt IDS, die sich einfach ändern
4) Keine Unterstützung für die Trennung von UI, Daten und dem Programm. Wie geschrieben, der Code ist heute noch typisch für Ms Access. Man bekommt halt schnell was zusammen …
5) der SQL Editor ist eine Zumutung!

Wo es glänzt
1) mal eben was zusammenstoppeln ist schnell erledigt
2) der Direktbereich, man kann während der Laufzeit anhalten und sich alles anschauen, kein rekompilieren nötig
3) preisgünstig

Es ist klar MS will, daß wir MS-SQL mit C# benutzen, es ist nicht überzeugend, daß dies für kleine Betriebe eine bessere Lösung als eine MS-Access basierte wäre.