Die Programmiersprache Ruby

Blog|

Forum|

Wiki  


Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]

Ein neues Thema erstellen Auf das Thema antworten  [ 63 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 14:53 
Offline
ri
Benutzeravatar

Registriert: 04 Okt 2005, 10:42
Beiträge: 740
Wohnort: Wien
Gekko hat geschrieben:
...es gibt aber sicher auch die Möglichkeit auf den Typ des Parameters zu prüfen, das werd ich mir heute noch mal ankucken:



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace parameterswitch

import System
import System.Collections

def switch(arg):
if arg isa string:
print "argument ist ein string."
elif arg isa int:
print "argument ist ein integer."
else:
print "argument ist irgendwas anderes."

switch("1")
switch(1)
switch(1.0)

/* Ausgabe:
argument ist ein string.
argument ist ein integer.
argument ist irgendwas anderes.
*/


Jupp, geht :lol:


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 15:48 
Offline
Rubyist

Registriert: 26 Apr 2006, 21:35
Beiträge: 366
Gekko hat geschrieben:


1
2
3
4
5
6
7
8
9
10
11
namespace helloworld

import System
import System.Collections

def doppelt(number as int):
return number * 2

list = map([1,3,5,7],doppelt)
print join(list)
// Ausgabe: "2 6 10 14"






1
2

(map (lambda (x) (* x 2)) '(1 3 5 7)) ; => (2 6 10 14)


Das soll kein vergleich sein, in ruby geht es ja ähnlich kurz und
in anderen sprachen auch. Mir ist nur aufgefallen dass ich bei
meinen blicken über den tellerand zunehmend zurück blicke
und mir mehr und mehr auffällt wie sehr mir das eigentlich gefällt
was ich sehe. Simple und effektiv. Back to the roots.

greets

_________________



 callcc{|xx| callcc{|yy| lambda{|zz| zz}[yy]}[xx]}["Love Ruby but adore Scheme"]

Solve it once, adapt it to your needs => Schnipsel


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 18:43 
Offline
ri
Benutzeravatar

Registriert: 04 Okt 2005, 10:42
Beiträge: 740
Wohnort: Wien
Ich highjacke meinen eigenen Thread für Boo...
Falls wer was dagegen hat: Ups :oops:

azuby hat geschrieben:
Wenn ich nun einen String "doppelt" haben will, was dann in Boo? Muss ich dann noch eine zweite Methode tippen?


Boo hat einen Ententyp 8) (Was hab ich gelacht, als ich das aus der Doku herausgelesen habe!)


1
2
3
4
5
def doppelt(arg as duck):
return arg * 2

liste = map([1,"Gekko",5.1],doppelt)
print join(liste)

Ausgabe:



2 GekkoGekko 10.2


Somit müsste glaube ich die Frage vollends geklärt sein.

Anmerkungen: Wenn man Boo als Interpreter verwendet (also entweder in Booish - den Irb Verschnitt - oder wirklich als Script), dann sind alle Variablen, wenn nicht anders deklariert vom Typ duck. Wenn man allerdings das Boo-Programm kompilieren will, dann funktioniert es folgendermassen:


1
2
3
4
i = 1
// i ist automatisch als Integer deklariert, kann _nicht_ im Scope umdeklariert werden.
a = "stringblabla"
// a ist jetzt ein String usw. usf.

D.h. der Parser werkt da irgendwie so was wie "halbdynamisch".
Erst wenn man definitiv sagt:


1
2
3
a as duck
a = 1
a = "bla"

kriegt man keine Fehlermeldungen um die Ohren geschmissen. Im Interpretermodus ist das wie gesagt egal, da verhält sich alles wie der Typ duck.

Also ich muss echt sagen, ich find das Konzept gar nicht mal so schlecht.


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 22:02 
Offline
Geselle

Registriert: 06 Jul 2006, 09:54
Beiträge: 149
Die Welt außerhalb des eigenen Tellers ist immer interessant und über Programmiersprachen diskutieren ebenfalls... ;) Ein paar Kommentare zu dem bisherigen Thread...

Wenn es darum geht, Konzepte von Programmiersprachen zu studieren, würde ich besondere Programmiersprachen auswählen.

Boo würde ich nicht wählen, da dieses zu nah an Python und VisualBasic liegt. Vielleicht habe ich die Sprache nicht genug studiert, aber das einzige, was anders als bei Python ist, ist das optionale statische Typsystem - und das ist mit dem von VisualBasic vergleichbar. Auf mich wirkt es zudem, dass die Aufgabe, ein korrektes & vollständiges Typsystem zu entwickeln, unterschätzt und etwa naiv angegangen wird. Das macht mich misstrauisch. Zudem wird das Typsystem mit dem IMHO falschen Grund motiviert. Sie sagen, statische Programme sind schneller. Das ist so pauschal falsch. Sie sind nur einfacher schneller auszuführen, will sagen, man braucht einen nicht so schlauen Compiler. Wie auch immer, ein besserer Grund wäre die bessere Dokumentation von Schnittstellen, Interaktion mit .NET oder IDE-Unterstützung (in dieser Reihenfolge).

SharpDevelop ist glaube ich die Windows-Version, aber ihre Schwester, MonoDevelop, integriert nicht nur Boo, sondern auch Nermele. Dies ist eine objekt-funktionale Programmiersprache in der Tradition von O'Caml aus Polen. IMHO deutlich interessanter als Boo, wenn es um die Konzepte geht. Die Syntax ist aber - da absichtlich C#-ähnlich - ausgesucht häßlich.

Es wurde Objective-C erwähnt: Ich würde lieber vorschlagen, das Original, Smalltalk, zu studieren. Schließlich ist Objective-C der (gelungene) Versuch gewesen, die Konzepte von Smalltalk in C zu integrieren. Gerade für Ruby-Kenner sollte Smalltalk sehr vertraut wirken (jedenfalls wenn man sich an die Syntax gewöhnt hat), da Ruby fast als Smalltalk mit anderer Syntax angesehen werden kann.

Daher ist Smalltalk vielleicht nicht so spannend, wenn man etwas anderes kennenlernen möchte. Self ist eine aus Smalltalk abgeleitete OO-Sprache ohne Klassen, die ich persönlich als ein Highlight ansehe. NewtonScript, das Konzept von Self mit Pascal-Syntax kennt wahrscheinlich niemand, aber JavaScript sollte dem einen oder anderen bekannt vorkommen. Self war auch hier Vorbild. Die Sprache Io von Steve Dekorte ist eine moderne Version einer prototyp-basierten Sprache. Self mit Multimethoden gekreuzt ist Cecil, ein weitere interessante Sprache.

Multimethoden sind ein interessantes Konzept. CommonLisp hat sie, aber auch Dylan. Cecil und Goo sind zwei unbekannte Sprachen, die Self bzw. Scheme mit Multimethoden mischen - beide sind prototypbasiert.

Vielleicht lohnt auch ein Blick auf Guy Steeles neue Sprache: Fortress. Meines Wissens gibt es noch keinen Compiler dafür und nur eine halbfertige Sprachspezifikation. Doch es ist interessant, wie er sich das Fortran des dritten Jahrtausend (meine Worte, nicht seine) vorstellt. Es hat z.B. traits, eine weitere Erfindung von Self. Scheme, ein einfaches Lisp von Steele und Susmann ist eigentlich Pflicht zu kennen.

Oder wenigstens ML als einfache funktionale Sprache. O'Caml ist eine relativ (ist nicht alles relativ) beliebte objektorientiere Variante von Standard-ML. Noch spannender ist aber vielleicht Alice. Nicht nur der Name - und der offensichtliche Bezug zum Wunderland - ist bemerkenswert, sondern auch deren Möglichkeiten nebenläufiger Programmierung. Ansonsten ist sicherlich Haskell als Sprache mit träger Auswertung (auch call by need genannt) etwas, das bemerkenswert und untersuchenswert ist.

Nein, alle diese Sprachen haben keine wirkliche praktische Bedeutung neben Java, C#, usw. aber darum ging es doch nicht, oder?

Daher: Wer's wirklich exotisch haben will, und APL oder J, K und wie dessen Varianten noch heißen für zu gewöhnlich hält (diese Sprachen haben alle als Besonderheit Vektoroperationen) der schaue sich mal Joy an. Das ist ein funktionales Forth. Bemerkenswert ist nicht nur die Rekursionstheorie dazu, sondern auch das - wenn ich richtig informiert bin - der Author vorher die anderen Sprachen nicht kannte. Ähnlich wie bei Forth - wo Moore auch nichts von dem bisherigen Stand der Technik wusste und einfach nur ein Radioteleskop steuern wollte - ist das so ein neue Blick auf alte Themen. Cat ist eine andere funktionale Stack-Sprache, die von Joy inspiriert wurde und "zufällig" recht gut auf die .NET-VM abbildbar ist.

Das erwähnte Groovy finde ich wieder recht unspannend, da dies einfach ein Ruby-Bastard mit wenig neuen Ideen ist. Okay, Ruby hat eigentlich auch keine (oder wenige) neue Ideen, doch irgendwie finde ich Ruby elegant und Groovy, nun, dass kann sich nicht entscheiden, ob es aussehen will wie Java oder doch wie Ruby oder lieber etwas ganz anderes.

Was mich bei Boo wundert ist, dass map keine Methode des []-Array ist. Ist die Sprache eher funktional bzw. prozedural statt objektorientiert?

Dem Scheme-Beispiel kann ich ja noch eine Variante in Haskell beifügen, die noch etwas kürzer ist, weil man die anonyme Funktion nicht explizit hinschreiben muss


map (*2) [1,3,5,7]


Wenn's um funktionale Sprachen speziell für die JVM oder .NET geht, sind F# und Scala noch erwähnenswert. Letztere gibt es für beide Plattformen und es ist eine elegante (die Syntax ist ein bisschen wie Python und Ruby) objekt-funktionale Compilersprache mit statischem Typsystem, der die gesamte Java- bzw. .NET-Bibliothek offen steht. C# 3.0 wird in dieser Beziehung aber auch recht gut sein.

Oh, noch ein paar kommerzielle Exoten gefällig: REBOL ist eine prefix-Sprache (genau wie Lisp aber ohne Klammern, also wie Logo) und hat einige interessante Konzepte übernommen - etwa das Code = Data ist. Curl ist eine aus T, einem Scheme-Dialekt entstandene Sprache, die versucht hat, HTML, CSS, usw. neu zu erfinden und eine einheitliche Syntax für Server und Client zu definieren. Eigentlich die richtige Idee, aber IMHO zu spät und eben kommerziell gewesen.

Schließlich fällt mir noch E ein, eine Sprache, die capability-basierte Sicherheitskonzepte integriert. IMHO sehr interessant, aber deren Webseite ist unaufgeräumt und wirkt überholt wenn nicht veraltet. Die Konzepte sind nichts desto trotz sehr interessant und selbst ohne das ist die Sprache eine nette aussehende funktionale Sprache, wo ich sympatisch finde, dass neue Methoden genau wie bei Logo mit "to" definiert werden.

Ich erwähnte schon nebenläufiges Programmieren: Erlang (eine funktionale Sprache mit Prolog-Syntax) ist hier ein Meilenstein. Es gibt auch einen Scheme-Dialekt namens Termite, der die selben Konzepte umsetzt. Ach, und Prolog ist natürlich auch durchaus studierenswert. Allerdings kann man das meist zusammen mit einer anderen Sprache wie Lisp, Scheme oder Smalltalk erledigen, da es eine gute Übung ist, einen Prolog-Interpreter in diesen Sprachen zu bauen.

Auch interessant sein soll Mozart/OS, doch das kenne ich (noch) nicht. Wer bei Haskell Monaden verstanden hat, kann sich ansonsten dort noch mal den Arrows widmen, ebenfalls ein Thema, zu dem ich leider nichts sagen kann.

Ansonsten: Zu einfachen prozeduralen Sprachen habe ich jetzt nichts weiter gesagt, weil hier eigentlich seit Algol-60 (das nach dem Erscheinungsjahr benannt ist) und Pascal (ca. 1972) nichts weiter zu vermelden ist.

Wer also auch dem Pragmatic Programmers Motto "lerne jedes Jahr eine neue Sprache" folgt, dem habe ich hier vielleicht einige Anregungen gegeben.

Stefan


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 22:20 
Offline
Rubyist

Registriert: 30 Mai 2006, 21:32
Beiträge: 324
Wow. Das ist einer schöner Abriss.

_________________
Gruß, Johannes Held


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 22 Aug 2006, 22:37 
Offline
ri
Benutzeravatar

Registriert: 02 Jun 2006, 23:18
Beiträge: 702
Hallo,

kleiner Tipp noch von mir, falls jemand von euch in Lisp reinschnuppern will: die Uni Trier bietet einen sehr schön umgesetzten, interessanten und noch dazu kostenlosen Online-Lisp-Kurs an.

Grüße,
Matthias


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 00:54 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
Na dann möchte ich auch noch mal drei Sprachen hinzufügen. Eine sehr alte, ihr Nachfolger und deren Erweiterung. Etabliert ist seit der ersten keine mehr, die ersten beiden haben allerdings viel beeinflusst, die erste ist sogar deutlicher Vorläufer der heutigen RegEx-Möglichkeiten (welche Art Sprachen habt Ihr von mir bitte sonst erwartet :wink: ), die zweite hat einige starke Besonderheiten bezüglich Generators und die dritte habe ich noch nicht benutzt, soll aber eine OO-artige Erweiterung der Zweiten sein.
  1. Snobol 4
    http://en.wikipedia.org/wiki/SNOBOL4
    http://c2.com/cgi/wiki?SnobolLanguage
    ftp://ftp.snobol4.com/vanilla.zip DOS-Version mit Einschränkungen.
  2. Icon
    http://en.wikipedia.org/wiki/Icon_programming_language
    http://www.cs.arizona.edu/icon/
  3. Unicon
    http://en.wikipedia.org/wiki/Unicon_programming_language
    http://unicon.sourceforge.net/
PS: Ganz vergessen habe ich natürlich noch eine andere Sprache, die der direkte echte (=implementierte und benutzte) Vorläufer von C war

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 03:23 
Offline
Lehrling
Benutzeravatar

Registriert: 26 Apr 2005, 15:14
Beiträge: 93
Wohnort: Hamburg
sma hat geschrieben:
für Ruby-Kenner sollte Smalltalk sehr vertraut wirken (jedenfalls wenn man sich an die Syntax gewöhnt hat), da Ruby fast als Smalltalk mit anderer Syntax angesehen werden kann.
Wieder mal einige "genial" informative Posts hier bei euch!!!!
Was fehlt Smalltalk denn? Die "Skriptfähigkeit"? Wozu war denn Ruby "nötig"?

P.S.:
sma=Smalltalk?

_________________
Programmers don't die,
they GOSUB
without RETURN.

Die drei Feinde des Programmierers?
Sonnenlicht, Frischluft und das unerträgliche Gebrüll der Vögel.

// A programmer's farewell
main()
{
print ("Goodbye World !);
end;
}


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 09:14 
Offline
Interpreter

Registriert: 29 Okt 2002, 14:25
Beiträge: 2137
WilhelmHH hat geschrieben:
Was fehlt Smalltalk denn?

Der Syntaxzucker.

_________________
Ruby-Mine

"Simplicity is the ultimate sophistication." Leonardo da Vinci


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 09:28 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
janfri hat geschrieben:
WilhelmHH hat geschrieben:
Was fehlt Smalltalk denn?

Der Syntaxzucker.

Fehlen muss man dabei aus jeweils ganz persönlicher oder Projektsicht sehen. Eine ähnliche Frage kam schon mal wegen Lisp auf, als diesbezüglich (praktisch) alle anderen Sprachen als überflüssig dargestellt wurden.

Wegen der Vollständigkeit kann man ja in allen Sprachen genau das gleiche machen, also wird es immer etwas Streit darüber geben, welche denn nun besser sein. Das ist allerdings überwiegend wie bei schöner, nämlich reine Geschmackssache.

Noch einmal der Hinweis: Es gibt für Kostenplanungen bei Projekten inzwischen über Jahrzehnte Aufzeichnungen, dass die Verwendung der Programmiersprache bei mindestens etwas grösseren Projekten eine völlig untergeordnete Rolle spielt.

btw - Etwas, was ich leider bei Ruby vermisse ist die Goal Directed Evaluation von Icon.

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 09:52 
Offline
Geselle

Registriert: 06 Jul 2006, 09:54
Beiträge: 149
WoNáDo hat geschrieben:
BCPL als Vorläufer von C

Dazwischen gab es auch noch B. Mehr Details: The Development of the C Language von der Konferenz HOPL II (History Of Programming Languages).

Stefan


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 10:05 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
sma hat geschrieben:
Dazwischen gab es auch noch B.

Richtig! - Nur wurde die nie in dem Sinne wie BCPL jahrelang wirklich benutzt. Ob der Vorgänger von BCPL, CPL (Compibed Programming Language), jemals benutzt wurde, weiss ich wiederum nicht.

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 10:43 
Offline
Geselle

Registriert: 06 Jul 2006, 09:54
Beiträge: 149
WilhelmHH hat geschrieben:
Was fehlt Smalltalk denn? Die "Skriptfähigkeit"? Wozu war denn Ruby "nötig"?

Wozu Ruby nötig war, kann sicher Matz am besten erklären. Vielleicht hat er es sogar schon irgendwo getan. Ruby entstand meines Wissens, weil Matz mit Perl nicht glücklich wurde.

Über die Frage "Was fehlt Smalltalk denn?" - kann man wahrscheinlich länger philosophieren. Ich biete mal einige mögliche Gründe ohne besondere Reihenfolge:
  • Die Syntax ist für Leute, die C oder Pascal kennen recht ungewöhnlich (albernes Argument, wird aber immer wieder genannt)
  • Smalltalk kennt (ursprünglich) kein Dateisystem, keine getrennt zu übersetzenden Einheiten, alles ist in einem "Image" (Speicherabzug) gespeichert
  • Smalltalk kennt (ursprünglich) kein Modulsystem, es ist ein Ein-Mann-Programmiersystem für den "personal computer".
  • Die Interaktion mit anderem Code ist nicht vorgesehen, da Smalltalk ursprünglich als Betriebssystem (ähnlich wie eine Lisp-Maschine) entwickelt wurde
  • Smalltalk-80 war kommerziell und sehr teuer
  • Der damalige Chef von ParcPlace, dem größten Smalltalk-Anbieter, hatte 1995 oder 1996 voreilig Smalltalk als tot erklärt und angekündigt, die Firma auf Java auszurichten. Das tötete nicht Smalltalk, aber ParcPlace...
  • "Moderne" Smalltalk-Systeme wie Squeak haben ein echt gewöhnungsbedürftiges UI und die Entwickler IMHO noch nicht einmal für 10 cent Gespür für ein gutes funktionales UI.
  • Man hat sich Mitte der 90er (da war die Sprache 15 Jahre alt) auf überlegenen Konzepten und Werkzeugen ausgeruht und die "jungen Wilden" unterschätzt bzw. ignoriert.
Für den Einsatzbereich von Ruby ist bei Smalltalk wahrscheinlich das größte Problem, dass es keine Scripte gibt. Smalltalk ist nicht einfach eine Programmiersprache, es ist eine komplette Entwicklungsumgebung, die man nicht von der Sprache trennen kann. In der Sprache gibt es beispielsweise keine Syntax, um neue Klassen anzulegen und ihnen Methoden zuzuordnen. Dies geschieht in der IDE.

Okay, man könnte


1
2
3
4
5
Object 
subclass: #Person
instanceVariableNames: 'name age'
classVariableNames: ''
category: 'example'

manuell hinschreiben, aber das ist umständlich, wenig deklarativ und niemand hat sich in 20+ Jahren die Mühe gemacht, die Methode anders zu nennen, weil es ja immer die IDE gab. Und für Methoden gibt es überhaupt keine Syntax-Alternative (nur ein fileout-Format).

Da die Sprache keine deklarativen Anteile hat, ist es auch unmöglich, ein Smalltalk-System in der Sprache zu bootstrappen. Das Image, in dem Quasi seit den frühen 70ern ein Smalltalk-System läuft, das niemals beendet wird - nur ab und zu beim Speichern eingefroren - enthält ein Geflecht aus Smalltalk-Objekten, das nicht deklarativ erfassbar. Doch was red ich, Ruby hat exakt das selbe Problem und hier wurde es einfach dadurch gelöst, dass der Teil in C geschrieben und gottgegeben ist.

Eine interessante Eigenschaft der Sprache Self - ein quasi zusammengestrichenes und damit interessanterweise mächtigeres Smalltalk - ist, dass sie fast aus dem Nichts bootstrapbar ist. Self kann damit aus Dateien - Scripten - starten und selbst Scripte haben. Self hat aber eine minimalistische Syntax, die selbst mir schwer zu lesen fällt. Auch Self braucht eigentlich seine grafische IDE, um wirklich benutzbar zu sein.

Ich möchte aber nicht schließen, ohne die Syntax von Smalltalk-80 vorgestellt zu haben. Damit man sieht, was geht und was nicht geht.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
         method = messagePattern [temporaries] [statements].
messagePattern = unarySelector | binarySelector name | keywordSelector.
unarySelector = name.
binarySelector = operator.
keywordSelector = {keyword name}+.
keyword = name ":".
temporaries = "|" {name} "|".
statements = expression { "." expression} ["^" expression].
expression = assignment | primary | messageExpr | cascadedMsgExpr.
assignment = name ":=" expression.
primary = literal | name | block | "(" expression ")".
literal = number | symbol | string | array.
symbol = "#" (name | operator | string).
array = "#" "(" {literal} ")".
block = "[" [blockPattern] [temporaries] [statements] "]".
blockPattern = {":" name}+ "|".
messageExpr = unaryExpr | binaryExpr | keywordExpr.
unaryExpr = unaryCont unarySelector.
binaryExpr = binaryCont binarySelector unaryCont.
keywordExpr = binaryCont {keyword binaryCont}+.
unaryCont = primary | unaryExpr.
binaryCont = unaryCont | binaryExpr.
cascadedMsgExpr = messageExpr {";" cascadeCont }.
cascadeCont = unarySelector | binarySelector unaryCont
| {keyword binaryCont}+.

Die Grammatik ist mehrdeutig und hat ein paar offene Enden, aber bemerkenswert ist, dass es hier nur um das Definieren von Methoden und das Senden von Nachrichten geht. Smalltalk kennt keine Syntax für Bedingungen oder Schleifen, denn alles ist in der Sprache selbst ausdrückbar.


1
2
a = 0 ifTrue: [
[a < 10] whileTrue: [a := a + 1]]

ifTrue: und whileTrue: sehen zwar wie Anweisungen aus, sind aber auch nur Schlüsselwortnachrichten, die in der Klasse Boolean bzw. BlockClosure definiert sind (das ist anders als bei Lisp, wo zwar "special forms" auch wie normale Funktionsaufrufe aussehen, es aber nicht sind).

WilhelmHH hat geschrieben:
sma=Smalltalk?

Nein, das ist reiner Zufall... ich habe allerdings fast 6 Jahre beruflich mit Smalltalk entwickelt und vielleicht hat da was abgefärbt :)

Stefan


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 13:28 
Offline
Interpreter

Registriert: 15 Mär 2005, 19:26
Beiträge: 6142
Wohnort: Karlsruhe
sma hat geschrieben:
Für den Einsatzbereich von Ruby ist bei Smalltalk wahrscheinlich das größte Problem, dass es keine Scripte gibt. Smalltalk ist nicht einfach eine Programmiersprache, es ist eine komplette Entwicklungsumgebung, die man nicht von der Sprache trennen kann.

Uff, das ist natürlich ein Killer-Kriterium für viele (=meine 8) ) Anwendungen.

Nichts desto trotz wollte ich mich schon vor einigen Jahren Ende der 90er mal mit Smalltalk auseinandersetzen, kaufte mir das Buch Smalltalk, Sprache, Klassen und Programmierwerkzeuge, 2. Auflage, Addison-Wesley - und war verwirrt und entsetzt.

Zuerst einmal wegen des Buches, welches teilweise recht chaotisch aufgebaut ist. Auf Seite 144 wird beispielsweise wegen der Iteratoren do, collect, etc. auf ein früheres Kapitel Elementare Sprachelemente verwiesen, welches es nicht gibt, und im Index wird Seite 144 als erstes Auftreten von do und collect genannt - derartiges zieht sich durch das ganze Buch.

Dann habe ich, wahrscheinlich dem Stil des Buches entsprechend, keine Sprachübersicht oder ähnliches gefunden => Erster Frust.

Nun zu Smalltalk, welches ich über das Buch kennengelernt (naja) habe - besser gesagt, zu den Smalltalks.

Dem Buch liegt eine CD bei, auf der Evaluationsversionen mehrerer Implementierungen sind. Das sind Smalltalk/V 2.0 für WIN16, SMALLTALK/V 2.0 für WIN32, VisualSmalltalk 3.0 ParcPlace-Digitalk, VisualAge 3.0 von IBM und VisualWorks von PArcPlace-Digitalk.

Warum diese Aufzählung? - Weil das Buch auf praktisch jeder Seite die selbst in Basiselementen abweichende Syntax der einzelnen Implementierungen beschreibt.

Wie man sich unschwer denken kann, klassifizierte ich das Buch als nicht lesenswertes Wurfgeschoss und Smalltalk als inkonsistente nicht-nutzbare Sprache zum spielen.

Das vor allem, weil ich nach freier Dokumentation und unter Windows verfügbaren freien Implementierungen suchte - und - nichts fand. Irgendwelche Gelder für das Ausprobieren einer Sprache bin ich nicht bereit zu investieren.

Nun habe ich heute für meine monatlich regelmässige mehrstündige Warterei in der Poliklinik dieses Buch mitgenommen - dieser Thread hat mich animiert wenigstens noch einmal reinzuschauen.

Meine Fragen blieben allerdings nach wie vor ungeklärt.

1. Gibt es vernünftige Standarddokumentation zu Smalltalk (gibt es überhaupt einen Standard / eine Referenzimplementierung)?

2. Gibt es eine frei verfügbare (GPL oder so) Implementierung, die auch unter Windows (2000) läuft?

_________________
WoNáDo.set_state!(:retired)


Nach oben
 Profil  
 
 Betreff des Beitrags:
BeitragVerfasst: 23 Aug 2006, 13:45 
Offline
Interpreter
Benutzeravatar

Registriert: 05 Jun 2005, 01:54
Beiträge: 3225
WoNáDo hat geschrieben:
1. Gibt es vernünftige Standarddokumentation zu Smalltalk (gibt es überhaupt einen Standard / eine Referenzimplementierung)?
Es gibt das GNU Smalltalk Manual, vielleicht hilft dir das weiter: http://www.gnu.org/software/smalltalk/g ... l/gst.html
"GNU Smalltalk is a Free (or Open Source) implementation that closely follows the Smalltalk-80 language as described in the book Smalltalk-80. GNU Smalltalk works great from the command line and has a minimal Graphical User Interface as well."
WoNáDo hat geschrieben:
2. Gibt es eine frei verfügbare (GPL oder so) Implementierung, die auch unter Windows (2000) läuft?
Wiederum Verweis auf GNU Smalltalk: http://www.gnu.org/software/smalltalk/smalltalk.html
Die Preisfrage ist jetzt natuerlich obs das schon wo vorkompiliert fuer Windows gibt, das hab ich naelich auf die schnelle nicht gefunden. Aber du kannst ja mal probieren ob du es mit MSYS kompilieren kannst.


Zuletzt geändert von cypher am 23 Aug 2006, 14:21, insgesamt 1-mal geändert.

Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 63 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach: