Imperative + Functional == :-)(bluebytesoftware.com)
bluebytesoftware.com
Imperative + Functional == :-)
http://www.bluebytesoftware.com/blog/2012/12/08/ImperativeFunctional.aspx
6 comments
This gentleman seems to be talking about a dialect of C# with more functional idioms and parallel-programming friendly features. However, a link describing the actual language itself would have been much more interesting. Briefly looking at the PDF, it doesn't seem to offer much more than rust (apart from .NET interop, which is certainly nothing to sneeze at, if it's your cup of tea), though the mention of a team at Microsoft using it as its primary language and having delivered "millions of lines of code" with it hints at a greater maturity.
You appear to be an emissary from the Rust community.
Let me make a request and hope you can forward it on to your dark masters in the land of Mozilla.
Please stop using every single topic on HN to mention "Rust does it better".
Bonus points: show off things actually made with Rust.
I've let it slide up to this point because any attempt to "get serious" was always countered with the excuse, "we're not reeeeaaaaady".
If you're going to keep proselytizing, you're going to be held to a higher standard. Also mentioning that Rust does it better without mentioning specifics is pretty much the opposite of useful. All you're doing is namedropping, not sharing knowledge or meaningful information.
Summary of my preferred reactions to this comment:
1. Add more content to your comment so it's substantive rather than name-dropping
2. Ask the Rust community to stop trying to outdo the Haskell community at propagandizing (hi dons!)
3. Start building things in Rust and show HN. A brief blog post describing pros/cons/future improvements would be boss.
Let me make a request and hope you can forward it on to your dark masters in the land of Mozilla.
Please stop using every single topic on HN to mention "Rust does it better".
Bonus points: show off things actually made with Rust.
I've let it slide up to this point because any attempt to "get serious" was always countered with the excuse, "we're not reeeeaaaaady".
If you're going to keep proselytizing, you're going to be held to a higher standard. Also mentioning that Rust does it better without mentioning specifics is pretty much the opposite of useful. All you're doing is namedropping, not sharing knowledge or meaningful information.
Summary of my preferred reactions to this comment:
1. Add more content to your comment so it's substantive rather than name-dropping
2. Ask the Rust community to stop trying to outdo the Haskell community at propagandizing (hi dons!)
3. Start building things in Rust and show HN. A brief blog post describing pros/cons/future improvements would be boss.
You seem to be taking this very personally AND making unwarranted assumptions.
Let me correct a few of your misapprehensions.
> You appear to be an emissary from the Rust community.
I follow Rust with interest, because I like a lot of its basic principles. This does not make me any kind of "emissary".
> Let me make a request and hope you can forward it on to your dark masters in the land of Mozilla.
I am in no way affiliated with the Mozilla organization.
> Please stop using every single topic on HN to mention "Rust does it better".
I am also not aware of 'using every single topic on HN to mention "Rust does it better". In particular, you may note the lack of the word "better" in my comment.
> 1. Add more content to your comment so it's substantive rather than name-dropping
This is quite ironic considering the meat of my post was a complaint about the lack of content in TFA.
> 2. Ask the Rust community to stop trying to outdo the Haskell community at propagandizing (hi dons!)
Again, I'm not clear where you see proselityzing in my post. Maybe there was something unclear about the way I wrote, but the idea was to take something ill-defined (the C# dialect in question) and compare it to something with clearly defined semantics which has been discussed here before. I've made no claim at superiority of one approach against the other. Considering how little there is in the article, it would have been silly even if I had been so inclined.
> 3. Start building things in Rust and show HN. A brief blog post describing pros/cons/future improvements would be boss.
Again, you seem to be reading more in my post than what I wrote. That said, and to address the point you raise here, the big problem with Rust until now is the syntax and feature sets has undergone significant changes between point releases, which is not an incentive to spend a lot of man-hours working on it just yet.
Let me correct a few of your misapprehensions.
> You appear to be an emissary from the Rust community.
I follow Rust with interest, because I like a lot of its basic principles. This does not make me any kind of "emissary".
> Let me make a request and hope you can forward it on to your dark masters in the land of Mozilla.
I am in no way affiliated with the Mozilla organization.
> Please stop using every single topic on HN to mention "Rust does it better".
I am also not aware of 'using every single topic on HN to mention "Rust does it better". In particular, you may note the lack of the word "better" in my comment.
> 1. Add more content to your comment so it's substantive rather than name-dropping
This is quite ironic considering the meat of my post was a complaint about the lack of content in TFA.
> 2. Ask the Rust community to stop trying to outdo the Haskell community at propagandizing (hi dons!)
Again, I'm not clear where you see proselityzing in my post. Maybe there was something unclear about the way I wrote, but the idea was to take something ill-defined (the C# dialect in question) and compare it to something with clearly defined semantics which has been discussed here before. I've made no claim at superiority of one approach against the other. Considering how little there is in the article, it would have been silly even if I had been so inclined.
> 3. Start building things in Rust and show HN. A brief blog post describing pros/cons/future improvements would be boss.
Again, you seem to be reading more in my post than what I wrote. That said, and to address the point you raise here, the big problem with Rust until now is the syntax and feature sets has undergone significant changes between point releases, which is not an incentive to spend a lot of man-hours working on it just yet.
I compiled rust tonight. It took longer to compile than it took me to read all the documentation. Strike one.
I too am not affiliated to Mozilla, unless the browser I'm using makes me an affiliated member. However judging from their discussion group, they know it's a problem and will probably try to reduce it to 15min(this is their goal, not their achieved min speed). Sadly, speed of compilation probably won't beat Go's which is 2min.
I do understand your complaint, but dismissing an alpha language because it compilation is too long, or documentation isn't up to par is a bit of an overstretch. They haven't been optimizing for it and the syntax is shifting, so making documentation at this point is like building a house on a sand pit.
I do understand your complaint, but dismissing an alpha language because it compilation is too long, or documentation isn't up to par is a bit of an overstretch. They haven't been optimizing for it and the syntax is shifting, so making documentation at this point is like building a house on a sand pit.
This is unfair.
Rust still builds LLVM toolchain (all of it!) to bootstrap itself.
As far as I know, they are planning to remove this dependency before Rust gets to 1.0.
Rust still builds LLVM toolchain (all of it!) to bootstrap itself.
As far as I know, they are planning to remove this dependency before Rust gets to 1.0.
They're having to use a custom version of LLVM (for GC reasons, I think) but havent yet got the patches back into the upstream mainline (but are presumably planning to).
Hah, all sane modern languages needs to patch LLVM for GC reasons :) The guys writing it did not really know a lot about that area and how to get those intrinsic features into the LLVM proper.
Congrats, you encountered my first complaint with Rust. Let me know how much fun the out-of-date documentation referencing syntax that no longer exists is.
If you ask about it or seek a redress you'll be told, "we're not reeeaaaaaady".
It's a state of affairs they've come to be quite comfortable with.
You're supposed to use Rust unless you're a Mozilla employee or intern, afaict.
If you ask about it or seek a redress you'll be told, "we're not reeeaaaaaady".
It's a state of affairs they've come to be quite comfortable with.
You're supposed to use Rust unless you're a Mozilla employee or intern, afaict.
What do you expect? They aren't ready.
I'm following the development of Rust with much interest. The design seems well-thought out, and occasional comments here by 'pcwalton, usually along the lines of “here's how we're trying to solve this problem in Rust”, are always worth a read. I wouldn't start a project in it, however, for at least another year unless my main goal was to experiment with the language.
When I did play with it a little, I indeed ran into problems with out-of-date documentation, but someone in #rust IRC (I think it was 'brson) very helpfully answered my questions and pointed me to some newer docs.
Perhaps your expectations are unrealistic. If you want a language you can use today for a real project, try Clojure or Go. I don't think you can fault the Rust project for being where they are now and communicating honestly.
I'm following the development of Rust with much interest. The design seems well-thought out, and occasional comments here by 'pcwalton, usually along the lines of “here's how we're trying to solve this problem in Rust”, are always worth a read. I wouldn't start a project in it, however, for at least another year unless my main goal was to experiment with the language.
When I did play with it a little, I indeed ran into problems with out-of-date documentation, but someone in #rust IRC (I think it was 'brson) very helpfully answered my questions and pointed me to some newer docs.
Perhaps your expectations are unrealistic. If you want a language you can use today for a real project, try Clojure or Go. I don't think you can fault the Rust project for being where they are now and communicating honestly.
Maybe you just shouldn't use it now when it's not ready.
There is no reason to complain about missing documentation or other stuff if they didn't get to do it until now. That what "not ready" means. Keep calm and wait ;-)
The paper is at http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf (the redirection fails, but the url is in the query string...)
Interesting goals but....
>> 1. Create a single language that incorporates the best of functional and imperative programming. Both offer distinct advantages, and we envisioned marrying the two.
Imperative/Functional hybrid are nothing new. C#, Ruby, Python, Javascript, Scala, and Groovy all fit that bill.
>> 2. Codify and statically enforce common shared-memory state patterns, such as immutability and isolation, with minimal runtime overhead (i.e., virtually none).
"Statically enforcing variable immutability...." Isn't that just a fancy word for "constant"?
>> 4. Do all of this while still offering industry-leading code quality and performance, rivaling that of systems-level C programs. Yet still with the safety implied by the above mentioned goals.
He wants to allow for "pockets of imperative mutability tied together with functional tissue". That's not a bad thing but it's not exactly a "safe" feature if put in the wrong hands. Lots of people have written function objects with bad imperative code and side effects. Lots of people have fed them to their language's equivalent of the map function. That can cause bugs.
>> 1. Create a single language that incorporates the best of functional and imperative programming. Both offer distinct advantages, and we envisioned marrying the two.
Imperative/Functional hybrid are nothing new. C#, Ruby, Python, Javascript, Scala, and Groovy all fit that bill.
>> 2. Codify and statically enforce common shared-memory state patterns, such as immutability and isolation, with minimal runtime overhead (i.e., virtually none).
"Statically enforcing variable immutability...." Isn't that just a fancy word for "constant"?
>> 4. Do all of this while still offering industry-leading code quality and performance, rivaling that of systems-level C programs. Yet still with the safety implied by the above mentioned goals.
He wants to allow for "pockets of imperative mutability tied together with functional tissue". That's not a bad thing but it's not exactly a "safe" feature if put in the wrong hands. Lots of people have written function objects with bad imperative code and side effects. Lots of people have fed them to their language's equivalent of the map function. That can cause bugs.
The strength of this system is that map is type checked to be provably side-effect free. The mapping function is free to internally allocate and mutate objects to get its job done, e.g. a RegexMatcher, but it may not mutate existing (non-isolated) state. This composes transitively, so even wrapping side-effects in abstractions and closures is insufficient to hide them.
> Imperative/Functional hybrid are nothing new. C#, Ruby, Python, Javascript, Scala, and Groovy all fit that bill.
Some of those languages are more functional than others. The Scala creator claims it's 50% imperative 50% functional. Others of those, e.g. C# and Groovy, are closer to 10 or 20% functional.
Some of those languages are more functional than others. The Scala creator claims it's 50% imperative 50% functional. Others of those, e.g. C# and Groovy, are closer to 10 or 20% functional.
It a certain degree, beauty is a better indicator than percentages when it comes to how functional a programming language is. Scheme scores high in that regard. Python does okay if you stay moderate in it's usage. Any amount of functional programming in Java tends to be downright ugly and unlikely to pass most code reviews.
This is a blog article from one of the researchers on a project to bring more immutability to C#, among other things. The paper the article references is well-summarized in a C# context here: http://www.infoq.com/news/2012/12/Immutable-CSharp
another thread, blog ref'g this paper
https://news.ycombinator.com/item?id=4871661
https://news.ycombinator.com/item?id=4871661