Habe damit neulich mal wieder was aus nostalgischem Anflug umgesetzt, was mich dazu brachte Tcl nie wieder anzufassen. "expr" für arithmetische Ausdrücke, ist ja wie zu Shellsteinzeiten, statische Variablen gibts auch nicht, geht nur über Hacks,... ein Krampf wenn man andere Sprachen kennt.
Die regexp war sehr clever implementiert und hat in Benchmarks alles geschlagen, die Tricks wurden aber inzw. von anderen übernommen, so dass es hiermit auch nicht mehr punkten kann, wobei das eh kein Kriterium für die Auswahl einer Scriptsprache ist, jedenfalls nicht für mich.
Das einzig interessante war Tk und das gibts für andere Scriptsprachen schon lange und ist heute auch nicht mehr so interessant wie früher. Brauche ich eine GUI-Anwendung mache ich das soweit möglich und sinnvoll ist als Browseranwendung, das läuft dann überall von PC auf jeder Platform bis Smartphone, Tablett.
Tcl hatte seine Chance, der Zug ist nun lange abgefahren.
Dein Posting offenbart, dass du nicht die geringste Ahnung von Tcl hast, und auch nur ganz wenig Ahnung von den Fallstricken des Programmierens.
Dass man in Tcl arithmetische Ausdrücke explizit in die expr-Funktion stopfen muss ist *Absicht*, denn damit wird der syntaktische Zucker verringert, der anderswo für die netten, schwer zu findenden Fehler sorgt. Was macht
if (c++) printf("foo") else printf("bar"); if (++c) printf("foo") else printf("bar");
in C? Muss man erstmal drüber nachdenken, hmm? Genau deshalb lautet der Rat *mach sowas nicht*. Über die Eigenschaft Perls, write-only zu sein und dank der impliziten Referenzen in der innersten Schleife noch viele weitere Wartungsprobleme zu erzeugen, brauchen wir glaube ich nicht weiter zu sprechen. Pythons Einrückungen zur Strukturierung klingen zwar wie eine gute Idee, weil es zu richtiger Einrückung erzieht, wenn man länger damit umgeht erkennt man aber, dass Sprachen, in denen Whitespace signifikant ist, *teuflisch* sind, weil Whitespace für das menschliche Auge eben nicht signifikant ist. Gilt z.B. auch für Inform7, das ist nicht Python-spezifisch.
Mit "statische Variablen" meinst du globale Variablen? Knall :: vor den Namen, fertig. Oder auch jeden anderen Namespace, auf den du zugreifen willst. Das was andere Sprachen machen, automatisiert einen üblen Mix von globalen und gescopten Variablen zu erzeugen, macht Tcl ebenfalls *absichtlich* nicht. Das ist nämlich genau das, was z.B. bei funktionaler Programmierung wieder für Kopfschmerzen sorgt.
(Im übrigen enthält jeder Perl- und Python- ...- Interpreter, der Tk einbindet, damit auch einen kompletten Tcl-Interpreter. It's everywhere, you can't flee. Genau für den Fall ist das Ding ja auch gedacht, also universelle Makrosprache, die man überall dazubinden kann.)
Warum man expr braucht is mir jetzt immer noch nicht klar. Selbst wenn man den Inkrementoperator nicht kapieren sollte: dann baut man ihn halt nicht ein.
Warum Whitespaces in Python tückisch sein sollen is mir auch nicht klar. Nenn mal ein Beispiel, wo die Einrückung von sinnvoll geschriebenen Python-Vode unklar ist.
Du brauchst in Tcl expr für arithmetische Ausdrücke, weil die Syntax in Tcl einem ganz einfachen Schema folgt
Funktion Argument Argument ...
Das erste in einer Anweisung ist immer die Funktion und alles was danach kommt sind immer Argumente. Es gibt keine implizite Auswertung arithmetischer Ausdrücke, das macht explizit die Funktion expr. Da Tcl wie alle Skriptsprachen eher für String- und Listenverarbeitung als fürs schnelle Numbercrunching verwendet wird, ist dieses Default auch sinnvoll. In Tcl gilt jedes Wort erstmal als String. Die Bedeutung eines Wortes legt erst die Funktion fest, in die es reingestopft wird. Der Interpreter denkt sich da nichts.
Die Einrückung ist in Python genauso sinnvoll wie in anderen Sprachen. Das Problem ist aber, dass das Auge die Menge des eingerückten Whitespace nicht abzählen kann (es ist ja Whitespace) und man am Ende eines geschachtelten Blocks daher nicht weiß, ob nun eine Ebene, drei Ebenen oder noch mehr zurückgeschachtelt wurde. Klammern kann man zählen. (Genausogut kann man natürlich im Editor sichtbare Tabs anschalten, aber das ist Holz in den Wald tragen - da kann man gleich bei den Klammern bleiben.)
Von Anonymous Coward am Mo, 13. Oktober 2014 um 23:56 #
Du brauchst in Tcl expr für arithmetische Ausdrücke, weil die Syntax in Tcl einem ganz einfachen Schema folgt
Funktion Argument Argument ...
Das erste in einer Anweisung ist immer die Funktion und alles was danach kommt sind immer Argumente.
Das ist nur eine andere Formulierung des gleichen Problems. Die Frage ist: können + und * nicht auch ganz einfach Funktionen sein? Jede ordentliche Sprache unterstützt heute in der einen oder anderen Form Infix-Notation.
Die Einrückung ist in Python genauso sinnvoll wie in anderen Sprachen. Das Problem ist aber, dass das Auge die Menge des eingerückten Whitespace nicht abzählen kann (es ist ja Whitespace) und man am Ende eines geschachtelten Blocks daher nicht weiß, ob nun eine Ebene, drei Ebenen oder noch mehr zurückgeschachtelt wurde.
Wenn man Klammern tatsächlich explizit zählen muss, hat man ohnehin ein Wartbarkeitsproblem.
die Menge des eingerückten Whitespace nicht abzählen kann
Du musst die Menge der Leerräume auch nicht zählen. Vier und acht Leerräume sollten die meisten mit bloßem Auge unterscheiden können. Über Inkonsistenzen bei den Leerräumen kann dich Pylint informieren und Lint ist immer eine gute Idee.
Im übrigen wollte ich mit dem Verweis auf C, Perl, Python nur aufzeigen, wie problematisch syntaktischer Zucker sein kann, weil man sich später beim Lesen oder Erweitern schwertut, die Funktion eines Programmteils genau zu erfassen.
Wer auf syntaktischen Zucker verzichtet, hat diese Probleme natürlich nicht. Der wird sich aber auch nicht darüber beschweren, arithmetische Ausdrücke mit expr zu prefixen, damit die Syntax simpel bleibt.
Nicht, dass ich das für ein wirklich tückisches Problem halten würde, aber:
if x: blub() bla()
Und jetzt kommt der Programmier blöd an die Tastatur oder übersieht, dass die automatische Einrückung gerade per Modus ausgeschaltet ist oder andere Szenarien:
if x: blub() bla()
Bei start und end-Token kann sowas nicht passieren, da hier der Parser das merken kann.
Das die Einrückung bei Zitaten entfernt werden gilt eigentlich so gut wie überall. Mir ist keine Forensoftware bekannt, die bei Zitaten nicht die Formatierung ändert.
Was du brauchst ist ein [code] Tag, da wird dann nichts entfernt. Gibt's AFAIK in diesem Board aber nicht.
Insofern würde ich dir empfehlen einfach auf pastebin auszuweichen. http://pastebin.com/
Von Anonymous Coward am Mo, 13. Oktober 2014 um 23:59 #
Wenn Du es nicht für ein ernsthaftes Problem hältst, wieso bringst Du es überhaupt zur Sprache? So etwas sieht man auf den ersten Blick und führt nie zu einem ernsthaften Problem.
Man würde es nicht sehen, wenn man nach der Änderung direkt den Editor schließt. Aus Gründen wie diesem würde ich diese Einrückungssyntax nicht unbedingt in kritischen Bereichen verwenden.
denn damit wird der syntaktische Zucker verringert, der anderswo für die netten, schwer zu findenden Fehler sorgt. Was macht
if (c++) printf("foo") else printf("bar"); if (++c) printf("foo") else printf("bar");
in C? Muss man erstmal drüber nachdenken, hmm?
Ähm sorry, aber den Unterschied zwischen c++ und ++c erkennt ein geübter C Programmierer sofort, der liest C Code wie andere nen Roman und geht bei so etwas triviales wie c++ oder ++c durch den Code, wie ein heißes Messer durch warme Butter. So etwas lernt man schon im Info Studium, weil man bei der Klausur nur Stift und Papier zur Verfügung hat und das daher im Kopf wissen und erkennen muss.
Ansonsten fehlt vor den beiden else noch jeweils ein Semikolon, aber ich denke, das war nicht das, worauf du hinaus wolltest. Der Compiler würde das jedenfalls einem sofort an den Kopf knallen.
Und mit dem Entfernen von syntaktischen Zucker kann man es auch übertreiben. Es gibt z.B. Sprachen, die bei der Variablendefinition kein Anfangsschlüsselwort (wie z.b var oder eben einen Typbezeichner) benötigen, dann kann man sich ohne einen guten Editor zu haben einen Wolf suchen. So etwas ist bspw. richtig übel:
// wir definieren unsere Variable in einer Sprache die kein Anfangsschlüsselwort oder Typbezeichner für Variablendefinitionen verlangt schaukelspiel = 1; .... // viel code dazwischen und dann irgendwo ein func(schauklespiel + 42){ .... }
Dieser Code wäre syntaktisch korrekt, nur semantisch ist er es nicht. Ich empfehle für solche Grützesprachen (wink an PHP) einen Editor, der im Code vorhandene Variablen in einer separaten Tabelle auflistet, dann fällt das schon eher auf.
Aber immerhin macht es da TCL mit dem set Schlüsselwort richtig.
Wenn diese beiden Anweisungen mit etwas Abstand und Code dazwischen hintereinander stehen, sieht man den Unterschied eben nicht sofort und nimmt daher an, dass beide Vergleiche identisch funktionieren. Tun sie aber nicht, wenn c durchgereicht wird, ist der Abstand nicht 1, sondern 2. Dass man überhaupt beide Varianten verwenden kann ist ein Beispiel für syntaktischen Zucker, der für nichts gut ist außer Verwirrung zu stiften.
Die von dir angesprochene Variablendefinition ist auch ein gutes Beispiel, weil der einzige Hinweis darauf, was diese Anweisung tut das = ist. Danach sucht man sich wirklich dumm und dusselig.
(In Tcl musst du noch nach ein paar anderen Schlüsselwörter suchen, incr erzeugt auch eine Variable, sofern sie nicht existiert und selbstverfreilich können selbstgebaute Funktionen das auch tun. Zumindest ist das aber nicht so aussichtslos wie die Suche nach dem =).
--
Im übrigen habe ich für Tcl mit wenig suchen ein "static" gefunden; wer meint das unbeidngt zu benötigen kann es sich ja in eine persönliche Library reinpacken
Wenn diese beiden Anweisungen mit etwas Abstand und Code dazwischen hintereinander stehen, sieht man den Unterschied eben nicht sofort und nimmt daher an, dass beide Vergleiche identisch funktionieren. Tun sie aber nicht, wenn c durchgereicht wird, ist der Abstand nicht 1, sondern 2.
Ach das meinst du. Eine falscher Eingabewert hat aber weder etwas mit dem Pre-Inkrement Operator noch mit dem Post-Inkrement Operator zu tun, denn egal welche Variante des if Konstrukts du zuerst nimmt, nach Auswertung der if Bedingung wird c immer um einen Wert erhöht bzw. der Ausdruck in der If Klammer nach Auswertung berechnet und erst dann kommt das, was innerhalb der geschweiften Klammer steht, ganz egal ob die If Auswertung mit einem TRUE oder FALSE abschloss.
oder anders gesagt, egal wo du weitermachst bzw. was die eigentliche Auswertung ausführt, überall wäre c erhöht: if (c++){ // c wäre hier um 1 erhöht } else { // c wäre auch hier um 1 erhöht } // und hier ist c sowieso um 1 erhöht.
gleiches gilt dafür: if (++c){ // c wäre hier um 1 erhöht } else { // c wäre auch hier um 1 erhöht } // und hier ist c sowieso um 1 erhöht.
Merke: Ob man nun c++ oder ++c schreibt, das hat bei einer If Bedingung nur eine Auswirkung auf die Auswertung der If Bedingung, berechnet wird der Ausdruck aber in beiden Fällen direkt nach der Auswertung und das immer VOR allem anderen, also vor allem, was danach folgen würde.
Dass man überhaupt beide Varianten verwenden kann ist ein Beispiel für syntaktischen Zucker, der für nichts gut ist außer Verwirrung zu stiften.
Wenn der Compiler nichts taugt, also schlecht beim Optimieren ist, dann gibt's zwischen diesen beiden Operatoren durchaus einen Unterschied der bei einem schlechten Compiler auch zu einem Performanceunterscheid führt. Siehe dazu: http://www.embedded.com/design/programming-languages-and-tools/4410601/Pre-increment-or-post-increment-in-C-C-
Auf dem PC wird man das Problem natürlich nicht haben, denn ausgereifte Compiler gibt's da wie Sand am Meer. Anders kann es aber im Embeddedbereich aussehen, wenn man für den jeweiligen µC einen ganz bestimmten Compiler verwenden muss.
Ja, man sieht daran, dass C eben verbesserter Assembler ist. Das ist sehr gut, wenn man sonst nur die Wahl zwischen Assembler und *lahm* hat. Wenn man von Hand optimiert, benötigt man auch tatsächlich beide Varianten.
Solange die ganze Skriptsprachen weiterhin Bindings für tk bereitstellen bleibt Tcl erhalten. Da teile von tk in Tcl erstellt sind, rufen die Bibliotheken Tcl-Functionen auf, die wiederum zum Zeichnen von Primitiven C aufrufen.
Skriptsprache X -> C -> Tcl -> C. Es gibt sogar immer noch Bindings, wo man direkt Tcl-Code schreiben darf.
Es ist zwar kein besonders gutes Toolkit, aber es läuft nunmal überall mit wenig Ressourcen ohne zu hässlich auszusehen.
Habe damit neulich mal wieder was aus nostalgischem Anflug umgesetzt, was mich dazu brachte Tcl nie wieder anzufassen. "expr" für arithmetische Ausdrücke, ist ja wie zu Shellsteinzeiten, statische Variablen gibts auch nicht, geht nur über Hacks,... ein Krampf wenn man andere Sprachen kennt.
Die regexp war sehr clever implementiert und hat in Benchmarks alles geschlagen, die Tricks wurden aber inzw. von anderen übernommen, so dass es hiermit auch nicht mehr punkten kann, wobei das eh kein Kriterium für die Auswahl einer Scriptsprache ist, jedenfalls nicht für mich.
Das einzig interessante war Tk und das gibts für andere Scriptsprachen schon lange und ist heute auch nicht mehr so interessant wie früher. Brauche ich eine GUI-Anwendung mache ich das soweit möglich und sinnvoll ist als Browseranwendung, das läuft dann überall von PC auf jeder Platform bis Smartphone, Tablett.
Tcl hatte seine Chance, der Zug ist nun lange abgefahren.
Wie wäre es mit Python und EasyGUI?
EasyGUI ist tot: http://easygui.wordpress.com/
jetzt hier die unausweichliche frage nach alternativen
PySide, PyQt, PyGTK, wxPython
TCL is tot aber TK lebt in python weiter (tkinter)
Ist nicht tot, ist nur eingefroren. Und es funktioniert.
Ich werde es mir trotzdem einmal ansehen. Ein Blick über den eigenen Tellerrand kann meist nicht schaden.
Dein Posting offenbart, dass du nicht die geringste Ahnung von Tcl hast, und auch nur ganz wenig Ahnung von den Fallstricken des Programmierens.
Dass man in Tcl arithmetische Ausdrücke explizit in die expr-Funktion stopfen muss ist *Absicht*, denn damit wird der syntaktische Zucker verringert, der anderswo für die netten, schwer zu findenden Fehler sorgt. Was macht
if (c++) printf("foo") else printf("bar");
if (++c) printf("foo") else printf("bar");
in C? Muss man erstmal drüber nachdenken, hmm? Genau deshalb lautet der Rat *mach sowas nicht*. Über die Eigenschaft Perls, write-only zu sein und dank der impliziten Referenzen in der innersten Schleife noch viele weitere Wartungsprobleme zu erzeugen, brauchen wir glaube ich nicht weiter zu sprechen. Pythons Einrückungen zur Strukturierung klingen zwar wie eine gute Idee, weil es zu richtiger Einrückung erzieht, wenn man länger damit umgeht erkennt man aber, dass Sprachen, in denen Whitespace signifikant ist, *teuflisch* sind, weil Whitespace für das menschliche Auge eben nicht signifikant ist. Gilt z.B. auch für Inform7, das ist nicht Python-spezifisch.
Mit "statische Variablen" meinst du globale Variablen? Knall :: vor den Namen, fertig. Oder auch jeden anderen Namespace, auf den du zugreifen willst. Das was andere Sprachen machen, automatisiert einen üblen Mix von globalen und gescopten Variablen zu erzeugen, macht Tcl ebenfalls *absichtlich* nicht. Das ist nämlich genau das, was z.B. bei funktionaler Programmierung wieder für Kopfschmerzen sorgt.
(Im übrigen enthält jeder Perl- und Python- ...- Interpreter, der Tk einbindet, damit auch einen kompletten Tcl-Interpreter. It's everywhere, you can't flee. Genau für den Fall ist das Ding ja auch gedacht, also universelle Makrosprache, die man überall dazubinden kann.)
Warum man expr braucht is mir jetzt immer noch nicht klar. Selbst wenn man den Inkrementoperator nicht kapieren sollte: dann baut man ihn halt nicht ein.
Warum Whitespaces in Python tückisch sein sollen is mir auch nicht klar. Nenn mal ein Beispiel, wo die Einrückung von sinnvoll geschriebenen Python-Vode unklar ist.
Du brauchst in Tcl expr für arithmetische Ausdrücke, weil die Syntax in Tcl einem ganz einfachen Schema folgt
Funktion Argument Argument ...
Das erste in einer Anweisung ist immer die Funktion und alles was danach kommt sind immer Argumente. Es gibt keine implizite Auswertung arithmetischer Ausdrücke, das macht explizit die Funktion expr. Da Tcl wie alle Skriptsprachen eher für String- und Listenverarbeitung als fürs schnelle Numbercrunching verwendet wird, ist dieses Default auch sinnvoll. In Tcl gilt jedes Wort erstmal als String. Die Bedeutung eines Wortes legt erst die Funktion fest, in die es reingestopft wird. Der Interpreter denkt sich da nichts.
Die Einrückung ist in Python genauso sinnvoll wie in anderen Sprachen. Das Problem ist aber, dass das Auge die Menge des eingerückten Whitespace nicht abzählen kann (es ist ja Whitespace) und man am Ende eines geschachtelten Blocks daher nicht weiß, ob nun eine Ebene, drei Ebenen oder noch mehr zurückgeschachtelt wurde. Klammern kann man zählen. (Genausogut kann man natürlich im Editor sichtbare Tabs anschalten, aber das ist Holz in den Wald tragen - da kann man gleich bei den Klammern bleiben.)
Im übrigen wollte ich mit dem Verweis auf C, Perl, Python nur aufzeigen, wie problematisch syntaktischer Zucker sein kann, weil man sich später beim Lesen oder Erweitern schwertut, die Funktion eines Programmteils genau zu erfassen.
Wer auf syntaktischen Zucker verzichtet, hat diese Probleme natürlich nicht. Der wird sich aber auch nicht darüber beschweren, arithmetische Ausdrücke mit expr zu prefixen, damit die Syntax simpel bleibt.
Nicht, dass ich das für ein wirklich tückisches Problem halten würde, aber:
if x:
blub()
bla()
Und jetzt kommt der Programmier blöd an die Tastatur oder übersieht, dass die automatische Einrückung gerade per Modus ausgeschaltet ist oder andere Szenarien:
if x:
blub()
bla()
Bei start und end-Token kann sowas nicht passieren, da hier der Parser das merken kann.
und die drecks Kommentarfunktion hat natürlich alle Leerzeichen weggemacht.
A:
B:
Sogar in den Zitaten. Naja, bei dem ersten sollen sowohl blub als auch bla eingerückt sein, bei dem zweiten nur blub.
Das die Einrückung bei Zitaten entfernt werden gilt eigentlich so gut wie überall.
Mir ist keine Forensoftware bekannt, die bei Zitaten nicht die Formatierung ändert.
Was du brauchst ist ein [code] Tag, da wird dann nichts entfernt.
Gibt's AFAIK in diesem Board aber nicht.
Insofern würde ich dir empfehlen einfach auf pastebin auszuweichen.
http://pastebin.com/
Wenn Du es nicht für ein ernsthaftes Problem hältst, wieso bringst Du es überhaupt zur Sprache? So etwas sieht man auf den ersten Blick und führt nie zu einem ernsthaften Problem.
Man würde es nicht sehen, wenn man nach der Änderung direkt den Editor schließt.
Aus Gründen wie diesem würde ich diese Einrückungssyntax nicht unbedingt in kritischen Bereichen verwenden.
Ähm sorry, aber den Unterschied zwischen c++ und ++c erkennt ein geübter C Programmierer sofort, der liest C Code wie andere nen Roman und geht bei so etwas triviales wie c++ oder ++c durch den Code, wie ein heißes Messer durch warme Butter.
So etwas lernt man schon im Info Studium, weil man bei der Klausur nur Stift und Papier zur Verfügung hat und das daher im Kopf wissen und erkennen muss.
Ansonsten fehlt vor den beiden else noch jeweils ein Semikolon, aber ich denke, das war nicht das, worauf du hinaus wolltest. Der Compiler würde das jedenfalls einem sofort an den Kopf knallen.
Und mit dem Entfernen von syntaktischen Zucker kann man es auch übertreiben.
Es gibt z.B. Sprachen, die bei der Variablendefinition kein Anfangsschlüsselwort (wie z.b var oder eben einen Typbezeichner) benötigen, dann kann man sich ohne einen guten Editor zu haben einen Wolf suchen.
So etwas ist bspw. richtig übel:
Dieser Code wäre syntaktisch korrekt, nur semantisch ist er es nicht.
Ich empfehle für solche Grützesprachen (wink an PHP) einen Editor, der im Code vorhandene Variablen in einer separaten Tabelle auflistet, dann fällt das schon eher auf.
Aber immerhin macht es da TCL mit dem set Schlüsselwort richtig.
Wenn diese beiden Anweisungen mit etwas Abstand und Code dazwischen hintereinander stehen, sieht man den Unterschied eben nicht sofort und nimmt daher an, dass beide Vergleiche identisch funktionieren. Tun sie aber nicht, wenn c durchgereicht wird, ist der Abstand nicht 1, sondern 2. Dass man überhaupt beide Varianten verwenden kann ist ein Beispiel für syntaktischen Zucker, der für nichts gut ist außer Verwirrung zu stiften.
Die von dir angesprochene Variablendefinition ist auch ein gutes Beispiel, weil der einzige Hinweis darauf, was diese Anweisung tut das = ist. Danach sucht man sich wirklich dumm und dusselig.
(In Tcl musst du noch nach ein paar anderen Schlüsselwörter suchen, incr erzeugt auch eine Variable, sofern sie nicht existiert und selbstverfreilich können selbstgebaute Funktionen das auch tun. Zumindest ist das aber nicht so aussichtslos wie die Suche nach dem =).
--
Im übrigen habe ich für Tcl mit wenig suchen ein "static" gefunden; wer meint das unbeidngt zu benötigen kann es sich ja in eine persönliche Library reinpacken
namespace eval ::static {}
proc static {name {value ""}} {
set caller [lindex [info level -1] 0]
namespace eval ::static::$caller {}
set qname ::static::${caller}::$name
if {![info exists $qname]} {set $qname $value}
uplevel 1 [list upvar #0 $qname $name]
}
#-- Testing:
proc intgen {} {
static i 0
incr i
}
% intgen
1
% intgen
2
% intgen
3
Richard Suchenwirth hat das schon vor Jahren im Tcl-Wiki gepostet und es wurden dort noch ein paar andere Varianten diskutiert
oder anders gesagt, egal wo du weitermachst bzw. was die eigentliche Auswertung ausführt, überall wäre c erhöht:
if (c++){
// c wäre hier um 1 erhöht
} else {
// c wäre auch hier um 1 erhöht
}
// und hier ist c sowieso um 1 erhöht.
gleiches gilt dafür:
if (++c){
// c wäre hier um 1 erhöht
} else {
// c wäre auch hier um 1 erhöht
}
// und hier ist c sowieso um 1 erhöht.
Merke:
Wenn der Compiler nichts taugt, also schlecht beim Optimieren ist, dann gibt's zwischen diesen beiden Operatoren durchaus einen Unterschied der bei einem schlechten Compiler auch zu einem Performanceunterscheid führt.Ob man nun c++ oder ++c schreibt, das hat bei einer If Bedingung nur eine Auswirkung auf die Auswertung der If Bedingung, berechnet wird der Ausdruck aber in beiden Fällen direkt nach der Auswertung und das immer VOR allem anderen, also vor allem, was danach folgen würde.
Siehe dazu:
http://www.embedded.com/design/programming-languages-and-tools/4410601/Pre-increment-or-post-increment-in-C-C-
Auf dem PC wird man das Problem natürlich nicht haben, denn ausgereifte Compiler gibt's da wie Sand am Meer. Anders kann es aber im Embeddedbereich aussehen, wenn man für den jeweiligen µC einen ganz bestimmten Compiler verwenden muss.
Ja, man sieht daran, dass C eben verbesserter Assembler ist. Das ist sehr gut, wenn man sonst nur die Wahl zwischen Assembler und *lahm* hat. Wenn man von Hand optimiert, benötigt man auch tatsächlich beide Varianten.
Wobei ich ernsthaft über Forth nachdenken würde, bevor ich einen zweifelhaften C-Compiler anwerfe.
Solange die ganze Skriptsprachen weiterhin Bindings für tk bereitstellen bleibt Tcl erhalten.
Da teile von tk in Tcl erstellt sind, rufen die Bibliotheken Tcl-Functionen auf, die wiederum zum Zeichnen von Primitiven C aufrufen.
Skriptsprache X -> C -> Tcl -> C.
Es gibt sogar immer noch Bindings, wo man direkt Tcl-Code schreiben darf.
Es ist zwar kein besonders gutes Toolkit, aber es läuft nunmal überall mit wenig Ressourcen ohne zu hässlich auszusehen.