Swift

  • zerm schrieb:

    Es ist ja
    std::cout << ...
    Also geht da was nach "out". Oder
    fd << ...
    wo etwas in ein File geht..

    Hauptgrund dafür ist aber, dass es kaum etwas besseres gibt, was Typsicherheit im Stringformatting erlaubt. Es gibt kein %@ in C++.

    Also ch finde
    [file append:…] immer noch leichter lesbar. Das liegt daran, dass ich in natürlicher Sprache auch append sage und nicht less-than less than.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • manoh schrieb:

    Amin Negm-Awad schrieb:

    Du magst dich mehr daran gewöhnt haben, aber das Wort "print" ist objektiv besser verständlich als "<<" (Oder war es >>?)


    Wäre eigentlich "show" nicht besser als "print"?

    Das mit den Schiebeoperatoren finde ich im großen und ganzen logisch. Entweder wird etwas nach z.B. std::cout reingeschoben oder aus std::cin rausgeschoben.
    Und wieso bedeutet << raus und >> rein?

    Als angehöriger des westlichen Kulturkreises lese ich allerdings meist von links nach rechts. Müsste es dann nicht
    … >> std:out
    heißen?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Ich kann mir nicht vorstellen, dass es um die Logik geht. Wenn man etwas nur ausladend erklärt bekommt ist es logisch.

    Logisch mag es sein, intuitiv hingegen ist es nicht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Wieder so ein Sicherheitskriterium, was vor Gefahren schützt, die nicht mehr existieren.

    Wie gesagt, ich mag keine Lauftzeitfehler. Atomreaktor in der Höhle, Du weisst schon.

    Amin Negm-Awad schrieb:

    Als angehöriger des westlichen Kulturkreises lese ich allerdings meist von links nach rechts

    Super Argument, da weiss ich nicht mehr, was ich darauf sagen soll.

    Ja, der Atomreaktor, der bei Objective-C nicht explodiert. Aber vielleicht sind das einfach die besseren Nukleartechniker?

    Ich wusste ja auch nicht, was ich dazu sagen soll, dass << für raus und >> für rein, logisch sei.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • TheFuriousLion schrieb:

    Ich hab mal eine Frage zu folgendem Swift-Code:

    Quellcode

    1. ​var someString = "Some Float is \(someFloat)."

    Wie kann man hier die Ausgabe des Floats auf 2 Dezimalstellen beschränken? (String Interpolation?)

    Wie man bereits am Threadtitel eindeutig erkennen kann, geht es hier um Objective-C und C++. Und außerdem platzt Du mitten in eine hochkarätige Expertendiskussion, da kann man doch nicht einfach persönliche Vorlieben mit konkreten Fragen und Fakten stören! Also: Was soll denn solch eine Frage hier? ;)

    Nebenbei: Ich hab' auch nichts Konkretes dazu gefunden, String Interpolation scheint das noch nicht zu können, da muss man sich wohl noch mit etwas wie let str = NSString(format:"%2d",someFloat) behelfen und das dann in in die Interpolation packen.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    TheFuriousLion schrieb:

    Ich hab mal eine Frage zu folgendem Swift-Code:

    Quellcode

    1. var someString = "Some Float is \(someFloat)."

    Wie kann man hier die Ausgabe des Floats auf 2 Dezimalstellen beschränken? (String Interpolation?)

    [...]

    Nebenbei: Ich hab' auch nichts Konkretes dazu gefunden, String Interpolation scheint das noch nicht zu können, da muss man sich wohl noch mit etwas wie let str = NSString(format:"%2d",someFloat) behelfen und das dann in in die Interpolation packen.

    Man kann in Swift mit Extensions (muss man für Swift jetzt eigentlich ein Praktikum beim Frisör machen? :D ) ja alles mögliche erweitern:

    Quellcode

    1. ​extension Float {
    2. var twoDec : String {
    3. return NSString(format: "%.2f", self)
    4. }
    5. }
    7. var someString = "Some Float is \(someFloat.twoDec)"

  • Was mir aufgefallen ist, dass zurzeit irgendwie Today Widgets nur mit Objective C statt mit Swift gehen. Fügt man einmal ein Widget in Objective C und einmal eins in Swift hinzu und baut diese ohne was daran zu ändern (also man übernimmt Apples Beispiel) wird beim Objective C Widget was angezeigt und beim Swift Widget kommt ein leeres Widget. Technik die begeistert :D

  • Also ich hab mir ja schon gedacht, dass Swift zu Beginn vielleicht anstatt wie angekündigt schneller ein klein wenig langsamer sein wird, aber die Ergebnisse hier können ja wohl nicht wahr sein
    splasmata.com/?p=2798
    The closest it came to Objective-C’s performance was a factor of 6.4x slower, and that was in a test we didn’t show results for (appending to an NSMutableArray instead of an Int array in Swift).

    Vielleicht sollte man noch warten, bis Swift ein bisschen abgehangen ist

  • bananenBrot schrieb:

    Also ich hab mir ja schon gedacht, dass Swift zu Beginn vielleicht anstatt wie angekündigt schneller ein klein wenig langsamer sein wird, aber die Ergebnisse hier können ja wohl nicht wahr sein
    splasmata.com/?p=2798
    The closest it came to Objective-C’s performance was a factor of 6.4x slower, and that was in a test we didn’t show results for (appending to an NSMutableArray instead of an Int array in Swift).

    Vielleicht sollte man noch warten, bis Swift ein bisschen abgehangen ist


    och 'easy' programming kostet halt CPU zeit... an jedem int ein sack voll bindings... , causalitäts und probability test, ARC nicht vergessen und die neuen Data Bindings

    BTW: hab ich schon C# programme an databindings eingehen sehen wenn damit freizügig durch dicke bäume iteriert wird...

    aber dafür gibts bestimmt bald schnellere hardware :D
    snafu
    :() { :|: &};:
    sometimes i dream in hex
    Obey gravity! Because its a law!

  • manoh schrieb:

    Amin Negm-Awad schrieb:



    ...

    Ich wusste ja auch nicht, was ich dazu sagen soll, dass << für raus und >> für rein, logisch sei.


    Hej komm man! Stell dich doch nicht so an! Das klingt ja fast so, als ob Du von Schiebe-Operatoren noch nie was gehört hast...
    Ich stell mich nicht an. Ich würde gerne wissen was an << und >> für raus bzw. rein logischer sein soll als an << und >> für rein bzw. raus.

    Ich glaube , dass dem eine ganz private Logik zugrunde liegt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Amin Negm-Awad schrieb:

    manoh schrieb:

    Amin Negm-Awad schrieb:



    ...

    Ich wusste ja auch nicht, was ich dazu sagen soll, dass << für raus und >> für rein, logisch sei.


    Hej komm man! Stell dich doch nicht so an! Das klingt ja fast so, als ob Du von Schiebe-Operatoren noch nie was gehört hast...
    Ich stell mich nicht an. Ich würde gerne wissen was an << und >> für raus bzw. rein logischer sein soll als an << und >> für rein bzw. raus.

    Ich glaube , dass dem eine ganz private Logik zugrunde liegt.


    Dem liegt gar keine nachweisbare Logik zugrunde - es ist willkürlich definiert. Das gilt aber für alle Sprachelemente in allen Programmiersprachen.

    Bei Definitionen geht es ja in erster Linie um Nützlichkeit, Konsistenz und Brauchbarkeit. Finde ich in diesem Fall gar nicht so schlecht - die Zeichen lassen sich ideographisch als Pfeile interpretieren, die auf eine Richtung hinweisen. In diesem Aspekt sind sie also konsistent mit den Shift-Operatoren (in einem Fall die Richtung der Schiebung, im anderen Fall die Richtung der Daten). Dass bestimmte Zeichen für mehrere Dinge verwendet werden ist zwar nicht schön, aber auch in fast allen Programmiersprachen zu finden. Kurz: Das finde ich schon ok, in C++ gibt es wesentlich Schlimmeres (siehe z.B. den Scott Meyer-Talk).

    Warum wird es hier eigentlich immer so emotional, wenn es um Programmiersprachen geht? Die sind halt so wie sie sind. Mir ist noch keine Programmiersprache untergekommen, die auch nur ansatzweise perfekt wäre. Und in jeder kann man beliebig unverständlichen Mist zusammenkleistern. Da nimmt man halt eine, die a) zur Verfügung steht und b) das Problem vernünftig lösen kann. Spielt es da eine Rolle, welche Zeichen man dafür hintereinanderschreiben muss?
    Multigrad - 360°-Produktfotografie für den Mac

  • Quellcode

    1. std::cout << "Mögen hätt ich schon wollen, "
    2. std::cout >> "aber dürfen habe ich mich nicht getraut.";


    Mit der privaten Logic, würde ich jetzt auch Merkhilfe nennen, hat das glaube ich eher weniger zu tun. Die eckigen Klammern zeigen einem doch eine Richtung an, oder sehe ich nur das.

    Apropos Operatoren: Hat mich bei Swift ein wenig überrascht, dass man extra andere Operatoren braucht, wenn man mit Über- / Unterlauf rechnen mag.

  • mattik schrieb:


    Warum wird es hier eigentlich immer so emotional, wenn es um Programmiersprachen geht?


    Echt ma! Total albern.

    Aber wenn ich nochmal einen meiner Mitarbeiter dabei erwische, dass er Nano statt vim benutzt, fliegt er. Bei Editoren hört der Spaß auf!

  • mattik schrieb:

    Amin Negm-Awad schrieb:

    manoh schrieb:

    Amin Negm-Awad schrieb:



    ...

    Ich wusste ja auch nicht, was ich dazu sagen soll, dass << für raus und >> für rein, logisch sei.


    Hej komm man! Stell dich doch nicht so an! Das klingt ja fast so, als ob Du von Schiebe-Operatoren noch nie was gehört hast...
    Ich stell mich nicht an. Ich würde gerne wissen was an << und >> für raus bzw. rein logischer sein soll als an << und >> für rein bzw. raus.

    Ich glaube , dass dem eine ganz private Logik zugrunde liegt.


    Dem liegt gar keine nachweisbare Logik zugrunde - es ist willkürlich definiert. Das gilt aber für alle Sprachelemente in allen Programmiersprachen.

    Bei Definitionen geht es ja in erster Linie um Nützlichkeit, Konsistenz und Brauchbarkeit. Finde ich in diesem Fall gar nicht so schlecht - die Zeichen lassen sich ideographisch als Pfeile interpretieren, die auf eine Richtung hinweisen. In diesem Aspekt sind sie also konsistent mit den Shift-Operatoren (in einem Fall die Richtung der Schiebung, im anderen Fall die Richtung der Daten). Dass bestimmte Zeichen für mehrere Dinge verwendet werden ist zwar nicht schön, aber auch in fast allen Programmiersprachen zu finden. Kurz: Das finde ich schon ok, in C++ gibt es wesentlich Schlimmeres (siehe z.B. den Scott Meyer-Talk).

    Warum wird es hier eigentlich immer so emotional, wenn es um Programmiersprachen geht? Die sind halt so wie sie sind. Mir ist noch keine Programmiersprache untergekommen, die auch nur ansatzweise perfekt wäre. Und in jeder kann man beliebig unverständlichen Mist zusammenkleistern. Da nimmt man halt eine, die a) zur Verfügung steht und b) das Problem vernünftig lösen kann. Spielt es da eine Rolle, welche Zeichen man dafür hintereinanderschreiben muss?
    Eben, es ist willkürlich definiert. Nichts anderes habe ich gesagt.

    Demgegenüber finde ich print oder auch meinetwegen show nicht willkürlich, sondern beschreibend.

    Ich finde das auch unemotional.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?