NG Programmiersprache?

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

Mr. N

SideWinder schrieb:

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.

http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12

volkard

Mr. N schrieb:

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

Ich bevorzuge da Sachen, die weniger abstrakt als Rekursion sind.

summe=0
foreach i in xs
  summe+=i

Manchmal (besonders wenn man Hochschulprofessor ist) baut man auch mal was rekursiv.

fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

Gute Abstraktion. Jetzt steht das Zeug auch recht hübsch und übersichtlich da.

Aber dann kommt einer, dem ist das doch nicht abstrakt genug, denn man kann ja noch fast den erzeugten Code erahnen, und er baut

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Böse Abstraktion.

Zeus

@SideWinder

Ein kleiner Überblick über Nano:

http://nano-lang.git.sourceforge.net/git/gitweb.cgi?p=nano-lang/nano-lang;a=blob;f=doc/Overview_Nano_De.pdf;h=32a7c491961c326a240fbd09ef28e3048377fc3d;hb=f3aa242

Die EBNF-Spezifikation:

http://nano-lang.git.sourceforge.net/git/gitweb.cgi?p=nano-lang/nano-lang;a=blob;f=spec/nano.spec;h=55db54c87dfa8d86e31847cb0eda5c4cd3a5a70a;hb=f3aa242

Mr. N

volkard schrieb:

Manchmal (besonders wenn man Hochschulprofessor ist) baut man auch mal was rekursiv.
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
Gute Abstraktion. Jetzt steht das Zeug auch recht hübsch und übersichtlich da.

Aber dann kommt einer, dem ist das doch nicht abstrakt genug, denn man kann ja noch fast den erzeugten Code erahnen, und er baut
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
Böse Abstraktion.

Das zweite ist natürlich performanter, wenn man die ganze Liste will.

Wobei ich - bitte nicht glauben, dass ich den Code hübsch fände - da noch eins draufsetzen kann:

fix $ ([0,1] ++) . (zipWith (+) <*> tail)

SideWinder

Zeus schrieb:

@SideWinder
Ein kleiner Überblick über Nano:
[...]

Vielen Dank, hast du die Zusammenfassung extra für mich gemacht oder erst gestern ins Repository hochgeladen?

Bin von einigen Dingen begeistert, aber bspw. die Begrenzung auf Rekursion als einzig iteratives Element will ich nicht wahrhaben

MfG SideWinder

Mr. N schrieb:

volkard schrieb:
Manchmal (besonders wenn man Hochschulprofessor ist) baut man auch mal was rekursiv.
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
Gute Abstraktion. Jetzt steht das Zeug auch recht hübsch und übersichtlich da.

Aber dann kommt einer, dem ist das doch nicht abstrakt genug, denn man kann ja noch fast den erzeugten Code erahnen, und er baut
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
Böse Abstraktion.
Das zweite ist natürlich performanter, wenn man die ganze Liste will.

Warum soll das performanter sein?

Zeus

SideWinder schrieb:

Vielen Dank, hast du die Zusammenfassung extra für mich gemacht oder erst gestern ins Repository hochgeladen?

Ich hab sie auf Anfrage für dich und alle Lauscher gemacht

SideWinder schrieb:

Bin von einigen Dingen begeistert, aber bspw. die Begrenzung auf Rekursion als einzig iteratives Element will ich nicht wahrhaben
MfG SideWinder

Yo mal sehen