4 ms·

Would not be my first choice. A good REPL allows you to write code quickly and off the top of your head. As article notes, Swift’s C pointer/buffer semantics ar

by hhas01 7y ago

Would not be my first choice. A good REPL allows you to write code quickly and off the top of your head. As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead. If you understand C it just gets in your way. If you don’t understand C it gets in your way even worse. Working with ObjC classes is cleaner, but even that has bridging issues. Incidentally, the Swift REPL itself has another nasty misfeature: it always outputs the fully introspected debug representation of complex values, rather than calling `description`/`debugDescription` where available. Not really an issue when working with pointers, but for native structs and classes with complex internal state it can print screens and screens of unreadable noise, totally defeating the purpose. Conversely, the GUI-based “Swift Playgrounds” REPL prints line output right but lacks the CLI’s persistency so re-evaluates all lines every time a new line is entered, making it useless for stateful work. TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here]

coldtea 7y ago
>As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead They look perfectly fine to me. What did you find troubling? >TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here] The only mess described thus far is in the REPL/Playgrounds for the language, which are not themselves "Swift".
- hhas01 7y ago
  There are ten different pointer types, all with different and not easily memorized APIs.
  - coldtea 7y ago
    Well, it's all in the name, no? And the use is rather obvious, mutable vs not, typed vs not, and buffer types (contiguous memory with count of items) or not. If only C had those how safer it would be!
    - hhas01 7y ago
      “If only C had those how safer it would be!” Indeed it would be, because then no-one would want to use C. All languages are abstractions, but there are good abstractions and there are bad abstractions, and a truly depressing number of Swift abstractions fall firmly in the “not good” camp. A well-designed type system abstraction would support and encourage free and open-ended composition of clearly-defined individual orthogonal concerns. Thus mutability would be a composable trait, `Mutable<Pointer<…>>`, untyped would just be `Pointer` without a constaint (Void being the default), and buffers would likewise be expressed via constraint, `Pointer<Buffer<TYPE,COUNT>>`. But Swift’s type system was designed by amateurs; its inconsistencies and lack of expressivity resulting in a stdlib that’s a bloated convoluted mess as it struggles around those limitations. (Makes even Ruby’s stdlib APIs look clean, consistent, and concise!)
      - SamReidHughes 7y ago
        > But Swift’s type system was designed by amateurs LOL. The amateurish type system design is the one you've described. Mutable<Pointer<...>> either makes the wrong thing mutable, or makes too much stuff mutable. Pointer<Buffer<Type, Count>> would make the whole language more complicated, and it doesn't solve any of the problems Swift's pointers solve. The Swift devs in fact are not amateurs, and it shows in how they managed to keep things simple, instead of convoluting the problem with total I-am-a-very-smart-Haskell-programmer complexity. > Thus mutability would be a composable trait I mean, this is a major tell. You don't just hand-wave mutability being a composable trait.
        hhas01 7y ago
        “Mutable<Pointer<...>> either makes the wrong thing mutable, or makes too much stuff mutable.” You may be reading `Mutable<>` overly literally. I just used generic notation for familiarity; that doesn’t mean it’d map directly to a struct. Have it be a `mut[able]` keyword if you prefer. The point is, it can be applied to any type, and eliminates the need for let and var definitions. “Pointer<Buffer<Type, Count>> would make the whole language more complicated” Why? We’ve gone from ten single-purpose types to three general-purpose ones: Mutable<>, Pointer<>, and Buffer<>. (And, in practice, Buffer would merge with Data, so really it’s two.) “The Swift devs in fact are not amateurs, and it shows in how they managed to keep things simple” Oh really. There is nothing simple about Swift, a language designed by C++ programmers to be a “better C++”. Just the fact it implements every collection type (String, Array, Dictionary, Set) twice—once as a class and then again as a struct—puts the lie to that. And then, of course, adopted by Apple and bodged into a “better ObjC++”. Which has even more hair on. See also: https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed/answer/Rob-Rix https://www.quora.com/Which-features-overcomplicate-Swift-Wh... “You don't just hand-wave mutability being a composable trait.” And yet, C’s `const` is composable. (Albeit not as a trait of the type itself, but I can’t think of a reason it couldn’t be.) Plus, with [im]mutability disentangled from collection implementation and a general purpose “pointer” for referring specifically to variables, the class+struct duplication can be eliminated. Let the user describe the behavioral constraints for their code, and leave the machine to decide when to allocate on heap vs stack and when to reference-count, single-owner/borrow, or pass-by-value. I may not know much about compiler engineering, but I do have a bit of experience in (Lisp-y) language design. Whereas the Swift team are compiler engineering wizards (no contest), but compiler engineers do not necessarily make good language designers (since they’re liable to design it to suit the language’s compiler engineers rather than its end users).
fit2rule 7y ago
On the subject of hair messes, I've always wondered what life would be like with a C+Lua-only style philosophy, stack, etc. And then the obvious thought occurs, a Lua editor/IDE environment built on top of that stack would be a very nice project. Basically, make everything Lua - the system services, etc. One of these days I'll sit down and play with the idea of using only LOAD81 [1], for example, to build an operating environment with a fat library of functionality .. [1] - http://github.com/antirez/load81.git http://github.com/antirez/load81.git

by hhas01 7y ago

coldtea 7y ago

>As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead They look perfectly fine to me. What did you find troubling? >TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here] The only mess described thus far is in the REPL/Playgrounds for the language, which are not themselves "Swift".

hhas01 7y ago
There are ten different pointer types, all with different and not easily memorized APIs.
- coldtea 7y ago
  Well, it's all in the name, no? And the use is rather obvious, mutable vs not, typed vs not, and buffer types (contiguous memory with count of items) or not. If only C had those how safer it would be!
  - hhas01 7y ago
    “If only C had those how safer it would be!” Indeed it would be, because then no-one would want to use C. All languages are abstractions, but there are good abstractions and there are bad abstractions, and a truly depressing number of Swift abstractions fall firmly in the “not good” camp. A well-designed type system abstraction would support and encourage free and open-ended composition of clearly-defined individual orthogonal concerns. Thus mutability would be a composable trait, `Mutable<Pointer<…>>`, untyped would just be `Pointer` without a constaint (Void being the default), and buffers would likewise be expressed via constraint, `Pointer<Buffer<TYPE,COUNT>>`. But Swift’s type system was designed by amateurs; its inconsistencies and lack of expressivity resulting in a stdlib that’s a bloated convoluted mess as it struggles around those limitations. (Makes even Ruby’s stdlib APIs look clean, consistent, and concise!)
    - SamReidHughes 7y ago
      > But Swift’s type system was designed by amateurs LOL. The amateurish type system design is the one you've described. Mutable<Pointer<...>> either makes the wrong thing mutable, or makes too much stuff mutable. Pointer<Buffer<Type, Count>> would make the whole language more complicated, and it doesn't solve any of the problems Swift's pointers solve. The Swift devs in fact are not amateurs, and it shows in how they managed to keep things simple, instead of convoluting the problem with total I-am-a-very-smart-Haskell-programmer complexity. > Thus mutability would be a composable trait I mean, this is a major tell. You don't just hand-wave mutability being a composable trait.
      - hhas01 7y ago
        “Mutable<Pointer<...>> either makes the wrong thing mutable, or makes too much stuff mutable.” You may be reading `Mutable<>` overly literally. I just used generic notation for familiarity; that doesn’t mean it’d map directly to a struct. Have it be a `mut[able]` keyword if you prefer. The point is, it can be applied to any type, and eliminates the need for let and var definitions. “Pointer<Buffer<Type, Count>> would make the whole language more complicated” Why? We’ve gone from ten single-purpose types to three general-purpose ones: Mutable<>, Pointer<>, and Buffer<>. (And, in practice, Buffer would merge with Data, so really it’s two.) “The Swift devs in fact are not amateurs, and it shows in how they managed to keep things simple” Oh really. There is nothing simple about Swift, a language designed by C++ programmers to be a “better C++”. Just the fact it implements every collection type (String, Array, Dictionary, Set) twice—once as a class and then again as a struct—puts the lie to that. And then, of course, adopted by Apple and bodged into a “better ObjC++”. Which has even more hair on. See also: https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed/answer/Rob-Rix https://www.quora.com/Which-features-overcomplicate-Swift-Wh... “You don't just hand-wave mutability being a composable trait.” And yet, C’s `const` is composable. (Albeit not as a trait of the type itself, but I can’t think of a reason it couldn’t be.) Plus, with [im]mutability disentangled from collection implementation and a general purpose “pointer” for referring specifically to variables, the class+struct duplication can be eliminated. Let the user describe the behavioral constraints for their code, and leave the machine to decide when to allocate on heap vs stack and when to reference-count, single-owner/borrow, or pass-by-value. I may not know much about compiler engineering, but I do have a bit of experience in (Lisp-y) language design. Whereas the Swift team are compiler engineering wizards (no contest), but compiler engineers do not necessarily make good language designers (since they’re liable to design it to suit the language’s compiler engineers rather than its end users).

fit2rule 7y ago

On the subject of hair messes, I've always wondered what life would be like with a C+Lua-only style philosophy, stack, etc. And then the obvious thought occurs, a Lua editor/IDE environment built on top of that stack would be a very nice project. Basically, make everything Lua - the system services, etc. One of these days I'll sit down and play with the idea of using only LOAD81 [1], for example, to build an operating environment with a fat library of functionality .. [1] - http://github.com/antirez/load81.git http://github.com/antirez/load81.git