Autor Thema: Lotus Script Stirbt ?!?  (Gelesen 1733 mal)

TomLudwig

  • Gast
Lotus Script Stirbt ?!?
« am: 22.10.03 - 13:05:29 »
Hi zusammen,
ist es wahr, dass Lotus Script in nächster Zeit ausstirbt?
Mit was dann Programmieren?
Kann mich jemand aufklären?
Thx

Offline Axel

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.658
  • Geschlecht: Männlich
  • It's not a bug, it's Notes
Re:Lotus Script Stirbt ?!?
« Antwort #1 am: 22.10.03 - 13:24:26 »
Hi,

kann ich mir nicht so recht vorstellen. Sicher ist allerdings, dass Java und JavaScript eine immer größere Rolle spielen wird.

Wenn man sich die Version 6 anschaut, da wurde an der Formelsprache (ich sage nur Schleifen) und an Script kräftig weiterentwickelt.

Schon aus Kompatibilitätsgründen muss Script bleiben.


Axel
Ohne Computer wären wir noch lange nicht hinterm Mond!

Axel Janssen temp

  • Gast
Re:Lotus Script Stirbt ?!?
« Antwort #2 am: 22.10.03 - 14:16:40 »
Es gibt eine relativ große Tendenz hin zu "managed environments", die besser erweiterbar, strukturierter und eben objektorientiert (oder bald oder jetzt auch aspekt-orientiert) sind.
Gilt für MS.Net, Java/j2EE und zu einem gewissen Grade auch für PHP5.
VB.Net hat eben nur noch relativ wenig mit VB6 zu tun.

Inwieweit diese Tendenzen aber überall (Mittelstand, etc.) ankommen, kann angezweifelt werden. Der Übergang zu OO ist nach meiner Erfahrung mit viel Arbeit, Irtümern, fehlgeschlagenen Versuchen, völliger Verwirrung, eingebildeter Klarheit, etc. verbunden. Ich persönlich finde es spannend.  

Das Problem, das mit nicht-so-gut-Objekt-Orientierung-unterstütztenden Skriptsprachen wie LotusScript ist, dass
a) Projekte ab einer gewissen Größe unmaintainable werden (100% meine Erfahrung).

b) man oft den selben low level code immer wieder neu schreibt, weil das mit den Auslagern in Funktionen eben nicht so gut funktioniert.

c) Da LotusScript relativ einfach ist, simplifizieren viele Leute noch mehr. Erwachsene Leute gehen dazu über die Dinge der Sprache, die das durchschnittliches Abstraktionsvermögen eines 7 jährigen belasten, als zu komplex zu deklarieren und nicht zu nutzen (Beispiele: ErrorHandling in LotusScript, divide-and-conquer (Aufteilung des codes in Funktionen), etc.). Diese  in der Lotus-Welt leider sehr weit verbreitete Praxis der 3 Akkorde Programmierung führt zu völlig unlesbaren code.
   
d) Das Wissen über die Nutzung von Objekt Orientierung ist in den letzten 10 Jahren dramatisch angestiegen (Design Pattern).

e) Neue "Werkzeuge" und Methoden des Projektmanagements (UML, RUP, xTreme Programming) sind auf OO-Sprachen ausgelegt.

f) Die neueren Programmiersprachen haben bessere Entwicklungswerkzeuge. Liegt zum Teil an Investitionen von MS, IBM, Borland, etc., zum teil aber auch daran, dass in den Sprachen selbst Dinge implementiert sind, die den Bau von Entwicklungstools vereinfachen.  


Gruß Axel

Glombi

  • Gast
Re:Lotus Script Stirbt ?!?
« Antwort #3 am: 22.10.03 - 15:00:05 »
Also,
weder die Formelsprache noch LotusScript wird - solange es Lotus Notes (in Zukunft heisst das dann Lotus Wokplace) gibt - von IBM (sprich Iris in diesem Fall) abgeschafft.
Diese Frage wird seit mind. 5 Jahren gestellt.
IBM hat bspw. für R6 die gesamte @Formel-Engine neu programmiert. Es gibt wahrscheinlich Zigmillionen LotusScript-Zeilen. Wie sollte IBM dem Kunden verkaufen, dass das irgendwann alles für die Mülltonne ist?
Also, ich sehe das gelassen.

Andreas
« Letzte Änderung: 22.10.03 - 15:00:38 von Glombi »

Offline Axel_Janssen

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 769
Re:Lotus Script Stirbt ?!?
« Antwort #4 am: 24.10.03 - 23:54:05 »
noch mal in aller Deutlichkeit:
LotusScript stirbt ist totaler Quatsch.

... und ich schreibe seit ca. 2.5 Jahren deutlich und zunehmend mehr Zeilen Java-code als Lotus-Script code und das hat inzwischen sogar fakturierbare Gründe.

... wenn aber z.B. ein Teil des Projekts Lotus Domino ist und ich so einen Workflow schreibe, stelle ich aus Reflex den zu schreibenden Agenten auf Java, tippe 3 Zeilen und sage dann: "Bist du eigentlich bescheuert" und mach das dann in LotusScript im Halbschlaf.

Es ist nur eben so, dass es oft für Interesse_am_Beruf, Job_Aussichten, etc. eine gute Idee ist, sich mit wirklich wichtigen neuen Entwicklungen wie z.B. Java oder C# zu beschäftigen. Nur Mißtrauen gegenüber HajoPeis, die irgendwas von Revolution verkünden, ist immer angebracht. Das lernt man übrigens dann am besten, wenn man sich tatsächlich mit den neuen Dingen beschäftigt.
Revolutionen gibts nämlich gar nicht. Es gibt nur einen Haufen Reformen und das ist ein mühsamer Prozeß. Zum Glück haben wir heute das Internet und dann geht das alles ein bischen schneller. Und die falschen Heiligen werden schneller aufgedeckt.

Klingt vielleicht ein bischen pathetisch, aber software-entwicklung ist vielleicht manchmal ein Vordringen in unbekanntes Gebiet, wo man nicht weiss, wo man am Ende lande. Da gibt es in den meisten Projekten Punkte, über die ich nur unvollständige Information habe und worüber ich keine realistischen Prognosen abgeben kann.
Es gibt inzwischen klare Argumente für mehr OO-mässige Umgebungen als LotusScript. Aber wenn du das erste Projekt damit machst, wirst du scheitern (oder du bist wirklich aussergewöhnlich talentiert für diese Umgebung, selten). Das hat immer Kosten.    

Ich finde auch, dass die Bedeutung von Programmiersprachen für den Job als Programmierer deutlich überschätzt werden. D.h. gibt es überhaupt  so viele "reine" Programmierjobs. Meist ist man doch Programmierer und Projekt Manager oder/und Programmierer und Consultant.
Eine der Dinge, die ich während des Booms immer gehasst habe (und zu extrem unproduktiven Ergebnissen geführt hat) war dieser hilflose Versuch fordistische Arbeitsprinzipien auf die Software-Entwicklung zu übertragen. Plötzlich hatte die Firma Geld aus dem Aktienmarkt und dann wurde versucht zwischen Technischen Wissensträgern und den Kunden eine Zwischenschicht an un-technischen "Projekt-Managern" zu setzen. Oft grüne Jungs und Mädels, die nach erfolgreich absolvierten BWL-Studien oder verwandten mit ihren textbook Management-Theorien auf die Entwickler losgelassen wurden. Entwickler, die funktionierende KundenBeziehungen hatten, konnten sich dann ein "bad_teamworker" Image zulegen, den Projektmanager-Titel für sich selbst durchsetzen und mehr oder weniger ungestört arbeiten. Bei Beendigung des Booms zerbrach das System an den selbst geschaffenen Kostenstrukturen und auch an einer allgemein schlechten Arbeitsatmosphäre.

Heute, auf dem Boden der Tatsachen, sieht man sich doch oft sehr vielfältigen Anforderungen ausgesetzt.
Einen großen Teil meiner Zeit beschäftige ich mich mit
- Projektmanagement, Zeitmanagement, Kundenkommunikation, Motivationsmanagement, Change-Management, Wissensmanagement (wo finde ich was), etc.
- Testumgebungen (Performance-Messungen für die Realität, Funktionstests, Einrichten von Rechnern).  
- ständig neue Tools und neue Produkte. Wie funktioniert diese xml-Datenbank, Wie arbeite ich effektiv mit MySql. Wie funktionieren Webservices.
- generellen, mehr administrativen Fragestellungen: Security, TCP-IP, die z.B. in Java oft in spezifischen APIs gekapselt sind. Verständnismässig ist nicht die API das schwierige, sondern das zugrundeliegende Subsystem (z.B. LDAP).
- generelle OO-Fragen. Wie programmiere ich OO richtig (Pattern, etc). Dies ist eine von der Programmiersprache losgelöste Fragestellung.  
- generell vernünftig programmieren.

Vieles von dem ist Programmiersprachenunabhängig. Und wenn man sich um ein wirkliches Verständnis bemüht und es nicht primär darum geht, die Anforderungen von den "Chefs" irgendwie ans Laufen zu bringen, egal wie, baut man ein gewisses grundlegendes Wissen auf, dass technischen Wandel überdauert.

Ende der 90er hörte man oft, dass es für prozedurale Programmierer schwerer ist, auf OO umzusteigen als für Neulinge neu mit OO anzufangen. Ich halte das für kompletten Schwachsinn und man hört das auch nicht mehr.

Gruß Axel
« Letzte Änderung: 26.10.03 - 08:41:17 von Axel_Janssen »
... design patterns are abstract designs that help identify the structure and elements involved in a specific design solution. From this, a concrete implementation can be produced.
Kyle Brown

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz