4 ms·

IMHO there are many obscure things about Rust for newbies, and its syntax is also less readable than that of Ada. This gives me high confidence that it has a br

IMHO there are many obscure things about Rust for newbies, and its syntax is also less readable than that of Ada. This gives me high confidence that it has a bright future. I'm not being sarcastic here, Rust seems to be a great language (definitely on my list to learn), I'm really just observing. Looking at the success and history of programming languages it seems to me that many if not most professional programmers want some obscurity, a desire that is often disguised as an apparent need for brevity which in reality plays no role with modern editors. Maybe this makes sense, after all it's better to have a language that an incompetent boss or a marketing department cannot just pick up easily to 'roll their own solution'.

JulianWasTaken 10y ago
Which evidence do you see that points to obscurity or partial obscurity leading to success (or adoption, I can't tell which you're claiming)?
- hubert123 10y ago
  The fact that not every language on the planet is an implementation of Actionscript 3
- jonathanstrange 10y ago
  Not evidence, only subjective gut feelings, and I've had adoption in mind. But I'm hesitant to answer this question, because it will invariably lead to language flame-wars. Anyway, it seems to me that Algol68, Pascal, and Ada are less obscure than C and C++, but the latter are clearly more popular and have proven their worth over a long time. At the same time, implicit-block type procedural languages like Visualbasic and Realbasic/Xojo are popular, but they do not get much love from professional programmers, even though they are maybe the least obscure among all imperative mainstream languages. LISPs are also an interesting case, S-expressions are among the least complicated and easiest to grasp syntax and CommonLisp offers practically everything a programmer could ever wish for (including multiple dispatch) but it never became very popular. But maybe I'm wrong. For example, advanced Lisp macrology is definitely obscure, so that should count in favor of Lisp being more popular according to me 'hypothesis'. Haskell syntax is fairly easy, but monads are certainly obscure, yet Haskell does not seem very popular. Likewise, Python does not seem to be very obscure, it certainly isn't syntax-wise, and it's still very popular. So I don't know, perhaps my assessment was premature. It almost certainly was. ;-) I've just always had this impression that many programmers prefer a certain amount of special trickery and shortcuts over clarity. But perhaps it's the availability of libraries what counts most in the end.
  - pjmlp 10y ago
    A big problem is that many of us that used to be on the Algol/Pascal camp had this utopic idea that engineers care for quality and would choose tools that provide such support. Wirth has a nice paper where he writes about the error of not doing any PR and thinking "build and they will come" would just work. https://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf https://www.inf.ethz.ch/personal/wirth/Articles/Modula-Obero... Check the "Conclusions and Reflections" chapter.
  - fpig 10y ago
    C is FAR less obscure than most of the languages you mention, ignoring things newbies generally don't need to worry about like standards, compiler implementations, memory alignment, virtual memory, etc. I was able to learn C reasonably well as a child precisely because of how straightforward it is. You can reserve a block of memory. You can free it. You can get the address of a value. You can get the value from an address. It works in an extremely straightforward way, unlike most languages. To a child, programming in C feels like the computer is doing exactly what it was told to do and nothing else. It feels like you understand what is going on, even though your understanding is a very simplified model of what is actually going on. Modern languages like C#, Javascript, Ruby... They are much harder to understand than C. The first time I saw a closure, I was completely dumbfounded. This doesn't make sense, a function is accessing a local variable of another function that has since been popped off the stack! What sorcery is this?? Even today things often confuse me, when I saw C# async/await for the first time I just couldn't understand how it can possibly work until I spent some time reading about it and I had been programming for decades by then including a decade in C#.
    - paulddraper 10y ago
      > This doesn't make sense, a function is accessing a local variable of another function that has since been popped off the stack! That's only weird to you because C doesn't do it. For someone starting in one of those languages, it simply makes sense that I can use any variable in scope. (Stack allocation? What is this sorcery you speak of?)
threatofrain 10y ago
I don't think the spread in difficulty between a non-obscured production programming language versus a highly obscured language falls within the range of a boss or marketing department. I feel that what the general populace would require, if you wish to see programming languages more widespread, would be an ease of interface akin to a quality WYSIWYG editor, which companies have been working on for awhile. I would love to use such an editor myself, instead allocating my new cognitive savings for problem solving. The gulf between WYSIWYG and the least-obscured / fewest constructs / best ergonomics / best developer UX / etc language still seems rather immense, even if you're thinking about Scratch. In Scratch you're dragging and dropping statements of logic, whereas in a WYSIWYG editor you're dragging and dropping elements of the page as you actually want it to look. The latter is much more declarative, and in range of what small business people want. I would argue that dragging and dropping for loops in Scratch really only helps for those who have keyboard difficulties. It's still a for loop. I'd also add as a side point that obscurantism doesn't always mean bad ergonomics or bad UX. Sometimes it protects cognitive resources, and other times, when you are forced to dig, the bet for cognitive savings fails.
MoSal 10y ago
What's syntactically obscure about Rust? I only knew(and liked) C reasonably well before Rust. And nothing felt obscure when I started learning it. I can only remember not getting what `||` meant (in the context of defining a closure without args). The positional meaning of `||` and `&&` is the only thing, I can recall right now, that can be considered obscure syntactically (for C developers at least) . They should have gone with literal `and`/`or` for the operators IMHO.
- Thiez 10y ago
  I suppose it can get a little silly when you mix closures without arguments and the logical 'or' operator', e.g.: // prints 'true' println!("{}", true||(||true)()||(||true)()); Of course you wouldn't actually do this unless you're being intentionally obscure. Another favorite of mine: // prints '()' println!("{:?}", (||||||||||())()()()()()); But I can't recall ever running into such silly code, in practice the closure syntax and logical or do not lead to confusion (imho, ymmv).
  - MoSal 10y ago
    > in practice the closure syntax and logical or do not lead to confusion (imho, ymmv). That's true. But put your self in the mind of a C developer looking at Rust code for the first time: if a || b { println!("True"); } Cool. Then: thread::spawn(|| println!("Hello from a thread!");); What? What is the logical or doing there? ---- IIRC, there are also cases where you have to write `& &` instead of `&&` to not confuse the compiler. That's a design/practical issue. Both those issues would have been avoided if literal `and`/`or` were used. I find it interesting how the only thing that momentarily confused me, as a C developer, about Rust syntax, was caused by Rust authors not wanting to syntactically deviate too much from C.

JulianWasTaken 10y ago

Which evidence do you see that points to obscurity or partial obscurity leading to success (or adoption, I can't tell which you're claiming)?

hubert123 10y ago
The fact that not every language on the planet is an implementation of Actionscript 3
jonathanstrange 10y ago
Not evidence, only subjective gut feelings, and I've had adoption in mind. But I'm hesitant to answer this question, because it will invariably lead to language flame-wars. Anyway, it seems to me that Algol68, Pascal, and Ada are less obscure than C and C++, but the latter are clearly more popular and have proven their worth over a long time. At the same time, implicit-block type procedural languages like Visualbasic and Realbasic/Xojo are popular, but they do not get much love from professional programmers, even though they are maybe the least obscure among all imperative mainstream languages. LISPs are also an interesting case, S-expressions are among the least complicated and easiest to grasp syntax and CommonLisp offers practically everything a programmer could ever wish for (including multiple dispatch) but it never became very popular. But maybe I'm wrong. For example, advanced Lisp macrology is definitely obscure, so that should count in favor of Lisp being more popular according to me 'hypothesis'. Haskell syntax is fairly easy, but monads are certainly obscure, yet Haskell does not seem very popular. Likewise, Python does not seem to be very obscure, it certainly isn't syntax-wise, and it's still very popular. So I don't know, perhaps my assessment was premature. It almost certainly was. ;-) I've just always had this impression that many programmers prefer a certain amount of special trickery and shortcuts over clarity. But perhaps it's the availability of libraries what counts most in the end.
- pjmlp 10y ago
  A big problem is that many of us that used to be on the Algol/Pascal camp had this utopic idea that engineers care for quality and would choose tools that provide such support. Wirth has a nice paper where he writes about the error of not doing any PR and thinking "build and they will come" would just work. https://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf https://www.inf.ethz.ch/personal/wirth/Articles/Modula-Obero... Check the "Conclusions and Reflections" chapter.
- fpig 10y ago
  C is FAR less obscure than most of the languages you mention, ignoring things newbies generally don't need to worry about like standards, compiler implementations, memory alignment, virtual memory, etc. I was able to learn C reasonably well as a child precisely because of how straightforward it is. You can reserve a block of memory. You can free it. You can get the address of a value. You can get the value from an address. It works in an extremely straightforward way, unlike most languages. To a child, programming in C feels like the computer is doing exactly what it was told to do and nothing else. It feels like you understand what is going on, even though your understanding is a very simplified model of what is actually going on. Modern languages like C#, Javascript, Ruby... They are much harder to understand than C. The first time I saw a closure, I was completely dumbfounded. This doesn't make sense, a function is accessing a local variable of another function that has since been popped off the stack! What sorcery is this?? Even today things often confuse me, when I saw C# async/await for the first time I just couldn't understand how it can possibly work until I spent some time reading about it and I had been programming for decades by then including a decade in C#.
  - paulddraper 10y ago
    > This doesn't make sense, a function is accessing a local variable of another function that has since been popped off the stack! That's only weird to you because C doesn't do it. For someone starting in one of those languages, it simply makes sense that I can use any variable in scope. (Stack allocation? What is this sorcery you speak of?)

threatofrain 10y ago

I don't think the spread in difficulty between a non-obscured production programming language versus a highly obscured language falls within the range of a boss or marketing department. I feel that what the general populace would require, if you wish to see programming languages more widespread, would be an ease of interface akin to a quality WYSIWYG editor, which companies have been working on for awhile. I would love to use such an editor myself, instead allocating my new cognitive savings for problem solving. The gulf between WYSIWYG and the least-obscured / fewest constructs / best ergonomics / best developer UX / etc language still seems rather immense, even if you're thinking about Scratch. In Scratch you're dragging and dropping statements of logic, whereas in a WYSIWYG editor you're dragging and dropping elements of the page as you actually want it to look. The latter is much more declarative, and in range of what small business people want. I would argue that dragging and dropping for loops in Scratch really only helps for those who have keyboard difficulties. It's still a for loop. I'd also add as a side point that obscurantism doesn't always mean bad ergonomics or bad UX. Sometimes it protects cognitive resources, and other times, when you are forced to dig, the bet for cognitive savings fails.

MoSal 10y ago

What's syntactically obscure about Rust? I only knew(and liked) C reasonably well before Rust. And nothing felt obscure when I started learning it. I can only remember not getting what `||` meant (in the context of defining a closure without args). The positional meaning of `||` and `&&` is the only thing, I can recall right now, that can be considered obscure syntactically (for C developers at least) . They should have gone with literal `and`/`or` for the operators IMHO.

Thiez 10y ago
I suppose it can get a little silly when you mix closures without arguments and the logical 'or' operator', e.g.: // prints 'true' println!("{}", true||(||true)()||(||true)()); Of course you wouldn't actually do this unless you're being intentionally obscure. Another favorite of mine: // prints '()' println!("{:?}", (||||||||||())()()()()()); But I can't recall ever running into such silly code, in practice the closure syntax and logical or do not lead to confusion (imho, ymmv).
- MoSal 10y ago
  > in practice the closure syntax and logical or do not lead to confusion (imho, ymmv). That's true. But put your self in the mind of a C developer looking at Rust code for the first time: if a || b { println!("True"); } Cool. Then: thread::spawn(|| println!("Hello from a thread!");); What? What is the logical or doing there? ---- IIRC, there are also cases where you have to write `& &` instead of `&&` to not confuse the compiler. That's a design/practical issue. Both those issues would have been avoided if literal `and`/`or` were used. I find it interesting how the only thing that momentarily confused me, as a C developer, about Rust syntax, was caused by Rust authors not wanting to syntactically deviate too much from C.