Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Erstens hat Racket auch ein klassenbasiertes Objektsystem, wo man diesen ganzen Typkram übrigens auch drauf anwenden kann. Zum anderen die die Idee ja nicht neu. Das geht z.B. auch in Ada. Da kann man ebenfalls Typen mit Contraints einschränken: subtype Monthtype is Integer range 1 .. 12;
und viola hat man ein Typ mit denen man Variablen deklarieren kann, die eben nur Ganzzahlen von 1 bis 12 annehmen können.
Und Ada ist nicht funktional. Eher strukturiert und natürlich seit den 90er Jahren auch Objektorientierung.
Sicher kann Racket auch OOP, dennoch scheint funktionale Programmierung im Vordergrund zu stehen. Ada scheint auch eine recht spezielle (und zu Anfangs pre-OOP) Entwicklung hinter sich zu haben.
andy_m4 schrieb:
Was ja auch eine große Stärke ist. Weil man eben nicht für jeden Kram eine extra Syntax braucht, sondern das nehmen kann, was man sowieso immer nimmt.
Mir fallen überhaupt nicht sehr viele Beispiele ein, wo man einen Monat modellieren will aber kein zugehöriges Datum oder Zeiträume. Generell scheint mir das gegebene Beispiel auch eher wenn schon dann auf enums hinaus zu laufen.
Ein Monat ist jedenfalls keine Zahl bzw. wird nur schlecht durch die natürlichen Zahlen kleiner als 13 repräsentiert. Wenn schon Zahlen, dann halte ich es z.B. für üblich, dass wenn ich vom zwölften Monat einen Monat weiter zähle keine Fehlermeldung kommt, sondern ich wieder beim ersten Monat lande.
Und wenn ich z.b. etwas anzeige, dann wird der Monat in der Regel ja nicht als "1" oder "2", sondern als "Januar" oder "Februar" oder zumindest "01", "02" dargestellt.
Sprich, wir haben Verhalten, verschiedene Repräsentationen und Gleichheit ist in natürlicher weise nicht Objektgleichheit, sondern Wertgleichheit -> ValueObject.
andy_m4 schrieb:
Sehe ich komplett anders. Funktionales Programmieren bringt in vielen Situationen Vorteile. Weil es es einfacher macht fehlerfreie Programme zu schreiben (durch die Minimierung von Nebeneffekten) und weil man (auch daraus resultierend) gute Unterstützung für Multithreading quasi nebenbei geschenkt bekommt.
Ich will funktionales Programmieren jetzt hier nicht als Allheilmittel verstanden wissen. Aber es sollte halt zum Repertoire eines Programmierers genauso dazu gehören, wie eben OOP und andere Paradigmen.
Ich hab ja auch nicht gesagt, dass das C++ Typsystem schlecht ist. Ich hab ja lediglich gesagt, dass ich ein gutes Typ-System als wichtig empfinde.
Abgesehen davon ist das ja nicht automatisch ein Problem. Klar kann man mit vorhandenen Datentypen gut leben. Die Frage ist ja eher, kann man das noch verbessern.
Und ist ja auch durchaus vollstellbar, dass C++ bezogen auf Typen selbst für Dich noch bisher unbekannte Möglichkeiten bereithält.
new Account() schrieb:
Falls ich mal bounded integers brauchen sollte, habe ich die Library im Reportaire. Danke für das Konzept des Beschränken eines Integers von 1 bis 12!
Bounded Integers war ja jetzt nur ein spezifisches und vorallem einfaches/nachvollziehbares Beispiel. Man kann damit noch eine ganze Menge mehr machen.
Ergänzung ()
BeBur schrieb:
Sicher kann Racket auch OOP, dennoch scheint funktionale Programmierung im Vordergrund zu stehen. Ada scheint auch eine recht spezielle []
Ja. Racket geht schon sehr stark in die funktionale Richtung. Oder sagen wir mal so: Viele Probleme lassen sich gut im funktionalen Stil lösen also stellt man dem möglichst wenig Hindernisse entgegen (funktionales Programmieren macht dann am meisten Sinn, wenn es die Sprache unterstützt). Nichtsdestotrotz beschränkt man sich eben nicht darauf. So ist der OOP-Kram ja nicht nur da, damit man sowas hat und in der Featureliste vorweisen kann, sondern es wird ja auch genutzt. Zum Beispiel beim GTK-basierten GUI-Framework.
Man bringt also schon relativ klar zum Ausdruck: Wir haben hier Paradigma XYZ und das ist das Beste was es gibt. Sondern man ist sich schon bewusst, dass alles seine Stärken und Schwächen hat. Und mit dem (wirklich sehr guten) Makrosystem bringt man ja auch eine Möglichkeit mit, auch was völlig Eigenes zu implementieren.
Man ist nicht mal an die Lisp-Syntax gebunden.
BeBur schrieb:
Mir fallen überhaupt nicht sehr viele Beispiele ein, wo man einen Monat modellieren will aber kein zugehöriges Datum oder Zeiträume.
Gut. Monat als Beispiel ist da vielleicht etwas schlecht. Es ging auch nur darum zu zeigen, dass man manchmal einen eingeschränkten Wertebereich haben möchte. Und Monat ist halt da ein allgemein verständliches und simples Beispiel.
Insofern stimme ich Dir zu, was Du zu dem Beispiel auch richtigerweise sagst. Aber das ist halt nicht der Punkt. Der Punkt ist, dass man halt ne einfache Möglichkeit haben möchte den Wertebereich einer Variablen mehr einzuschränken als es über die üblichen Variablentypen möglich ist.
Das meinte wohl eher, dass man nicht ein Sprachkonstrukt dafür haben möchte bzw. braucht, da man i.d.R. nach "explicit before implicit" vorgeht, d.h. man würde im Kontext seiner Domäne jede Klasse sowieso derartig konzipieren, dass die Klasse selbst überprüft, ob eine Eingabe innerhalb ihrer abzubildenden Domäne korrekt ist und niemand sonst, alle sonstigen Eingaben also "akzeptiert" werden sollten.
Das ist ja z.B. auch eine der Begründungen für das Duck-Typing und die wachsenden Datentypen in Python: wenn eine Klasse eine Zahl hält und ich addiere etwas hinzu, dann hat es keinen Overflow zu geben, sondern sich die Genauigkeit des dahinterlegenden Datentypen eben im Zweifelsfall anzupassen.
Es sei denn, ich will eben aus Performancegründen etwas bestimmtes.
So wie du es im Prinzip ja auch schon hier geschrieben hast:
Fonce schrieb:
(z.B. beim Zugriff auf einen std::vector über die Methode at(int Index).
Das würde ich nicht sagen. Es mag daran liegen, das ich viel bei verteilten Systemen (Back-End) und mittlerweile ja im Bereich Data Science / ML unterwegs bin, aber es gibt unglaublich viele Probleme die man sehr schnell und elegant funktional lösen können.
Wenn man jetzt z.B. eher UX macht, irgendwelche Business-Modelle o.Ä. findet das sicherlich weniger Verwendung, aber wann immer man irgendetwas entwickelt, wo viele Daten verarbeitet werden müssen, sollte man imho die funktionalen Paradigmen beherrschen.
Zur funktionalen Programmierung sei noch gesagt das sie durch die Unterstützung von Lambda Expression ja auch eine gewisse Verbreitung in der OOP Welt hat. Wenn man das einmal verinnerlicht hat kann man z.B. mit Linq und Lambda Expressions viele Konstrukte, die sehr geschwätzig wären, sehr prägnant durch ein oder zwei Zeilen ersetzen.
SOLID, clean code sind ja beispielsweise so Schlagworte.
Vielleicht verfehle ich das Thema (meine persönliche Einschätzung):
1. wichtige Regel, Projekt in einer Firma eruieren, in dem man mit der Fachabteilung, die die Software benötigen, redet den jetzigen Zustand versteht und kommuniziert was sie aber wirklich brauchen. Ansonsten kann es sein, dass man unnötigen code baut und alles verkompliziert.
Ich finde ein Projekt ist nie kompliziert, solang man versteht wie alles funktioniert und es aufteilen kann und inkrementell daran arbeitet.
Von Vererbung halte ich nichts, wenn sie vergewaltigt wird und ich habe das schon gesehen, wie Vererbung falsch genutzt wird. Wir benutzen keine Vererbung mehr, wenn es nicht 100% nötig ist. Edit: oder keinen Sinn macht.
Von Vererbung halte ich nichts, wenn sie vergewaltigt wird und ich habe das schon gesehen, wie Vererbung falsch genutzt wird. Wir benutzen keine Vererbung mehr, wenn es nicht 100% nötig ist.
