5 ms·

>And that's the frustrating part: this stuff was and is available and well-known. At least if you bother to look and/or ask. But instead, we just choose these t

by simias 6y ago

>And that's the frustrating part: this stuff was and is available and well-known. At least if you bother to look and/or ask. But instead, we just choose these things willy-nilly and everybody has to suffer the consequences. That could be it, or that could be that these days any language that doesn't have a syntax vaguely resembling C on one hand or Python on the other it is considered niche or "weird". You'll also have an endless stream of people commenting (mostly from the Python side) that your language is noisy, because they won't take the time to understand its syntax and it won't read like pseudocode, and that's a bad thing for some reason. But I digress, because that's a pet peeve of mine. Anyway, my point is that if Swift had Smalltalk-like syntax it would not have been nearly quite as marketable. The situation with Javascript is somewhat similar: under the hood the language is more like a Lisp than C, yet it awkwardly uses C-style syntax (and weird rules for automatic semicolon insertion, because that's more like peusdocode that way, and that's a good thing for some reason).

mpweiher 6y ago
> Smalltalk-like syntax would not have been nearly quite as marketable This was one bit I left out: with Objective-C, Apple had firmly established keyword syntax in a Tiobe top 3 language, albeit within square brackets, so there was absolutely no need to do this for "marketing". It truly was snatching defeat from the jaws of victory. > that your language is noisy Smalltalk is about as syntactically quiet as you can get.
- simias 6y ago
  To be clear I wasn't making the "noisy" critique myself, it's just a qualifier I've seen, in my opinion unfairly, applied to the syntax of certain languages in the past. I think the problem is not whether the language is really noisy or not, it's more whether the language is familiar or not. Nobody complains that "(x + 1) / (y * 4)" is noisy, even though it's more symbols than numbers or letters. Everybody is familiar with mathematical notation. I think deep down a lot of the "noisy" complaints are really about unfamiliarity, and that was my point: most coders aren't familiar with Smalltalk but most coders are familiar with C-style syntax, so it wins by default in the marketability department. It's a bit like when people who are first exposed to Lisp say "oh my god all these parens!" or when Python-first coders have to code in C and say "wow, I can't believe I have to put semicolons everywhere". Yet when one is familiar with these languages the parens/semicolon kind of fade away because you see the structure behind the tokens, so to speak. I don't even consciously notice semicolons anymore, and I type them without thinking as naturally as I hit "return" at the end of a line. But if you're just starting it does take a while to get used to them.
  - neutronicus 6y ago
    The one thought about C++ Lisp completely ruined for me is giving closing braces their own line. Why do all my functions have to end with six newlines?!!??
    - saagarjha 6y ago
      Generally in C++ you shouldn't be nested your code so that you'd need six lines just for your brackets.
      - neutronicus 6y ago
        In code I control, I agree. If you're working in an early-return-hostile codebase it gets difficult, though.
    - kazinator 6y ago
      They don't. There is a workable style for C and C++ (and other "C-likes") which looks like this: int main(void) { int ch; while ((ch = getchar() != EOF) { putchar(ch); } if (ferror(stdin)) { return EXIT_FAILURE; } else { return 0; } }
      - neutronicus 6y ago
        Oh, man, do you have a .clang-format or, better yet, emacs C-style that implements this?
- kiawe_fire 6y ago
  Was not "marketing" one of the biggest driving factors of moving to Swift, though? Objective-C ranked highly in usage, but largely because of it being necessary for iOS development. At the same time, it was common outside of the Apple bubble for devs wanting to make something for iOS to complain about having to learn this "weird language with square brackets" that "only Apple uses", and "why can't we just use something like Java like we can with Android?" With, of course, zero knowledge of Objective-C's Smalltalk roots, or its purported ethos. I know it's more complicated than "square brackets bad", with all the C code mixed in, and memory release pools and all, but in general, Apple did still have a marketing problem courting outside developers to build native apps without resorting to "web view" wrappers. I love Swift, I really do, but I would love something that feels more directly Smalltalk-esque even more. Swift decidedly feels like the goal was to make something that looked familiar enough to the C / Java / Javascript / C-like devs to get them on board, without tossing out some of the core benefits of the Smalltalk ethos. Which, apparently, means using C-like methods with parentheses at first... until you reach special cases where you don't. Smalltalk is, IMO, a great example of how something can both be very expressive yet very minimal... but that inherently means ditching some very familiar syntax. As soon as you do that, you lose a lot of C-like developers (be it rightfully or wrongfully so).
  - mpweiher 6y ago
    > Apple did still have a marketing problem courting outside developers Apple categorically did not have a problem courting outside developers at this point in time. They hit 20m registered developers in 2018: https://techcrunch.com/2018/06/04/app-store-hits-20m-registered-developers-at-100b-in-revenues-500m-visitors-per-week/?guccounter=1 https://techcrunch.com/2018/06/04/app-store-hits-20m-registe... Yes, this was after the Swift announcement, but the trajectory was in place way before that. WWDC has been completely sold out for how many years? At first, it sold out in a couple of weeks, then a couple of days, then a couple of hours and finally a couple of minutes or even seconds. Then they started doing the lottery and even that was a while ago. > but that inherently means ditching some very familiar syntax Swift has tons of unfamiliar syntax. And you don't have to adopt Smalltalk as-is. Objective-Smalltalk, for example, has class definition syntax and uses curly braces. Those are not big deals. Keyword syntax, on the other hand, is a big deal, as the example of Swift shows. Because you do want argument labels, and you do want to pass closures. But that just gets messier and messier.
- novok 6y ago
  Language platforms, especially on the front end, are chosen for the customer base you can deliver to for the most part, not because the language is great or horrible unless its egregiously bad.

by simias 6y ago

mpweiher 6y ago

> Smalltalk-like syntax would not have been nearly quite as marketable This was one bit I left out: with Objective-C, Apple had firmly established keyword syntax in a Tiobe top 3 language, albeit within square brackets, so there was absolutely no need to do this for "marketing". It truly was snatching defeat from the jaws of victory. > that your language is noisy Smalltalk is about as syntactically quiet as you can get.

simias 6y ago
To be clear I wasn't making the "noisy" critique myself, it's just a qualifier I've seen, in my opinion unfairly, applied to the syntax of certain languages in the past. I think the problem is not whether the language is really noisy or not, it's more whether the language is familiar or not. Nobody complains that "(x + 1) / (y * 4)" is noisy, even though it's more symbols than numbers or letters. Everybody is familiar with mathematical notation. I think deep down a lot of the "noisy" complaints are really about unfamiliarity, and that was my point: most coders aren't familiar with Smalltalk but most coders are familiar with C-style syntax, so it wins by default in the marketability department. It's a bit like when people who are first exposed to Lisp say "oh my god all these parens!" or when Python-first coders have to code in C and say "wow, I can't believe I have to put semicolons everywhere". Yet when one is familiar with these languages the parens/semicolon kind of fade away because you see the structure behind the tokens, so to speak. I don't even consciously notice semicolons anymore, and I type them without thinking as naturally as I hit "return" at the end of a line. But if you're just starting it does take a while to get used to them.
- neutronicus 6y ago
  The one thought about C++ Lisp completely ruined for me is giving closing braces their own line. Why do all my functions have to end with six newlines?!!??
  - saagarjha 6y ago
    Generally in C++ you shouldn't be nested your code so that you'd need six lines just for your brackets.
    - neutronicus 6y ago
      In code I control, I agree. If you're working in an early-return-hostile codebase it gets difficult, though.
  - kazinator 6y ago
    They don't. There is a workable style for C and C++ (and other "C-likes") which looks like this: int main(void) { int ch; while ((ch = getchar() != EOF) { putchar(ch); } if (ferror(stdin)) { return EXIT_FAILURE; } else { return 0; } }
    - neutronicus 6y ago
      Oh, man, do you have a .clang-format or, better yet, emacs C-style that implements this?
kiawe_fire 6y ago
Was not "marketing" one of the biggest driving factors of moving to Swift, though? Objective-C ranked highly in usage, but largely because of it being necessary for iOS development. At the same time, it was common outside of the Apple bubble for devs wanting to make something for iOS to complain about having to learn this "weird language with square brackets" that "only Apple uses", and "why can't we just use something like Java like we can with Android?" With, of course, zero knowledge of Objective-C's Smalltalk roots, or its purported ethos. I know it's more complicated than "square brackets bad", with all the C code mixed in, and memory release pools and all, but in general, Apple did still have a marketing problem courting outside developers to build native apps without resorting to "web view" wrappers. I love Swift, I really do, but I would love something that feels more directly Smalltalk-esque even more. Swift decidedly feels like the goal was to make something that looked familiar enough to the C / Java / Javascript / C-like devs to get them on board, without tossing out some of the core benefits of the Smalltalk ethos. Which, apparently, means using C-like methods with parentheses at first... until you reach special cases where you don't. Smalltalk is, IMO, a great example of how something can both be very expressive yet very minimal... but that inherently means ditching some very familiar syntax. As soon as you do that, you lose a lot of C-like developers (be it rightfully or wrongfully so).
- mpweiher 6y ago
  > Apple did still have a marketing problem courting outside developers Apple categorically did not have a problem courting outside developers at this point in time. They hit 20m registered developers in 2018: https://techcrunch.com/2018/06/04/app-store-hits-20m-registered-developers-at-100b-in-revenues-500m-visitors-per-week/?guccounter=1 https://techcrunch.com/2018/06/04/app-store-hits-20m-registe... Yes, this was after the Swift announcement, but the trajectory was in place way before that. WWDC has been completely sold out for how many years? At first, it sold out in a couple of weeks, then a couple of days, then a couple of hours and finally a couple of minutes or even seconds. Then they started doing the lottery and even that was a while ago. > but that inherently means ditching some very familiar syntax Swift has tons of unfamiliar syntax. And you don't have to adopt Smalltalk as-is. Objective-Smalltalk, for example, has class definition syntax and uses curly braces. Those are not big deals. Keyword syntax, on the other hand, is a big deal, as the example of Swift shows. Because you do want argument labels, and you do want to pass closures. But that just gets messier and messier.
novok 6y ago
Language platforms, especially on the front end, are chosen for the customer base you can deliver to for the most part, not because the language is great or horrible unless its egregiously bad.