unübersichtliche Programmiersprache gesucht
Martin Lentzsch
Ich suche ein Programmiersprche die möglichst unübersichtlich ist und nicht
irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht annähernd so
aussieht.
Der Hintgrund hierzu ist folgender: Ich möchte einem Freund ein
Geburtstagsgeschenk machen was mit programmieren zu tun hat. Ich hatte mir dazu
gedacht die Seriennummer eines Amazon Gutscheines zu verschlüsseln. Irgendwie
muss ich ihm ja den Algorithmus zukommen lassen. Dies soll natürlich nicht so
ganz trivial sein. Da er aber beruflich und hobbymäßig programmiert scheiden die
o.g. Sprachen aus. Er ist auch fit in Java, JavaScript und Assembler.
Ich dachte da an etwas wie Cobol, Modula oder Fortran, wobei Modula auf den
ersten Blick ziemlich Pascal mäßig aussieht.
Gibts da nicht noch etwas interessantes?
Danke euch!!!
Gruß aus Berlin
Martin
--
You can only be young once, but you can be immature forever
mail to: martin (at) lentzsch. net
Spamfilter (at)=@ und Spaces löschen
Florian Hars
>Ich suche ein Programmiersprche die möglichst unübersichtlich ist und nicht
>irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht annähernd so
>aussieht.
Spontan fallen mit da Intercal, BrainF*ck und unlambda ein.
http://www.mines.edu/students/b/bolmstea/randlang/index.html hat mehr
davon.
Tsch�ss, Florian.
Florian Weimer
> Ich suche ein Programmiersprche die möglichst unübersichtlich ist und
> nicht irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht
> annähernd so aussieht.
Warum nicht JCL? Oder S/360-Assembler?
Lutz Donnerhacke
>Ich suche ein Programmiersprche die möglichst unübersichtlich ist und
>nicht irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht
>annähernd so aussieht.
http://internet.ls-la.net/mirrors/99bottles/
Schau sie Dir alle an. Weitere Informationsquellen sind jeweils verlinkt.
>Irgendwie muss ich ihm ja den Algorithmus zukommen lassen. Dies soll
>natürlich nicht so ganz trivial sein. Da er aber beruflich und hobbymäßig
>programmiert scheiden die o.g. Sprachen aus. Er ist auch fit in Java,
>JavaScript und Assembler. Ich dachte da an etwas wie Cobol, Modula oder
>Fortran, wobei Modula auf den ersten Blick ziemlich Pascal mäßig aussieht.
>Gibts da nicht noch etwas interessantes?
Es bieten sich folgende Sprachen an:
Brainfuck, Blank, Bobo, Befunge, Befdc, CLOS, Boxer, Babbage's Analytical
Engine, Forth, False, Froth, dc, DSSP, M4, INTERCAL, Mops, M5, Mercury,
KidSim, LabVIEW, M-Speak, K, Luck, Perl, Prolog, [nt]roff, Prograph, Pilot,
Rapid, Plex (oder der Nachfolger Erlang), obj, Orthogonal, Postscript,
Snobol, Smalltalk, Tcl, SQL, VHDL, Trac, sed, Spitbol, vim, TeX, sendmail,
Haskell, Terse, TinTin, UltraMacros, Saul, Teco, ZZT oder Turing Maschine.
Besser ist es aber, die Lösung in Povray rendern zu lassen, so daß es erst
nach dem Rendern offensichtlich wird.
Noch besser ist es aber, die mathematischen Eigenschaften der Nummer zu
erkunden und dann nur durch ihre Beschreibung ein Rätsel zu stellen.
(Bsp: Der niedere Wert eines Primzahlzwillings, der eine primale
Zwillingkardinalität aufweist. Sedezimal geschrieben ist er
sechsstellig.)
Peter Ikier
Martin Lentzsch <madi...@web.de> writes:
> Hi Folks!
>
> Ich suche ein Programmiersprche die möglichst unübersichtlich ist und nicht
> irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht annähernd so
> aussieht.
Schau mal unter http://www.nyx.net/~gthompso/quine.htm ,
unter http://internet.ls-la.net/mirrors/99bottles/
oder unter http://www2.latech.edu/~acm/HelloWorld.shtml .
> Der Hintgrund hierzu ist folgender: Ich möchte einem Freund ein
> Geburtstagsgeschenk machen was mit programmieren zu tun hat. Ich hatte mir
> dazu gedacht die Seriennummer eines Amazon Gutscheines zu verschlüsseln.
> Irgendwie muss ich ihm ja den Algorithmus zukommen lassen. Dies soll
> natürlich nicht so ganz trivial sein. Da er aber beruflich und hobbymäßig
> programmiert scheiden die o.g. Sprachen aus. Er ist auch fit in Java,
> JavaScript und Assembler.
>
> Ich dachte da an etwas wie Cobol, Modula oder Fortran, wobei Modula auf den
> ersten Blick ziemlich Pascal mäßig aussieht.
Wie wäre es mit einem Forth-Ausdruck, der die Seriennummer berechnet?
So im Stil von
3 5 7 2 8 11 4 * + / - * + .
Bisschen peppig aufgemacht, könnte das doch ganz nett sein.
Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
Klammern um sich werfen.
> Gibts da nicht noch etwas interessantes?
Sicher, aber da du ja wohl den Algorithmus in der entsprechenden Sprache
schreiben mußt sollte sie zumindest für dich lernbar sein, oder?
Ansonsten würde ich mal INTERCAL oder BeFunge versuchen:
http://www.muppetlabs.com/~breadbox/intercal-man/home.html
http://www.mines.edu/students/b/bolmstea/mtfi/befunge-93.html
Ui, BeFunge gibt es sogar als Visual Befunge '93 für Windows!
http://home.wanadoo.nl/wimrijnders/bef.htm
Wieder was gelernt! ;-)
> Danke euch!!!
Gruß
pi
--
Wenn LISP-Programmierer eine Lösung zu einem Problem gefunden
haben, dann bauen sie einen großen Käfig aus Klammern drumherum,
damit die Lösung nicht wieder wegläuft, richtig?
[Nico Hoffmann in DeTeJott]
Andreas Bogk
> Wie wäre es mit einem Forth-Ausdruck, der die Seriennummer berechnet?
[...]
> Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
> Klammern um sich werfen.
Ich scheine wohl der einzige zu sein, der sowohl Forth als auch Lisp
für lesar hält...
Gruss Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Jochen Schmidt
> Peter Ikier <p...@cli.de> writes:
>
>> Wie wäre es mit einem Forth-Ausdruck, der die Seriennummer berechnet?
> [...]
>> Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
>> Klammern um sich werfen.
>
> Ich scheine wohl der einzige zu sein, der sowohl Forth als auch Lisp
> für lesar hält...
Nein wir sind nicht alleine... ;-)
ciao,
Jochen
Peter Ikier
Andreas Bogk <and...@andreas.org> writes:
> Peter Ikier <p...@cli.de> writes:
>
> > Wie wäre es mit einem Forth-Ausdruck, der die Seriennummer berechnet? [...]
> > Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
> > Klammern um sich werfen.
>
> Ich scheine wohl der einzige zu sein, der sowohl Forth als auch Lisp
> für lesar hält...
Neinnein, ich kann die auch lesen. Nur ein C/C++/Java-Programmierer (wie
der OP meinte vorzufinden) tut sich damit u.U. etwas schwerer.
Was nicht heißen soll, daß man in C keine unlesbaren Programme schreiben
kann... ;-)
BTW: Noch ne Idee:
Man könnte doch einen großen Karton nehmen, in Geschenkpapier wickeln
und die Seriennummer auf dem Geschenkband der Schleife in Morsecode
plazieren... 8-)
Gruß
pi
--
Ich bin immer für "ungewöhnliche" Geschenkverpackungen zu begeistern!
Florian Weimer
> Peter Ikier <p...@cli.de> writes:
>
>> Wie wäre es mit einem Forth-Ausdruck, der die Seriennummer berechnet?
> [...]
>> Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
>> Klammern um sich werfen.
>
> Ich scheine wohl der einzige zu sein, der sowohl Forth als auch Lisp
> für lesar hält...
Nein, sicherlich nicht. ;-)
Allerdings gibt es solches Forth und solches Forth.
Lutz Donnerhacke
>Ich scheine wohl der einzige zu sein, der sowohl Forth als auch Lisp
>für lesar hält...
Nein, aber die Lesbarkeitsdefinition des Beschenkten war doch gegeben.
Heiko Berges
>Ich suche ein Programmiersprche die möglichst unübersichtlich ist und nicht
>irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht annähernd so
>aussieht.
So richtig unübersichtlich? TECO. Das sieht eigentlich nichts ähnlich,
eher so, als ob eine Katze über die Tastatur gelaufen ist.
Heiko
michael paap
> So richtig unübersichtlich? TECO. Das sieht eigentlich nichts ähnlich,
> eher so, als ob eine Katze über die Tastatur gelaufen ist.
Uaah. Das sieht ja wirklich wüst aus. Dagegen ist Perl englischer
Klartext.
Auf http://www.cl-ki.uni-osnabrueck.de/~nntthele/be/teco.html findet
man:
Skript, das das aktuelle Datum und Uhrzeit einfügt:
!DATE.TES!EI^[[M[D[Y[W[H[M[S[0[1^BU0(Q0/32)&15UM(Q0)&31UD(Q0/512)UYQDUW
QM-2"=31%W'QM-3"=59%W'QM-4"=90%W'QM-5"=120%W'QM-6"=151%W'QM-7"=181%W'
QM-8"=212%W'QM-9"=243%W'QM-10"=273%W'QM-11"=304%W'QM-12"=334%W'QY&3"=
QW-59">1%W''QY+QW+(QY-1/4)U1Q1-(Q1/7*7)U1Q1"=^UWSUN^['Q1-1"=^UWMON^['
Q1-2"=^UWTUE^['Q1-3"=^UWWED^['Q1-4"=^UWTHU^['Q1-5"=^UWFRI^['Q1-6"=^UWSAT^['^H*2U0
Q0/3600UHQH*3600U1(Q0-Q1)/60UN(Q0-Q1)-(QN*60)US:GW32^TQM-10"<48^T'QM:=
47^TQD-10"<48^T'QD:=47^T1900+QY:=32^TQH-10"<48^T'QH:=58^TQN-10"<48^T'QN:=58^T
QS-10"<48^T'QS=]1]0]S]M]H]W]Y]D]M^[^[^M
Kann man Code in so einer Sprache nicht einfach durch die berühmten
Affen zufallsgenerieren lassen? Vielleicht macht der ja dann was ganz
tolles...
Gruß,
Michael
Friedrich Domincus
> Heiko Berges wrote:
>
> > So richtig unübersichtlich? TECO. Das sieht eigentlich nichts ähnlich,
> > eher so, als ob eine Katze über die Tastatur gelaufen ist.
>
>
> Uaah. Das sieht ja wirklich wüst aus. Dagegen ist Perl englischer
> Klartext.
> Auf http://www.cl-ki.uni-osnabrueck.de/~nntthele/be/teco.html findet
> man:
>
> Skript, das das aktuelle Datum und Uhrzeit einfügt:
>
> !DATE.TES!EI^[[M[D[Y[W[H[M[S[0[1^BU0(Q0/32)&15UM(Q0)&31UD(Q0/512)UYQDUW
> QM-2"=31%W'QM-3"=59%W'QM-4"=90%W'QM-5"=120%W'QM-6"=151%W'QM-7"=181%W'
> QM-8"=212%W'QM-9"=243%W'QM-10"=273%W'QM-11"=304%W'QM-12"=334%W'QY&3"=
> QW-59">1%W''QY+QW+(QY-1/4)U1Q1-(Q1/7*7)U1Q1"=^UWSUN^['Q1-1"=^UWMON^['
> Q1-2"=^UWTUE^['Q1-3"=^UWWED^['Q1-4"=^UWTHU^['Q1-5"=^UWFRI^['Q1-6"=^UWSAT^['^H*2U0
> Q0/3600UHQH*3600U1(Q0-Q1)/60UN(Q0-Q1)-(QN*60)US:GW32^TQM-10"<48^T'QM:=
> 47^TQD-10"<48^T'QD:=47^T1900+QY:=32^TQH-10"<48^T'QH:=58^TQN-10"<48^T'QN:=58^T
> QS-10"<48^T'QS=]1]0]S]M]H]W]Y]D]M^[^[^M
ROCA -Sprache
Read once, cry always ;-)
Salve
Friedrich
Janosch Zwerensky
>Ich suche ein Programmiersprche die möglichst unübersichtlich ist und nicht
>irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht annähernd so
>aussieht.
Eine triviale Lösung für dieses Problem bestünde darin, das Programm in einer
beliebigen Dir bekannten Sprache zu schreiben, für die Du einen Compiler hast,
und dem Bekannten dann ein Listing des vom Compiler zurückgegebenen
Assemblercodes zu überreichen.
Natürlich gibt es auch noch etliche "esoterische" Sprachen wie z.B. Brainf*ck,
die sich für Deine Zwecke gut eignen würden. Ich vermute allerdings, daß das
*Programmieren* in diesen Sprachen eine ähnlich schmerzhafte Erfahrung ist wie
das Entziffern bereits bestehender Programme (ob jemand mal einen Compiler
geschrieben hat, der eine aus Brainf*ck-Perspektive höhere Sprache dorthin
compiliert, weiss ich nicht *gg*).
Grüße,
Janosch.
Janosch Zwerensky
>Eine triviale Lösung für dieses Problem bestünde darin, das Programm in einer
>beliebigen Dir bekannten Sprache zu schreiben, für die Du einen Compiler hast,
>und dem Bekannten dann ein Listing des vom Compiler zurückgegebenen
>Assemblercodes zu überreichen.
Mir fällt gerade auf, daß das aus verschiedenen Gründen eine sehr schlechte
Lösung war *g*.
Möge das dem Vergessen anheim fallen.
Grüße,
janosch.
Janosch Zwerensky
>Uaah. Das sieht ja wirklich wüst aus. Dagegen ist Perl englischer
>Klartext.
>Auf http://www.cl-ki.uni-osnabrueck.de/~nntthele/be/teco.html findet
>man:
hmmm... allerdings kann man im Grunde in allen turing-vollständigen Sprachen
zu jeder gegebenen berechenbaren Funktion beliebig unübersichtlichen Code
produzieren, der diese Funktion berechnet *g*.
Für C finden sich entsprechende Beispiele etwa unter http://www.ioccc.org/ ;)
Grüße,
Janosch.
Lutz Donnerhacke
>Natürlich gibt es auch noch etliche "esoterische" Sprachen wie z.B.
>Brainf*ck, die sich für Deine Zwecke gut eignen würden. Ich vermute
>allerdings, daß das *Programmieren* in diesen Sprachen eine ähnlich
>schmerzhafte Erfahrung ist wie das Entziffern bereits bestehender
>Programme (ob jemand mal einen Compiler geschrieben hat, der eine aus
>Brainf*ck-Perspektive höhere Sprache dorthin compiliert, weiss ich nicht
>*gg*).
IIRC gibt es ein GCC Frontend für Brainfuck.
Tobias Kunze
> Ich suche ein Programmiersprche die möglichst unübersichtlich ist und
> nicht irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht
> annähernd so aussieht.
Nicht ganz so gemein wie die anderen genannten Vorschläge (Brainf*ck
und Konsorten), dafür aber mit klassischer Bildung:
Lingua::Romana::Perligata -- Perl in Latin
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
tobias
Georg Bauhaus
:
: !DATE.TES!EI^[[M[D[Y[W[H[M[S[0[1^BU0(Q0/32)&15UM(Q0)&31UD(Q0/512)UYQDUW
: QM-2"=31%W'QM-3"=59%W'QM-4"=90%W'QM-5"=120%W'QM-6"=151%W'QM-7"=181%W'
: QM-8"=212%W'QM-9"=243%W'QM-10"=273%W'QM-11"=304%W'QM-12"=334%W'QY&3"=
: QW-59">1%W''QY+QW+(QY-1/4)U1Q1-(Q1/7*7)U1Q1"=^UWSUN^['Q1-1"=^UWMON^['
: Q1-2"=^UWTUE^['Q1-3"=^UWWED^['Q1-4"=^UWTHU^['Q1-5"=^UWFRI^['Q1-6"=^UWSAT^['^H*2U0
: Q0/3600UHQH*3600U1(Q0-Q1)/60UN(Q0-Q1)-(QN*60)US:GW32^TQM-10"<48^T'QM:=
: 47^TQD-10"<48^T'QD:=47^T1900+QY:=32^TQH-10"<48^T'QH:=58^TQN-10"<48^T'QN:=58^T
: QS-10"<48^T'QS=]1]0]S]M]H]W]Y]D]M^[^[^M
ich find das viel zu regelmaessig. das wenigste waere, mit
unsinnstiftenden bezeichnern oder ideogrammen arbeiten zu
koennen :)
- georg
michael paap
> ich find das viel zu regelmaessig. das wenigste waere, mit
> unsinnstiftenden bezeichnern oder ideogrammen arbeiten zu
> koennen :)
Derlei Wünsche wundern mich bie jemandem, der den Doppelpunkt als
Quotezeichen benutzt, nicht im Mindesten. ;-)
Gruß,
Michael
Hannah Schroeter
In article <uit8vj...@cli.de>, Peter Ikier <p...@cli.de> wrote:
>[...]
>Evtl. auch Lisp (z.B. Emacs Lisp), da kann man so richtig schön mit
>Klammern um sich werfen.
Naja, eigentlich nicht. An den meisten Stellen sind keine
redundanten Klammern erlaubt.
Wenn Du in C also z.B.
1 + 2 * 3 oder 1 + (2 * 3) oder (((1)) + ((2) * 3))
schreiben kannst, kannst Du in Lisp (egal welcher Dialekt) so gut
wie nirgends einfach mal etwas eine Ebene mehr klammern.
Was natürlich geht ist in Common-Lisp z.B. die identity-Funktion
aufzurufen, also
(+ (identity 1) (identity (* (identity 2) 3)))
Aber das entspräche dann ja der Variante in C:
int identity(int x)
{
return (x);
}
... ((identity(1)) + (((identity)(2)) * 3)) ...
>[...]
Gruß,
Hannah.
Georg Bauhaus
: Derlei W?nsche wundern mich bie jemandem, der den Doppelpunkt als
: Quotezeichen benutzt, nicht im Mindesten. ;-)
keine spitzen (>) bemerkungen bitte, gleiche rechte fuer
alle satzzeichen! wir sind in d.c.l.misc :>
- georg
michael paap
> keine spitzen (>) bemerkungen bitte
Ich kann nicht anders... ;-)
Sag mal, besteht zwischen der Verwendung totaler Kleinschreibung und
Deinem Nachnamen ein Zusammenhang, oder ist das Zufall? *g*
Hmmm. Ob er das jetzt versteht? Wer weiss... na gut: Erklärung weiter
unten.
Gruß,
Michael
das bauhaus, gegründet 1919 von walter gropius in weimar als "hochschule
für bau und gestaltung" hatte sich zum ziel gesetzt, funktionalität und
materialbeschaffenheit zu einer neuen stilistischen einheit zu
verbinden. die gestaltung und das aussehen von produkten sollte sich von
dieser funktionalen aesthetik herleiten (daß das bauhaus 1933 aufgelöst
wurde, wird niemanden wundern). aus dieser zielsetzung heraus
propagierte das bauhaus u.a. auch die absolute kleinschreibung.
Georg Bauhaus
: Sag mal, besteht zwischen der Verwendung totaler Kleinschreibung und
: Deinem Nachnamen ein Zusammenhang, oder ist das Zufall? *g*
jA.
Werner Purrer
>
> Ich suche ein Programmiersprche die möglichst unübersichtlich ist und
> nicht irgendwie verwand ist zu C, Pascal, Basic oder so und auch nicht
> annähernd so
>
APL damit wirst Du sicher glücklich!
Werner Purrer
>
> Warum nicht JCL? Oder S/360-Assembler?
Mhh naja die Kriterien dürften wohl auf jeden Assembler zutreffen, solange
man sich relativ nahe an der Prozessorebene bewegt (aka keine künstlich
aufgesetzen prozeduren und schleifen sondern echte jumps, binäre vergleiche
von registern etc....)
Aber wie bereits gesagt, die bescheuertste Sprache die ich jemals in den
Händen hatte mit der man allgemeine Probleme lösen konnte war APL.
Georg Bauhaus
: Aber wie bereits gesagt, die bescheuertste Sprache die ich jemals in den
: H?nden hatte mit der man allgemeine Probleme l?sen konnte war APL.
Was ist denn an APL ernsthaft bescheuert?
gruesse,
georg
Florian Hars
> Was ist denn an APL ernsthaft bescheuert?
Eine aktuelle APL-Variante ist K, hier ist etwas Beispielcode:
http://groups.google.com/groups?as_umsgid=ava88.13862%24Hb6.1172043%40newsread1.prod.itd.earthlink.net&hl=en
Anders als APL benutzt K keine ausgefallenen Sonderzeichen.
Noch Fragen?
Tschüss, Florian.
Werner Purrer
>
> Was ist denn an APL ernsthaft bescheuert?
Gegenfrage musstest Du damit schon mal ein Programm erstellen.
Programmierung in APL würde in etwa einem Programm gleichkommen dass zu
100% in Regular Expressions geschrieben ist!
Lutz Donnerhacke
>Programmierung in APL würde in etwa einem Programm gleichkommen dass zu
>100% in Regular Expressions geschrieben ist!
Das ist einfacher als mit Markov Ketten (ala sendmail.cf).
Georg Bauhaus
: Anders als APL benutzt K keine ausgefallenen Sonderzeichen.
J auch nicht, und ist fuer nicht eingeweihte alles andere
als lesbar, wenn wir schon bei (vermutlich UNIX-)regular
expressions als moeglichkeit, programme zu schreiben, ankommen.
Uebrigens beides eine gute Empfehlung fuer den OP :-)
: Noch Fragen?
- Anders als APL/APL2/A+/J ist K da besonders gut, wo es um
verarbeitung von Daten-Serien geht, soweit ich weiss.
- in deinem sinn waere jeder nicht in ASCII kodierte operator
ein sonderzeichen und was ist wahrnehmungs-technisch nuetzlicher
als gute bilder und symbole? Insbesondere, wenn sie nicht x-mal
ueberladen sind (pro sprache). Guck dir buecher aus den 60er und 70er an,
textsatz vom feinsten, keine ASCII/BCD oder sonstwas ersatz-Darstellung.
- Jede gut sortierte Bahnstation, viele gebrauchsanleitungen
mit ihren bildchen geben genuegend unterstuetzung fuer diese
auffassung. Unkenntnis der bedeutung von geschickt gewaehlten
symbolen ist imA keine entschuldigung.
- Sonderzeichen...Wieso fassen wir eigentlich alles andere als
ca. 80 oder 90 Zeichen von 7-Bit ASCII als sonderzeichen auf? sonst tun
sich programmierer nicht so schwer, dinge wertfrei beim Namen
zu nennen.
gruesse,
georg
--
(P.S. sine necessitate: dieser text enthaelt keine umlaute weil
(a) das terminal entsprechend eingerichtet ist, (b) 8-bit nicht
mal in europa nicht ausgrenzt. o.K., vergesst die bemerkung.)
Georg Bauhaus
: Programmierung in APL w?rde in etwa einem Programm gleichkommen dass zu
Fuer einen Leser, der APL nicht gelernt hat?
Zusaetzlich zu dem, was Lutz angemerkt hat:
Gut, jedes endliche Programm ueber einem endlichen Alfabet kann
ich an einen endlichen automaten verfuettern, zB mit dem Ergebnis 0
oder 1, aber ich bezweifle, dass die maechtigkeiten von REs und
APL sich auch nur annaehernd decken. Wie sehen das IF und,
sagen wir, die Vorwaerts-Verzweigungen in REs aus, um mal mit was
einfachem anzufangen?
gruesse,
georg
Werner Purrer
>
> Fuer einen Leser, der APL nicht gelernt hat?
> Zusaetzlich zu dem, was Lutz angemerkt hat:
>
> Gut, jedes endliche Programm ueber einem endlichen Alfabet kann
> ich an einen endlichen automaten verfuettern, zB mit dem Ergebnis 0
> oder 1, aber ich bezweifle, dass die maechtigkeiten von REs und
> APL sich auch nur annaehernd decken. Wie sehen das IF und,
> sagen wir, die Vorwaerts-Verzweigungen in REs aus, um mal mit was
> einfachem anzufangen?
>
Ich will hier nicht die Sinnhaftigkeit von REs anzweifeln oder sie
schlechter oder besser machen als sie sind-ich hab sie nur als Synonym für
den Ansatz verwendet den APL versucht. Jeder kennt die Mächtigkeit von REs
und jeder ist schon mal vor dem Problem gestanden wie unleserlich eine RE
werden kann wenn man versucht alles auf einmal damit zu erschlagen.
Ich will sie aber nicht schlecht machen, ich verwende REs auch sehr oft,
aber APL so gut es auch ist bestimmte mathematische Probleme zu lösen, so
schwer ist es ein Programm dass damit geschrieben ist, zu verstehen. Bei
den REs geht es denn sie beschränken sich auf dass wass sie sollen,
Mustererkennung in Texten. Apl will da einfach viel mehr und versagt dann
komplett.
Während REs dass für Mustererkennung sein will was mathematische Operatoren
für andere Einsatzgebiete sind, versucht APL so ziemlich alles durch die
merkwürdigsten Operatoren zu erschlagen (Das Kennen des griechischen
Alphabets ist in diesem Falle sicher von Vorteil), was einfach der falsche
Ansatz ist. Ich geb aber zu für Matrizenoperationen oder ähnliches ist APL
hervorragend geeignet. Aber ein längeres Programm damit zu programmieren
würde ungefähr in die Richtung gehen ein Softwaresystem per endlicher
Automaten zu beschreiben!
Trotzdem man sollte APL mal gesehen haben damit man sieht dass der heute
als gegeben angesehene Konsens in den Sprachgruppen auch nicht natürlich
gewachsen ist und es viele Fehlversuche gab!
Es hat schon seinen Grund warum manche Sprachdesigner Überladene Operatoren
nicht besonders gerne haben, und APL betreibt den Einsatz von Operatorn zum
Exzess.
Werner Purrer
>
> - Sonderzeichen...Wieso fassen wir eigentlich alles andere als
> ca. 80 oder 90 Zeichen von 7-Bit ASCII als sonderzeichen auf? sonst tun
> sich programmierer nicht so schwer, dinge wertfrei beim Namen
> zu nennen.
Ich denke es geht hier weniger um den Einsatz von Symbolen-die sehr
aussagekräftig sein können wenn sie gut gemacht sind, sondern eher darum
dass bestimmte Sprachen diese zu exzessiv gebrauchen und damit die
Lernschwelle massiv in die Höhe treiben und die Übersichtlichkeit stark
eindämmen. Irgendwie erinnert mich das an den Vergleich des
römischen/griechischen Alphabets mit dem Chinesischen.
Prozedurale und OO Sprachen versuchen aus wenigen Grundelementen
(Lexikalische Elemente/Token) größere Einheiten zu bilden die aufgrund der
einfach Basis leichter erfasst werden können, so wie die westlichen
Alphabete es mit den Worten machen.
Sprachen wie APL versuchen alles in die Basis zu fassen, sodaß diese
entsprechend groß und schwer zu fassen ist so wie es Asiatische Alphabete
machen!
Welcher Ansatz der bessere ist, das wollen wir mal dem Anwender überlassen!
Aber ich denke die seit etwa 10 Jahren gehende Diskussion pro und contra
Operator Overloading sollte auch mal in diese Richtung überdacht werden!
Georg Bauhaus
: Ich denke es geht hier weniger um den Einsatz von Symbolen-die sehr
: aussagekr?ftig sein k?nnen wenn sie gut gemacht sind,
aber gilt das nicht fuer jeden bezeichner?
: sondern eher darum
: dass bestimmte Sprachen diese zu exzessiv gebrauchen und damit die
: Lernschwelle massiv in die H?he treiben und die ?bersichtlichkeit stark
: eind?mmen.
Also es kommt schon darauf an was gelernt werden soll, wer die
Schleifen-Syntax von Pascal kennt, kann deswegen noch nicht
zwei Vektoren darstellen und addieren. Wer + in APL verstanden
hat, kann das:
1 2 3 + 4 5 6
vs.
?
in Pascal/C++/F/Ada[*]/...?
Leicht lesbare sprachen verlagern das problem in Buechereien,
und produzieren lange Programme. Und die Lesbarkeit von kleinen
Einheiten dieser Programme macht ein grosses
Programm doch nicht weniger komplex, gschweige denn macht sie das
Erfinden und Nachvollziehen von Problemloesungen mittels Programmierung
_insgesamt_ einfacher!
Was den Vergleich lateinisch/griechich vs. Chinesich angeht:
Keineswegs ist irgendwie erwiesen, dass Lesen von Woerten nach
hiesigen Konstruktions-Prinzipien leichter ist, als das Erfassen
chin. Ideogramme. Die Latinisierungs-Kampagne in China ist wohl gestoppt,
ist auch ein etwas zu naiver (Amdahl!) Versuch, zu glauben, dass
mit weniger Buchstaben auch automatisch _insgesamt_ weniger
Komplexitaet zu meistern ist. Die Geschwindigkeit mit der die Leute
in China Zeitung lesen (nicht in Umschrift, sondern in chin. Schriftzeichen)
soll atemberaubend sein.
(Halt mal einen hiesigen Text quer und lese
Zeilen von oben nach unten, um die hierzulande notwendige
Kombinations-Leistung nochmal nachzuvollziehen.) [**]
: Prozedurale und OO Sprachen versuchen aus wenigen Grundelementen
: (Lexikalische Elemente/Token) gr??ere
in der Tat!
: Einheiten zu bilden die aufgrund der
: einfach Basis leichter erfasst werden k?nnen,
Nun ja, die einfache Basis kann leicht erfasst werden.
Wieso sollten lange prozedural oder funktional verfeinert
verfasste grosse Operationen und komplexe Objekt-Beziehungen
leicht erfassbar sein? Irgendwo muss zur Komplexitaets-Reduktion
in Programmen fuer die wirkliche Welt immer Kapselung hin. Und Warum gibt
es Werkzeuge fuer Analyse, Design, und Reengineering?
Beispiel: Eiffel. Im Standardwerk (tolles Buch)
wird immer wieder heraus gestellt, wie einfach die Sprache ist.
Aber die 1k Seiten belegen die unverbruechliche Schwierigkeit
den Umgang damit zur Konstruktion von Programmen zu lernen.
: Aber ich denke die seit etwa 10 Jahren gehende Diskussion pro und contra
: Operator Overloading
10 Jahre? Also mindestens die Diskussion um viel/wenig Operator
overloading in SNOBOL4/SPITBOL ca. 1972. APL ueberlaedt in gew. Sinn
auch, aber ich finde, eher wenig.
gruesse,
georg
[*] Was macht mensch fuer 1 2 3 + 4 5 6 in Ada?
Typischerweise Typen fuer Vektoren in einem generischen Paket
bauen, vorzugsweise diskriminierbar bauen, und passende
Operationen dazu definieren, insbesondere "+" ueberladen, sodass
(1, 2, 3) + (4, 5, 6)
geschrieben werden kann. Um sowas wie APL-Komfort zu haben :-)
Und da soll der Lernschwelle vergleichsweise niedrig haengen?
Georg Bauhaus
Mir scheint es gibt hier einige missverstaendnisse.
: Ich will sie aber nicht schlecht machen, ich verwende REs auch sehr oft,
: aber APL so gut es auch ist bestimmte mathematische Probleme zu l?sen, so
: schwer ist es ein Programm dass damit geschrieben ist, zu verstehen.
Fuer wen? Was ist mit Leuten, die die ARRAY-features von Fortran95
nicht kennen? Das kannst du doch dann auch nicht auf Fortran schieben?
APL als Sprache fer mathematische Probleme abzukanzeln scheint
mir der Sprache nicht gerecht zu werden.
: (Das Kennen des griechischen
: Alphabets ist in diesem Falle sicher von Vorteil)
Im Fall von APL? Mein APL2 weist nicht mehr als 6 griechische
Buchstaben aus:
epsilon
rho
iota
delta
(alpha)
(omega)
: , was einfach der falsche : Ansatz ist.
Naja, zB Im fall von epsilon:
als einstellige funktion: auflisten aller elemente des arguments.
Als zweistellige funktion: Test ob links in rechts enhalten ist.
Wer schon mal eine Menge gesehen hat, kann ja mal sagen,
ob das schwer zu lernen oder der falsche Ansatz ist :-).
APL ist vielleicht nicht der richtige Ansatz um eine _andere_ Sprache
als APL zu lernen.
: Aber ein l?ngeres Programm damit zu programmieren
: w?rde ungef?hr in die Richtung gehen ein Softwaresystem per endlicher
: Automaten zu beschreiben!
Sag das den grossen Finanz-Unternehmen oder den Versicherungen.
Dir ist bekannt, dass es Mechanismen der Kapselung in APL gibt
(funktions-definitionen zB, fuer den anfang)?
Ich bezweifle auch, dass die beschreibung einer multiplikation
zweier beliebiger betrags-beschraenkter Ganzzahlen durch einen
Automaten, wenn er denn noch in den Speicher passt, irgendwie mit
a x b
konkurrieren kann.
: und es viele Fehlversuche gab!
Nun ja. Beleg?
: Es hat schon seinen Grund warum manche Sprachdesigner ?berladene Operatoren
: nicht besonders gerne haben, und APL betreibt den Einsatz von Operatorn zum
: Exzess.
zum Exzess ueberladene Operatoren in APL? (was deine formulierung
rhetorisch andeutet) Guck dir ein APL noch mal an, bitte.
gruesse,
georg
Werner Purrer
>
> zum Exzess ueberladene Operatoren in APL? (was deine formulierung
> rhetorisch andeutet) Guck dir ein APL noch mal an, bitte.
> gruesse,
> georg
Mhh ich hab schnell mal ein kleines APL Listing aus dem Web ausgegraben:
>This is a small dump program, which opens up a file and displays its data
>in hexadecimal and ASCII format. The non-ASCII symbols of APL are
>represented in braces {keyword}
[0] Z{<-}HEXDUMP F;B;E;H;N;P;Q;V;#IO
[1] @ Hex dump of file F
[2] #IO{<-}0 @ use index origin 0
[3]
[4] @ Read the file (using APL*PLUS operations)
[5] N{<-}-1+0{max}{max}/-#NNUMS @ available tie number
[6] F #NTIE N @ open the file
[7] E{<-}#NSIZE N @ file size
[8] V{<-}#NREAD N,82,E,0 @ read file as character data
[9] #NUNTIE N @ close the file
[10]
[11] @ Form the hex dump
[12] Q{<-}16 @ display 16 bytes/line
[13] N{<-}{ceiling}E{divide}Q @ number of lines
[14] Z{<-}8 HEX Q{times}{iota}N @ addresses
[15] Z{<-}(0 2+{shape}Z){take}Z @ add two blank columns
[16] H{<-},' ',2 HEX #AV{iota}V @ data in hex
[17] P{<-}(Q{times}3){reshape}' ' @ padding for short last row
[18] H{<-}(N,Q{times}3){reshape}H,P @ turn hex display into a matrix
[19] Z{<-}Z,(0 3+{shape}H){take}H @ append it to the result
[20] B{<-}#AV[127],32{take}#AV @ nonprinting chars
[21] V[(V{epsilon}B)/{iota}{shape}V]{<-}'.' @ change 'em to "."
[22] Z{<-}Z,(N,Q){reshape}V,P @ append ASCII display to result
[0] Z{<-}N HEX V
[1] @ N-digit hex representation of values V
[2] Z{<-}'0123456789ABCDEF'[{transpose}(N{reshape}16){represent}V]
Ok dass mit den unmengen an Operatoren nehm ich zurück (da war meine
Erinnerung schlimmer als die Realität), aber die Leserlichkeit dürfte in
etwa auf Assemblerebene liegen!
Aber ich denke mal diese Diskussion könnten wir hier wohl endlos fortführen!
Lutz Donnerhacke
>Gut, jedes endliche Programm ueber einem endlichen Alfabet kann
>ich an einen endlichen automaten verfuettern, zB mit dem Ergebnis 0
>oder 1, aber ich bezweifle, dass die maechtigkeiten von REs und
>APL sich auch nur annaehernd decken.
RE bilden Typ2 Sprachen, APL Typ0 Sprachen.
>Wie sehen das IF und, sagen wir, die Vorwaerts-Verzweigungen in REs aus,
>um mal mit was einfachem anzufangen?
Gar nicht. Aber in den üblichen Implementationen gibt es Rückwärtsreferenzen
und das macht aus diesen (Reg)Ex über den Beweis der Markovketten auch eine
Typ0 Sprache, d.h. die beschreibbaren Wortmengen sind gleich.
Georg Bauhaus
: Erinnerung schlimmer als die Realit?t), aber die Leserlichkeit d?rfte in
: etwa auf Assemblerebene liegen!
Weil du immer unterstellst, dass alle LeserInnen von Programmen
kein APL koennen. Wer kein C kann, kann auch mit den meisten
C-Konstruktionen nix anfangen :-)
Und wenig text muss einer im allg. _langsam_ und mit genuss lesen :-)
tschuess ersma,
georg