AutoIT - Prognosen zur Weiterentwicklung

  • Salü miteinander

    Vor ca. 4 Jahren habe ich mich für eine Weile von der IT verabschiedet.

    Ich sehe, dass in der Zwischenzeit das Installations-Paket um 2018 zum letzten Mal upgedated wurde.

    Und ich frage mich: Ist AutoIT am sterben, resp. wird da nichts mehr weiter entwickelt?

    Denn ich möchte mich wieder einarbeiten ins AutoIT. Aber wenn das Teil eh stirbt, dann such ich was neues..

    (?)

  • Das Thema wird im engl. Forum immer wieder diskutiert.
    Die Gegenfrage lautet dann : Welche Funktionalität fehlt?

    Jon arbeitet gerade an einer neue Beta (Bugfixes, Maps ...)

    • Offizieller Beitrag

    Aber wenn das Teil eh stirbt, dann such ich was neues..

    Naja, nur weil eine Programmiersprache "nicht mehr weiterentwickelt wird" (was ja nicht ganz stimmt), stirbt sie ja nicht (im Sinne von Aussterben).

    AutoIt funktioniert einwandfrei, auch unter Windows10.

    Insofern muss man sagen: Wenn Dir AutoIt als Programmiersprache gefällt und Dir ausreicht, dann arbeite Dich wieder ein.

  • AutoIt funktioniert einwandfrei, auch unter Windows10.

    Die Gegenfrage lautet dann : Welche Funktionalität fehlt?

    WPF Elemente ansteuern und das in der STL von AutoIt, nicht als UDF nachgeliefert.

    AutoIt ist schon etwas in die Jahre gekommen, das ist nicht zu leugnen, insbesondere wird das Manpulieren von GUIs in Zukunft wesentlich schwieriger werden weil Win32-Controls einfach ausgetauscht werden.

    Wenn da nichts kommt, fällt ein wesentlicher Teil davon weg.

    Auch ist meiner Meinung nach der Trend dazu, alle möglichen Feature Requests zu erfüllen ein Schritt in die falsche Richtung.

    Jetzt mal ganz ehrlich. DllCallAddress um u.a. expliziten Assembly-Code zu callen? In einer Skriptsprache????

    AutoIt4, sollte es je dazu kommen, oder wir schlauen Füchse im deutschen Forum entwickeln es einfach selbst x), sollte wieder auf die Wurzeln zurückgehen, nämlich Abläufe zu automatisieren.

    Klar, man kann mit Au3 auch komplexere Programme schreiben, aber das ist ja nicht der Sinn davon oder? (Ja... hab ich auch schon öfters gemacht)

  • Klar, man kann mit Au3 auch komplexere Programme schreiben, aber das ist ja nicht der Sinn davon oder? (Ja... hab ich auch schon öfters gemacht)

    Warum sollte es keinen Sinn machen komplexe Programme in Autoit zu schreiben, wenn die Performance dafür ausreicht?

    Ich persönlich arbeite momentan viel mit Freebasic, aber dort sieht es ähnlich mit der Weiterentwicklung aus, es gibt primär einen Freiwilligen, der Entwicklung betreibt, also auch nicht besonders rosige Zukunft für FB.

    Ich persönlich mag die Basic Sprache, ist intuitiv und leicht zu erlernen. Mit C / C++ habe ich mich bis jetzt nicht richtig anfreunden können.

    Jon ist momentan der einzige Entwickler, ergo, falls er Lust hat die Sprache weiter zu entwickeln, dann geht's weiter, ansonsten Stillstand. Solange Autoit ordentlich funzt, ist dies nicht weiter tragisch.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    Einmal editiert, zuletzt von UEZ (2. Juli 2020 um 16:25)

  • Warum sollte es keinen Sinn machen komplexe Programme in Autoit zu schreiben, wenn die Performance dafür ausreicht?

    Die Frage nach der Performance von AutoIt stellt sich nicht. Moderne CPUs können AutoIt ausführen und sind schnell genug.

    Das Problem ist, dass AutoIt nicht dafür ausgelegt ist. Nur weil mein Drucker einen Mikrocontroller beinhaltet und ich darauf DOOM spielen könnte, heißt es nicht, dass ich das auch machen sollte.

    AutoIt hält an anderen Paradigmen und Konzepten fest, als dass es sich eignet komplexe Programme damit zu schreiben.

    Ich sage nicht, dass es nicht möglich sein, ich sage nur, dass es viel bessere Alternativen gibt die einen nicht mit den Problemen belästigen die AutoIt einem an den Kopf wirft.

    Typensicherheit, DLL-Export, Inline-Assembly, Objektorientiertheit, Multithreading / Multiprocessing, Vernünftiges IPC, Prototypenimport von DLL-Funktionen wie bei Hochsprachen statt alles separat wrappen zu müssen, ...

    Versuch mal in C++ eine GUI zu erzeugen die auf Klick von Buttons die Maus umherfährt oder in Fenstern herumklickt.

    Und jetzt versuch mal in AutoIt eine (gut ein wenig übertrieben) Krankenhausverwaltung zu programmieren.

    Jede Sprache hat ihre eigene Daseinsberechtigung. Natürlich kann man in AutoIt Programme schreiben, und das kann ich auch nur jedem empfehlen der mal die Füße ins kalte Wasser namens Programmieren stecken möchte,

    aber wenn du auch nur etwas modulares bzw. wartbares basteln möchtest, dann geht es halt nicht in AutoIt ohne dafür UDFs ranzuziehen um diese Funktionen bereitzustellen (die wiederum dein Skript ausbremsen obwohl andere Sprachen das schon von Haus aus haben).

    • Offizieller Beitrag

    Jede Sprache hat ihre eigene Daseinsberechtigung. Natürlich kann man in AutoIt Programme schreiben, und das kann ich auch nur jedem empfehlen der mal die Füße ins kalte Wasser namens Programmieren stecken möchte,

    AutoIt war (und ist) für mich immer eine BASIC-ähnliche Sprache. Also das, was ich früher in BASIC (zum Beispiel auf dem C64) geschrieben habe, schreibe ich heute in AutoIt.

    Ehrlich gesagt, habe ich AutoIt noch nie zur Automatisierung von Fremdprogrammen benutzt. Ich habe das immer gleich komplett mit AutoIt erledigt. Gerade weil AutoIt diese Möglichkeiten bietet.

    Ok, manches ist etwas zeitkritisch, aber dafür habe ich im Laufe der Jahre gelernt, wie man Assembler-Routinen mit AutoIt benutzten kann (an dieser Stelle ein dickes Dankeschön an Andy).

    Das Einzige, was mir in den letzten Jahren auf den Keks geht, sind die blöden AntiViren-Programme, die alle AutoIt-Programm fälschlicherweise als Virus ansehen und ungefragt löschen.

    Dafür kann AutoIt nichts, zugegeben, aber das führte dazu, dass ich mich in letzter Zeit viel mit "Nim" beschäftige.

  • Hi,

    in der aktuellen c´t lese ich gerade einen Artikel, der sich mit "Programmiersprachen" beschäftigt, auch wird die Anfängerfreundlichkeit nachgefragt.

    Auch online erhältlich https://www.heise.de/ct/artikel/Pro…er-4769771.html

    Ich habe mir, mit meiner mittlerweile fast 45-Jährigen Programmiererfahrung als NICHT-Programmierer, mal sämtliche vorgestellten Artikel zu den einzelnen Sprachen durchgelesen.

    Ganz zum Schluß lautete mein Fazit, ja, kann man alles haben, muß man aber nicht!

    Mit einigen dieser Sprachen hatte ich mehr oder weniger intensiven Kontakt, letztendlich komme ich zum ernüchtenden Ergebnis: WAS HABEN DIE ZEHNTAUSENDE ENTWICKLER BLOS IN DEN LETZTEN JAHRZEHNTEN VERPENNT?!

    KEINER, aber ohne Ausnahme KEINER dieser Sprachentwickler hat für andere Anwender außer sich selbst entwickelt!

    ALLE, aber ausnahmslos ALLE der TOP 20-Computersprachen hängen 10 bis 15 Jahre hinter der Hardwareentwicklung zurück!

    Also das, was ich früher in BASIC (zum Beispiel auf dem C64) geschrieben habe, schreibe ich heute in AutoIt.

    So ist es, BASIC war schon immer auf jeder Platform lauffähig und somit auch einfachst benutzbar. Wieso auch nicht?! Nur weil irgendwelche nerdigen Gehirnakrobaten sich für SPEZIALBEREICHE eine Computersprache ausgedacht haben und versuchten, diese dann mainstreamfähig auszubauen, wird das ALLGEMEINE Programmtechnische Problem damit nicht automatisch einfacher nutzbar!

    Was soll ich von einem "Programmierer" halten, der mir erzählt, dass er alle 2 Jahre eine "neue" Programmiersprache lernt, um immer auf dem aktuellen Stand zu sein? Will mir irgendjemand erzählen, dass diese Leute nach 10 Jahren Berufserfahrung 5 Computersprachen aus dem Effeff KÖNNEN? Belastbar in mehreren Projekten? Meine tägliche Erfahrung mit dieser Art Programmiereren und deren Programmen ist ernüchternd!

    Anwender/Benutzerfreundlichkeit?

    Versuch mal in C++ eine GUI zu erzeugen die auf Klick von Buttons die Maus umherfährt oder in Fenstern herumklickt.

    Yepp, das absolut erschreckende dabei ist, dass das ja machbar ist....indem man sich auf den Stand von vor 30 Jahren begibt und alles "zu Fuß" programmiert.

    Aktuell ist ja IoT ein Renner, die verwendeten Microcontroller sind ausnahmslos in (ANSI-) C zu programmieren. Ab und an auch mal C++ oder gar eine "Hochsprache". Wieso?! Weil C simpelst in Maschinensprache umzuwandeln und auch zu debuggen ist. "Standard" vor 30 Jahren! Aktuell wird BASIC auf den Controllern implementiert! Weil die Zielgruppe, nämlich kreative Köpfe, sich nicht mit "Nerdkram" auseinander setzen sollen, sondern mit einfachsten Mitteln ein kreatives Ergebnis produzieren!

    Ich persönlich arbeite momentan viel mit Freebasic,

    Ein simples Programm schreiben, compilieren, läuft. Problem gelöst!

    Mit C / C++ habe ich mich bis jetzt nicht richtig anfreunden können.

    Ich konnte mich mit keiner der OOP-Sprachen anfreunden. Weil meine "einfachen" computertechnischen Probleme (Ingenieurwesen) auch mit einer "einfachen" Sprache lösbar sind.

    Ich brauch keinen esoterischen Schnickschnack. Und schon garnicht brauch ich Code, den ich nach einigen Monaten selbst nicht mehr lesen bzw. debuggen kann....

    VBA treibt mich manchmal an den Rand der Verzweiflung, aber nur deswegen, weil die Entwicklung vor 20 Jahren stehengeblieben ist.

    Ansonsten allerfeinstes BASIC. Excel/Word und VBA, ein klasse Team! Hätte Jon statt sich mit AutoIt rumzuärgern, dessen Funktionalität und clevere Usability in VBA untergebracht, er wäre heute zigfacher Millionär!

    Wieso hat M$ das nicht mit seinen zehntausenden von Programmierern geschafft? DAS nehme ich denen echt übel! Ich weiß, dass die das KÖNNTEN!

    Btt:

    Aber wenn das Teil eh stirbt, dann such ich was neues..

    Ich sag´s mal krass: Du hast eh keine Ahnung vom Programmieren, und du hast auch kein relevantes Programmiertechnisches Problem!

    Für dich existiert eigendlich überhaupt kein Grund, sich mit einer Programmiersprache langfristig auseinanderzusetzen. Ob die jetzt AutoIt heißt, oder anders.

    Du solltest dir die Frage stellen, wie du in 5 Jahren, wenn du ab heute täglich mehrere Stunden lang programmieren MUSST, deine Programme erstellen willst!

    Und mit "wie" meine ich, soll dich deine Sprache mit ihrer Umgebung bei deiner Arbeit unterstützen und dir so viel wie möglich helfen, oder willst du, wie Millionen anderer "Programmierer" auch, in Foren rund um die Welt irgendwelche "Spezialisten" angraben, die dir dann den Arm aus der Sonne legen sollen?

    Ich meine das durchaus ernst.

    Ich benutze dienstlich AutoIt in einer uralten Version. Wenn AutoIt seit 9 Jahren nicht weiterentwickelt worden wäre, dann wäre mir das ziemlich egal, denn alle Programmiertechnischen Probleme (Programm/Maschinensteuerungen) konnte ich (bisher) lösen.

    AutoIt ist schon etwas in die Jahre gekommen, das ist nicht zu leugnen, insbesondere wird das Manpulieren von GUIs in Zukunft wesentlich schwieriger werden weil Win32-Controls einfach ausgetauscht werden.

    Wenn da nichts kommt, fällt ein wesentlicher Teil davon weg.

    Und das wäre dann das Ende für einen Teil meiner aktuelle Arbeit (mit AutoIt).....:Glaskugel:

    Aber VBA hängt ja immer noch an Excel dran, vielleicht spendieren die dann sogar mal "neue" Controls (die ehrlich gesagt aber auch garkeiner braucht ^^)

  • Ich programmiere (hauptsächlich) in AutoIt und C++ (aktuell, AutoIt für quick n dirty was ausprobieren, C++ für die Arbeit, oder wenn etwas "richtig" gemacht werden soll).

    Was mir in AutoIt fehlt sind eindeutig Objekte. Ja ich war früher ein OOP Gegner (weil ich OOP hauptsächlich von Java kannte, und mir jede scheiß Vorlesung Java quer in den Hals gestopft hat und ich damit einen richtig intensiven Hass gegen Java entwickelt habe). Es gibt aber auch andere Ansätze (Die sehr komfortabel sind), z.B Objekte auf das zu reduzieren was sie sind: Eine Struct mit angehängten Funktionen.

    Ich will in AutoIt die Möglichkeit eine Struct (oder Map) zu haben der ich ein paar Funktionen zuordnen kann (ja ich weiß, dass man einfach den Funktionspointer in die Map packen kann, und dann Aufrufe nach dem Prinzip ($Map.funktion)($Map, $a, $b, $c) hat (ohne die Klammer um $Map.funktion geht es aus unerfindlichen Gründen nicht). Der Folgepunkt ist sowieso hundertmal wichtiger.

    Ich will in AutoIt die Möglichkeit Operatoren für Structs (oder Maps) zu definieren. Wenn ich meine Vector2(float, float) Struct habe will ich z.B. $a += $b schreiben können.

    Das Ding hinter "Objekten" oder Operatoren ist nicht, dass ich unbedingt den Stil einer anderen Sprache haben will, sondern, dass der Komfort so gigantisch ist, dass ich mir ohne diese Möglichkeiten immer ein bisschen wie im Mittelalter vorkomme. Natürlich kann ich alles von Hand ausschreiben, für Operatoren Funktionen basteln AddRefVec2fValVec2f($a, $b) statt $a += $b, usw usw. Es ist aber so viel schöner, wenn man sich selbst Datentypen definieren kann und damit problemlos rechnen kann ohne 500 verschiedene (gnadenlos überladene) Funktionen auswendig wissen zu müssen.

    Als letzten Punkt gäbe es da natürlich noch das Überladen der Operatoren (und wenn man will von Funktionen). Aktuell kann man das indirekt schon machen (z.B. indem man eine Funktion mit 5 default parametern hat und intern je nach Datentyp der Eingabe unterscheidet welche "Version" der Funktion man ausführen will), aber unter der Voraussetzung, dass es Objekte/Map/Struct + Operatoren gibt sollte es möglich sein z.B. das "+" zu überladen, dass ich damit meine Vec2 + Vec2 oder auch Vec3 + Vec3 rechnen kann und zwar mit dem selben operator.

    Klingt jetzt doof, aber ich bin in C++ oft wesentlich schneller und wesentlich Fehlerärmer unterwegs, einfach aus dem Grund, weil es Operatoren gibt. Statt 3 Seiten voller Indexgekloppe (wenn man $vec2 = Array[2] mit [0]=x und [1] = y hat z.B.) gibt es eine Hand voll gemütlicher nachvollziehbarer wartbarer Zeilen.

    lg

    M

  • Hallo Leute, hallo Mars
    Freut mich, dass du oft schneller in C++ bist als in Autoit. Für die meisten realen Anwendungsfälle halte ich das für mich völlig unerreichbar. Allerdings habe ich auch nur mal eine Vorlesung C++ besucht und sonst nichts damit gemacht. Wer weiß, was ein echter Könner zaubern kann.

    Auch in AutoIt warst du wahrscheinlich vor zehn Jahren schon besser als ich. Daher ist das zwar ein Kommentar, der etwas Zweifel ausdücken soll, aber nicht sarkastisch gemeint ist.

    Für die allermeisten (auch guten Programmierer) wird eine Sprache wie AutoIt schnellere Lösungen bieten. Daher hat sie ganz sicher ihre Berechtigung.
    Deine Wünsche teile ich aber alle überhaupt nicht. Überladung von Funktionen, naja ok. Überladung von Operatoren? Das macht für mich irgendwie alles kaputt für das AutoIt steht.

    Ich folge völlig alpines. AutoIt sollte in erster Linie Probleme der Automatisierung vereinfachen.

    Genau am Kern-Feature verliert AutoIt gerade. Stattdessen werden Sachen gewünscht, die mit der einfachen Automatisierung gar nichts zu tun haben, sondern auf mittlere Sicht, das Niveau heben und es Einsteigern schwerer machen.

    Man hat doch eine ganze Fülle von Sprachen, die bieten was du möchtest. Aber ist es wirklich der richtige Weg für AutoIt? Denk mal an deinen Einstieg in die Programmiersprache zurück. Hätten diese Konzepte den krass einfachen Einstieg in die Programmierung geboten, gefördert oder behindert?
    In erster Linie war die Sprache gedacht, schneller umsetzbare Lösung im Automatisierungsbereich zu ermöglichen.
    Klar, kann man mit der Sprache noch viel mehr machen. Die Hilfe zeigt es. Viele hier haben das bewiesen - auch du.
    Aber der Kern der Sprache ist Automatisierung. Man kann sich nun dafür einsetzen, dass AutoIt Dinge kann, die in anderen Sprachen schon viel besser funktionieren oder man kümmert sich darum, dass die Stärken von AutoIt nicht verloren gehen.
    Ich halte letzteres für sinnvoller.
    Mars ich hoffe das kommt nicht als negativer Angriff rüber. Ich habe einfach einen ganz anderen Blick auf die Sprache und wollte den Unterschied hier deutlich machen.

    Grüße autoiter

    Einmal editiert, zuletzt von autoiter (6. Juli 2020 um 18:57)

  • Ich sehe das auch nicht als Angriff ;)

    Für nahezu alles was GUIs oder (fern) Steuerung von Programmen beinhaltet ist AutoIt nach wie vor die erste Wahl und egal wie schnell oder gut man in C++ ist, keine Chance da auch nur ansatzweise in vergleichbarer Zeit zu einem vergleichbaren Ergebnis zu kommen, selbst wenn man jede lib auswendig kennt (was utopisch ist, da es quasi unendlich viele gibt^^).

    Mein Problem ist, dass ich AutoIt hinterherweine, weil das die erste (und einzige) Sprache ist die ich wirklich verinnerlicht habe (egal wie man es dreht, ich kann einige Sprachen, aber bei keiner kenne ich gefühlte 99% aller Funktionalität), aber jedes Mal wenn mir ein lustiges Feature unterkommt frage ich mich: Das ist doch ansich echt cool und macht vieles einfacher. Das will ich in meiner Lieblingssprache auch.

    Ich will ja nicht, dass die Sprache ihren Kern verliert. Ich will nur irgendwie "das beste aus beiden Welten". Die Einfachheit und Fehlertoleranz, mit der man extrem schnell zu guten Ergebnissen kommt kombiniert mit der Möglichkeit auch kompliziertere Sachen leserlich(er) zu gestalten.

    Es ist auch nicht schlimm wenn man das anders sieht, dafür sind wir doch alle individuelle Menschen die ihren eigenen Kopf mit eigenen Vorlieben haben :S