+1
Ich würde es wirklich gerne sehen.
Besser lesbar wie end für die Indizierung.

+1
Am 27. Dezember 2013 um 13:06 schrieb "GaborOszlanyi" [email protected] :

+1
Ich würde es wirklich gerne sehen.
Besser lesbar wie das Ende für die Indizierung.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/JuliaLang/julia/issues/5238#issuecomment -31280112
.

Auch dieser Vorschlag gefällt mir.

Ich bin ein bisschen überrascht von der großen Resonanz, die das hier bekommt. Ich hatte immer das Gefühl, dass die buchstabierten Operatoren für den Kontrollfluss viel intuitiver waren, aber ich wusste nicht, dass das Gefühl weit verbreitet war.

Ich war kein Fan, als Sie diesen Vorschlag gemacht haben, aber ich muss sagen, nach einigem Nachdenken macht es für mich auch viel Sinn. Dies sind im Gegensatz zu allen anderen Kontrollflussoperatoren, die Symbole anstelle von Text verwenden. Dies kann die Verwirrung mit & und | verringern.

Mir ist aufgefallen, dass die Sprachen, die and und or bereitstellen (Perl, Ruby, Lua – für die, die ich überprüft habe) auch not bereitstellen (Lua bietet nicht einmal an ! ). Meine erste Reaktion ist, dass ich es nicht mag, da es mit ! überflüssig ist. Aber vielleicht gibt es einen triftigen Grund, warum sich diese Sprachen dafür entschieden haben.

Ich persönlich mag not sehr, aber ich glaube nicht, dass der Wechsel zu not etwas wie die Reduzierung der Mehrdeutigkeit bietet, die die Verwendung von and und or bietet.

not ist auch keine Kurzschluss-/Kontrollflussoperation, und ich habe immer Probleme damit, es in Bezug auf die Assoziativität zu lesen. Der einzige Ort, den ich in Pyhton mag, ist der if not ... aber das liegt daran, dass ich ihn als Kontrollflussoperation lese.

+1

Kann auch XOR als Kurzschluss hinzugefügt werden?
Und Kurzschlussversion der invertierten Versionen (XNOR,NAND,NOR) ?

XOR ist nie kurzschließbar. Die anderen können trivial mit ! plus den Operatoren and und or werden.

+1
Ich möchte darauf hinweisen, dass es in Ruby ständig Verwirrung über && vs. 'and' gibt (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), also es wäre gut, wenn wir die von Ruby verwendete Logik für die Verwendung beider Operatoren im Hinterkopf behalten und entscheiden würden, ob es die Verwirrung wert ist oder ob && zugunsten von 'und' vollständig entfernt werden sollte.

Ich würde es vorziehen, dass and und or eine sehr niedrige Priorität haben, wie sie es in Perl und Ruby tun, damit Sie Dinge schreiben können wie

k <= n and k *= 2

Manchmal möchten Sie das boolesche Ergebnis etwas zuweisen:

cond = f() && g()

Was damit zu kollidieren scheint.

Genau aus diesem Grund haben Ruby und Perl beide Sätze von Operatoren mit unterschiedlicher Priorität. Nicht dafür werben, sondern nur sagen. Ich bin mir nicht sicher, wie häufig diese Verwendung tatsächlich ist, während das Durchstöbern unseres Codes viele k <= n && (k *= 2) Arten von Dingen aufdeckt.

Erstens bin ich auch für and und or .
Ich sehe, dass die vier niedrigsten Prioritätsgruppen in Julia im Moment sind

1. Zuweisungen einschließlich += usw., := , => und ~
2. Der ternäre Operator ?
3. ||
4. &&

Ich denke, dass dies sinnvoll ist (bei ~ bin ich mir nicht sicher, aber das ist nebensächlich). Logisch and und or sind sowohl als rechte Seite von Zuweisungen als auch als Bedingung von ? nützlich. Wenn Sie entweder eine Zuweisung oder einen ternären Operator als Argument für and oder or , wissen Sie wahrscheinlich, dass Sie etwas Ungewöhnliches tun und dass Klammern in Ordnung sind.

Übrigens, ich denke, viele Leute würden erwarten, dass eine Sprache, die and und or für logische Operationen verwendet, not für logische Negation verwendet. Aber wenn wir gute Gründe haben, ! zu behalten, könnte das in Ordnung sein. (Ich vermute, dass ! nicht unbedingt nur eine logische Negation ist, zumindest wenn #4892 implementiert wird und zusammengeführt wird.)

Ich wäre ein wenig traurig über not anstelle von ! , aber ich werde hier alles machen.

Ich glaube wirklich nicht, dass not analog ist – and und or sind Kontrollflussoperatoren, keine Funktionen, während ! nur eine Funktion ist.

Ich stimme Stefan zu. Das einzige, was Ihnen not wirklich bringt, ist, dass Sie nicht so viele Klammern verwenden müssen. Ich denke, das ist ein separates Thema.

Ich habe nur über die anfänglichen Erwartungen neuer Benutzer gesprochen. Aber ich denke
es scheint einen triftigen Grund zu geben !

Ich möchte widersprechen. Nicht wenige Sprachen verwenden && und ||, einschließlich aller, die ich regelmäßig verwendet habe, und diese sind immer kurzgeschlossen. Mit bzw. hätte ich keine intuitive Erwartung, ob sie kurzschließen oder nicht. Ich mag auch, wie && und || sind optisch klar von Variablennamen und -nummern getrennt.

Die Tabelle unter http://en.wikipedia.org/wiki/Short-circuit_evaluation kann für diese Diskussion von Bedeutung sein.

Als jemand aus der Python-Welt bin ich überrascht, dass ich mit @GunnarFarneback einverstanden bin. In letzter Zeit habe ich festgestellt, dass die englischen Bedingungen ( and , or , not ) oft dazu führen, dass ich falschen Code schreibe, von dem ich naiverweise erwarte, dass er funktioniert (weil es Sinn macht in englisch) und muss mir dann ein paar Sekunden am Kopf kratzen, während ich mental vom Englischen in logische Aussagen umwandle, bevor ich meinen Fehler erkenne. Das heißt, ich bin in keiner Richtung besonders voreingenommen; setze gerade meine 2¢ ein.

Ich bin auch für and und or

+1

+1
habe beide Betreiber
and und or mit schwacher Priorität
Ich würde argumentieren, dass cond = f() && g() cond = (f() && g()) .
Ich unterstütze auch die Verwendung von not mit schwacher Priorität, da ! , die in jedem Kontext, den ich gesehen habe, starke Priorität hat, if !(something and something) erfordert, was ich in einigen Tiefen nicht mag , irrationales und unveränderliches Niveau. Ich habe auch das Gefühl, dass ! manchmal schwer zu sehen ist. Ich kenne auch den Ursprung von ! nicht, bin aber der Meinung, dass es einen rechtmäßigen Platz als Fakultätsoperator für ganze Zahlen hat - daher eine Präferenz für die ~ Syntax von Matlab.

@johnmyleswhite wird dieses Problem geschlossen? Ich denke, das Schiff ist auf diesem gesegelt.

:(

Kurzschluss dieses Stirnrunzeln

Ich denke, das sollten wir noch in Betracht ziehen. Viele Leute scheinen && und || wie wir sie verwenden und würden and und or bevorzugen. Es gibt auch das Problem der Rangfolge, was && und || etwas umständlich macht. Wir könnten in eine Zukunft übergehen, in der && und || erfordern, dass beide Operanden boolesch sind und and und or tun, was && und || tun dies derzeit, aber mit niedrigerer Priorität, sodass Sie x == nothing and x = 0 und so weiter schreiben können. Entweder das oder eine andere einzeilige bedingte Syntax wie x = 0 if x == nothing einführen.

Die letzte Syntax x = 0 if x == nothing hat einige der Probleme IMO, die der Vorschlag in https://groups.google.com/forum/#!topic/julia -dev/cnmLcNg8h0Q hat.
Sind die beiden folgenden Optionen so schrecklich, dass Julia Nachbedingungen braucht?

    if x == nothing ; x = 0 ; end

oder

   x == nothing && (x = 0)

Das heißt, genauso wie es mir nichts ausmacht, ein repeat ; expr(s) ; until cond Konstrukt in Julia zu sehen (aber ohne es leben kann), sehe ich nichts Falsches daran, and und or zu Julia hinzugefügt.
Sie scheinen besser in die Julia-Syntax zu passen, als die von C && und || geliehenen zu verwenden.

Ich denke, das sollten wir noch in Betracht ziehen.

+1

Ich war überrascht, dass die Zuweisung eine niedrigere Priorität hatte als || , also suchte ich nach früheren Diskussionen und fand dieses Problem. Es ist keine große Sache, aber diese Klammern sehen für mich fehl am Platz aus. Es dauerte eine Weile (mehrere Sekunden, glaube ich, und ein Test in REPL), um herauszufinden, welcher Zuordnungsort ungültig war. - Die Fehlermeldung zeigte die Zeile nach dem Ende der Funktionsdefinition an.

isempty(o) || (m.over[s][NULL] = o)

Im Gegensatz dazu sehen die Klammern in cond = (f() && g()) für mich in Ordnung aus. Ich denke, ich würde sie trotzdem verwenden.

Für das, was es wert ist, würde ich auch and und or bevorzugen.

+1 auch von mir.

Die Reaktion ist fast einstimmig positiv zugunsten von and usw. Ich zähle zwei Meinungen dagegen, eine gleichgültig, ein paar nicht näher und alle anderen (15 oder mehr) dafür.

Ein Argument dagegen (schwieriger zu lesen) ist meiner Meinung nach falsch. Das Argument ist, dass foo and bar aufgrund von 3 Wörtern gegenüber dem Wort SYMBOL-Wort schwieriger zu lesen ist als foo && bar . Jeder verwendet jedoch Syntax-Highlighting, und in diesem Fall passiert das Gegenteil. and ist als Schlüsselwort eingefärbt, also wird a<1 and b>3 tatsächlich einfärben, um die linken und rechten Unterausdrücke visuell aufzuteilen, während a<1 && b>3 alle drei Operatoren dieselbe Farbe haben. Hinweis auf potenzielles Operator-Präzedenz-Kopfkratzen.

Ein Argument _für_, das noch nicht präsentiert wurde, ist, dass es eine elegante Konsistenz dafür gibt, dass boolesche Operatoren Wörter sind, da das Ergebnis der Operation entweder true oder false , also auch ein Wort. So ist es für einen Anfänger sehr einfach, & vs. and für bitweise versus logisch auswendig zu lernen. Es ist viel schwieriger, & im Vergleich zu && auswendig zu lernen, da es sich um eine willkürliche Zuweisung handelt. Garantierte Anfänger verwenden & falsch, da & das Wort and auf Englisch vermittelt. Dies kann zu Fehlern bei der Rangfolge führen (?).

Ein weiteres mögliches Argument _für_ wäre, dass das Gehirn das {BUNCH OF SYMBOLS}-Wort {BUNCH OF SYMBOLS} auf natürliche Weise analysiert.

Warum nicht einfach wechseln? Jetzt ist immer die beste Zeit dafür, es wird nie einfacher sein als jetzt. Es ist nicht gerade schwierig, Code zu reparieren, der derzeit && verwendet.

Haben and or not xor vielleicht nand nur der Vollständigkeit halber?? Ich habe nichts dagegen, ! behalten. Lassen Sie den Programmierer entscheiden, wann er welche verwenden möchte. Daran ist nichts auszusetzen! Allerdings hat ! bereits eine Verwendung in foo! Stilfunktionen, also gibt es ein Argument "Symbolwiederverwendung minimieren".

@StefanKarpinski es scheint einen Konsens dafür zu geben seit 2013, ich könnte versuchen, dies umzusetzen, aber ich mache mir Sorgen, ob dies überhaupt in Betracht gezogen wird, da dieses Thema noch nicht abgeschlossen ist, würde ich davon ausgehen, dass dies noch offen ist Diskussion? Die Verwendung dieser Wörter anstelle von Symbolen passt gut dazu, dass isa auch ein Infix-Operator ist, genau wie bei true , false , end usw. Es scheint konsistenter und lesbarer auf diese Weise.

+1

Ziehe gerade von Python nach Julia. Es scheint, dass Julia in Gefahr ist, in einen Symbolüberlauf zu geraten. Aus Gründen des menschenlesbaren Codes unterstütze ich nachdrücklich and und or

Die Unterstützung des Schlüsselworts not könnte auch die Lesbarkeit des Codes verbessern.

Sollten wir die Verwendung von and und or (und möglicherweise not ) in 0.7/1.0 verbieten/verbieten, um diese später hinzufügen zu können, falls wir uns dazu entschließen? mögen sie sie tatsächlich?

Damit wäre ich fertig. Ich wette, @JeffBezanson ist dagegen, aber wenn wir es jetzt nicht zulassen, können wir unsere Meinung später jederzeit ändern und es zulassen, während wir nicht in die andere Richtung gehen können. Es kann auch hilfreich sein, Benutzern, die Operatoren im Python-Stil ausprobieren, eine einfache Fehlermeldung "Use && anstelle von and " ausgeben zu können.

Ich denke, das wäre großartig!

Wiedereröffnung und Ergänzung zum Meilenstein, um sicherzustellen, dass wir nichts vergessen.

Ich verstehe die Absicht des Meilensteins nicht, wir werden and und or hinzufügen? wir überdenken es? suchst du nach einer anderen verwendung davon? Oder meinen Sie, Sie werden veraltete Warnungen hinzufügen, damit Leute, die von Python kommen, && anstelle von and ?

Ich hatte https://github.com/JuliaLang/julia/pull/19788, in dem sie Aliase waren, aber ich kann das ändern, um sie zu ersetzen.

Der Meilenstein soll heißen: Eine Entscheidung treffen. Oder, wenn wir nicht rechtzeitig eine Entscheidung treffen können, lehnen Sie jede Verwendung von and und or damit wir die Entscheidung verschieben können, ohne zu riskieren, später den Code anderer zu knacken.

Ich verstehe, dass es angesichts des Bestrebens, Code in ein paar Wochen einzufrieren, möglicherweise zu spät ist, um diese Dose Würmer jetzt wieder zu öffnen (und ich schätze die Idee, Abschreibungen hinzuzufügen, um die Tür für die Zukunft offen zu lassen), aber ein Gedanke:

Als dies zum ersten Mal zur Diskussion kam (2013), war die Julia-Community in erster Linie Entwickler – Leute mit starkem CS-Hintergrund, die mehr als gewohnt waren, && und || . Ich _vermute_, dass die Leute, die and und or am meisten schätzen, angewandte Benutzer sind, die mit ASCII-Salaten nicht so vertraut sind und die noch nicht genug Zeit mit älteren Sprachen verbringen müssen, um sich vollständig daran zu gewöhnen && und || . Es könnte interessant sein zu sehen, wie die Leute darüber denken, wenn wir aktuelle Julia-Benutzer befragen (insbesondere wenn wir es in einem Diskurs zur Sprache bringen, in dem es wahrscheinlich mehr Nicht-Entwickler sehen werden).

Es wurde vorgeschlagen, die Syntax and , or und not reservieren. Wenn wir das tun, können wir diese als Operatoren an jeder Stelle in der 1.x-Timeline hinzufügen. Eine weitere Diskussion ist vorerst nicht erforderlich.

Ich könnte diese als permanente Syntaxfehler analysieren, wie wir es mit ** tun. Aber ich bin immer noch sehr, sehr dagegen, ihnen eine andere Bedeutung zu geben.

Ich finde es auch schade, dass wir alte Themen ausgraben, für die bereits eine Entscheidung getroffen wurde, insbesondere so nahe bei 1.0.

Um es klar zu sagen: Das wird getan, wenn es jemand tut.

Danke für die Klarstellung! :D

Es erscheint mir sehr albern, sich die Mühe zu machen, sie zu analysieren und andere Verwendungen zu verbieten, und es trotzdem zu einem Syntaxfehler zu machen. Ich denke, die meisten Leute hätten lieber keine Situation, in der and und or reservierte Wörter sind (dh in Kontexten wie <strong i="7">@stackeval</strong> 1 0 and 1 or nicht verwendbar sind), aber nichts Nützliches tun. Ich würde vorschlagen, dass sie entweder überhaupt nicht geparst oder als Aliase geparst werden (was nicht ungewöhnlich ist, da C und Ruby dies tun).

Wir haben uns bereits entschieden, sie nicht als Aliase zu parsen, deshalb wurde die PR geschlossen. Also +1 dafür, dass sie überhaupt nicht geparst werden.

Auf die Gefahr hin, diese Diskussion, die bis zum Erbrechen geführt wurde, noch einmal aufzuwärmen, stelle ich fest, dass in Bezug auf C und Ruby die Verwendung von and und or in C meiner Erfahrung nach sehr ungewöhnlich ist, und die meisten gängige Ruby-Styleguides erfordern && und || anstelle von and und or .

IMHO: Es scheint, als ob die ursprünglichen Debatten ziemlich gespalten waren, und das Hinzufügen dieses Schutzes lässt einfach Raum für die Community, ihn in Zukunft erneut zu besuchen, wenn sie es möchte.

Ich habe keine Ahnung, warum das wieder geöffnet wurde.

Ein Julia-Dialekt mit syntaktischen Funktionen wie diesem könnte mit JuliaParser.jl leicht erstellt werden, sobald sich die internen und Metaprogrammierungs-APIs stabilisiert haben, kann es kaum erwarten! :Lächeln:

Für diejenigen, die zu diesem Thema kommen, ohne das Geschehene verfolgt zu haben: Obwohl die Idee, and und or , ziemlich viel Unterstützung gefunden hat *), die erste PR, die sich dem Problem nähert - #19788 - führte hauptsächlich zu einer nicht schlüssigen Diskussion, ob and und or direkter Ersatz für && und || oder eine etwas andere Semantik haben sollten, z Vorrang zu haben, aber es wurde als unerwünscht angesehen, sie nur zu Pseudonymen zu machen. PR #24965 hätte die Schlüsselwörter (zusammen mit not ) reserviert, um ihnen während des 1.x-Zyklus eine Bedeutung zu geben. Eine Diskussion während eines Triage-Anrufs führte jedoch zu einer Ablehnung, sodass dies der früheste Zeitpunkt, an dem dies überdacht werden könnte, für 2.0 ist. (Und man müsste wahrscheinlich wirklich überzeugende Argumente vorbringen, damit die Änderung dann eintritt.)

*) Es scheint, als ob die vorgeschlagene Änderung bei einflussreicheren/"Kern"-Entwicklern weniger beliebt ist, daher kann es jedoch irreführend sein, nur die Anzahl der 👍s zu betrachten.

Ich hoffe, ich habe nicht zu stark vereinfacht und die Dinge anständig richtig gemacht. Entschuldigung, wenn ich es nicht getan habe.

Der früheste Zeitpunkt, an dem dies überdacht werden könnte, ist also für 2.0. (Und man müsste wahrscheinlich wirklich überzeugende Argumente vorbringen, damit die Änderung dann eintritt.)

Ich verstehe nicht, warum es jemals passieren sollte, wenn wir uns jetzt mehrmals entschieden haben, es nicht zu tun. Ich hoffe, wir können vermeiden, dieses Problem bei jeder größeren Version erneut auszugraben.

Wenn Julia lange genug bleibt, um mit Python zu konkurrieren, kann ich garantieren, dass dies immer mehr auftauchen wird. Viele Python-Benutzer möchten nicht zur C-Syntax zurückkehren. Dies ist einer der vielen Gründe, warum Python so beliebt ist: leicht zu erlernen, süchtig in der Anwendung, Sie werden nicht mehr auf die alte Vorgehensweise zurückgreifen wollen.

Neue Sprachdesigner behaupten oft, dass sie eine benutzerfreundliche Syntax wünschen, aber sie neigen dazu, sich in ausgefallenen Funktionen zu verlieren, die nur eine kleine Untergruppe von Benutzern jemals wollen oder verwenden wird, während sie einfache Optimierungen übersehen, die die Akzeptanz fördern könnten.

Ein typisches Beispiel: Es werden bizarre Unicode-Operatoren unterstützt , aber keine natürlichen Sprachen and und or .

R verwendet auch && und || und 1-Indexierung. Es ist nicht nur ältere (oder niedrigere Sprachen wie C). Es ist mir gleichgültig, welche ich verwenden soll, aber es ist nicht schwieriger: Ich habe sowohl R als auch Python für absolute Anfänger beigebracht (kein Programmierunterschied) und damit hatten sie nicht zu kämpfen. Normalerweise waren die zugrunde liegenden Konzepte wichtiger und das Erlernen dauerte länger als die Symbole oder Wörter, die zum Schreiben des Codes verwendet wurden. "Benutzerfreundliche" und "intuitive" Syntax für Sie als R-, Python-, C-Benutzer usw. unterscheidet sich einfach aufgrund dessen, was Sie bereits kennen. Dies ist nicht der Fall für absolute Anfänger, mit denen wir uns hier mehr beschäftigen sollten, da ich denke, dass diejenigen mit Erfahrung in der Programmierung in anderen Sprachen die Erfahrung und das Fachwissen haben, um mit den verschiedenen Konventionen in einer neuen Sprache umzugehen.

Der einzige Grund, der hier angesprochen wurde, ist, dass Python and und or und solche Leute. Lohnt sich der Umstieg? Julia ist nicht Python und sollte es auch nicht versuchen. Wir haben bereits Python. Um jeden zu motivieren, auf eine neue Sprache umzusteigen, sollte es anders sein. Neue Benutzer von Julia sind möglicherweise keine Python-Programmierer, sie haben möglicherweise Erfahrung mit einer anderen Sprache (oder gar keiner, wenn sie populär genug wird).

Ich erkenne, dass dies wahrscheinlich ein totes Problem ist, aber als Antwort auf @TomKellyGenetics würde ich vorschlagen, dass IMHO viele von uns argumentieren würden, dass R als "älter" eingestuft wird und es nicht besonders benutzerfreundlich ist ... Und während ich Anfängern zustimme, && Betreiber ist „nicht das, was sie mit zu kämpfen“, das glaube ich die meisten Studenten ich habe gelehrt find Englisch Sprache Operatoren ( and , or ) vertrauter und lesbar , ob sie Python sind Benutzer oder nicht.

R verwendet auch && und || und 1-Indexierung. Es sind nicht nur ältere (oder niedrigere) Sprachen wie C).

Ich bezog mich auf C-ähnliche Sprachen, dh Sprachen, die die Syntax stark von C übernehmen, normalerweise mit dem selbsterfüllenden Argument "es ist die Syntax, die jede andere Sprache verwendet". Die R-Syntax ist eher C-ähnlich, obwohl sie hier und da divergiert. Julia ist eher Fortran-ähnlich als C-artig, obwohl es einige Überschneidungen gibt.

Ich habe sowohl R als auch Python für absolute Anfänger beigebracht (kein Programmierunterschied) und damit hatten sie nicht zu kämpfen.

IME-Studenten, die neu in der Programmierung sind, kämpfen zusätzlich zu allem anderen mit der Syntax, es ist der Tod durch tausend Schnitte. Programmieren ist fremd, und wenn man abstrakte Symbole der natürlichen Sprache vorzieht, wird es noch fremder und leicht zu vergessen. Ich höre oft, wie Anfänger in C-ähnlichen Sprachen Dinge fragen wie: "Wie schreibt man 'oder' nochmal?"
Aber natürliche Sprache in der Programmierung ist nicht nur für Anfänger ein Thema. Selbst erfahrene Programmierer verpassen eher ein ! gegenüber einem not , und viele finden es einfacher, or und and über || schneller zu lesen und && .

Julia ist nicht Python und sollte es auch nicht versuchen. Wir haben bereits Python. Um jeden zu motivieren, auf eine neue Sprache umzusteigen, sollte es anders sein.

Julia ist auch nicht C oder Fortran. Die überwiegende Mehrheit der populären Sprachen ist C-ähnlich, also bedeutet hervorzuheben bedeutet normalerweise, etwas anderes zu tun als C. Ich mag Fortran, C und ihre Nachkommen eigentlich, benutze sie die ganze Zeit, aber an einigen Stellen sind sie zu kurz und ich denke, wir können es Machs besser. Die Verwendung natürlicherer Sprache ist eine Möglichkeit. Es ist erwähnenswert, dass Fortran 77 und höher .not. , .and. und .or. mit guter Wirkung verwendet. In diesem Sinne möchte ich eigentlich, dass Julia mehr Fortran-artig ist, weniger C-artig!

Dieses Problem wurde behoben; and und or sind als Bezeichner erlaubt und wir werden weiterhin && und || für den Kontrollfluss verwenden. Ich bin mir nicht sicher, warum das noch diskutiert wird.

Es besteht die Tendenz, die Bedeutung oberflächlicher Syntaxprobleme zu überschätzen, da sie sehr gut sichtbar, leicht zu diskutieren und ihre Implikationen normalerweise klar sind. In einem anderen Bereich wird eine Sprache als unbrauchbar angesehen, es sei denn, Codeblöcke werden von geschweiften Klammern umgeben, in diesem Fall sind sowohl Julia als auch Python unerschwinglich.

Ich denke, es ist fraglich, ob a and b tatsächlich lesbarer ist als a && b . && fällt mehr auf. Die Tatsache, dass || und && gleich lang sind, kann auch zu einer schöneren Formatierung führen. Einer der Gründe, warum Operatorsymbole wie a = b und a + b so gut funktionieren, ist, dass sie eine visuelle Struktur über etwas wie set a to b hinzufügen. a[i] oder element i of a ?

Sie werden nicht mehr auf die alte Vorgehensweise zurückgreifen wollen.

Für mich ist die alte Vorgehensweise die manuelle Speicherverwaltung und die schwache Unterstützung für Polymorphismus, nicht die Schreibweise von && .

Julia hat einige Ausdrücke in natürlicher Sprache, wie zum Beispiel for a in [1, 2, 3] . Das liest sich besser und ist intuitiver als for a = [1, 2, 3] , das auch Julia unterstützt. Ich würde sicherlich nicht vorschlagen, dass wir für alle symbolischen Operatoren natürliche Sprachalternativen anbieten, nur für die wenigen, die Julia intuitiver und lesbarer machen.

FWIW, ich habe dafür gestimmt, beide Gruppen von Operatoren zu übernehmen, um die Einführung zu erleichtern und den Benutzern eine Wahlmöglichkeit zu geben. In C++-Projekten, in denen die Leute beides verwenden, hat es mich nie gestört. Ich sehe darin keinen Schaden, nur Vorteile.

Insgesamt liebe ich die Richtung, in die Julias Syntax gegangen ist. Ein gutes Gleichgewicht zwischen natürlicher Sprache und Symbolen, das beweist, dass eine numerische Sprache sich bei der universellen Programmierung auszeichnen kann. Ich kann es kaum erwarten zu sehen, wie es wächst und sich entwickelt. Das ist meine Art zu sagen, dass das Hinzufügen der natürlichen Sprachoperatoren technisch abwärtskompatibel ist. :Grinsen:

Ich werde versuchen, or , and und not für eine mögliche zukünftige Verwendung zu reservieren und eine Warnung / einen Vorschlag zur Verwendung der entsprechenden Symbole auszusprechen. Soll ich dies in Julia 0.7, 1.0 oder in beiden tun?

24965 ?

Ah, das habe ich übersehen, danke! Ich denke, dass das Nichtreservieren von Keywords die zukünftige Unterstützung dieser Keywords nicht verhindert.

Entschuldigung, ich habe alle Diskussionen gelesen, aber immer noch nicht verstanden. Wie kann ich jetzt and , or in Julia verwenden?

Du kannst nicht