"And finally, pie in the sky, can we solve packaging apps up into distributable binaries, please? Rust and Go are making us look bad."

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.

  foo.each do |x|
    return if x == 3
  end

The thing is, they’re rare in practice for cultural reasons.

What are the "hacky" methods currently used for packaging you mentioned? The only methods I'm aware of no longer work or still require a separate runtime.

In Ruby iteration is implemented by letting something call a block repeatedly until the end of the iteration. The interpreter provides jump points in order to implement skipping or breaking the iteration. A continue is implemented as a form of jumping to the end of the block, a break is implemented by jumping past the call to the iterator function. Without the return it would be very awkward to return something from the function.Imagine a function that returns the first even item from a list:

    >> def find_even iterable
    >>  iterable.each { |x| return x if x % 2 == 0 }
    >> end
    => nil
    >> find_even [1, 3, 5, 6]
    => 6

    >> def find_even iterable
    >>  done = false
    >>  rv = nil
    >>  iterable.each { |x|
    >>   if x % 2 == 0
    >>    done = true
    >>    rv = x
    >>    break
    >>   end
    >>  }
    >>  rv
    >> end
*

Blocks are pretty much an iteration construct.

It's really not that confusing.

1.) A struct in ruby isn't just data, it is an object.

2.) Structs come with some weird gotchas, most notably that it is an Enumerable!

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).

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....

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.

I definitely don't want to discourage innovation, or bringing great ideas to ruby from other places-- I just want to emphasize caution :)

An OpenStruct is slower than a hash, but then again, an OpenStruct is kind of pointless.

If the reason not to use better principles is because Ruby makes them painful, rather than there's something about the domain that makes them a bad idea, why choose Ruby to begin with? Presumably the ecosystem.

I agree with emphasizing caution, but I definitely think it's worth being at least somewhat weird with your Ruby to get as much as you can from the best of both worlds, the Ruby ecosystem and functional principles.

It requires a good knowledge and dedication to consistently return a new object (not mutate state). Further, chaining is problematic for tracing errors because so much happens on a single line. Ruby has many subtle features that can bite you in the ass.

Don't get me wrong, I LOVE RUBY, I would love these paradigms to be better suited (rbx/jruby come close). I just find if I embrace mutability, state, and OO principles in Ruby I am rewarded in quality by having other smart people who are more easily able to critique my code and better it.

The abstraction I (completely willing to admit being wrong/stupid) don't believe is worth it. I think less effort and more reward can be had using the right tool for that job. I, for what it is worth, came to my conclusion through the pain of trying.

I generally agree with the rest of your comment though, however I think some ruby code (per the original post) can be improved by introducing some of these paradigms.

And immutable structures with efficient "updates". Because otherwise every time you're altering the structure you have to copy it in full (though shallowly) then mutate it in place.

https://github.com/hamstergem/hamster

Not that I don't wish we could swap tired old Java for Scala at work, but I worry that opt-in immutability means somebody will opt-out and foul things up in Scala, as well :-(

For languages (e.g. - Scala, Nim) that have separate keywords for declaring/initializing immutable and mutable symbols, I wish they would avoid short words like "var" for mutable identifiers, maybe using a keyword like "mutable", "datadivision" or "ipeedinthepool" to discourage mutable data.

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.

"Why and how to avoid nil"

https://www.destroyallsoftware.com/screencasts/catalog/how-a...

you have to pay to see it, but it's terrific. (not mine, just a fan.)

Wouldn't that layer be there all the time anyway? Either in the form of a sum type (Just a | Nothing), explicit nil checking, or ignoring nil's and getting a runtime error.

In fact Ruby's case/when statement is very limited form of pattern matching that can be put to great use with proper use of Structs and overloading of ===.

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:

    ...

    ...

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?).

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.

    /* Return validated output for printing */
    static
    t_output *      val_and_xform
        (
        int         in_cnt     /* input item counter, 1 based */
        t_input *   raw_in     /* raw input, immutable, not null */
        )
        {
        ...
        }

I can see the style-nazis hating on it with a white-hot fury, tho.

So much of what people redundantly cram into test suites could be handled with simple contracts.

http://www.poodr.com/ goes in-depth about this.

  [:quacks], [:barks] => Maybe[:flies]

http://user.it.uu.se/~kostis/Papers/succ_types.pdf

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.

That doesn't seem very useful, I already know that my program could "possibly" be correct. If I didn't think so I wouldn't be working on it.

I'm interested in finding out whether it "is" correct or not.

If I ask the type system, and it just shrugs and says "dunno lol" then that type system isn't worth much to me.

Is it inferior to a full static route system? Yes. Are there benefits to dynamic type systems? Yes. Success typing is a way to get a bit a both.

So, contracts that specify what functions accept and produce by class membership provide less assurance than they superficially appear to.

Ruby is certainly a language suitable for the duck typing technique. The term was originally used in reference to Python, and both languages have reasonably equivalent reflection abilities.

Compare that to duck-typing in Go where it was a very deliberate design decision.

e.g. https://twitter.com/tomdale/status/457282269342744576

    import foo # creates only foo
    require 'foo' # can change everything 

The thing is: ruby has #load(true) to load a file in anonymous module, it would just need to return that module and we could build something reasonably close to python's import.

(I think there was an RCR for this many years ago)

Technically incorrect. The code within `foo` could alter anything itself accessible via an import, and it could walk up the stack to mess with the "current" stack frame of the module being defined by the import.

It's generally not done and would be considered very bad form, but it's definitely possible.

> In both ruby and python you can execute code that changes the global namespace from within a module, but you have to go out of your way to do it in python, while in ruby it's the default.

The tweet is about monkeypatching existing structures though. And you can definitely do that in Python, including at import (though that's generally considered a Bad Idea, libraries which can do that such as gevent usually require an explicit call to patch or replace existing modules)

Symbolic computation is way too expensive.

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.

Fixed precision decimal floating point has numerical problems because numbers scale by too large an increment. (see footnote)

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.

Arbitrary precision decimals don't solve anything either.

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.

Even better might be a symmetric level-index number system; you get the advantages of logarithmic number systems but also get immunity from overflow and underflow - the only operation that isn't closed is division by 0 and since operations can't underflow all 0s are actually 0.

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.

---

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:

http://www.reddit.com/r/programming/comments/2ut00j/a_little...

and I give a rough rule-of-thumb about what type to use when here:

http://www.reddit.com/r/learnpython/comments/2wyeho/is_this_...

For a truly different Ruby coding style checkout some of Ara T. Howard's code: https://github.com/ahoward.

Apparently Rails 5 will take advantage of symbols GC to use symbols as keys for the params hash instead of strings. It uses strings now only to prevent DoS because of uncollectable symbols.

I find it a bit surprising though that an article that is generally in favor of functional programming is bashing Ruby symbols. Ruby symbols come from Lisp and are just a form of atoms which are common place in functional languages. Erlang, Lisp, Elixir, Clojure, Scale to name a few all have atom/symbol support in some form. They are immutable even across systems. It just seems to run counter to the article's argument. Also there was no supporting reason why symbols should be killed. The article is released after GC was introduced for symbols so I'm assuming that's not the reason to "kill symbols".

I'm not sure there isn't more about symbols than that but I'll think about it the next time I'll write some Ruby. I'll pretend I have only strings and see what happens. One thing for sure: we'd need a syntactical shortcut because having to type "string".freeze everytime is unbearable. If the right shortcut is :string or the lispy 'string, I don't know but if we need it symbols are fine even if symbol.class could end up being String.

As far as the difference between "string".freeze and :string; the symbol will resolve to the same object_id every time across systems and processes. If you spin up irb and type :foo.object_id you will see 1092508. Now one way this is commonly used in Ruby is when we use Object#send. We pass a symbol in place of the function name as the first argument and internally this is used as a system optimization to lookup the function that is being called dynamically.

Now I haven't been knee deep in the code of any of the Rack web servers, but I would imagine that something like Puma which is built for concurrency and multi-threading could take advantage of this behavior as well for some shared process to enable spinning up lighter weight additional processes or threads thus leading to lower memory consumption on your web server and the ability to handle more traffic on the same hardware.

Erik is right in saying that strings and symbols are "converging"; they have not yet converged however. At the point at which strings converge to symbols in the sense that both resolve to the same object across systems, then what we have left is symbols and so it is not symbols that have been killed, but rather strings supplanted by symbols. If instead we go the direction of saying memory and performance don't matter so let's punt on that whole symbols are immutable thing I think we are giving up too much.

I use Ruby because the high level abstraction is great and saves me developer cycles, but I also want it to eek out as much performance as possible. Honestly in general I'm tired of hearing the argument that X should die now because it is a performance hack. Some performance hacks are good.

(For reference: In the video he discusses symbols vs freezing strings from 22:00 to 25:07)

object_id for symbols is not consistent across processes.

   % ruby -e "p :foo.object_id"
   396968
   % ruby -e "p :bar.object_id"
   396968
   % ruby -e ":bar; p :foo.object_id"
   397128

https://gist.github.com/mboeh/83338a4e3a6a77689e22

Something that I found a bit ironic about the video linked in the article is at 5 mins 30 secs in; he states, "Why not give the memory address a name that makes sense to a person?" Here is referring to assembly and the abstraction it makes and how this relates to the abstraction that is variables. Symbols are really a cross system immutable memory address abstraction; I don't see how this is a bad thing.

I wish I had been clearer in my talk but I only had 30 minutes and wanted to cover other topics. Here is a more comprehensive argument against symbols in Ruby:

In every instance where you use a literal symbol in your Ruby source code, you could you could replace it with the equivalent string (i.e. calling Symbol#to_s on it) without changing the semantics of your program. Symbols exist purely as a performance optimization. Specifically, the optimization is: instead of allocating new memory every time a literal string is used, lookup that symbol in a hash table, which can be done in constant time. There is also a memory savings from not having to re-allocate memory for existing symbols. As of Ruby 2.1.0, both of these benefits are redundant. You can get the same performance benefits by using frozen strings instead of symbols.

  "string".freeze.object_id == "string".freeze.object_id

  def measure
    t0 = Time.now
    yield
    t1 = Time.now
    return t1 - t0
  end

  N = 1_000_000

  puts measure { N.times { "string" } }
  puts measure { N.times { "string".freeze } }
  puts measure { N.times { :symbol } }

1. Symbols and frozen strings offer identical performance, as I claim above.

2. Allocating a million strings takes about twice as long as allocating one string, putting it in into a hash table, and looking it up a million times.

3. You can allocate a million strings on your 2015 computer in about a tenth of a second.

If you’ve optimized your code to the point where string allocation is your bottleneck and you still need it to run faster, you probably shouldn’t be using Ruby.

With respect to memory consumption, at the time when Matz began working on Ruby, most laptops had 8 megabytes of memory. Today, I am typing this on a laptop with 8 gigabytes. Servers have terabytes. I’m not arguing that we shouldn’t be worried about memory consumption. I’m just pointing out that it is literally 1,000 times less important that it was when Ruby was designed.

Ruby was designed to be a high-level language, meaning that the programmer should be able to think about the program in human terms and not have to think about low-level computer concerns, like managing memory. This is why Ruby has a garbage collector. It trades off some memory efficiency and performance to make it easier for the programmer. New programmers don’t need to understand or perform memory management. They don’t need to know what memory is. They don’t even need to know that the garbage collector exists (let alone what it does or how it does it). This makes the language much easier to learn and allows programmers to be more productive, faster.

Symbols require the programmer to understand and think about memory all the time. This adds conceptual overhead, making the language harder to learn, and forcing programmers to make the following decision over and over again: Should I use a symbol or a string? The answer to this question is almost certainly inconsequential but, in the aggregate, it has consumed hours upon hours of my (and your) valuable time.

This has culminated in objects like Hashie, ActiveSupport’s HashWithIndifferentAccess, and extlib’s Mash, which exist to abstract away the difference between symbols and strings. If you search GitHub for "def stringify_keys" or "def symbolize_keys", you will find over 15,000 Ruby implementations (or copies) of these methods to convert back and forth between symbols and strings. Why? Because the vast majority of the time it doesn’t matter. Programmers just want to consistently use one or the other.

Beyond questions of language design, symbols aren’t merely a harmless, vestigial appendage to Ruby. They have been a denial of service attack vector (e.g. CVE-2014-0082), since they weren’t garbage collected until Ruby 2.2. Now that they are garbage collected, their behavior is even closer to a frozen string. So, tell me: Why do we need symbols, again?

I should mention, I’d be okay with :foo being syntactic sugar for a frozen string, as long as :foo == "foo" is true. This would go a long way toward making existing code backward compatible (of course, this would cause some other code to break, so—like everything—it’s a tradeoff).