10 ms·
Stroustrup's Rule and Layering Over Time in Rust
- smegel 10y agoThis is worse than Perl.
- sfilargi 10y agoWhat I really appreciate in a language, especially when I am starting out with it, is the Python's slogan "only one way to do it".
- zafta 10y ago(except for string formatting)
- to3m 10y agoOur one way to do it is Python 2.7, and Pyth... hmm, let's try that again...
- ajross 10y agoWhich doesn't work, even in Python. Python 1.0 could iterate over various collections with straightforward syntax that still works. No such programmer would recognize the functional style that's taken over for iteration in the modern language. Likewise the evolution from list comprehensions to generators left us with some terribly overlapping syntax.
- sfilargi 10y agoCan't argue with that, but what I really said was that in contrast to the article, and Stroupstrup's rule, if I was to design a language I would put the "one way to do it" very high in my priorities. Going with let's have "explicit syntax" now until the users get familiar with it and we will make it more terse later, is not a good idea IHMO. But I do understand and appreciate that sometimes evolutionary changes will bring in duplication, so I am in no way attacking Rust and the specific example of the evolution of the error handling syntax.
- kibwen 10y ago> Going with let's have "explicit syntax" now until the > users get familiar with it and we will make it more > terse later is not a good idea IHMO. I don't think this is a conscious decision. IMO, when you're first designing a language, you don't necessarily know what idioms are going to be most common, so you use special syntax sparingly, and force users to be explicit everywhere else. Then, once you have experience with how people use the language and can empirically observe what idioms are popular, you favor those idioms with shorthand syntax. Getting back to the specific example in the OP, for a long time there was a discussion on whether Rust should use the question mark for some dedicated syntax (having removed the C-style ternary operator in 2012 as redundant with `if`). But people disagreed on what to use it for: some wanted to use it to designate functions that return booleans (like Ruby does); others wanted to use it to designate functions that return Option (my original stance, way back when); others wanted it as sugar for constructing and typing Options (as Swift eventually did); some wanted a C#-style coalescing operator. But after years of experience it turns out that none of the above are especially prevalent in Rust, especially once the community embraced the Result type (which matured relatively late in Rust's development) for most of what Option had originally been used for. In retrospect having a terse way to handle Results is an obvious win and I absolutely adore the new `?` operator, but it takes time to produce the evidence that such things are truly worth their weight.
- sfilargi 10y agoAck. Maybe I misunderstood the article then! When I read: For new features, people insist on LOUD explicit syntax. For established features, people want terse notation. I understood, keep it explicit to begin with, and make it terse when users get familiar. Probably I got it wrong.
- kibwen 10y agoI don't think you're wrong, I just think that you're overlooking that not all features eventually receive terse notation. Some stay loud and explicit forever! Only a few, relatively important features receive terse notation, and knowing which features those are requires observing how the language is used.
- Animats 10y agoNow Python has asynchronous list comprehensions, for which there seem to be few use cases. If Python supported compute parallelism it might be useful, but Python async is only for async I/O.
- agumonkey 10y agoMaybe languages should provide starter pack, not batteries (as in libraries made noob friendly). Just enough vocabulary in a module to go along with most needs.
- shakna 10y agoSo... Like Scheme? R5RS or R7RS?
- zardeh 10y agoIts important to read that line in context: >There should be one-- and preferably only one --obvious way to do it. The zen of python isn't saying "only have one way to do anything" it says "have at least one obvious way, and preferably only one obvious way to do this". There can be lots of ways to iterate over a list: [x for x in l] for x in l: x while (x for x in [1,2,3]).next(): ... Only one is obvious for a given situation.
- AceJohnny2 10y agoChange takes time! This is a great example, as he has specific instances of evolving syntax to describe the same thing, semantically. The big problem, of course, is that code hangs around. Can you evolve your syntax as people get used to it? Not only are you adding work to your parser, but people who use your language also have to deal with the multiple iterations of the syntax that linger in various codebases. This is one reason I detest dealing with Perl codebases. Anyhow, as an exercise of evolving syntax while keeping the underlying semantics, I find Reason [1], a new syntactic layer over OCaml, particularly interesting. [1] https://facebook.github.io/reason/ https://facebook.github.io/reason/
- sriram_sun 10y agoTrue. However, it would also be nice if there is an automated upgrade path for syntactic changes like python 2to3.
- nickm12 10y agoPython 2 to Python 3 is a semantic change, which is why it has been so slow going for some codebases.
- dherman 10y agoThe reason for layering is that the lower layer code remains compatible and even, let's say, idiomatically acceptable if excessively verbose.
- stymaar 10y ago> Can you evolve your syntax as people get used to it? Not only are you adding work to your parser, but people who use your language also have to deal with the multiple iterations of the syntax that linger in various codebases. Clippy[1] helps a lot in this case, it helps people writting idiomatic Rust and it's updated when new syntaxes introduces new ways to do stuff, so the old one is deprecated _de facto_. [1] https://github.com/Manishearth/rust-clippy https://github.com/Manishearth/rust-clippy
- 10y ago
- akkartik 10y agoFascinating example of the Overton Window (https://en.wikipedia.org/wiki/Overton_window https://en.wikipedia.org/wiki/Overton_window) and Milo Criterion (http://www.ribbonfarm.com/2011/09/23/the-milo-criterion http://www.ribbonfarm.com/2011/09/23/the-milo-criterion) in action in software.
- agumonkey 10y agoReading about Milo reminded me of MSOffice Ribbon. And now I wonder if there are reflection or theories about social fluid dynamics and how to redirect a flow of people into something radical-looking without creating turmoil.
- akkartik 10y agoThe same site has this later post about the transition process for a big change, which partially answers your question: http://www.ribbonfarm.com/2014/09/24/the-rhythms-of-information-flow-pacing-and-spacetime http://www.ribbonfarm.com/2014/09/24/the-rhythms-of-informat.... It's a very alien worldview for most developers, who tend to focus all their attention on designing a feature and none on designing the transition process for the feature.
- agumonkey 10y agoWhat a long article, I am thrilled (no sarcasm, I love everything about rhythm).
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- Teckla 10y agoI often feel like I'm the only software developer in the world that thinks most programming languages are evolving in the wrong direction. Our civilization is going to end up with countless dead languages -- dead programming languages, that is -- because future generations won't know how to read the increasingly terse and arcane syntax that is all the rage these days. Either that, or the investment necessary to read these crazy languages will be considered an ill advised investment in resources. We'll end up recreating the wheel indefinitely, but in different languages. I would like to see much, much simpler programming languages, even if they're more verbose, as long as the result is improved readability and longevity of the code written in said languages. I think some of the older languages are far superior in many ways, if only because, with some of them, you can actually read and understand the code without even any formal training in the language.
- gambogi 10y ago> you can actually read and understand the code without even any formal training in the language. Forgive my youth, which languages are these?
- jandrese 10y agoI taught myself HyperTalk with no formal programming training by reading the source code embedded in scripts.
- jzwinck 10y agoSome examples might be COBOL, Java, BASIC, and Logo. Of course reading any program still requires a mind accustomed to logical thought. A subsistence farmer has a different sort of "no formal training" than an 18 year old taking Chemisty courses. In any case there is no need to worry...the important thing is the ideas not the syntax. And the useful ideas tend to be conveyed through time in multiple languages.
- int_19h 10y agoI can't speak for COBOL and Logo... but Java, really? When you're looking at a hello world program in it, 80% of it doesn't make sense to someone not familiar with the concept - import? class? static? void? BASIC is even worse in many respects. It starts being deceptively simple, but do you think that someone looking at these two lines: PRINT a, b; PRINT a; b would be able to tell the difference? Or, say, what does this do? LINE (0, 0) - (100, 100),, BF (no, it doesn't draw a line) And then if we're talking about classic BASIC, you have to remember that A% is integer while A$ is string etc. None of that is at all obvious. Or, say, you see this: NAME x AS y A reasonable guess would be that it renames a variable, or maybe creates an alias, right? But no - it actually renames a file with a name corresponding to a value in variable x, to a new name corresponding to a value in variable y. And many BASIC dialects will even helpfully stringize it for you, if the variables were, say, integers.
- EugeneOZ 10y agoIt only works when your function returns error of the same type as expression inside 'try!' or '?' macros. So in a lot of cases it doesn't work or forces programmer to return underlying type of error, instead of error which belongs to current level of visibility (in other words, it provokes programmer to violate encapsulation for the sake of lazyness). Also it means we have 2 ways to do same thing and users have to know this small trick even to read code (so it raises entry level). I love Rust language and feel sorry for this criticism. But small things are important.
- edmccard 10y ago>It only works when your function returns error of the same type as expression inside 'try!' or '?' macros. So in a lot of cases it doesn't work or forces programmer to return underlying type of error Or you can implement a conversion from the underlying error to your custom error type[1], and 'try'/'?' will just work. [1]https://doc.rust-lang.org/book/error-handling.html#composing-custom-error-types https://doc.rust-lang.org/book/error-handling.html#composing...
- EugeneOZ 10y agoPlease see reply in nearby comment (to follow DRY principle :)), and I want to note that second reason is also important: a lot of people are scared already by initial complexity of Rust and Rust's syntax. It's a mistake, because after couple of months Rust looks not more difficult than PHP or JavaScript (but gives much more satisfaction). So less quirks Rust will have - more readable and predictable code will be for newcomers.
- cfallin 10y ago> It only works when your function returns error of the same type as expression inside 'try!' or '?' macros. The language has actually thought of this case -- it turns out you can map lower-level errors into your higher-level error type by implementing the `From<E>` trait. E.g.: use std::io; pub enum MyErr { Io(io::Error), Custom(String) } impl From<io::Error> for MyErr { fn from(err: io::Error) -> MyErr { MyErr::Io(err) } } fn do_stuff() -> Result<(), MyErr> { let f = try!(File::open(...)); // ... }
- FrancoDiaz 10y ago"syntax doesn't matter, only semantics!" is what I classify as geek machismo. I used to see a lot of that over at http://lambda-the-ultimate.org http://lambda-the-ultimate.org in its heyday.
- Retra 10y agoIt's basically a pedant's creed. I really wish everyone who desired to express that point would translate it into some forgotten language first, just to drive the irony deep.
- Too 10y agoFollowing this rule, maybe it's time to add a shorthand for std::unique_ptr<> to c++ already. I'm not really a fan of asterixes or ampersands either but 17 characters, 5 of them requiring shift modifier, for something you write that often quickly becomes annoying.
- alfanick 10y agoUsually I define new types, when I use them a lot like: class Something { typedef std::unique_ptr<Something> unique; typedef std::shared_ptr<Something> shared; typedef std::weak_ptr<Something> weak; }; // ... // later in the code Something::unique a; // instead of std::unique_ptr<Something> a;
- eropple 10y agoThat's a neat way of handling it. I wouldn't have considered it. I think I'm gonna steal it.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- CyberDildonics 10y agotemplate<class T> using unq = std::unique_ptr<T>; This is a start, then I usually define specific types from there.
- dtheodor 10y agoI really don't see Rust as a good example of a language getting its syntax right. It reads like Perl. You know what's good syntax? The one that reads like pseudocode (Python is the closest to that).
- Daishiman 10y agoPerl has infinity ways of describing the same computation with no clear best practices in many cases. Rust's problem is the same that any language in its domain encounters: it must encode a lot more information than similar scripting languages in order to describe the semantics of this program. It most certainly does not read like Perl. The sigils are weird but there's few of them and they're used consistently and without overloaded meaning. And unless you want to make a horrendously verbose language by assigning keywords to stuff related to lifetimes, pointers and references, it attempts to strike the balance between readability and compactness for the experienced developer. Rust used to have a lot more sigils. Its syntax and semantics are nowadays a lot simpler than languages in the same domain (C++ I'm looking at you) and a lot of the complexity has been pushed into the traits system, IMO for the better.
- steveklabnik 10y agoHave you looked at Rust lately? We used to get that comparison a lot, back when we had a lot of sigils, but we've removed those by now. The ones we do have are very similar to C-family languages.