Ruby's Creed - <AUTHOR> https://metaredux.com/posts/2019/04/02/ruby-s-creed.html <comment><USER3> Regarding the @ positional-argument syntax: I mean, my use of Ruby dropped considerably years ago, but from a Ruby-philosophy standpoint it looks fantastic to me. Having to constantly make up (usually single-character anyway) names for those parameters in map/filter chains was one of the ugliest parts of the language, especially when there was no actually-good name for things like temporary tuples, and the Smalltalk-derived (I think) syntax for block parameters is so visually heavyweight: { |…| … } { |…| … } { |…| … } where all the stuff in the || is close to useless, as opposed to just { … } { … } { … }. Method references passed with &, while separately useful, are not a good substitute; they're often less readable (to me) because the form of the expression is obscured, and they break down much faster, for instance as soon as you need any single other argument, rather than just when the block gets complex enough that the parameter names become important for readability.

I can appreciate that it moves farther away from "requiring things to be explicit means you get fewer accidental barriers to moving code around or increasing/decreasing complexity", though, as some of my recent work has been in Java and I've had an eye for that aspect of it. But the next time I do anything in Ruby I'll be remembering that this is there.

<comment><USER4> I like Kotlins solution for this. If there is only one argument in the lambda/block and the type is clear from the context you don't have to declare it and you can use the 'it' keyword instead.

<comment><USER5> Kotlin is great, but I think the "it" syntax was derived from Groovy.

<comment><USER6> I'm not positive, but Groovy may in turn have been inspired by Perl's $_, as in 'map { $_ + 1 } (1..10);'.

If I recall correctly, the canonical name for that parameter is 'it' as well (though I've never met a Perl programmer that calls it that . . . er, calls it 'it' . . . er, you get the idea).

<comment><USER7> The first time I saw `it` in a similar construction was in Arc language's aif macro:

            (mac aif (expr . body)
               `(let it ,expr
                  (if it
                      ,@(if (cddr body)
                            `(,(car body) (aif ,@(cdr body)))
                            body))))

HN uses it quite a lot, e.g.:

            (defop logout req
               (aif (get-user req)
                    (do (logout-user it)
                        (pr "Logged out."))
                    (pr "You were not logged in.")))

<comment><USER8> Anaphoric macros have been used in common lisp since forever.

<comment><USER7> Thanks for the name! Here's a wikipedia article about them: [https://en.wikipedia.org/wiki/Anaphoric_macro](https://en.wikipedia.org/wiki/Anaphoric_macro)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Allowing @1 and @2 instead of |a, b| is a horrible change to Ruby. In the ruby tracker Matz himself states this is a compromise. So now Ruby is getting half- baked compromises that look out of place, all to appease some people making requests.

If the requested functionality is so pertinent, then a _proper_ solution should be made, in line with Ruby's style. Not cryptic sigil soup with @ and .:, etc.

If a feature exists, it will get abused down the line. I do not want to read Ruby codebases that have @1, @2, @3, etc instead of named variables. We all know that temporary code is permanent. Just making this syntax possible is terrible.

I have to say I'm disappointed. I have enjoyed using Ruby for the last ~5 years but I disagree strongly with this syntax change.

<comment><USER10> Properly used, it's just a short-hand for small expressions, where adding formally declared parameters adds 50% or more bulk to the code.

      {|a, b| a + b}  versus {@1 + @2}

type of thing. Note also that a and b are not more informative than @1 and @2.

Both these examples convey one message: "I'm a function that adds two arguments".

Here is a useful power: omit the smaller numbers:

      # TXR Lisp:
      5> (mapcar (aret @3) '((a n 1 10) (b m 2 20)))
      (1 2)
      6> (mapcar (aret @2) '((a n 1 10) (b m 2 20)))
      (n m)

aret: a)pply list to function, which ret)urns an expression.

Simply by using @20, we get a twenty-argument function with 19 don't-cares.

<comment><USER11> Perl is still available if you want to use it.

Naming arguments "a" and "b" is widely considered bad practice either way, of course it's not more informative.

<comment><USER12> So you would prefer {|dividend, divisor| dividend/divisor} over {@1/@2}?

<comment><USER13> On a team, I would prefer the former over the latter.

As a single contributor that's trying to hack together an idea, the second option is not so bad; however, it will probably need to be changed far off in the future.

I think named block parameters are cool in the sense that they enable some expressiveness but bad in the sense that they lose some readability. I won't know how I truly feel until I have to maintain/read a large codebase where they are used.

<comment><USER12> How do you feel about the Groovy/Kotlin style that would translate (roughly speaking):

[1,2,3].map{|n| n * 2}

to:

[1,2,3].map{it * 2}

?

It's not generalizable to multi-argument lambdas, but multi-argument lambdas are the ones that are more important to name. (e.g. with reduce, {|memo, it| memo += it})

<comment><USER14> The underscore is fairly pleasant to read:

      [1,2,3].map{_*2}

I think that's what Scala has. For multi-args, perhaps:

      [1,2,3].reduce{_1+=_2}

<comment><USER15> Underscore is very commonly used to signifiy "I don't care about this argument" in Ruby, so at least on it's own it'd be confusing, and _1 is a valid local variable name, so would risk breaking existing code, though I've personally not seen it used, so maybe it'd be an acceptable risk.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Syntax is hard. In general I think that adding a simple numbered argument access for blocks makes sense, and something like swifts $ syntax would look pretty natural, ie:

``` books.map { $0.title } ```

In the Ruby lang discussion on this they go through a dozen different possible syntaxes and they all have issues -- for example the $ is problematic because Ruby currently uses these for global variables.

Even so, IMO using the `@` symbol for this will make the language harder to learn. It's not a very nice thing to have syntax that is almost ambiguous to the human.

``` books.map { @prefix + @1.author } ```

I teach Ruby to a lot of engineers (of all different experience levels), and one of the nice things is that it's so easy to pick up and be productive quickly. But there are bits where it takes some practice, and I'm not looking forward to telling people, "The at sign means it's an instance variable. Well, except if you're in a block and it's @1 or @2 or something, in which case it's a positional argument." Oof.

<comment><USER17> I absolutely agree, interference with instance variable/method alias '@' looks awkward. For me it seems a little bit against Ruby-way.

<comment><USER15> Instance variables can not start with a digit, so this works fine from that perspective.

<comment><USER18> So another exceptional edge case to learn.

<comment><USER15> Given how little of Ruby syntax most people know before they're able to read and understand Ruby, I don't see that as much of a concern. "@" suggests it's probably local of sorts, the number makes it clear it's not an instance variable, and the absence of |somevar| in a chained block will strongly suggest it's an argument, without having to know the precise details.

There are many additions to Ruby I don't care much for, but this is one of the most intuitive I've seen.

</comment></comment></comment></comment></comment><comment><USER19> Ruby 1.9 hash literal syntax was introduced as an evolutionary step toward keyword arguments. If the former didn't exist, the latter would be a special syntax similar to but incompatible with the existing idiom to use a hash in terminal argument position as keyword arguments. That is, without the ability to treat foo(:a => 1, :b => 2) as equivalent to foo(a: 1, b: 2), you end up with two versions of every API -- "hash kwargs" and "real kwargs". And you'd similarly lose the ability for existing APIs to migrate to explicit keyword arguments from hash kwargs.

Would I prefer it if Ruby had started out with Crystal's named argument syntax? Absolutely. But Crystal had the luxury of starting from scratch without any need for backwards compatibility.

<comment><USER20> I think Rubys vararg syntax is terribly unintuitive and inconsistent though.

<comment><USER19> It is, but it was also a compromise meant to maintain compatibility with existing code. And I mentioned it specifically because the OP identified keyword arguments as a good new feature but the new hash syntax as bad.

</comment></comment></comment><comment><USER21> I agree and disagree.

The more features the language has, the harder it is to read.

And using @ for positional arguments when it's already used for instance variables is a questionable choice. But on the other hand, the syntax for these blocks has always been clunky.

But Ruby is all about options. You can do things the way you want, when you want. That's the happiness you achieve. But it does become more difficult to read for newcomers and devs not up on the latest updates, which is a major sacrifice.

Some of these new features are blessings though. The safe navigation operator saves lots of checks and I wish I had it in JavaScript and other languages (rather than checking for a property first).

<comment><USER9> > Ruby is all about options

Err, is that why things like Rails are convention over configuration? I personally would rather have consistency throughout ruby codebases than various random solutions people have come up with.

@1 and @2 is more difficult to read, full stop. It's more difficult for newcomers because it's more random "magic" that one has to learn, and it's difficult for ruby devs when they read other people's code and have to discern what @1, @2, @3 might possibly be. At least variable names give information, if done properly.

Matz even stated this was a compromise. I think it's utterly unsatisfactory for Ruby to just accept this as it is currently. There has to be a better solution than @1 and @2.

<comment><USER22> Ruby != Rails. I think it makes sense that the language remains flexible while the framework is opinionated. I probably won't use @1 et al in my projects, that's where enforcing consistency via rubocop comes into play.

<comment><USER9> Sure, ruby isn't rails. But a lot of tools are also opinionated (like Rubocop, even.. or Brakeman, etc). One can always change values but there -are- default configurations that people generally tend to go with.

Having consistency in the language is also better overall for the community. If you read through a new codebase, having consistent patterns makes that process significantly better.

@1 and @2 are only going to make things less readable. People will choose the easier option and never go back to refactor it once completed. It's a horrible change for Ruby.

</comment></comment></comment></comment><comment><USER23> I don't necessarily agree but it's a fair argument and well written. It's probably impossible to satisfy everyone; if Matz drops these features the people who want them (and I'm sure they exist) will yell that the language is stagnating compared to Python 3 and Node. If he adds them, we are adding bloat. There is constant pressure to add more stuff to "evolve" the language, hopefully the community steer through this pressure to the right direction.

</comment><comment><USER24> As a rubyist of 10 years, a few thoughts. I wasn't aware of these upcoming features, but to some extent they make a lot of sense. Except... yeah, those symbol choices.

I agree that @1, @2 etc look totally wrong, and maybe that subjective view will change - but scope-wise, having @-variables that are nothing to do with the current instance would utterly ruin scannability. On the other side, I suspect Rubocop will very quickly react to outlaw it, so no big problem as far as my code goes.

I very rarely use &method(:foo). I find it ugly, and &:foo is more useful in 98% of circumstances. Maybe I would use it if it were shorter - but .:foo seems wrong. I feel like it would, again, be harder to scan.

That said, the more I let it sit in my brain, the less passionately I object.

> Still, I was disappointed when the safe navigation operator as introduced, > as it basically acknowledged that it's fine to return nil

I think this is indicative of the crux of the problem. Optimizing for programmer happiness implies you know what programmers need. Some programmers have no problem working with nils - we've long since accepted them, even embraced them.

The safe navigator pattern almost gave us a way of implementing a null object pattern with literally no work, while screaming out to the world "this method accepts nil, so watch out". I would much prefer code that accepts nil as a fact of life than code that denies its very existence.

I feel that "hacky code" will be well served by these changes, and I think that "production code" will be better served by tight Rubocop rules. So, everyone's happy!

<comment><USER25> > I very rarely use &method(:foo). I find it ugly, and &:foo is more useful in > 98% of circumstances. Maybe I would use it if it were shorter - but .:foo > seems wrong. I feel like it would, again, be harder to scan.

Ever since the near-death of the hash rocket syntax have these days been coming as you can already see the same line of thinking coming out of it. Superficially the introduction of the symbolic hash syntax that aligns it with yaml/js and saves a few chars was locally good for readability, yet fundamentally it could not deprecate the hash rocket because if one of your keys is not a literal symbol then you're toast and have to use hash rockets in your code, which means you end up with mixed patterns throughout your code and thus have to 1/ keep two tokenisation branches inside your head and 2/ make decisions about the syntax to use every single time you write a hash, which looks like small things but long term sand in a gearbox grinds it to a stop.

At some point you end up with all those little syntactic sugary things which make sense locally but which overall makes for increasingly heavy cognitive overload and you end up in a tar pit through normalization of deviance.

When Ruby began to take off, people said it was like Perl's heir, only readable. Today as both a Rubyist and a former Perlist, I do long for Perl (and violently enforce readability rules on Ruby projects I own)

</comment></comment><comment><USER26> I'll come to the defense of &. - for better or worse Ruby is mostly used for building database backed web applications where nils are simply unavoidable without some extreme over engineering or awkward idioms. `user&.address&.street` is at least safer than `try` - `user.try(:adress).try(:street)` - will not raise an error that `adress` is not a method. You could try and apply the null object pattern, but then `user.address.present?` is quite a rabbit hole - and frankly nil is the right return value for a user with no address on file.

<comment><USER27> Yeah, the safe navigation operator is great, and I really miss it especially when I write JavaScript and have to do something like `foo && foo.bar && foo.bar.baz` instead (...which isn't even the same since it returns `false` if something is null).

<comment><USER28> Just use lodash for that.

Your example would become:

      // this won't throw an exception if foo is null
      _.get(foo, 'bar.baz')

And you can even set a default value to return if it is: [https://lodash.com/docs/4.17.11#get](https://lodash.com/docs/4.17.11#get)

<comment><USER29> The point isn't that it's an unsolvable problem, the point is that you have to resort to clunky syntax or a 3rd party library to do this. And for something as basic as this, there's probably a number of different libraries that solve the same problem a slightly different way.

</comment></comment></comment></comment><comment><USER30> It's interesting to see that languages try to get features that other languages have.

In Swift they have position argument in block from the start

        users.map{$0.name}

now they want to add Ruby's &:attr feature[1]

        users.map(\.name)

Maybe the best feature user want is the one other languages have. Or this is just Blub Paradox[2] in real life.

[1]: [https://github.com/apple/swift- evolution/blob/master/proposa...](https://github.com/apple/swift- evolution/blob/master/proposals/0249-key-path-literal-function-expressions.md) [2]: [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

edit: grammar

<comment><USER31> They both look ugly to me. Furthermore, there is a cognitive burden. There is nothing to think about in

      users.map{|u| u.name}

I even use to write it more explicitly as

      users.map{|user| user.name}

The short forms

      users.map{&:name}
      firstname.lastname@example.com}

are like "oh wow, what does that mean?" and I've been using Ruby since 2005. And the ugliness...

<comment> ben-schaaf I don't actually mind the syntax that much, `&` on a symbol just gives you a proc for calling `send` on the first argument. What bothers me is the limitations. If you're going to have special case syntax to avoid having a useless first argument why not go all the way?

Something like this would have made a lot more sense imo:

        users.map { .name.uppercase + '3' }
        numbers.map { * 3 }

<comment><USER32> The last one looks a lot like Haskell:

      map (* 3) numbers

</comment></comment></comment></comment><comment><USER33> > In my opinion half-baked micro-optimizations add nothing, but complexity in > the long run, and should be avoided. I'm really worried that Ruby has been > gradually losing its way and has strayed from its creed.

It seems to me that "Optimizing for programmer happiness" is bound to end up with these half-baked micro-optimizations. The very first example of what the author considers the essence of Ruby is a perfect showcase of that, in my opinion.

Without a criteria that establishes whether or not you've now optimized _more_ or _less_ for programmer happiness, your users will just create blub fortresses that they stay in. Since the entire tagline is based on subjectivity and the users don't have any meaningful foundational principles to appreciate, all they have is their opinions on that feature they don't see why they need.

</comment><comment><USER34> I'm a huge fan of all the features this person is complaining about.

<comment><USER35> But do any of these features progress the language or provide any performance benefits? Most read as syntactic-sugar (I understand Ruby is about developer happiness) and unnecessary.

<comment><USER36> They progress the language by adding syntactic sugar. Many Ruby programmers aren't waiting around for Ruby to suddenly become fast. If that happened it'd be great, but most code I write isn't performance critical, so it's okay if they just give me a feature where i can write `user&.name` instead of `user && user.name`

</comment></comment></comment><comment><USER37> Completely agreed. I find it hard to read anything but the simplest of @ positional examples, and code has to be written to be read.

I have been writing Go a lot more these days and greatly appreciate the simplicity of language. Coming from a Perl background, and the TMTOWTDI (There's More Than One Way To Do It) philosophy, I've seen how that can make for clever but hard to read programs and I'd have preferred Ruby to err in the other direction.

</comment><comment><USER38> I was happy with Ruby and Rails until when i have to write my own abstraction. (something like has_many, belongs_to in ActiveRecord).

Ruby class/metaclass things is really cumberstone to me. It's not about the magic, it's about the complicated data flow through all the class abstractions that push me off Ruby.

I prefer functional abstraction to class abstraction whenever i can.

<comment><USER39> meta programming and the flexibility Ruby has around how it can be achieved are the things that set Ruby in a league of its own.

<comment><USER40> Definitely a league of it's own in difficulty of refactoring

<comment><USER41> That and difficulty introducing new developers to Ruby projects. When so much metaprogramming and abstraction is used, and everyone creating their own DSLs, developers often have to learn new languages every time they are brought on board to a Ruby project. It basically defeats the point of "convention over configuration" in Rails. Rails is fine on its own, but what Ruby allows people to do creates these "elegant" messes that end up being more difficult to learn, requiring people to become "experts". (which I suppose creates job security)

Don't even get me started on how lots of Ruby developers don't believe in documentation because the expressiveness of the language makes their code "self-documenting". (i.e. their shit doesn't stink)

I actually love Ruby, but I've learned to avoid the advanced features unless they make perfect sense for the task at hand. The Ruby culture, however, is what caused me to appreciate JavaScript; the fact that it contains a simpler set of tools makes the language more readable IMO, despite it being less English-like, and I find today's JS projects much easier to understand than almost any Ruby or Rails project of even modest scale.

<comment><USER39> you were either burned really hard by metaprogramming gone wrong or you've actually never seen it done properly.

there is a school of thought that says in some cases you should not shoehorn the problem you are trying to solve into <insert your favorite programming language in here>. In cases like that having a DSL (which does stand for Domain Specific Language) is worth its weight in gold. Focusing on expressing the problem in it's own domain language is beautiful. Ruby just happens to be awesome at building DSLs.

to your point about "elegant" messes: you can create a mess whatever tool/language you want. the language is not there as guardrails. I agree with you that less is more and in most cases you don't need some of the uberpowerful features, but when you do, the way you solve the problem is absolutely beautiful. IMHO, Ruby code is the closest to code poetry that you can get with a vanilla/for the masses programming language.

<comment><USER41> I've seen it done properly, it's just that the majority of the Ruby metaprogramming I've seen is completely unnecessary. I'm sure it's God Mode to a lot of people, and the powers of God are difficult to resist.

DSLs can be great. The problem I have with DSLs in the Ruby world is that it's too normal to just whip up a DSL for things that don't require it. A good example of a DSL is RSpec, which has a very specific goal in mind and is well documented. A bad example of a DSL is one that Bob the developer created for a Rails app at Acme Corp., which is sparsely documented because Bob is a busy guy and there's a lot of tasks in the backlog more important to stakeholders than documentation. Said Rails app at the end of the day serves webpages, and somehow the business logic "required" its own language built by one or two people who couldn't dedicate enough time and thought to the design of the DSL; it was built _pragmatically_ , and down the road when Bob quits nobody is going to want to touch it because the methods defined in the DSL have their tentacles in everything. In the best case, Bob actually wrote tests just for the DSL as well as the business application itself.

You are right in that a mass can be made using any tool. Where I disagree is where a language can act as guardrails. Guardrails might not even be the right term. What I do believe is that, a great deal of the time, the most powerful tool isn't necessarily better than the simpler one. Someone learning to fly probably shouldn't be given a fifth-generation fighter jet, as a much smaller aircraft would allow them to fly sufficiently without the complexities I'm sure there are in operating a military fighter jet, despite the fact that the fighter jet can do "more". Even an experienced aviator probably doesn't need to be flying a fighter jet for their purposes.

Ruby, IMO, is a lot like a fighter jet. Yes, it can fly from A to B, but it's can evade radar, has a machine gun, and do maneuvers other planes can't. Other languages might not have those other things, but that prevents less disciplined pilots from the temptation of doing unnecessary things that can result in mistakes. Sometimes you need a fighter jet, but most of the time we're not at war.

Everyone's experience is different, and I'm not saying your point of view is invalid, but I just feel different personally. I really wish people wouldn't use Ruby like they're a fighter jet pilot all the time. As someone who attended a coding bootcamp, I would like for bootcamps to emphasize hesitance around writing DSLs and metaprogramming rather than pushing those concepts on to junior developers as if they are the duct tape that applies to all problems.

</comment></comment></comment></comment></comment></comment><comment><USER42> In "optimizing for programming happiness", there's much more left to be defined than "happiness". I think the biggest ambiguity here is "programming".

"Programming" can mean a lot of things, and I think Ruby still tailors too much to the "be able to scrap things together somewhat elegantly" meaning.

But once the project takes off, you want performance and safety. Performance is constantly improved, but it seems safety is completely overlooked. TypeScript & co. proved you can make a type system that doesn't compromise for flexibility, so I think it should be at the core of the Ruby language improvements discussions.

<comment><USER32> I would like to have a language that has a builtin dial for strictness. The lowest setting (for use on a REPL or when prototyping something) would use dynamic typing with implicit coercions like e.g. JavaScript. But then, as the safety/performance/stability of your code becomes more critical, you can turn the dial higher and higher to get static type checking, then borrow checking, etc.

Sort of like how the NPM guys rewrite some critical-path components in Rust, but without having to hop to a different language. Sort of like how a lot of JS devs move to TypeScript halfway through the project, but then again, TypeScript can only go so far because it's shoehorned onto the existing JS, rather than designed in from the get go.

</comment></comment><comment><USER20> ah, _that_ topic... Well, for what its worth, I mostly agree with the author, except I never felt Ruby has made me "happy" more than any other programming language with at least some semi-decent features. Its problems make up for its features and, at the end of the day, it has enough annoying parts to make me angry at times.

The new features, of course, is pointless. It solves no problem, but brings with it the typical downsides of adding a new language feature. It reinvents the wheel, but makes it triangle-shaped, and tells you it's only meant for crash-tests anyway.

<comment><USER33> > Well, for what its worth, I mostly agree with the author, except I never > felt Ruby has made me "happy" more than any other programming language with > at least some semi-decent features.

In surveys, Ruby hasn't (to my knowledge) scored highest in developer happiness for a very long time (if ever). Languages that don't tie themselves to a subjective tagline like that do, though. Rust, for example, has a pretty clear direction and mission and has some of the most excited and happy users in every survey I've seen.

Trying to talk about developer happiness as some kind of defining characteristic has always been a bad idea and I think, ironically, you end up with unhappy users by using it as an ideal to make change in your language. I think it only gets worse when the paradigm the language is built on and how it expresses that paradigm is also susceptible to more bugs than the alternatives.

The only real way to optimize for developer happiness is to optimize aggressively for simplicity. The entire foundation of Ruby is a barrier to that and it doesn't have the good tooling, interactivity or introspection of something like Smalltalk to handle that.

</comment></comment><comment><USER43> I don't understand his problem with hash literals. Hash rockets are just ugly and verbose and needed to go (through they're still needed for some object types to be declared as keys).

The positional arguments I'm on-the-fence about. I enjoy them in Elixir, but at the same time I wish it had a little more flexibility to name arguments. And I like the clarity that named arguments provide.

The `then` alias is also a major improvement; `yield_self` is a confusing and ugly combination of protected keywords.

<comment><USER18> "Hash rockets are just ugly and verbose"

Ugh, you make it sound like playing code golf and counting every character automatically leads to the most readable code.

Replacing a two character operator with a one character operator, or whatever, is not a significant win for developer productivity. More powerful abstraction tools are what allow non linear productivity gains. Slightly different literal syntax is more a bike shedding topic than anything that's going to help programmers produce better software faster.

<comment><USER43> I contend it pretty much is an issue of bikeshedding. Still, it's less code, and I don't really see how `{ key: 'value' }` is not preferred over `{ :key => 'value' }`. Ok I'm done on this issue...

</comment></comment></comment><comment><USER44> The author starts with ` named block parameters`. But Clojure had this. I always Ruby has similar thing. In Clojure you can do `%1` or `%2` similar to `@1` `@2` in Ruby. So I guess the feature were inspired by Clojure. Even Elixir has it. The author is also a Clojure developer so I found it's weird that he hate that Ruby syntax.

However, at the same time, I totally agree that Ruby has so much more thing to work and improve, not to worry about these thing. As a Ruby dev, I don't want a new syntax to catch up with JavaScript where new syntax come up every weeks.

Ruby should focus more on type system, performance. Even some type hint like PHP would be very helpful. Lots of Ruby gem kind of introduce type. Example in Mongoid:

      class Person
        include Mongoid::Document
        field :first_name, type: String
        field :middle_name, type: String
        field :last_name, type: String
      end

I would love to have some type so we can use it directly.

Another weak point of Ruby is its module system :(. Some module system like Python would be great where we can load thing and alias them to avoid conflict.

<comment><USER25> > In Clojure you can do `%1` or `%2` similar to `@1` `@2` in Ruby

I very much like the feature itself, esp. for one liners you can come up with on a pry prompt. What I very much dislike though is the use of @ which is a glorious hack if there is any since currently @ tokenizably resolves to 'instance variable' in many a brain (and @@ to class variable but those should die since class variables can be implemented as instance variables of an instance of Class which is both much more elegant and less prone to corner cases, but I digress). In fact I'd very much be happy to use %1 as a syntax since that would match the "%1" placeholders in strings right away. "%1" in strings, \1 in regex for backrefs, $1 for regex groups, {%1} in blocks somehow works as a metapattern, but reusing @1 vs @myvar is such a mismatch that it brings a terrible cognitive dissonance (just see e.g how in [1, 2, 3].each { @1 + @I } both @ have different scopes!).

I can see the argument coming (if it did not already happen) that "OMG this is going to special case stuff in the parser so that the % method can be separate from this new syntax! plus this may break existing code!" to which I reply %1 won't ever appear in the same place in the AST as a modulo operator with a right hand integer argument and this is your job as a language implementor to make the dev job easy, and it's crackpot anyway since that will already special case the @ syntax in the parser. Simple is hard, bailing on implementing the simple solution as a language implementor even if it's internally tough is a copout.

</comment></comment><comment><USER45> I was sad to see => aka "hashrocket" syntax go, and it still slips in sometimes... but it is nice being able to use the same hash syntax in Ruby and JS.

What I'm intrigued by is the author's suggestion that there's more to the change than a relatively minor syntax change. Is there more to the story? I always assumed that both syntaxes are functionally identical.

<comment><AUTHOR> > What I'm intrigued by is the author's suggestion that there's more to the > change than a relatively minor syntax change.

I don't remember him saying that about hash literals. All I caught was that he doesn't like how it's limited to expressing only symbol-keyed hashes. Maybe I missed something, though.

<comment><USER45> That was exactly what I didn't pick up on, and you took for granted. I only rarely use non-symbol keys, so it hadn't dawned on me that the new syntax was, in fact, knee-capped.

</comment></comment></comment><comment><USER35> Personally, even though `.then` resembles A+ promise-like syntax -- I find that it feels more idiomatic than `yeild_self`. I remember Matz talking about this at RubyKaigi, and I wondered how it would work in practice; however, I enjoy that syntax much more than its predecessor.

Addressing some of the author's comments, I would agree with:

\- Endless ranges

\- The "@" syntax names.each { puts @1 }

I would love to see more dialogue on how these changes _could_ positively affect the language. Also, if these are adopted widely, there will be the inevitable Rubocop rule telling you that it prefers this syntax over the "legacy." I love Rubocop, but sometimes I feel there's no end to the journey to writing 'idomatic' ruby and the continued language sprawl definitely does not help on this front.

</comment><comment><USER46> Shouldn't this

        h = Hash.new { @1[@2] = "Go Fish: #{@1}" }

Be

        h = Hash.new { @1[@2] = "Go Fish: #@1" }

For maximum syntax golf?

Or are positional arguments not working the same way as instance variables wrt to interpolation?

</comment><comment><USER26> I've been primarily a ruby programmer for the last 10 years. I remember when I started to learn Ruby the "there's more than one way to do it" philosophy really bothered me, and I thought it would cause lots of problems. But I just haven't found that to be the case. Even though a lot of these language additions don't add functionality they do make day to day programming more pleasant. Maybe I just kind of think the same way as Matz.

I remember I thought &. was going to lead to loads of PHP style abuse, but I haven't seen that. My initial reaction to the new implicit block parameters was also "yuk" for all the reasons mentioned in the article. But I think they will generally be used responsibly for very small blocks, where people would typically just name their vars x, y, z anyway.

"There's more than one way to do it" did make learning a little harder, but you spend much more time as an expert than as a beginner, so I don't think languages should be optimized for beginners.

As for refinements, I have never used them, never seen them used, and I don't even really remember what they are. I think they were to save us from the evils of monkey patching. But in general the community has learned to monkey patch fairly responsibly, and I've rarely had a problem with it, except with a few fairly old gems.

As for new features that I think would really bring ruby to the next level - better functional programming support, better concurrency support, and optional typing would be fantastic (I know, hello Elixir. But I hear typespecs in elixir are meh).

Functions are only "first class-ish" in ruby - the block/proc stuff was fairly revolutionary to people coming from Java and C, but it is clunky compared to most any other language with first class functions. Javascript should never do something better than ruby.

Good concurrency primitives are also key for language adoption in 2019 - <USER2> though simple process based concurrency is simple and safe for probably 80% to 90% of the apps out there - when people choose languages they want the one that will handle 10,000 requests per second using 2 GB of RAM.

<comment><USER47>
        As for refinements, I have never used them, never
        seen them used, and I don't even really remember
        what they are. I think they were to save us from
        the evils of monkey patching.

They're pretty cool. IMHO they could be considered a best practice whenever you're reopening a class, whether it's for the purpose of monkey patching an existing method or adding your own.

Rather than overriding, say, `String#upcase` on a _global_ basis you could override it in some reduced scope, like within some specific class. This is arguably not ideal, but I would say that it is more explicit and less dangerous than a global monkey patch.

Or, if you have a use case for adding a bunch of new methods to `String`, you can go ahead and add that `String#decorate_with_random_emoji` method you've always dreamed of - but only within particular scopes, such as a particular Rails presenter or something. I think this is often better than polluting the `String` class globally, or having some utility class full of methods like `MyAwesomeStringUtils.decorate_with_random_emoji(some_string)`.

In most cases I would say that these refinements belong in a mixin that classes can explicitly opt into -- `include my_string_refinements` or whatever.

<comment><USER26> Thanks. Maybe I'll take another look at them.

</comment></comment></comment><comment><USER48> I learned some cool new features coming in Ruby 2.7 and I am very much looking forward to them now.

The rest of this post is drivel, complaints, and ends with begging questions answered in his opening bullets. How does this optimize ruby for happiness? Flexibility and choice.

Backwards compatibility is maintained. You can write the same old ruby you wrote before if you want to avoid change. I'm very happy to have some new syntax tools in the toolbox.

</comment><comment><USER49> Numbered arguments for short lambdas is not a rare language feature, and of them all, Ruby (and Perl) is exactly what I'd expect to have it.

</comment><comment><USER50> I like JavaScript's (old?) solution to the indexed argument problem: the implicit `arguments` parameter. I haven't bothered looking into the rationale for why that wasn't carried over into arrow functions, but I miss it when debugging programs written using ES6.

I'd be interested to know if anything similar was considered during the discussions around adding indexed arguments to Ruby.

<comment><USER51> Could you pitch an example where Javascript's `arguments` improves the code? Especially wrt the positional arg syntax at hand?

The only use-case I've seen for `arguments` is to create confusing function signatures with no formal arguments.

Your linter could prohibit its usage and your code would be better off.

Btw, `(...args) => args[0] + args[1]` works. No special `arguments` variable needed. Not sure why you'd do that over `(x, y) => x + y` though.

<comment><USER50> Besides debugging, I don't know that I've ever used the arguments parameter to do anything useful. I've leaned on underscore/lodash/ramda when doing anything involving clever involving partial application, shuffling arguments, etc. As I mentioned, though, I like/d `arguments` (I don't write much JS these days) because it gives you lots of debugging information with a simple call to `console.log(arguments);` -- made even simpler courtesy of a Vim abbreviation (`autocmd FileType javascript iabbrev adebugger console.log(arguments)`).

</comment></comment></comment><comment><USER3> As for refinements, the use case I imagine is when you need to be defining a method that _dispatches on the type of_ objects that are not "yours", especially where that dispatch plausibly needs to be extended with more types by other code. (If it doesn't need to dispatch on type, you can just define a function in a module and be done; if the dispatch never needs to be extended, you can kinda do the same thing, but it's much uglier.) Serialization is the most common case where I've run into this, where objects of different types need to be serialized differently; indeed the [https://bugs.ruby- lang.org/projects/ruby-trunk/wiki/Refineme...](https://bugs.ruby- lang.org/projects/ruby-trunk/wiki/RefinementsSpec) gives "ToJSON" as an example refinement.

A different way of handling this exists in CLOS: methods are defined on generic functions, which are are namespaced in packages just like class names are, but importantly, the class package and the generic package have no pervasive special relationship: a class doesn't "own" methods. So I can defgeneric extravagant-imperial-licentiousness:freeze and then define methods for it on all sorts of types, and it won't clash with someone else's jawbreakingly-simplistic-obdurate-numbness:freeze method. A consumer of either or both methods can choose to import one of the symbols and/or refer to either or both of them by their full names.

In Ruby, I've observed two "traditional" ways to do this: (1) add an ugly decoration to the method name which can never be elided (which is what I did in some internal projects, and then I added a prettier module function for external consumption that just trampolined to that method); or, seemingly more commonly and much worse, (2) ignore collisions, define whatever name you like on whichever classes you like, assume that you have dominion over your favorite short name and/or that the semantics are "obvious" and universal and that no one will ever load a library that does it some other way on top of yours and thereby break all the code depending on your version, and thereby, when that sometimes happens, land the hapless integrator in the dreaded "monkey patch hell".

Refinements supposedly provide a better way to evade (2). I didn't get to play with them enough to be sure that they do, and in particular ISTR this might not actually let you have a fresh method name which can also be extended elsewhere without requiring all consumers of the method name to be aware of all the extension refinements, which if so seems like a disaster for serious use. I feel like there's a better mechanism for this hiding somewhere in Ruby design-space, but I don't know what it is.

</comment><comment><USER10> TXR Lisp envy.

      1> (mapcar (op list (cons @1 @2)) '(1 2 3) '(a b c))
      (((1 . a)) ((2 . b)) ((3 . c)))

[http://nongnu.org/txr/txr-manpage.html#N-038348D3](http://nongnu.org/txr/txr- manpage.html#N-038348D3)

</comment><comment><USER52> This is a good reminder as to why Ruby is often called "the bad parts of Perl." I really appreciate other programming language ecosystems (almost any modern ones besides Ruby) that have abandoned things like this as bad practice, while Ruby continues to double down on it.

<comment><USER53> That's funny, I usually hear Ruby referred to as "the good parts of Perl" (and Google searches for those phrases suggest the same[1]) -- there's no sigil conjugation, objects are first class, and there are fewer magic variables/idiomatic usages of magic variables. I agree with the author that 2.7's new block syntax is a step in the wrong direction (and that safe navigation/method reference are a little uglier than they need to be), but I think Ruby has otherwise done an exceptionally good job of taking the best parts of Perl and combining them with the best parts of Smalltalk.

[1]: I only get 1 Google result for "the bad parts of perl" and about 1000 for "the good parts of perl".

<comment><USER54> I definitely see Ruby as Perl's spiritual successor. I would say it's one of the few languages other than Perl that can be considered "write optimized". Ruby makes it very very easy to just write code that just works. Just, a lot of code later you have huge monstrosity of rot that's almost impossible to maintain; I think that happens with all large codebases, Ruby just gets there faster.

<comment><AUTHOR> > I definitely see Ruby as Perl's spiritual successor.

Matz has said this himself:

* "I chose the name of the language from the jewel name, influenced by Perl. Although I named Ruby rather by coincidence, I later realized that ruby comes right after pearl in several situations, including birthstones (pearl for June, ruby for July) and font sizes (Perl is 5-point, Ruby is 5.5-point). I thought that it only made sense to use Ruby as a name for a scripting language that was newer (and, hopefully, better) than Perl." ([https://lingualeo.com/tr/jungle/231625](https://lingualeo.com/tr/jungle/231625))

* "Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually." ([https://www.artima.com/intv/ruby3.html](https://www.artima.com/intv/ruby3.html))

</comment></comment></comment></comment><comment><USER55> Looks like Tim Toady finally got his hands on Ruby.

</comment><comment><USER56> > _Here's a list of changes and additions that I certainly never needed (or > wanted):_

A, the classic "features before I came to use the language are nice and dandy, features added after I've learnt it are bad" complain.

<comment><USER57> It certainly reads that way. The author takes "programmer happiness" very personally here.</comment></comment>


Woven image from 1839 was an important step in the history of computing (2016) - <AUTHOR> http://www.historyofinformation.com/detail.php?entryid=2245 <comment><USER2> To see a jacquard loom in action, check out this clip from James Burke's excellent documentary, Connections: [https://www.youtube.com/watch?v=itd-4lMoXgI](https://www.youtube.com/watch?v=itd-4lMoXgI)

The clip doesn't show it, but Burke in the documentary makes the same connection as the article, but in a little more detail. He goes from Jacquard -> Babbage -> Hollering ( who used punchcards for the 1890 census), who founded the company which later became IBM.

Really fascinating to watch Burke pull up existing pieces of the modern world and examine their roots. Most of the time, it reveals that most revolutionary innovation was just a variation/consolidation of existing technologies.

<comment><USER3> Hollerith:

[https://en.wikipedia.org/wiki/Herman_Hollerith](https://en.wikipedia.org/wiki/Herman_Hollerith)

Connections used to be one of my favorite columns in Scientific American.

<comment><USER2> ah oops. Thanks for the correction!

</comment></comment></comment><comment><USER4> > The image, including caption and Carquillat's name, taking credit for the > weaving, measures 55 x 34 cm

> using 24,000 Jacquard cards, each of which had over 1000 hole positions

So, 24 megapixels, or about 6000x4000px at about 300dpi, that's a nice resolution, considered magazine photo quality nowadays.

<comment><USER5> I'd expect given that this is weaving the effective resolution is significantly lower. Both light and dark threads have to spend some time on top and bottom to hold the fabric together, if I understand correctly.

The PDF "Basics of Jacquard Design in Photoshop" [1] seems to suggest a 6x6 "pixel".

[1]: [https://mycourses.aalto.fi/pluginfile.php/153467/mod_folder/...](https://mycourses.aalto.fi/pluginfile.php/153467/mod_folder/content/0/Jacquard%201-%20weft%20system%20in%20English.pdf?forcedownload=1)

</comment></comment><comment><USER6> This is a much-higher-quality version of the actual woven material in question: [https://www.metmuseum.org/toah/works-of- art/31.124/](https://www.metmuseum.org/toah/works-of-art/31.124/)

</comment><comment><USER7> A bit disappointing that the article, which devotes seven paragraphs to discussing this image, does not actually display the image in question. Surely there is a public domain photograph of the image itself that would have been suitable to embed into the article?

EDIT: My mistake. It appears to be in the top-left corner.

<comment><USER8> It's on the page, in the left hand column at the top.

[https://commons.wikimedia.org/wiki/File:Machine- loomed_silk_...](https://commons.wikimedia.org/wiki/File:Machine- loomed_silk_portrait_of_Joseph-Marie_Jacquard_Wellcome_L0020370.jpg)

</comment></comment><comment><USER9> Weaving continued to play an integral role in computing with the development of 'rope memory' – the core of the Apollo navigation computer. [1]

1: "Moon Machines: Navigation Computer" [https://youtu.be/wD97RSpiZe0?t=1336](https://youtu.be/wD97RSpiZe0?t=1336)

</comment><comment><USER10> Here's a detailed visual guide about how the loom worked:

[https://www.youtube.com/watch?v=K6NgMNvK52A](https://www.youtube.com/watch?v=K6NgMNvK52A)

(Sorry, no sound apparently...)

</comment><comment><USER8> How can an entire article about Babbage and the Jacquard loom not mention Ada Lovelace even once?

"…We may say most aptly, that the Analytical Engine weaves algebraical patterns just as the Jacquard-loom weaves flowers and leaves " — Ada Lovelace

[https://medium.com/@hellomista/lovelace-and- babbage-91a76b19...](https://medium.com/@hellomista/lovelace-and- babbage-91a76b19ff30)

There is a great collection of her writings here:

[http://www.claymath.org/publications/ada-lovelaces- mathemati...](http://www.claymath.org/publications/ada-lovelaces-mathematical- papers)

<comment><USER11> I feel like this article is simply intended to demonstrate what the Jacquard loom produced. Leaving out the contributions of Lovelace is no different from leaving out the contributions of Turing. Both were monumentally worthy contributions to programming, but the intent of this article was to focus on one small but important facet of the overall history.

I myself have read many times over the years about the Jacquard loom but never actually saw a product of it. That is fascinating for me and doesn't take away any of my respect for what Ada Lovelace gave us.

<comment><USER12> What's the connection between Turing and the Jacquard Loom? I googled, and there doesn't seem to be any direct connection.

<comment><USER13> That's actually exactly the point the parent poster is making. Ada Lovelace has no direct relation to the Jacquard Loom. She's only related because she worked with Babbage, and Babbage was mentioned. Both of you are pointing out that Ada/Turing don't need to be mentioned, as it's not an article about general computing, but specifically about the Loom.

<comment><USER12> I'm actually disagreeing with that point, and was doing it by asking a leading question. Turing doesn't appear to have even talked about the Jacquard Loom, while Lovelace did. I consider that to be a direct connection between Lovelace and the loom.

<comment><USER14> There's a direct connection between _greglindahl_ and the Jacquard loom, too ((s)he wrote about it), but that's no reason to mention _greglindahl_ in the article.

Writers writing about these subjects may ignore non-male protagonists, but for subjects like these, one can only try to show that statistically.

<comment><USER15> > greglindahl

Call me uncouth, but I don't know who "greglindahl" is...?

EDIT: Ok - I have an idea now who "greglindahl" is - but I wasn't able to find any reference to writings about the Jacquard loom?

But Lovelace was writing about the Jacquard loom in relation to computation; was greglindahl's writings of the same style - that is, were they in relationship to computation?

If not, then of course there'd be no reason to mention that writer.

But the fact that Lovelace did write about the context of computation in relation to the loom, makes the idea that she could have been mentioned salient.

I'm not arguing that she should have been mentioned, but I can understand how someone could think that might be a worthy addition to the piece.

<comment><USER14> _"but I can understand how someone could think that might be a worthy addition to the piece."_

I can understand that, too, but if, as _telesilla_ did, you write _"How can an entire article about Babbage and the Jacquard loom not mention Ada Lovelace even once?"_ , I and, I guess, many others, don't read that as 'might be a worthy addition'.

And I don't know _greglindahl_ , either, but their comment that I replied to argued that, a) the article wasn't about the loom, but about general computing, and b) because of that, and because Lovelace wrote about the jacquard loom, she should have been mentioned the moment Babbage got mentioned. That's the only place I know where _greglindahl_ writes about the loom.</comment></comment></comment></comment></comment></comment></comment></comment>


Linux Game Porting and Day of the Tentacle Remastered - <AUTHOR> http://cheesetalks.net/porting_dott.php <comment><USER2> This and Monkey island's series are among my fondest memories in the gaming world.

Truly master pieces of the 80/90's.

Now we need a port of the Johnny Castaway Screensaver (instead of a hack) and my nostlagia will kick in.

<comment><USER3> I played through a bunch of these games with a good friend of mine; some really great memories there.

</comment></comment><comment><USER4> This was already posted yesterday: [https://news.ycombinator.com/item?id=12154180](https://news.ycombinator.com/item?id=12154180)

</comment><comment><USER5> This artcle was surprisingly difficult to follow with all those comments</comment>


The Dark Side Of Entrepreneurship (Continued) - <AUTHOR> http://petewarden.typepad.com/searchbrowser/2010/10/the-dark-side-of-entrepreneurship-continued.html

<comment><USER2> The article is a little sketchy but I can relate to the issue that is being put across here. I work a day job (as a systems analyst) that I'm quite passionate about, and my "side project" is as an artist / illustrator.

To get suitable stretches of uninterrupted time outside of a 9-10 hour day at work, I have to be militant about influence on both time and energy on any given day. The energy one is the hardest one to manage, and it involves cutting a lot of people out of my life, specifically the "draining" ones.

I used to be the kind of person that would invest a lot of energy in trying to get other people motivated or help them through hard times, then I realised I had nothing left to keep my own life moving forward.

I stagnated for a period of about 2 years then drew the line and cut off anyone that I found repeatedly crashing in on my life looking for support without doing a damned thing to help themselves.

At this point in life, professionally I'm achieving about 2x-3x what I used to but my personal life is abhorrent. It's a trade I'm willing to make but something that will need to be balanced out as I get older, as I'm already in a circumstance where I have few non-professional peers what so ever.

</comment><comment><USER3> There is a hope. Be organized, consider your life needs very carefully if you have the maturity to do so, and schedule your time accordingly. Although there's creative benefits to "flying by the seat of one's pants", it can be a quite hazardous path.

</comment><comment><USER4> Yup. For me, a 4 year relationship (out of 13 of off & on + a great friendship) ended in bitterness, in large part due to startup stress.

</comment><comment><USER5> My solution so far has been to be a dork that women don't even want to talk to. >_<

<comment><USER6> My wife has a beautiful friend who wants to marry a nerdy guy... her phrase . So your strategy could pay off! There's a great song by an English band: "sit down next to me" by James, which works for me when I feel dorky.</comment></comment>


Jamf S1 - <AUTHOR> https://www.sec.gov/Archives/edgar/data/1721947/000104746920003905/a2241939zs-1.htm#di71001_market_and_industry_data <comment><USER2> For those who were unaware, Jamf is an enterprise management company that offers Apple device management. This is an interesting time for them to IPO, as Apple just acquired one of their competitors a week ago..

</comment><comment><AUTHOR> Metrics highlights: $225M ARR, growing 40% YoY; 120% net revenue retention; 17 month S&M Payback (LTM, subscription gross margin basis); -11% operating margin; $6K average ARR/customer</comment>


GridVid.Me Launches Low-Cost Cloud Video Encoding Solution - <AUTHOR> http://techcrunch.com/2012/12/05/gridvid-me-launches-low-cost-video-encoding-to-compete-with-zencoder-and-encoding-com/

<comment><USER2> It sounds awesome for some large website with tons of videos, but for personal use you need a really fast uplink to make use of that service.</comment>


Trinity - Distributed Graph Database from Microsoft Research - <AUTHOR> http://research.microsoft.com/en-us/projects/trinity/ <comment><USER2> So many cool things come from Microsoft that lack the story and passion of some of the more well-known open source projects. It's truly disappointing.

<comment><USER3> You want a story, here's a passionate story!

MSR Asia is based in Beijing and is one of the fastest growing research outfits in the world. They're slowly showing up all over the place in the CS world, and this is just one of the examples.

Consider Microsoft Academic Search. It BLOWS AWAY Google Scholar, Citeseer etc. in terms of features. Once they attain coverage parity, there is reason to use anything else.

Academic Search, Trinity, and similar projects out of MSR Asia seem to be directly having impact in Bing. In a matter of a short few years, you're looking at a barebones search engine (Live.com) building an R&D infrastructure, with prototypes, and production modules feeding into what is now a pretty rocking search engine. [Example of Academic search integration with Bing: <http://www.bing.com/search?q=donald+knuth> , scroll to bottom -- page also shows Freebase integration in middle]

Ironically, Microsoft is playing David in the David vs Goliath story here, and the passion is showing in terms of the ecosystem of computing projects and products that are making it into Bing.

If you want to look outside of Bing, consider the Kinect effort. Did you know that the _hardware_ ships with mathemetical models built at MSR, trained using Dryad? (Dryad is an MapReduce competitor out of MSR) The training is the "secret sauce" and why you don't have to spend days calibrating the Kinect.

None of this is privileged information -- you just have to follow the hyperlinks :) The open source world is built on collaboration and sharing, and hence the "story" is the backbone of most work. But that doesn't mean other people don't have stories and passion!

<comment><USER4> Searching <http://www.bing.com/search?q=donald+knuth>, I see the freebase integration, but I don't see anything other than search results and ads at the bottom of the page. What am I looking for?

<comment><USER3> See: <http://i.imgur.com/efj7m.png>

"Data provided by MS Academic Search"

<comment><USER4> Strange - that didn't appear for me.

</comment></comment></comment></comment></comment><comment><USER5> MSR might just be the bell labs of this century! They already employ Tony Hoare (Quicksort), Niraj Kayal (the K in AKS), Simon Jones (GHC). What a heady list!

</comment><comment><USER6> This looks very interesting, although it seems like they are relying on a very high speed network to get around the latency issues inherent in sharding a graph database. (They mention partitioning, but not whether it occurs online).

Related, my Third Year project is a graph database that loads its data lazily from configurable back ends (databases, caches, APIs, written in Clojure). Now I have more evidence for my dissertation that this kind of tech is useful.

I wonder what their language for queries is going to look like, the only main graph language I've found is Gremlin, which used to be XQuery derived, but recently switched to chained objects.

</comment><comment><USER7> This looks great. I wonder if its usable for real-time (low latency) queries? Looks a bit batch oriented to me.

Also, is this open source? Can I download and play?

</comment><comment><USER8> What is the point? Show us the code or shut up.

<comment><USER9> Respectfully, Josh. Comments like this really don't help the conversation much here at HN.

<comment><USER8> It's a company talking about an internal tech (in comparison to another company's internal tech, no less.) They didn't release it. It is completely useless from a hacker's POV.

I stand by my comment.

Also, my name isn't Josh.

<comment><USER9> I apologize about the name shortening. As I said, no disrespect intended.

</comment></comment></comment></comment><comment><USER10> Is there a download link somewhere? Couldn't find it.

BTW, will it run on Linux?

</comment><comment><USER11> Buzzword BINGO!</comment>


Proving Differential Privacy with Shadow Execution - <AUTHOR> https://github.com/cmla-psu/shadowdp <comment><AUTHOR> paper: [https://arxiv.org/abs/1903.12254](https://arxiv.org/abs/1903.12254)</comment>


British Airways will host an 11-hour hackathon in the sky - <AUTHOR> http://venturebeat.com/2013/03/20/british-airways-will-host-an-11-hour-hackathon-in-the-sky/

<comment><USER2> Apply here: <http://ungroundedthinking.com/></comment>


Ask HN: What's your process of writing a blog post? - <AUTHOR>

I've made it a point to start blogging recently, and with a huge thanks to Octopress, I actually enjoy it now.
I wrote about my typical process of writing a post here: http://cnnr.me/b/2012/01/my-blogging-process/
But I'm interested in hearing how HNers typically blog. Do you have any kind of process you usually follow before getting a post up? <comment><USER2> My first step is to stumble across a topic I think others may find interesting. Then I just start writing. The first pass generally comes out as a bunch of poorly organized random thoughts, but once that process is done I tend to have a much clearer idea of how I want to present the topic.

From there I can rearrange what I've already written, which is usually ~50% of the content, and fill in the rest. I will revise the post until I feel like it is coherent but I don't get too hung up on getting it perfect.

I started blogging back in the Fall so I'm just forming the blogging-habit but I'm finding this method works well for me. It removes the writers block problems I've experienced in the past and makes the process much more enjoyable.

<comment><AUTHOR> This makes sense, and I can see how you'd be able to crank out posts from it. How do you go about keeping track of any "excess topics"? Typically, whenever I find something I like and dive into it, my mind can diverge the post into a few separate posts, which helps keep them to a good size.

Thanks for the comment and insight!

<comment><USER2> > How do you go about keeping track of any "excess topics?"

I usually have 2-3 posts going at any one time. I use a text editor to write my drafts and keep them in two local folders -- "posted" and "drafts." (I think there purposes are self-evident...). I'm sorry to say my system is neither sophisticated nor original but it works.

</comment></comment></comment><comment><USER3> Clickable : <http://cnnr.me/b/2012/01/my-blogging-process/></comment>


Branch - <AUTHOR> http://branch.com/ <comment><USER2> The biggest indictment of Branch to me is that since they alpha/beta/gamma/episilon-launched months and months ago, _no one_ I come across in my Twitter feed, Tumblr feed, RSS nor anywhere else uses it; it's something that seems deeply embedded in a Valley bubble. I am also dead-tired of promotional videos that in vague terms and promises make it sound like we're curing cancer.

The number of tools intended to "enhance conversation" are a dime a dozen, but fair or not, I think there is something to be said for traction and widespread use, even though it may seem like a chicken-and-egg problem.

If blogs and online publishers wanted to use the format, they would want to put it on their website directly for the ads, hits, and audience interaction, but Storify already accomplishes this to a large extent (barring any shut-down by Twitter).

It reminds me of the whole ~~social media~~ web 2.0 craze way back when.

There is also something weird about inviting people to listen in on a pseudo- private conversation. It makes it very artificial and staged somehow.

But hey, the logo is pretty cool. Probably one of my favourites out there.

+++

EDIT: If I were Branch, instead of promoting it as something generally applicable, which it is not, I would promote it as something targeting more niche purposes where it makes sense to use it and grow it from there and let people discover utilities slowly.

Another way to promote and develop it is as a GroupMe for Twitter, which by now is its own type of communication. As an addition to DMs and @mentions in your Twitter bar, you now have branches of conversations defined by the topic or group of people.

That kind of integration would probably lead to a Twitter acquisition, but that can't be the worst thing to happen to a company anyway ...

\---

The impression their website leaves users with is that this is something aimed specifically at self-important boffins and "thought leaders" - bloggers in realms Apple, tech, and Awl-ish dabblings. Exclusive online punditry circlejerk, essentially. The Davos of social media.

It just reinforces the idea that I am never going to use this, because let's be honest, I am not important/well-connected enough to get asked to join anyone's conversation - and I don't want to spam people just to try the thing out. It's as if it is a recursive start-up which has created a tool designed to let users talk about the start-up.

They should call themselves Recursive Corp instead of Obvious Corp, because it seems to have based its entire philosophy on its Valley-esque self-importance and -indulgence.

<comment><USER3> > _There is also something weird about inviting people to listen in on a > pseudo-private conversation. It makes it very artificial and staged > somehow._

Agree. What if they were actually private conversations, but with the same model of inviting people in?

I thought of Branch recently when I was reading the intro of Shirky's "A Group Is Its Own Worst Enemy"[1]. He mentions that before the internet, technology only enabled two-way, one-to-one communication (telephone, telegraph) and one- way, one-to-many communication (newspapers, radio, TV). The pattern of many- to-many, starting with BBSes in the 70s and becoming fully ubiquitous only now with Facebook, is new.

It got me thinking about how the many-to-many communication models online don't match those we have offline. When you have many-to-many communication offline, you sit down at a table with a small group of friends, family, or colleagues. Everyone at the table can listen and speak. People can leave, or new people can be invited to join. And the group is an ad-hoc one, formed _for_ the conversation, which doesn't persist after the conversation is over.

There's no form of online conversation that has these characteristics — no remotely mainstream one, anyway. And Branch is interesting to me because it's sort of trying to tackle that, except by allowing everyone in the world to read the conversations (or "listen"), they turned it into something completely different.

I don't think many-to-many communication online is a solved problem. We may still see new, better models that will displace the current ones.

[1]: <http://www.shirky.com/writings/group_enemy.html>

<comment><USER4> I don't mean to suggest that many-to-many communication online is a solved problem, but I want to note that the description you offered of small-group many-to-many communication offline, "you sit down at a table with a small group of friends, family, or colleagues. Everyone at the table can listen and speak. People can leave, or new people can be invited to join. And the group is an ad-hoc one, formed for the conversation, which doesn't persist after the conversation is over.", sounds a lot like a thread on a forum to me. Or a thread on Hacker News, to whatever extent we'd like to claim this isn't a forum.

People interested in the listed topic see it and "join" by entering, then glance around either near the beginning or the end, or try to get caught up, looking for a strand to join in with. They can leave again freely or speak up, and whoever is left paying attention may respond to them. Only the people interested continue to pay attention, and eventually the discussion dies out and everyone's moved on. The ad-hoc group no longer persists.

It doesn't really have an effective way to invite people into the conversation, but I feel that the other things are present.

<comment><USER3> Nope, that's not private and not restricted. Essentially everyone in the world is invited and everyone in the world (even those who don't speak) can listen. In practice the number of participants is much larger; at a table you probably have 2 <= N <= 10. And there's no presence information: if someone "gets up from the table" (stops looking at the thread) you don't know that. There's no visible distinction between being silent and not being there at all.

<comment><USER4> Ah, the distinction of smallness and privacy outside of the group didn't originally catch my eye. Thanks for clearing it up. :)

</comment></comment></comment></comment></comment><comment><USER5> What the heck is it? I seriously can't tell from the front page.

<comment><USER6> I had no idea either. And then I clicked on "What do you like about Reddit?" and it said it ended in August 2012 which had me even more confused.

But after clicking around I worked it out. It was an elitist (and far less useful) version of Quora. Or was it simply a polished discussion board. Then I clicked the About Branch button and realised it was more about the Twitter integration than anything.

IMHO: Try and clarify what this is on the home page. "A new way to talk to each other." is contrived, meaningless and simply not true. It's not new, it's better.

<comment><USER7> I don't understand the "Branch is an elitist Quora" analogy (which is one that I've heard before).

Quora is for monologues. Branch is for dialogues.

<comment><USER8> Sorry but I see dialogues more often under the answers at Quora than I see at Branch(es?)

<comment><USER7> That may be true. But that's not how the services are designed.

Quora gives your full attention to an answer. It collapses the comments. It lets you downvote unpopular opinions.

Branch limits the most that anyone can say at a time (to something like 800 characters--which is enough for an explanation but not enough for a tirade). And it gives equal weight to each comment that someone makes.

</comment></comment></comment></comment></comment><comment><USER9> Why does the home page have no information on what it is except, "A new way to talk to each other"?

</comment><comment><USER10> The initial flashy transitions that are happening are seriously slowly the overall page load. I don't know why intro/index pages do this so often. It just deters me from going further into the app. That said, it's a great domain name and it seems like a mashup of Twitter/Quora. Will be interesting to follow this.

</comment><comment><AUTHOR> I am submitting this because Branch is now open to the public.

Mods: I feel like the original submission title should be restored to give context to the submission.

<comment><USER11> What was the original submission title?

<comment><AUTHOR> "Obvious Corp's Branch now open to public"

<comment><USER12> That is a much better title. The new one provides no context or help. I know it's branch because the URL is right next to the title.

</comment></comment></comment></comment><comment><USER13> Not signing up for a service that wants significant OAuth access to my Twitter (or any other) account without giving me neither a reason nor an alternative.

</comment><comment><USER14> To the curious: It's a messageboard with some nice UX elements and a few twists (you have to ask or be invited in order to post to threads).

Annoying, though, that not only do you have to fork over your Twitter credentials (and your entire graph over there), but then the site subsequently asks you to confirm an email address.

I thought OAuth & OpenID style logins were supposed to help cut down on friction, not add more?

<comment><USER15> not a limitation of OpenID or OAuth, it's just that twitter doesn't give your email address to 3rd parties (facebook does)

</comment></comment><comment><USER16> Been having some great conversations about design recently; great to see Branch open to all.

<http://branch.com/g/design-startups>

</comment><comment><USER17> Sorry for being negative, but the slogan made me close the tab in horror. The page took a while to load and I couldn't figure out what it did, but was curious. Then slogan loaded and I closed it in a hurry. "New way to talk to each other" is NOT a good slogan.

Great domain name, though.

<comment><USER18> don't really understand why you closed the tab in horror. Why is it not a good slogan? After all, that's what it does.

<comment><USER17> The short answer is I, and I'm sure tons of other people, do not need another way to talk to each other, we're doing just fine. There have been so many offering with almost that exact wording that its become a cliche.

<comment><USER19> It's interesting that you were so proud to judge a website by its slogan that you'd come here and tell all of us. It's one thing to have that reaction, it's another not to resist that urge and then announce to everyone that you judged the book by its cover.

> do not need another way to talk to each other, we're doing just fine

People are very poor judges in deciding whether they need something new before they actually see it. I have no idea if this is something we "need" but this is some bizarre anti-progress attitude. The world is in need of new and better ways of doing almost everything.

<comment><USER17> I actually did it with helpful intent. The slogan is so bad that it needs to be changed as soon as possible. Most people who see that slogan and not like it would not provide feedback about it.

<comment><USER19> I'm not challenging that it's a useful data point. I'm questioning why you couldn't resist the urge to close the tab if you're going to bother to offer feedback. Time is finite and it's a perfectly valid reaction but not if you're going to attempt constructive criticism.

I'm also challenging that "we're doing just fine". Progress is always welcome and needed.

<comment><USER8> When I read about someone closing the tab in horror, I understand that he/she really disliked something about the page and used this expression to be more striking. Is there anyone who literally does that? =)

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> The apparent lack of nested commenting kills it for me. Also, it takes up a ton of space to show very little information. It's like if a designer was given unlimited license to produce something beautiful and useless.

</comment><comment><USER21> I went through the process of creating a "Branch" about Native/Hybrid/Webview apps <http://branch.com/b/native-vs-hybrid-vs-webview-mobile-apps>

There doesn't look to be a way to search or discover content, which leads to this sort of "loneliness" problem. It would be nice to search or suggest groups or discussions based on who I follow on Twitter or something, but as of now my homepage is just...pretty bare, and I'm waiting on folks to do stuff with my topic before I can use the site any further.

</comment><comment><USER22> We tested an MVP of a very similar service some months back. When we launched <http://www.qonversa.com>, we had no idea about Branch. So we launched a MVP and tested the hypothesis on a set of Indian users(we are from India). The idea fell flat coz of the exact same problems mentioned by everyone out here. The site's still there & we are thinking of pivoting it or maybe working on something else. Any inputs?

</comment><comment><USER23> Man, I've tried to use Branch. A few times. I've tried to invite people and join conversations, but I just can't get into it.

I resent the fact that there is no content discovery on the site. Why can't I be able to search for conversations? I don't care about "most highlighted branches". Branch doesn't know what my preferences are. Whereas on a site like Quora, content discovery by topic and search is brilliant.

Maybe one day.

</comment><comment><USER24> Well after being frustrated by the lack of any real explanation on the home page, I did manage to fumble around on Google and find their actual "What is this" page. Still pretty vague, but they should _definitely_ put some of this content on their current home page:

<http://branch.com/learn-more>

</comment><comment><USER25> Totally fucking lame. I can't search for discussions. They hide the popular discussions in the sidebar. All hype, zero value. It's pretty and that's all. $2M in funding, I laughed.

However, I created a scala group: <http://branch.com/groups/scala/join/a726238227c>

</comment><comment><USER26> Randomly clicking around, busted out laughing when I came to <http://branch.com/b/teen-wolf-or-vampire-diaries>

_I need to hop on the VD train._

(last answer on that page as of now)

</comment><comment><USER27> Can someone please explain what branch is and why it's different? I can't seem to make heads nor tails of it, and the front page video is typical useless marketing material.

<comment><USER28> Branch is basically a conversation platform. User A posts up a topic and then invites people who he/she feels is knowledgeable about the topic to answer it. The invited people can in turn invite others to the conversation as well. You can think of it as a private forum.

</comment></comment><comment><USER29> WOW, the design of this site is phenomenal. Beautiful UI/UX.

</comment><comment><USER30> It's a page of 9 short comments, but 8/9 are are elided after the first few words. Is the new way of talking to each other sentences where you can't see the end?

</comment><comment><USER31> I like it when I get linked to a started convo/branch, but I am having some issues with discoverability. Mainly, I can't seem to discover anything.

</comment><comment><USER32> Is there a way to search for groups you may be interested in joining... other than guessing the URL? Or is that somewhat missing the point?

</comment><comment><USER33> This project is nothing new and must have been mentioned on HN before. Why is HN allowing duplicates these days?

<comment><AUTHOR> I submitted this because Branch is now open to the public, instead of private beta.

<comment><USER33> Oh my bad then. Sorry.

</comment></comment></comment><comment><USER34> Are there private groups yet? In order to compete with FB Groups, you would really need private groups.

</comment><comment><USER35> I think the design is gorgeous and find the general idea very interesting. Good luck for 2013

</comment><comment><USER36> I like it. Cool idea and looks like a good execution. Search would be nice, along with SSL.

</comment><comment><USER37> This reminds me of <https://menshn.com/> (which was put together by a UK MP), however it seems better executed.

The front page doesn't really state this but from what I can see it's effectively a forum mixed with twitter and limited to certain subjects.

</comment><comment><USER12> So it's a forum, that literally brings nothing new in terms of features?

</comment><comment><USER38> Congrats on the launch guys! Great to see successful HackNY alumni.

</comment><comment><USER39> No way to delete an account? Booooooo.

</comment><comment><USER40> This site just caused Chrome to crash.

<comment><USER41> Oh no! Sorry about that - any chance you remember which page?

<comment><USER42> The animation in the header of 'Our Company' may have something to do with it (that, and my laptop being ancient) as I crashed as well when attempting to close that tab.

</comment></comment></comment><comment><USER43> another glorified forum emulation

</comment><comment><USER44> Isn't this just a strong implementation of comment Ancestry in Rails? Seems like one to me.</comment>