I'd also add that rubys confusion about what a function is is the thing that's been annoying me the most lately. You have procs, lambdas, blocks, and all with subtle differences (<a href="http://awaxman11.github.io/blog/2013/08/05/what-is-the-difference-between-a-block/" rel="nofollow">http://awaxman11.github.io/blog/2013/08/05/what-is-the-diffe...</a>), and all I want are simple funcs as first class citizens that have consistent behavior. (TCO as a default would also be nice).<p>"And finally, pie in the sky, can we solve packaging apps up into distributable binaries, please? Rust and Go are making us look bad."<p>As a ruby programmer the lack of any reasonable - i.e. not hacky - way to build binaries is annoying. Unless you're building a server side app, you can pretty much forget using ruby because of this. Maybe that's all ruby cares about, its certainly its niche but I like ruby and would like to be able to use it for cli programs, etc. Personally, I don't want end users of my code to have to install ruby, learn about ruby gems and boot the ruby vm before having to run a cli program.
Some small but I think important nit-picky things about Struct<p>1.) A struct in ruby isn't just data, it is an object.<p>2.) Structs come with some weird gotchas, most notably that it is an Enumerable!<p>3.) It's generally better to use a hash (in ruby) if you want "pure" data object (and they at least used to be faster).<p>I myself have written a lot of "weird" Ruby and I will say that more often than not it's detrimental to an application that is used/developed by others. Often times ideas that seem brilliant in one language, cannot be translated into another (immutability), and it's best to use the recommended paradigms. Especially when those using the software are not familiar with them, and most likely won't become familiar with them....<p>For me, many functional paradigms are just lost on ruby because it's so highly mutable that practicing them is more academic than practical (sadly). That's why I write Scala or Elixir now when I want/need those paradigms-- because they're the right tools for that job.<p>I definitely don't want to discourage innovation, or bringing great ideas to ruby from other places-- I just want to emphasize caution :)
That's not that weird. After trying to learn Haskell and reading "Understanding Computation" the Struct and enumerable style of structuring code feels very natural.<p>I disagree with the conclusions though. Contracts and replacing `nil` with `Maybe` doesn't sound right to me at all since I use `nil` pretty heavily all over the place and the extra layer of `Maybe` doesn't buy me anything. I don't understand what he means by a dependency system since Gems have their dependencies spelled out pretty explicitly. Killing symbols is just silly because I use them to tag all sorts of stuff and message passing with symbols feels more natural than any other data type. Packaging could be better and optional types would also be nice. I like how TypeScript does it actually quite a lot.
Mostly that was an interesting article, but there was one pain point: having to read the parameter list to a routine <i>three</i> (!) times.<p>Honestly, why has no language (few languages?) come up with a scheme yet to put the formal parameters to a routine one per line, with documentation, like so:<p><pre><code> ...
</code></pre>
param-name [<type, if specified>] [<documentation>]<p><pre><code> ...
</code></pre>
Swap the name and type order for "New Jersey" style languages vs "Swiss" style languages as needed.<p>This is actually how I used to write out my C function headers (Frack K&R layout!), even though we didn't use a doc generator tool such as Doxygen (sp?).<p>Javadoc is only slightly less offensive, naming the parameters twice, due to slavish adherence to the altar of New Jersey formatting. I would love to see "//@ description..." after each parameter as an alternate to "* @param name description..." duplication above the parameters. "WET brain-death forever!", I guess.
That Ruby looks excellent. I hadn't realized the contracts gem existed.<p>So much of what people redundantly cram into test suites could be handled with simple contracts.
I'd be really interested to see success typing applied to ruby.<p><a href="http://user.it.uu.se/~kostis/Papers/succ_types.pdf" rel="nofollow">http://user.it.uu.se/~kostis/Papers/succ_types.pdf</a><p>TL/DR:
Success typing considers all possible types a value can have. If a function returns either a bool or an int and you then pass that value into a function that accepts a string or an int, then the success typing checks out. It doesn't mean your program is correct, but that it could possibly be correct. On the other hand, if you pass the "bool or int" value into a function that only accepts a string, the type checker will complain and you know for sure your program is incorrect. In other words, you will get false negatives but never a false positive.
Traveling Ruby is a good way to package ruby applications. <a href="https://github.com/phusion/traveling-ruby" rel="nofollow">https://github.com/phusion/traveling-ruby</a>
Ruby's cardinal sin: there's no way to `require` code without global side effects.<p>e.g. <a href="https://twitter.com/tomdale/status/457282269342744576" rel="nofollow">https://twitter.com/tomdale/status/457282269342744576</a>
If you want to replace floats, what with?<p>Symbolic computation is way too expensive.<p>Fractions are good whilst they're restricted in size but are too slow at arbitrary precision and too inaccurate with numbers not centred on 1.<p>Fixed precision decimal floating point has numerical problems because numbers scale by too large an increment. (see footnote)<p>Arbitrary precision floats don't solve anything unless your problem was too little precision - with the precision of a 64 bit float this is rarely the case and 128 bits is massively more than that.<p>Arbitrary precision decimals don't solve anything either.<p>Logarithmic number systems are a good contender but almost all operations become
lossy. This is OK if you're using them as approximations - which is the common use of floats - but the fact floats are exact on the integers up to a large ceiling is useful (see Javascript) as with many other of their exactness properties.<p>Even better might be a symmetric level-index number system; you get the advantages of logarithmic number systems but <i>also</i> get immunity from overflow and underflow - the only operation that isn't closed is division by 0 and since operations can't underflow <i>all</i> 0s are actually 0.<p>If it were me implementing a new very-high level language with only weak cares about speed (eg. faster than doing it symbolically), I'd probably choose to use fixed precision fractions that fall back to symmetric level-index numbers instead of rounding. That way I'd get precise rationals (including int64s), immunity from underflow and overflow and a smoother error curve than floats.<p>---<p>Some people are pretty surprised to hear me criticize decimal types, but they're genuinely numerically worse than binary floating point. I've talked about this in depth here:<p><a href="http://www.reddit.com/r/programming/comments/2ut00j/a_little_thing_to_love_about_perl_6_and_cobol/cobl3vd" rel="nofollow">http://www.reddit.com/r/programming/comments/2ut00j/a_little...</a><p>and I give a rough rule-of-thumb about what type to use when here:<p><a href="http://www.reddit.com/r/learnpython/comments/2wyeho/is_this_an_error_in_the_python_interpreter_if_not/covafmk" rel="nofollow">http://www.reddit.com/r/learnpython/comments/2wyeho/is_this_...</a>
Really, that's not weird at all. Far from it.<p>For a truly different Ruby coding style checkout some of Ara T. Howard's code: <a href="https://github.com/ahoward" rel="nofollow">https://github.com/ahoward</a>.