Diskussion:Starke Typisierung/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Englische Seite?

Hm, hier wird es bunt. Dem englischen Artikel nach, gibt es viele Bedeutungen. Bitte um Mitarbeit! :-) --Marc van Woerkom 18:00, 27. Dez 2004 (CET)

Ich habe mal den Inhalt der englische Seite eingearbeitet. Mir fehlt die entsprechende Literatur, um selbst beurteilen zu können, wie relevant die einzelnen Punkte sind. --Dr. Tux 14:23, 17. Mai 2005 (CEST)

Ich glaube sehr wohl dass es stark typisierte Programmiersprachen gibt: die ML Familie (SML, Ocaml, ...). Kennen tu ich nur Ocaml, und da erfuellt die Kernsprache meines Wissens die genannten Vorraussetzungen (obwohl man natuerliche mit dem Modul Marshal oder C-implementierten Funktionen boese Dinge machen kann, zum Beispiel ein float in ein int casten)

Das mag schon sein, ich kenne die ML Sprachen nicht. Aber die Definition von strong typing ist für sich schon so schwammig und verwaschen, dass man wahrscheinlich immer irgendwas an einer Sprache findet, das dagegen spricht. Aber darum geht es gar nicht. Es gibt halt Sprachen, die genügen kaum einem Kriterium, und welche, die genügen mehreren. Wer eine wasserdichte Definition aufstellen will, kann´s ja versuchen. Aber die Begründung sollte mindestens 100 DIN-A4 Seiten lang sein und auch philisophischen Diskussionen standhalten können. :-) --Dr. Tux 11:06, 27. Jan 2006 (CET)

Kopfkratz

So ganz ohne Verweis auf Literatur sollte man die wagen Behauptungen nicht stehenlassen. igel+- 01:13, 26. Jul 2006 (CEST)

Weblink

Der Weblink ist im Moment defekt.--Plaicy 19:36, 10. Apr. 2007 (CEST)

Scheint schon seit einem halben Jahr tot zu sein. Ich habe auf web.archive.org umgelenkt. --jpp ?! 13:28, 11. Apr. 2007 (CEST)

C

Dass, C oder C++ stark typisiert seien, kann ja wohl nur ein übler Scherz sein. Einige Beispiele, von denen jedes einzelne gegen eine starke Typisierung spricht:

  • Ganze und reelle Zahlen können ohne Typenprüfung vermengt werden
  • Vorzeichenbehaftete und positive Zahlen können ohne Typenprüfung vermengt werden
  • Der Divisionsoperator hat keinen eindeutigen Ergebnistyp
  • Operatoren können überladen werden
  • Bei Zeigervaribalen gibt es gar keine Typprüfung
  • Fließkommazahlen können ganzzahligen Variablen zugewiesen werden
  • Variante Datenverbunde
  • Keine booleschen Werte, Vermengung mit int
  • Fehlende Typprüfung bei Datenfeldern

Ich habe C/C++ daher entfernt. Membeth 11:26, 2. Aug. 2007 (CEST)

PHP / Python

Ich stosse recht häufig auf die Ansicht, Python sei stark typisiert, während PHP schwach typisiert sei - so auch in diesem Artikel.

Der einzige Unterschied zwischen beiden ist jedoch, dass PHP "auf der linken Seite" ein kontextabhängiges implizites Casting vornimmt, während bei Python ein explizites Casting erforderlich ist. Bei beiden Sprachen gibt es keine feste Bindung von Datentyp und Variable: beide sind dynamisch (nicht schwach) typisiert.

Bei beiden Sprachen bleibt durch ein Casting das referenzierte Objekt / der referenzierte Wert unberührt; sein Datentyp kann nicht geändert werden.

PHP: 

$foo = "3";
echo gettype($foo * 2); // integer. Impliziter Cast
echo gettype($foo);     // string

Python: 

foo = "3"
type(int(foo) * 2) # <type 'int'>. Expliziter Cast
type(foo)          # <type 'str'>


Meiner Meinung nach ist daher das Typsystem beider Sprachen als "dynamisch" und "stark" zu betrachten; das kontextabhängige implizite Casting der Variable in PHP ist eine spezifische Implementierung eines dynamischen Typsystems und reicht m.E. nicht aus, von einer schwachen Typisierung zu sprechen.

-- Blaufalke 16:34, 31. Dez. 2007 (CET)

zur QS

Der Artikel ist in der Tat ausbaufähig. Der Begriff wird leider wirklich sehr unterschiedlich gebraucht, was der Artikel aber ja auch nennt. Bei den Vorteilen wäre es also z.B. gut, zu benennen zu welcher Definition sie gehören. Nichtsdestotrotz enthält der Abschnitt einen wahren und wichtigen(!) Kern, der erhalten werden sollte.

Bei den - momentan entfernten - Beispielen sehe ich das ähnlich. Ich kann die Beispiele nachvollziehen und halte sie für hilfreich und wichtig im Artikel. Nur sollte angegeben werden, zu welcher Definition sie gehören. So wie ich das sehe gehören die Beispiele mehr oder weniger zur Definition 4, also Typkonvertierungen müssen explizit geschehen. (BTW: Ich würde noch solche Ausnahmefälle wie Konvertierung double => float zulassen d.h. diese Problematik erläutern.)

Ich schlage also folgendes vor:

  • Die erste Definition, die quasi die genannten 8 vorweg nehmen will entfernen und dafür die 8 Definitionen ggf. überarbeiten und genauer darauf eingehen, dass es keine allgemeingültige Definition gibt.
  • Die 8 Definitionen an sich überarbeiten (Definition 8 ist mir Beispielsweise unklar).
  • Zu jeder (zusammengehörigen Gruppe von Definitionen des Begriffs (3 und 4 sind z.B. sehr ähnlich)) einen eigenen Abschnitt mit ner Erläuterung, Vor- und Nachteilen, sowie Beispielen.

Aus Zeitmangel kann ich das jetzt nicht selbst machen, aber da der QS-Baustein jetzt gesetzt wurde... Wenn ich in ein paar Wochen mal wieder mehr Zeit hab und der Artikel ist immer noch ausbaufähig, nehme ich mich ihm vllt. mal an... --Der Hâkawâti ✉ 17:36, 6. Nov. 2009 (CET)

>>> Ich habe mal angefangen, hier aufzuräumen und erbitte Kommentare dazu. <<< Äh... gut. Hier Kommentare:

  • Sieht für den Anfang schonmal ganz gut aus.
  • >>> die strengstmögliche Interpretation des Begriffs <<< Die da wäre?
  • >>> Die eigentliche Absicht des Begriffs ist es <<< Hm... gefällt mir so nicht. Erstens hat ein Begriff keine Absicht, sondern höchstens das Konzept, das mit dem Begriff bezeichnet wird, und zweitens kommt das auf die Definition von starker Typisierung an. Die von mir favorisierte Definition (keine impliziten Typkonvertierungen) hätte einen anderen Hintergrund. Beispielsweise wäre PHP nach dieser Definition eine sehr schwach typisierte Sprache, weil andauernd irgendwelche implizite Casts gemacht werden. Typfehler gibt es aber IMHO in PHP keine. Eben aufgrund der impliziten Konvertierungen.
  • >>> Die am häufigsten angetroffene Definition <<< Sicher, dass die am häufigsten ist? Ich halte die von mir favorisierte für am verbreitetsten. Subjektiv natürlich. Ich denke also wir sollten hier keiner Definition den Vorrang geben.
  • >>> ... fällt mit der statischen Typisierung zusammen: Hierbei ist der Typ jeder Entität ... <<< Das seh ich anders. Statische Typisierung bindet den Typ an den Bezeichner, starke Typisierung an die Entität (meine favorisierte Definition). Zudem suggeriert der Satz, dass es eine einzige genaue Definition von statisch typisiert gäbe. Sollte es Definitionen von statisch typisiert geben, die die Entität und nicht den Bezeichner betrachten, sollte der dazugehörige Artikel ergänzt werden.--Der Hâkawâti ✉ 22:43, 12. Nov. 2009 (CET)
Soweit ich die theoretische Informatik verstanden habe, ist unter "starker Typisierung" zu verstehen: Im Programmtext wird der Typ jeder Variablen, aller Konstanten, Prozedur- und Funktionsparameter (hier auch Rückgabewerte), Class-Interfaces und -methoden natürlich auch, explizit festgelegt. Typecasting muss ebenso ausdrücklich durchgeführt werden. So merkt schon der Compiler oder der Interpreter, das eventuell was nicht stimmt.
  • Die Frage nach "strengstmöglich": denkbar wäre, das selbst ein cast von (int) nach (long) beschrieben werden muss. Sowas ist mir allerdings nicht bekannt. Weitere Beispiele von ziemlich streng nach lax:
  • ziemlich starke Typisierung: Pascal, Modula, Ada, PL/SQL usw., Java
  • bei C++ hängt es von jeweiligen Compiler-Optionen ab.
  • PHP ist zwar schwach typisiert, aber
  • Perl interessiert Typisierung wenig. (Beispiel: Inkrement von Strings ;-)
In der Objektorientierung wird ein Objekt vom Typ A normalerweise per Klassen-Methode in eines vom Typ B umgewandelt, also findet eine explitite Typumwandlung statt. Ausnahmen sind möglich bei gemeinsamer Basisklasse (oder -Klassen bei Mehrfachvererbung). --grixlkraxl 12:15, 26. Jan. 2010 (CET)

Siehe auch Zuweisungskompatibilität. Bautsch 04:51, 23. Jan. 2011 (CET)

Vorteile / Nachteile

Die Liste der Vorteile ist recht dürftig. Meiner Meinung nach fehlt der wichtigste Vorteil. Durch starke Typisierung lassen sich Fehler, welche durch das Mischen von unterschiedlichen Typen entstehen, schon beim Compilieren des Programmes erkennen. Bei schwach typisierten Sprachen treten solche Fehler erst zur Laufzeit auf und lassen sich nur durch intensives Testen vermeiden.

Den momentan einzig erwähnten Vorteil, dass man durch starke Typisierung schon im Quellcode auf den Rechenaufwand bei der Typumwandlung hingewiesen wird, halte ich für zweitrangig. Bei der Leistungsfähigkeit heutiger Rechner fallen diese Umwandlungen meistens nicht mehr ins Gewicht.

Wenn auf die Vorteile der starken Typisierung hingewiesen wird, sollte auch auf die Nachteile hingewiesen werden. Insbesondere die höhere Komplexität für den Programmierer gehört für mich auf die Liste der Nachteile. (nicht signierter Beitrag von 77.58.82.94 (Diskussion | Beiträge) 00:48, 15. Jun. 2008 (CEST))

Zu [1]

Die 2 nachweisbar falschen Behauptungen sind:

  • "die strengstmögliche Interpretation des Begriffs findet sich in keiner Programmiersprache wieder"
Wenn man Programmiersprachen, die nebenbei auch Beweisassistenten sind, (z.B. Agda) betrachtet, können die gar nicht anders, als im strengsten Sinne stark typisiert zu sein. Ganz egal, wie dieser Sinn definiert ist.
  • "[fällt mit statischer Typisierung zusammen:] Hierbei ist der Typ jeder Entität in einem Programm bereits zur Übersetzungszeit vollkommen festgelegt und kann sich über die gesamte Laufzeit des Programms auch nicht ändern. "
Was ist hier bei z.B. C#? Das ist definitiv statisch typisiert. Objekte können aber dynamische Typen haben, die statisch nirgends auftauchen. Sind die dann keine Entitäten, oder wie, oder was? Oder was ist mit "Entität" gemeint? (Gut, das ist eher uneindeutig als falsch, aber immerhin). Aber wie auch immer: Man kann allen wie auch immer gearteten Entitäten den statischen Typ Object geben, und über die gesamte Laufzeit des Programms beibehalten. Das kann's ja nicht sein.

--Daniel5Ko 23:48, 11. Mai 2011 (CEST)

C schwach typisiert

C ist doch der Klassiker unter den schwach typisierten Sprachen. Siehe Objektorientierte Programmierung von Bernhard Lahres, Gregor Rayman. --188.108.103.243 16:14, 17. Jul. 2012 (CEST)

Ich verstehe auch nicht, wie Programmierer darauf kommen, dass C oder C++ stark typisiert sei. Insbesondere bei Zeigervariablen gibt es überhaupt keine Kontrolle der Zuweisungskompatibilität und das ist VeriFone mit seinen Electronic-Cash-Lesegeräten auch gerade wieder auf die Füße gefallen. Viele Manager, die für die Auswahl der Programmierwerkzeuge verantwortlich sind, verstehen diese Probleme überhaupt nicht und machen sich, ihren Programmierern, ihrem Unternehmen und den Kunden das Leben unötig schwer. --Bautsch (Diskussion) 18:09, 17. Jul. 2012 (CEST)
vollkommen richtig, ich korrigiere die Passage jetzt. --Herbert Klaeren (Diskussion) 19:04, 17. Jul. 2012 (CEST)
Vielen Dank ! Erschwerend kommt bei C der Mangel der fehlenden Differenzierung zwischen ganzzahligen, Booleschen und Mengen-Datentypen hinzu. Das ist gravierend und wirklich alles andere als typsicher. --Bautsch (Diskussion) 09:51, 18. Jul. 2012 (CEST)
danke für den Hinweis, das ist natürlich auch sehr wesentlich! --Herbert Klaeren (Diskussion) 15:43, 18. Jul. 2012 (CEST)
Das habe ich dazu gerade noch im Archiv von 2007 gefunden: Diskussion:Starke_Typisierung/Archiv/1#C; scheint später nicht weiter beachtet worden zu sein. --Bautsch (Diskussion) 17:28, 18. Jul. 2012 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Starke_Typisierung/Archiv/1&oldid=198986304“