NG Programmiersprache?

Zeus

Zum Punkt, du hast hergeleitet, dass ich etwas Vergleiche, was ich nicht getan habe. Ich hab eine Frage für eine Kategorie gestellt und Java als Beispiel genommen. Eigentlich dachte ich, dass du weißt, dass man Aussagen für Beispiel nicht auf Kategorien verallgemeinern darf und schon gar nicht auf andere Kategorie.

Außerdem ist Java keine pure objektorientierte Programmiersprache.

Wenn du eine pure objektorientierte Programmiersprache mit Operatordefinition (nicht Überladung!) suchst, dann nimm Cecil. Diese Sprache hat aber wirklich keine Verbreitung jenseits der Uni.

volkard

Zeus schrieb:

Außerdem ist Java keine pure objektorientierte Programmiersprache.

"pur objektorientiert" gibt es nicht.

Mr. N schrieb:

Zeus schrieb:

Mr. N schrieb:

Du vergleichst Äpfel mit Birnen. Java versucht allem krampfhaft seine Objektorientierung für Arme aufzuzwingen, das heißt aber noch lange nicht, dass eine rein-funktionale Sprache schlecht wäre.

Das musst du mir genauer erläutern! Sonst hacke ich das bösewillige Unterstellung ab.

In rein objektorientierten Sprachen (in Java-Art*) ist es schwierig, Konzepte wie Addition auszudrücken:
obj1.add(obj2)
- nicht gerade elegant!

Aber kannst du mir etwas konkretes nennen, was in funktionalen Programmiersprachen nicht gut geht? Zumindest nicht so gut wie in einer Sprache, die Objektorientierung unterstützt.

Prozesse beschreiben, oder Objekte darstellen geht in rein funktionalen Programmiersprachen genauso gut, wie Funktionen beschreiben in "rein" Objektorientierten Sprachen mit "Objekt.Methode(Parameter)-Syntax". Ein Prozessor führt Prozesse aus (Prozedurale Programmierung), in Software müssen meistens realitätsnahe Objekte dargestellt werden (Objektorientierte Programmierung). Nicht, dass es keine guten Gründe für funktionale Programmierung gäbe, aber ich glaube ein sehr wichtiger ist einfach der, dass die meisten studierten Programmierer Informatiker (Mathematiker) sind. Da liegt das sehr mathematische Modell natürlich nahe.

Zeus

volkard schrieb:

Zeus schrieb:

Außerdem ist Java keine pure objektorientierte Programmiersprache.

"pur objektorientiert" gibt es nicht.

Begründet oder erklärt durch?

Mr. N

Lieber Funktional als Tod schrieb:

Prozesse beschreiben, oder Objekte darstellen geht in rein funktionalen Programmiersprachen genauso gut, wie Funktionen beschreiben in "rein" Objektorientierten Sprachen mit "Objekt.Methode(Parameter)-Syntax". Ein Prozessor führt Prozesse aus (Prozedurale Programmierung), in Software müssen meistens realitätsnahe Objekte dargestellt werden (Objektorientierte Programmierung).

Ich denke, "realitätsnahe Objekte" lassen sich in guten funktionalen Programmiersprachen auch sehr gut darstellen.

Nicht, dass es keine guten Gründe für funktionale Programmierung gäbe, aber ich glaube ein sehr wichtiger ist einfach der, dass die meisten studierten Programmierer Informatiker (Mathematiker) sind. Da liegt das sehr mathematische Modell natürlich nahe.

Das kannst du mir zumindest nicht vorwerfen, da ich weder Informatik noch Mathematik studiere. (Das brauchen wir jetzt aber nicht vertiefen.)

Nexus

Mr. N schrieb:

Ich denke, "realitätsnahe Objekte" lassen sich in guten funktionalen Programmiersprachen auch sehr gut darstellen.

Findest du? Rekursion für Prozesse, die man in der Welt eigentlich nacheinander auf gleicher Ebene iterativ durchführt? Kein wirklicher Zustand, keine Variablen? Nahezu alles ist eine Funktion?

Meiner Meinung nach erfordert rein funktionale Programmierung ein spezielles Denken, das anfänglich viel weniger intuitiv als z.B. objektorientierte und prozedurale Programmierung ist.

Zeus

Ist dieses Konstrukt in einen reinen funktionalen Programmiersprache nicht möglich? (In Nano Syntax also für euch Pseudocode )

func printList<T>(arg :: []T -> void) {
	var size :: const int(32) := arg.length
	var current :: int(32) := 0

	func printIt(void -> void) {
		if (current > size) system.out.print(line := arg[current++])
	}		

	printIt()
}

SideWinder

@Zeus: Du scheinst ja mit dieser Sprache viel am Hut zu haben Gibt es da außer der SourceForge-Seite noch weitere Informationen?

MfG SideWinder

Zeus

Ich weiß auch nicht genau, was mich geritten hat, aber ich bin der Erfinder bzw. Schöpfer von dieses imaginäre Hobby-Programmiersprache, d.h. ich hab schon vor eine ein Spezifikation(min. EBNF) und Compiler zu bauen, nur ist alles noch in einem frühen Stadium. Da ich aber der Threadstarter bin, kannst du dir vorstellen, was ich damit erreichen wollte Jedenfalls ist es witzig, wie ich Ideen in meine Programmiersprache einbauen und im nächsten Moment möchte jemand anderes es gern auch in Eine haben - nicht nur in diesen Thread. Ich könnte eine Zusammenfassung von meine Ideen schreiben und auch hier posten, falls es dich so sehr interessiert, aber das zu ein späteren Zeitpunkt, sonst schleichen sich zu viele Rechtschreibfehler ein, dass es keiner lesen kann XD. Auf jeden Fall ist mein Marketing spitze meine Sourceforge Seite ist Top 1 auf Google.de und Google.com - haha.

SideWinder

Wär schon toll wenn du mir evtl. einen Link auf die EBNF und einen zusammenfassenden Absatz zu deiner Sprache reinstellen würdest. Vielleicht packt mich ja das Interesse

MfG SideWinder

Mr. N

Nexus schrieb:

Mr. N schrieb:

Ich denke, "realitätsnahe Objekte" lassen sich in guten funktionalen Programmiersprachen auch sehr gut darstellen.

Findest du? Rekursion für Prozesse, die man in der Welt eigentlich nacheinander auf gleicher Ebene iterativ durchführt? Kein wirklicher Zustand, keine Variablen? Nahezu alles ist eine Funktion?

Das stimmt so einfach nicht. Nein, man muss nicht alles mit Rekursion erledigen, in der Tat will man das auch nicht, da Rekursion sehr wenig abstrakt ist.

Zustand, Variablen gibt es auch. Allerdings eben in einer Abstraktion gekapselt:

do
  x <- newIORef 0
  modifyIORef x (+1)
  print =<< readIORef

Aber natürlich benutzt man sie nur dann, wenn man es für gut befindet. Man muss IORef nicht verwenden, und es ist nicht der Standard.

Es gibt auch schönere Abstraktionen für solche Dinge, siehe z.B. http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-State-Lazy.html

Meiner Meinung nach erfordert rein funktionale Programmierung ein spezielles Denken, das anfänglich viel weniger intuitiv als z.B. objektorientierte und prozedurale Programmierung ist.

Ich müsste leider lügen, wenn ich behaupten würde, ich hätte mir einfach damit getan, Haskell zu lernen. Aber vielleicht können bessere Lehrmaterialien das verbessern. "Real World Haskell" und "Learn you a Haskell" machen es inzwischen ja schon relativ einfach.

Zeus schrieb:

Ist dieses Konstrukt in einen reinen funktionalen Programmiersprache nicht möglich? (In Nano Syntax also für euch Pseudocode )
func printList<T>(arg :: []T -> void) {
	var size :: const int(32) := arg.length
	var current :: int(32) := 0
		
	func printIt(void -> void) {
		if (current > size) system.out.print(line := arg[current++])
	}		
		
	printIt()
}

Nicht, dass diese Funktion besonders sinnvoll wäre...

printList arg = do
  let size = length arg
  current <- newIORef 0
  return $ do
    c <- readIORef current
    when c < size $ do
      print (arg !! c)
      writeIORef current (c + 1)

volkard

Mr. N schrieb:

Nein, man muss nicht alles mit Rekursion erledigen, in der Tat will man das auch nicht, da Rekursion sehr wenig abstrakt ist.

Das gefällt mir auf der humoresken Ebene. Ich nehme es gleich mal in meine Sig auf.

*john 0

thatway schrieb:

Ist wohl sinnlos mit dir, kommen ja doch nur verlogene Unterstellungen.

Es ist immer wieder schön zu sehen, daß Personen denen die Argumente ausgehen, dann automatisch auf persönliche Angriffe umstellen.

Zu Thema Multiple Inheritance zurück:
Als erster wäre hier "The Design an Evolution of C++, Bjarne Stroustrup, 1994" als Quelle zu nennen. Es findet sich reichhaltiges Material pro MI im Buch.
Dann ist da noch "Objektorientierte Analyse und Design, Grady Booch, 1994" zu nennen. MI wird zwar selten benötigt, wenn man sie braucht vereinfacht sie das Design deutlich. Die Gegner von MI kommen meistens aus dem Smalltalk Lager. Smalltalk "löst" das Problem via duck typing, hier wird eine implizite Abhängigkeit erzeugt, die die Abhängigkeit zwischen den Klasse nur verschleiert, aber sie nicht wirklich auflöst.

~john schrieb:

thatway schrieb:

Ist wohl sinnlos mit dir, kommen ja doch nur verlogene Unterstellungen.

Es ist immer wieder schön zu sehen, daß Personen denen die Argumente ausgehen, dann automatisch auf persönliche Angriffe umstellen.

~john schrieb:

thatway schrieb:

Wenn Du nicht weißt wie man das richtig entwirft, mach dafür nicht Deine Mitmenschen verantwortlich. Es gibt mittlerweile eine reichhaltige Entwurfsmusterliteratur, darin kannst Du solche Grundlagen nachlesen.

Ist wohl sinnlos mit dir, kommen ja doch nur verlogene Unterstellungen.

Wer greift da wen persönlich an?

~john schrieb:

Zu Thema Multiple Inheritance zurück:
Als erster wäre hier "The Design an Evolution of C++, Bjarne Stroustrup, 1994" als Quelle zu nennen. Es findet sich reichhaltiges Material pro MI im Buch.

Du meinst jetzt aber nicht dieses Terminal Task Displayed Beispiel? Gabs nicht auch schon vor nem viertel Jahrhundert MVC?

Da muss ich dann doch knivil recht geben.

knivil schrieb:

Next Generation Programmiersprache? Und alle labern von C++, Qt und ueber Vergangenheit.

Mr. N

volkard schrieb:

Mr. N schrieb:

Nein, man muss nicht alles mit Rekursion erledigen, in der Tat will man das auch nicht, da Rekursion sehr wenig abstrakt ist.

Das gefällt mir auf der humoresken Ebene. Ich nehme es gleich mal in meine Sig auf.

Ich hab darüber dann gestern noch mit denis (Dr. Greenthumb) diskutiert... Nehmen wir z.B. die Summenfunktion, diesmal zur Abwechslung in Scheme.

Vergleiche die rekursive Version

(define (sum xs) (if (null? xs) 0 (+ (car xs) (sum (cdr xs)))))

mit der Higher-order function-Version

(define (sum xs) (fold-left + 0 xs))

Welche ist abstrakter?

volkard

Es gibt gute Abstraktion und böse Abstraktion. Du bis zur dunklen Seite der Macht gewechselt, fürchte ich.

Je mehr die Leute Sprachen studieren, statt sie praktisch einzusetzen, desto realitätsfremder werden sie anscheinend.

Mr. N

volkard schrieb:

Es gibt gute Abstraktion und böse Abstraktion. Du bis zur dunklen Seite der Macht gewechselt, fürchte ich.

Dann gibt es wohl mehrere dunkle Seiten, ich dachte immer, das hier sei die dunkle Seite der Macht: http://www.springsource.org/

Im Ernst, was ist "gute" und was ist "böse" Abstraktion? Das musst du mir erläutern, fürchte ich.

SideWinder

Das mit Spring musst du mir jetzt aber erklären, habe gerade ein Projekt mit Spring hinter mir und kann es bis jetzt nur empfehlen. Wobei hier auch weit nicht alle Teile des Frameworks eingesetzt wurden.

MfG SideWinder