Nicht objektiv

[timf]

Warum Objective-C im moment so im Zenit des Hype steht muss ich nicht erklären, hat doch apple kürzlich angekündigt den einsatz der open source sandboxes für apps mit html+js zu unterbinden...wenn ich mich richtig erinnere
(ja, wir haben freitag :)

Wenn nicht-typisierten Script-Sprachen (JavaScript...) mit C++ vergleicht werden kommt es zu einem nicht-objektiven Spiegel.

Ein Progger kann mit einer nicht-typisierten Scriptsprache seine produktivität um den faktor 10 steigern (auch wie wart- und lesbarkeit des code)

Und ich plage mich momentan mit C++ rum... der Aufwand und die Lernkurve sind ungleich im Gegensatz zu den Scriptsprachen. IMHO

Jedoch hat jede Sprache seinen Einsatzbereich und der Projektleiter entscheidet ob er sein Team quälen will oder nicht - SCNR

[titrat]

timf schrieb:
--------------------------------------------------------------------------------
...
> Ein Progger kann mit einer nicht-typisierten Scriptsprache seine
> produktivität um den faktor 10 steigern (auch wie wart- und lesbarkeit des
> code)

Wie objektiv!
Wird die Produktivität dabei in billbaren Stunden gemessen? :-)

> Und ich plage mich momentan mit C++ rum... der Aufwand und die Lernkurve
> sind ungleich im Gegensatz zu den Scriptsprachen. IMHO

Sicher, Skriptsprachen sind schneller erlernbar, aber produktiver wohl eher nur kurzsichtig, kommt aber wie immer auf den konkreten Fall an.

> Jedoch hat jede Sprache seinen Einsatzbereich und der Projektleiter
> entscheidet ob er sein Team quälen will oder nicht - SCNR

In der Tat, und das ist gut so.

[zilti]

Ich habe bis jetzt noch nicht herausgefunden, warum eine dynamisch typisierten Sprache (es gibt keine nicht-typisierten) produktiver zu verwenden sein soll als eine statisch typisierte.

C++ habe ich damals innert einer Woche gelernt (ich konnte schon Java, und da ist der Schritt relativ klein) und in 2 Wochen mit SDL ein Mehrspielerspiel für meine Maturaarbeit (ist evtl. vergleichbar mit einer Abitur-Abschlussarbeit, falls es das bei euch gibt) geschrieben. Nichts von wegen schwierig aus meiner Sicht. Nur die Sache mit den Header-Files ist verdammt umständlich, unübersichtlich und kontraproduktiv. Und wehe, man vergisst als Java-Programmierer in C++ eine Variable als Pointer zu deklarieren... ("Verdammt, wieso wird der Wert nicht aktualisiert?")

[zilti-Sympathisant]

Dynamisch typisierte Sprachen sparen viel Tippen a la inttostring(zahl) ,aber dadurch passieren bestimmt auch ne menge fehler, floats runden etc.

Die Header lassen mich auch überlegen, ob das jetzt sinnvoll ist, hobbymäßig mit SFML dem Quasi SDL-Nachfolger oder D'Enfent-Engine noch was mit C++ zu machen. Ich hätte gerne D genommen, aber da passiert anscheinend nix mehr.

[GodsBoss]

Ich behaupte: Es ist nicht der Unterschied zwischen statischer und dynamischer Typisierung. Es gibt auch statisch typisierte Sprachen, wo man die Typen meist nicht angeben muss, weil vom Compiler automatisch erkannt wird, was es ist (Typinferenz).

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[w3group]

zilti schrieb:
--------------------------------------------------------------------------------
> Ich habe bis jetzt noch nicht herausgefunden, warum eine dynamisch
> typisierten Sprache (es gibt keine nicht-typisierten) produktiver zu
> verwenden sein soll als eine statisch typisierte.

1. Nicht typisierte Sprachen: Z.B. Assembler, Forth
2. Wenn man Produktivität auf Codieren reduziert sind mit dynamisch
typisierten Sprachen zu Projektbeginn rascher Ergebnisse zu erzielen.
Man erspart sich Denk- und Tipparbeit. Etwas später in der Projektphase,
wenn die Anwendung etwas umfangreicher geworden ist, wird es immer
schwieriger Änderungen und Erweiterungen einzubringen. Da punktet
dann die Typisierung.

> C++ habe ich damals innert einer Woche gelernt (ich konnte schon Java, und
> da ist der Schritt relativ klein)

Wahnsinn, das ist richtig toll!
Ich hab 10 Jahre gebraucht um C++ zu beherrschen.

> ... Und wehe, man
> vergisst als Java-Programmierer in C++ eine Variable als Pointer zu
> deklarieren... ("Verdammt, wieso wird der Wert nicht aktualisiert?")

vielleicht ist eine Woche doch ein bischen kurz ?

Gruß
Andi

[GodsBoss]

> 2. Wenn man Produktivität auf Codieren reduziert sind mit dynamisch
> typisierten Sprachen zu Projektbeginn rascher Ergebnisse zu erzielen.

Ist das so? Das Hauptärgernis der Typisierung in Java und C++ (und einigen anderen) ist m.E. nicht die Typisierung selbst, sondern die explizite Typisierung. Das machen Sprachen mit Typ-Inferenz besser.

> Man erspart sich Denk- und Tipparbeit. Etwas später in der Projektphase,
> wenn die Anwendung etwas umfangreicher geworden ist, wird es immer
> schwieriger Änderungen und Erweiterungen einzubringen. Da punktet
> dann die Typisierung.

Hmmmm, warum? Was leistet Typisierung, was man mit Tests nicht abfangen kann?

> > C++ habe ich damals innert einer Woche gelernt (ich konnte schon Java,
> und
> > da ist der Schritt relativ klein)
>
> Wahnsinn, das ist richtig toll!
> Ich hab 10 Jahre gebraucht um C++ zu beherrschen.
>
> > ... Und wehe, man
> > vergisst als Java-Programmierer in C++ eine Variable als Pointer zu
> > deklarieren... ("Verdammt, wieso wird der Wert nicht aktualisiert?")
>
> vielleicht ist eine Woche doch ein bischen kurz ?

Tja, Schach lernt man sicher in einer halben Stunde. Aber Meister ist man dann noch lange nicht. ;-)

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[w3group]

GodsBoss schrieb:
--------------------------------------------------------------------------------
> > 2. Wenn man Produktivität auf Codieren reduziert sind mit dynamisch
> > typisierten Sprachen zu Projektbeginn rascher Ergebnisse zu erzielen.
>
> Ist das so? Das Hauptärgernis der Typisierung in Java und C++ (und einigen
> anderen) ist m.E. nicht die Typisierung selbst, sondern die explizite
> Typisierung. Das machen Sprachen mit Typ-Inferenz besser.

ja, Typ-Inferenz finde ich auch cool, aber leider kenne ich da nichts für
C, C++ oder Java. Aber man könnte mal Googlen ob sich da jemand
Gedanken drum gemacht hat.


> > Man erspart sich Denk- und Tipparbeit. Etwas später in der Projektphase,
> > wenn die Anwendung etwas umfangreicher geworden ist, wird es immer
> > schwieriger Änderungen und Erweiterungen einzubringen. Da punktet
> > dann die Typisierung.
>
> Hmmmm, warum? Was leistet Typisierung, was man mit Tests nicht abfangen
> kann?

Die Tests programmieren zu müssen ?

[GodsBoss]

> > > 2. Wenn man Produktivität auf Codieren reduziert sind mit dynamisch
> > > typisierten Sprachen zu Projektbeginn rascher Ergebnisse zu erzielen.
> >
> > Ist das so? Das Hauptärgernis der Typisierung in Java und C++ (und
> einigen
> > anderen) ist m.E. nicht die Typisierung selbst, sondern die explizite
> > Typisierung. Das machen Sprachen mit Typ-Inferenz besser.
>
> ja, Typ-Inferenz finde ich auch cool, aber leider kenne ich da nichts für
> C, C++ oder Java. Aber man könnte mal Googlen ob sich da jemand
> Gedanken drum gemacht hat.

Uff, da muss ich auch passen. Wenn es nur darum geht, etwas für die Java-Runtime zu schreiben, kann ich aber Scala empfehlen, das zu Java-Bytecode kompiliert wird. Dabei ist Scala mit Java größtenteils interoperabel. Eine neue Sprache (Scala) müsste natürlich trotzdem gelernt werden – wenn es dir darum geht, das zu vermeiden, dann gibt es m.E. keine Lösung.

> > > Man erspart sich Denk- und Tipparbeit. Etwas später in der
> Projektphase,
> > > wenn die Anwendung etwas umfangreicher geworden ist, wird es immer
> > > schwieriger Änderungen und Erweiterungen einzubringen. Da punktet
> > > dann die Typisierung.
> >
> > Hmmmm, warum? Was leistet Typisierung, was man mit Tests nicht abfangen
> > kann?
>
> Die Tests programmieren zu müssen ?

Tests muss man sowieso programmieren, ich fand die Überlegungen zu diesem Zitat überzeugend (aus Move over Java I have fallen in love with JavaScript):
„Compile does not make the need for tests to go away, but the tests do make the need for compiler to go away.“

Ich schreibe sowieso Tests, die prüfen, ob alles funktioniert. Die Typisierung kann dann auch nichts mehr abfangen.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[w3group]

> > > > Man erspart sich Denk- und Tipparbeit. Etwas später in der
> > Projektphase,
> > > > wenn die Anwendung etwas umfangreicher geworden ist, wird es immer
> > > > schwieriger Änderungen und Erweiterungen einzubringen. Da punktet
> > > > dann die Typisierung.
> > >
> > > Hmmmm, warum? Was leistet Typisierung, was man mit Tests nicht
> abfangen
> > > kann?
> >
> > Die Tests programmieren zu müssen ?
>
> Tests muss man sowieso programmieren, ich fand die Überlegungen zu diesem
> Zitat überzeugend (aus Move over Java I have fallen in love with
> JavaScript):
> „Compile does not make the need for tests to go away, but the tests do make
> the need for compiler to go away.“
>
> Ich schreibe sowieso Tests, die prüfen, ob alles funktioniert. Die
> Typisierung kann dann auch nichts mehr abfangen.

ja, ich habe mir schon gedacht dass die Diskussion diese Richtung einschlagen
wird. Bisher habe ich persönlich noch kein (auch nicht größeres) Unternehmen
angetroffen die TestCases über mehr als kritische oder komplexe Funktionalitäten
gelegt hätten. TestCases sind nunmal aufwendig, also kosten sie Geld (das schlägt
im Angebot ganz schön zu Buche). Daher wird sorgfältig überlegt wo überall
TestCases einzupflegen sind. Bei einem Budget von 3000 Euro für ein kleines
Programm, wo sollst du da noch viele TestCases einplanen ? Alternativ kannst du das
Projekt natürlich ablehnen (und Pommes beim McDonalds verkaufen ? - nur ein
Spaß).

Nein im Ernst, habe viele Jahre sehr erfolgreich mit Smalltalk entwickelt. Die Programme
liefen (laufen) erstaunlich stabil, auch ohne statischer Typisierung. Bei einem Projekt
mussten später große Teile umgestellt werden, hier wäre eine statische Typisierung
recht hilfreich gewesen, das war ein *riesen* Aufwand. Die TestCases waren natürlich
sehr hilfreich, aber die Arbeit deswegen nicht einfacher. Bei statischer Typisierung
sagt dir der Compiler eben sofort wo es klemmt.

Ich denke aber schon dass sich die Vor und Nachteile beider Varianten etwa die
Waage halten. Es ist wahrscheinlich einfacher bei statischer Typisierung optimierende
Compiler zu schreiben.

Scala, Haskell und OCaml halte ich persönlich für höchst interessant. Da ich aber
zum Speedjunkie mutiert bin (Web-Anwendungen) entwickle ich zur Zeit nur noch in C.