101–110 of 135 posts
Earlier quoted context omitted.
> This bending of traditional tradeoffs has let us implement features that would have been otherwise impossible. Could you talk more about what sort of features these are?
Err, he gave examples, as well as links.
Earlier quoted context omitted.
You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.
How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)? In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".
How is it not? That is a complete non-sequitur and makes no sense. What sort of definition of functional programming are you using that you think it restricts what data types you are allowed to use? Do you think you aren't allowed to use lists in C?
>In "Real World Haskell" they advise you to forgo of arrays
You might want to read it instead of misrepresenting something out of context. You might also wish to consider that many of the haskell shootout submissions came from the authors of RWH.
Earlier quoted context omitted.
> binary-trees uses artificial strictness for the sake of the benchmark Using strict evaluation when appropriate is most certainly idiomatic Haskell code. > Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance). This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we b…
There probably isn't a point to it, as we're likely trying to argue different points. I posit that using Haskell in such a way is a disservice to the language. If you want to code in such a way, why use Haskell? Haskell is plenty fast as is and doesn't need to resort to unsafe code. What's the point?
Furthermore, even if you write nearly everything in the IO monad Haskell you'll gain a lot from the type system and from easily peeling out small, meaningful pure segments.
Earlier quoted context omitted.
>I feel like in the case of some it's just parroting someone elses argument. It usually is. The reality is that like most memes like this, there's a grain of truth at the center, but most of the people repeating it don't know where the truth ends and the exaggeration begins. Regex-dna is using low level ByteString operations to squeeze out a bit of extra performance. This makes it quite a bit longer and would rarely…
> I'd hardly call it unidiomatic though, you just normally use "read" instead of "unsafeRead", etc. Isn't "idiomatic" defined by what you "normally" use?
Earlier quoted context omitted.
> I'd hardly call it unidiomatic though, you just normally use "read" instead of "unsafeRead", etc. Isn't "idiomatic" defined by what you "normally" use?
Does using a less commonly used function for its intended purpose make the code unidiomatic?
I mean: it's not like the specific problem domain needed a "less commonly used function" (e.g. you need a function to do X, where X is something that you rarely need to perform).
Rather it's: "we need to code A, but we will use less commonly used functions instead of what we'd normally use for A, just to get more performance".
Plus, it's not like you merely exchange function f with g, while all other factors stay the same. The choice of those "less commonly used functions" also affects other aspects of the program's design (e.g. making it into a more imperative style, going for unsafe, opting for mutability, etc).
So the interesting question to call it idiomatic or not, for me, is:
"If ultimate performance wasn't a factor, would a Haskell programmer write this program in the same way?"
Earlier quoted context omitted.
You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.
How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)? In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".
The normal definition of functional programming, in which not all data structures used in imperative programming are idiomatic (or even considered "functional").
For starters, mutable data structures would be considered not purely functional. E.g:
"Most books on data structures assume an imperative language such as C or C++. However, data structures for these languages do not always translate well to functional languages such as Standard ML, Haskell, or Scheme. This book describes data structures from the point of view of functional languages, with examples, and presents design techniques that allow programmers to develop their own functional data structures" [1]
[1] http://www.cambridge.org/us/academic/subjects/computer-scien...
Earlier quoted context omitted.
Rust and Go do not overlap much other than they are both natively compiled, have curly braces and are backed by 'web' companies. Go was designed for building server software and for encouraging standardized, easy to maintain software. Rust on the other hand is generally targeted at the same areas where C and C++ are used for today.
The main similarity is that Go was called a systems language for some reason, and the idea is now cached in people's minds.
Related: Would Rust be a bad choice for backend web development (ie, an alternative for Ruby/Python) and why or why not?
Earlier quoted context omitted.
Does using a less commonly used function for its intended purpose make the code unidiomatic?
If the goal of using the less commonly used functions is performance, then it probably does. I mean: it's not like the specific problem domain needed a "less commonly used function" (e.g. you need a function to do X, where X is something that you rarely need to perform). Rather it's: "we need to code A, but we will use less commonly used functions instead of what we'd normally use for A, just to get more performance"…
Yes, it is exactly like that. That was the point. It is literally changing out the name of a function. It has absolutely no effect on the rest of the code. Which is why the code is idiomatic by any reasonable definition.
Earlier quoted context omitted.
Yeah, I wonder how he manages to juggle all of that. What's your secret wycats? (I'm not really expecting there to be a single secret).
For what it's worth, a big part of this is slowly winding down earlier commitments over time. I joined TAG a couple years ago, and decided not to run again this year because I had largely achieved my original goals of changing the composition and mission of the TAG, and others can carry the torch forward. I also retired from the Rails team this year after a somewhat-long period of inactivity (from day-to-day decision…
That just might be the best piece of advice I've heard in a long time.
Earlier quoted context omitted.
Do you have an opinion on how Rust compares to Go?
Rust and Go do not overlap much other than they are both natively compiled, have curly braces and are backed by 'web' companies. Go was designed for building server software and for encouraging standardized, easy to maintain software. Rust on the other hand is generally targeted at the same areas where C and C++ are used for today.