3 ms·

There are a couple of features I'd love Crystal to have, but I might be in the minority. One, immutability by default, or rather, make immutability more the rul

There are a couple of features I'd love Crystal to have, but I might be in the minority. One, immutability by default, or rather, make immutability more the rule than the exception. Two, type checked named parameters/keyword arguments. Yes they are verbose, but they make it much more clear what the code is doing upon 2nd, 3rd,..... 100th reading than something like MyObject.method(a, b, 1, zurb, foobar, false, -1, "bob"), where the order is important and the variables don't ned to be well named. Swift, Kotlin, and Scala seem to be the only significant languages to get both features pretty close to what I'd want. Otherwise, I don't see much in the language space that scratches that itch. Those three languages seem to be the closest to getting "the future" right when it comes to the "next generation" of languages - functional, object oriented, type checked and compiled languages with a bit of dynamic checking/inference for programmer convenience. Other languages seem to be too much in other particular directions to get the benefit of different styles where it makes sense. I had high hopes for Mirah, but it hasn't really evolved the way I'd hoped. I don't know if my notion for a language is the right direction for Crystal, but I'd love it if someone came along and made my "perfect language" for me. It'd be one less thing to build myself.

Igglyboo 12y ago
Curious, I've been hearing a lot lately about functional languages and immutability and wasn't quite sure how it worked. I agree with it in premise but it seems like all these immutable data structures introduce massive overhead. What is going on behind the scenes when I modify a single value in an array with 10k members? Surely it's not going to create an entirely new array.
- programminggeek 12y ago
  It might do that wildly inefficient thing... Or, you might do something where you have a list of pointers, and you point at a different value instead of mutating an existing value. I haven't dug into the details of how immutable data structures can be made to work efficiently, but part of the charm is that in many cases you don't mutate the array at all. What I mean is, there are certain behaviors around mutation that programmers do because they can. When you take away the ability to mutate data, you design differently and without side effects. All of a sudden testing becomes easier, faster, cheaper for large parts of your codebase. You have simpler solutions that are potentially easier to reason about because the complex (and sometimes elegant) solutions aren't so readily available. A few talks that are around this style of thinking: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=tq5SQ4W3gRI https://www.youtube.com/watch?v=tq5SQ4W3gRI http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy Boundaries are good, values are good, simple things that work together are good. The more we can take the good parts and form them together into a cohesive language/framework/platform, the better our software will be.
- rdc12 12y ago
  This book is more or less the definitive book on functional persistent data structures. More about how to design and reason about them, then a collection book. http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504 http://www.amazon.com/Purely-Functional-Structures-Chris-Oka...
- Dewie 12y ago
  > Curious, I've been hearing a lot lately about functional languages and immutability and wasn't quite sure how it worked. I agree with it in premise but it seems like all these immutable data structures introduce massive overhead. There is some seemingly inherent overhead for certain data structures. On the other hand it allows for structural sharing, and plays more nicely with concurrency and whatnot. Suffice it to say that you'd be wise to design your immutable (persistent, specifically) data structures very differently to how you would design your regular imperative data structures. There was a famous PhD dissertation - now a book - on the topic. You'll find it easily enough if you search for it. Yes, immutable data structures seem very inefficient. But they're implemented in a more clever way than to just take regular imperative data structures and copying for every "update" instead of directly mutating. > What is going on behind the scenes when I modify a single value in an array with 10k members? Surely it's not going to create an entirely new array. It would be unwise to use a huge array (in the usual sense - contiguous memory) like that to begin with. You'd probably have an "array" that is more in the shape of a tree, which facilitates more efficient "updates".

Igglyboo 12y ago

Curious, I've been hearing a lot lately about functional languages and immutability and wasn't quite sure how it worked. I agree with it in premise but it seems like all these immutable data structures introduce massive overhead. What is going on behind the scenes when I modify a single value in an array with 10k members? Surely it's not going to create an entirely new array.

programminggeek 12y ago
It might do that wildly inefficient thing... Or, you might do something where you have a list of pointers, and you point at a different value instead of mutating an existing value. I haven't dug into the details of how immutable data structures can be made to work efficiently, but part of the charm is that in many cases you don't mutate the array at all. What I mean is, there are certain behaviors around mutation that programmers do because they can. When you take away the ability to mutate data, you design differently and without side effects. All of a sudden testing becomes easier, faster, cheaper for large parts of your codebase. You have simpler solutions that are potentially easier to reason about because the complex (and sometimes elegant) solutions aren't so readily available. A few talks that are around this style of thinking: https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=tq5SQ4W3gRI https://www.youtube.com/watch?v=tq5SQ4W3gRI http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy Boundaries are good, values are good, simple things that work together are good. The more we can take the good parts and form them together into a cohesive language/framework/platform, the better our software will be.
rdc12 12y ago
This book is more or less the definitive book on functional persistent data structures. More about how to design and reason about them, then a collection book. http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504 http://www.amazon.com/Purely-Functional-Structures-Chris-Oka...
Dewie 12y ago
> Curious, I've been hearing a lot lately about functional languages and immutability and wasn't quite sure how it worked. I agree with it in premise but it seems like all these immutable data structures introduce massive overhead. There is some seemingly inherent overhead for certain data structures. On the other hand it allows for structural sharing, and plays more nicely with concurrency and whatnot. Suffice it to say that you'd be wise to design your immutable (persistent, specifically) data structures very differently to how you would design your regular imperative data structures. There was a famous PhD dissertation - now a book - on the topic. You'll find it easily enough if you search for it. Yes, immutable data structures seem very inefficient. But they're implemented in a more clever way than to just take regular imperative data structures and copying for every "update" instead of directly mutating. > What is going on behind the scenes when I modify a single value in an array with 10k members? Surely it's not going to create an entirely new array. It would be unwise to use a huge array (in the usual sense - contiguous memory) like that to begin with. You'd probably have an "array" that is more in the shape of a tree, which facilitates more efficient "updates".