[HN Gopher] I Love Ruby
___________________________________________________________________
I Love Ruby
Author : mooreds
Score : 107 points
Date : 2023-12-18 21:18 UTC (1 hours ago)
(HTM) web link (eliseshaffer.com)
(TXT) w3m dump (eliseshaffer.com)
| claudiug wrote:
| same
| zakshay wrote:
| same!
| xal wrote:
| same
| brink wrote:
| After 10 years in Ruby, I moved onto Rust four years ago, and
| don't plan on really looking back. But with that said, I'm glad
| you love Ruby! There are certainly things to love.
|
| Personally, I just can't do without a good type system anymore. I
| think Rust has spoiled me. I do miss Ruby's powerful reflection
| features though.
| TOGoS wrote:
| Same. I used to love Ruby because it just matched the way I
| thought, and the standard library was layed out in a way that
| was consistent and easy to remember (one reason I never got
| into Python was that, while batteries may be included, the
| naming conventions are all over the place and I found every
| step of using them surprising). I fell out of love with it when
| 1.9 broke all my string manipulation code. The Rails crowd
| pushed the 'magic' stuff way farther than I was every
| comfortable with. I rarely made use of reflection, but even so
| find my old programs buggy enough due to mishandling of edge
| cases that I just don't really trust it anymore.
| TypeScript/Deno has mostly taken its place for me, though I
| don't find it quite as ergonomic for little system admin tasks
| as Ruby was.
| graypegg wrote:
| I think I have a few "most favourite" technologies that all max
| out some principle or idea that I like.
|
| The author here really hits on exactly why Ruby is my favourite
| "get things done" language. Rust, Typescript, and Crystal are
| all things I've worked with, but nothing gets out of my way
| like Ruby. It feels like sketching? It's very expressive thanks
| to it's prose-y syntax, but also metaprogramming + reflection
| like you mentioned really makes forming an idea while
| developing possible, at least much more possible than most
| other careful correctness-ensuring paradigms.
|
| There's nuance to these things, and nothing is the best really.
| But I think satisfying a borrow handler or a type checker does
| slow down that flow for me. I'd pick up a brush if I know what
| I'm making for sure, but a piece of chalk if I'm just wanting
| to get something working. Personal taste of course!
| tlrobinson wrote:
| Agreed, when Ruby became popular it was primarily competing
| against languages with verbose and rigid static type systems
| like Java. That is no longer the case, and the benefits of
| safety and developer experience provided by a good type system
| outweighs the cost.
| tines wrote:
| I know it's not the point of the article, but, as a code
| reviewer, this:
|
| > Well written ruby code can often read like natural language.
| Features like predicate methods even give up punctuation. [...]
| This is often why ruby programmers don't like comments. In most
| cases, the language makes comments unnecessary.
|
| churns my stomach. Good comments are rarely about saying what the
| code does, they're about explaining _why_ the code does what it
| does. Regardless of how comprehensible ruby code is, it doesn't
| change the need for comments. If I had a nickel for every time I
| gave a commit a -1 review because it had too few comments or the
| wrong kind of comments or lacked a "why" commit message, I'd be a
| rich man.
| pmgei48t wrote:
| out of curiosity how many ruby codebases have you worked on?
| stickfigure wrote:
| Why do you ask that? I worked in Ruby at Pivotal, with lots
| of people who espouse the "comments are just lies waiting to
| happen" philosophy. I agree with the parent, it's wholly
| misguided. Good comments save many, many hours of rediscovery
| by people who are new to the code - which includes the
| original author after walking away for a few years.
|
| If I had to guess, the anti-comment attitude comes from
| consultants who re-implement the same CRUD webapp on Rails
| over and over. Sure - no surprises, no comments, fine.
| pmgei48t wrote:
| 'cause i have no trouble reading ruby code without comments
| and neither do most rubyists in my experience
| soulbadguy wrote:
| +1
|
| I would even go a step further : I prefer a cryptic code with
| good comment explaining what the code does and why it does what
| it's trying to do vs a very clear code with comment on How the
| code works.
| gorgoiler wrote:
| One of the features I hope we'll see in the next generation of
| source control is having better support for annotating lines of
| source code with commit message information. We have good old
| "blame" right now but it's very easy to lose that information
| across refactors or reformatting (for example if someone
| introduces an auto formatter to the codebase, or if you move
| some code but also edit it such that your tool doesn't
| understand the old code and the new code were related.)
|
| Commit messages are such a good place to explain code and I
| rarely need the same explanation in a comment. I worry though
| about the fragility of the connection between (a) the source
| code and (b) the important commits that explain why the code is
| there.
|
| Perhaps there are some very good UIs out there already that
| show something a little more intelligent than than the most
| recent commit from blame?
|
| Another idea might be to attach blame-like functionality to the
| syntax tree so that the explanatory messaging can be tracked at
| the function level, rather than as lines of source code. Can
| others here can point me in the right direction for either a
| more tangible description of this feature, or an existing
| research?
| tcoff91 wrote:
| There is a git-blame-ignore-revs that you can configure to
| keep your git blames more useful.
| maximus-decimus wrote:
| My latest comment I wrote was for Ruby legacy code. It was
| "This method's documentation says it returns a string. That is
| a lie, it can return an object of any type."
|
| What's even better than comments, is a compiler that actually
| guarantees you're gonna be given something of the type you
| expect.
| soulbadguy wrote:
| To be fair in a weakly/duck typed languages a string can be
| an object of any type. The fair question to ask would : do
| those type quack and walk like a string.
| maximus-decimus wrote:
| They don't, it was returning settings from a json file and
| so was returning booleans, ints and floats.
| chihuahua wrote:
| Yes, this part of the article seems like nonsense to me. If it
| didn't have a question mark, we would need a comment? But
| because the predicate name contains a question mark, that's the
| only reason why we don't need a comment? That's nonsense.
|
| This only makes sense if we're in the school of thought that
| writes
|
| i = i + 1 // increment i by one
| woodruffw wrote:
| This is an uncharitable reading; I don't think the author is
| _literally_ saying that predicate-style methods are a perfect
| replacement for comments.
|
| The more charitable interpretation is that they're pointing
| out the developer ergonomics of things like predicate methods
| remove the need for comments that might otherwise be
| reasonable to insert. Whether or not that is _true_ is
| subject to reasonable debate, but it 's definitely a more
| nuanced opinion than "Ruby's predicate idiom means I don't
| have to document my obvious code."
| stouset wrote:
| I love Ruby and this is spot-on. Comments in _any_ language
| should explain why and not what.
| nextos wrote:
| Sure, not justifying code without comments. But keep in mind
| Ruby is a bit like Lisp, where there is a strong tradition of
| building DSLs.
|
| Hence, lots of Ruby code is a sequence of trivial declarative
| blocks that look like natural language.
|
| In these parts of the code, comments are redundant. I think
| that is the OP's point. Other parts definitely need them.
| dudul wrote:
| Maybe it's a hot take but I even disagree that code that reads
| like natural language is good.
|
| Is mathematic better when it reads like English? I personally
| don't think so. Yeah it's a bunch of symbols and conventions to
| learn but it ends up being more precise.
|
| I dont have anything to back it up :) I just think that natural
| language is almost by design messy and imprecise so I'm not
| really looking for that in my code.
| krupan wrote:
| https://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.ht...
| monlockandkey wrote:
| The most challenging part of reading code is the WHY. But is
| easier said then done when it comes to documenting code with
| this in mind. Happy medium is to make sure the author peppers
| in enough context of why something is like this.
| dbrueck wrote:
| Yes! Well-written code can be a joy to read, but it represents
| a subset of the total amount of useful information about what's
| going on in a program or system. Obviously code can be overly
| and unhelpfully commented, but poorly commented code is usually
| a very strong indicator of a mediocre programmer.
|
| Why does this function exist? Why was it implemented this way
| and not that way? Sometimes these are really important bits of
| info. Here's where this approach breaks down. Here's a sharp
| edge that we hope to remove someday. This part here incurs some
| technical debt but this is why we did it.
|
| In order to really maintain a codebase (meaning: safely fix
| bugs and add new features), you need to have an understanding
| that at least approaches that of the person who wrote the code
| originally, and good comments (e.g. level of intent comments)
| can help you do that. This is true even for your own code that
| you're returning to after some amount of time.
| krupan wrote:
| Occasionally it's necessary to write code that would make
| people ask, "why?!?" and comments definitely help there, but I
| feel like that's generally rare, especially when you use good
| variable/function names, keep functions small, keep nesting to
| a minimum, and follow all the other good programming practices.
| If you are writing/reading code and thinking it needs comments,
| maybe think a little harder about how the code itself could be
| made more clear.
|
| Comments are not checked by compilers, linters, code
| formatters, unit tests, integration tests, or any other
| automated tools for correctness, consistency, and good
| formatting. They rot quickly.
| jacobsenscott wrote:
| I can probably count on one hand the number of comments I've
| written a comment in over a decode of coding ruby. I've _never_
| encountered code I couldn 't understand just from reading the
| code. It really just isn't done in the ruby world. And good -
| comments are just noise in any language. You need to read the
| code because comments are wrong often enough (and 1% of the
| time is more than often enough) you can never trust them.
|
| Consider the overhead of a comment - first you need to read the
| comment because they are always above the code so that's what
| your brain will do. This will prejudice your reading of the
| code.
|
| Then you need to read the code while trying to block the
| comment prejudice out of your mind.
|
| Then you need to sort of mentally diff the comment and the
| code, and if the comment is wrong (spoiler...) decide if you
| are going to delete the comment (the best choice, unless you
| get a code reviewer who likes comments) or fix the comment (the
| worst choice, a waste of time, but maybe the only way to get it
| through code review).
|
| Now consider code without a comment: you just read the code.
| t-writescode wrote:
| Sometimes you just need comments. I've written graphing
| algorithms that traverse databases in Ruby. I named functions
| well, too; but the actions I was doing were so weird without
| sufficient context that when someone might need to change it,
| 6 months or a year from now, they would have absolutely no
| idea why I was doing. And no amount of clean code patterns,
| nor code as documentation patterns would have clarified what
| was being done as much as the multi-paragraph with ascii art
| comment I wrote above the function.
|
| Sometimes you just need comments.
| kazinator wrote:
| Some code needs "why" comments, and other code just needs
| "what" comments (unless it's written in a clear, high level
| language).
|
| "Why" comments need to go onto code that make some kind of
| arbitrary decision. Or code which is integrated with processes
| that are happening elsewhere and has to behave in a way that
| complements those behaviors. Otherwise the reader would have to
| read that code together with all those other pieces (or
| specifications) in order to understand it. Code that is written
| in a certain way (particularly, an unusual way) for some reason
| that is not obvious deserves a "why" comment. E.g. "due to a
| compiler/library bug [give specific version info], we cannot
| just do this: ...".
|
| Code that doesn't make arbitrary decisions or integrate with
| things elsewhere, or make unusual coding decision for reasons,
| often doesn't require "why" comments.
|
| The author of the article hastened to add:
|
| > _And when you do need [comments], it's often when you're
| doing a very specific or obscure thing that requires context to
| understand. It's clear from the code why you need a comment in
| that case._
|
| It's clear from the code why you need a comment, because it's a
| "why" comment.
| fny wrote:
| Also, literate programming is a feature of any language. Sure
| Ruby has punctuation, but is there enough of a difference
| between `Array#empty?` vs `Array#isEmpty` to break a absolutely
| not.
|
| I say this as someone who wrote Ruby for 6 years and loves the
| language for its other features (e.g. everything is an object,
| functional programming, DSL-capabilities)
| thih9 wrote:
| The example was: 'if
| @subscription.supports_feature?(:feature_a)'.
|
| In a different language you might deal with more boilerplate
| (getting some data access object for feature status, passing
| the db connection, extracting the subscription id, etc), or
| less clear naming schemes (importing namespaces, aliasing them
| for convenience, your subscription might come from some one
| letter temp variable), or something else. At this point the
| "why" comment might be not that different from the actual ruby
| code.
|
| Note that we only see one line of ruby code; the parent method
| name, or the if body would have more context.
| kreutz wrote:
| I love Ruby too. I wish they fully embraced types. Sorbet is not
| fun to use.
| revscat wrote:
| Good lord, no, it is not. I tried Sorbet on a small personal
| project and rather quickly abandoned it. It made the code ugly
| and was a pain to maintain.
|
| The fact that Sorbet has not seen adoption outside of Shopify
| is also somewhat telling.
|
| It's disappointing, because Ruby needs this. Modern tooling has
| moved in the direction of typed languages, and Ruby's tooling
| has suffered comparatively. Outside of RubyMine it's still
| difficult to get "jump to definition" to work consistently, and
| in 2023 this is a rather embarrassing strike against the
| language.
| narven wrote:
| try Crystal lang (https://crystal-lang.org/)
| mathverse wrote:
| This. I dont really need true essence of metaprogramming
| craziness of Ruby. I need Ruby-like, dev happiness, readability
| and performance. Wish Crystal would catch up and get some
| attention.
| pmgei48t wrote:
| me too
| desireco42 wrote:
| I for one appreciate this post. I love Ruby too and it brought a
| lot of joy and pleasure in my life. I am mostly not using it
| today but it is OK, I still love it.
| soulbadguy wrote:
| It's interesting how different languages resonate so differently
| with each of us. I have tried a bunch of languages, and got
| pretty deep into ruby at one point in time when rails was the
| main web framework i was using. However ruby is probably my least
| favorite language. Most of the features which actually make ruby
| unique are exactly the one that turned me away and toward
| something like F# when i want funtional goodness, C++ when i feel
| adventurous and scheme/racket when i want dynamic language fix.
|
| > Ruby is probably the most expressive programming language on
| Earth
|
| I wonder if there is a generally accepted quantifiable definition
| of programming language expressiveness. Here the author seems to
| equate it to closeness to natural languages.
|
| In my experience, ruby code is easy to write, but hard to follow
| without being familiar with the code base and it's idom. A lot of
| the information required to understand it is passed through
| implicit context.
| philomath_mn wrote:
| > I wonder if there is a generally accepted quantifiable
| definition of programming language expressiveness
|
| In my opinion, expressiveness is used as the catchall, je ne
| sais quoi whenever someone likes a language and needs another
| bullet point to put in the "Pros" column.
| jjgreen wrote:
| It has a certain _je ne sais quoi_ but I don 't know what it
| is.
| haolez wrote:
| On the other hand, I find it extremely difficult to follow C#
| code. It's a lot of type gymnastics and dependency injection
| noise that makes it hard to understand where's the actual
| business logic.
| soulbadguy wrote:
| Agree. However i think this is mainly an artifact of
| API/framework designed in the 2000 and 2010 with over-
| enginered and over used designed patterns from the GOF. Both
| java and C# have their root deep in enterprise land were
| those are still sadly too common.
|
| Modern framework are a bit better.
| uticus wrote:
| > I wonder if there is a generally accepted quantifiable
| definition of programming language expressiveness.
|
| If there is such a definition it would not fit into these sorts
| of conversations. I love Ruby but every time I see someone
| mention Ruby "expressiveness" it is never mentioned as a
| subjective fact like syntax feature count. Instead it is always
| closely tied to emotional feeling, assumptions, and intuition.
| "Ruby's expressiveness means it just gets out of the way and
| lets me code." I've probably said that myself a hundred times.
|
| OTOH it _is_ great for DSLs and metaprogramming, gives a taste
| of what the LISPers have always had. Maybe that is a good
| definition of "expressive".
|
| [edit: added thought about DSLs]
| samsquire wrote:
| It's positive and uplifting post and it is that too when a
| language works with how you think and is expressive and
| productive. It's unsatisfying to work against a learning curve if
| you are hitting obstacles.
|
| A language is one possible notation of thought.
|
| I like to be productive with my thoughts. I tend to do proof of
| concepts in Python then port to C or in Java directly.
|
| I remember learning about Ruby when posted on digg and there was
| a new tool coming out all the time.
| robertlagrant wrote:
| I've no opinion on Ruby, but I don't really understand this
| article. People like familiar tools, and get good at them -
| agree. But a lot of languages can be written in fluent ways, and
| I didn't really find the test example that easy to read. I
| wouldn't say "end end end" at the end of describing the test out
| loud, for example.
| akprasad wrote:
| I'm glad that the author enjoys Ruby! As someone with limited
| Ruby exposure, these quotes stood out to me:
|
| > The language is meant be joyful to use. [...] Everything else
| that Ruby is stems from this value.
|
| This is important and underrated. I think many programmers have a
| bias that working on a difficult problem entails using a "real"
| programming language with sharp edges. I had some version of this
| bias for a long time until I started exploring the most recent
| generation of systems languages.
|
| > Well written ruby code can often read like natural language.
|
| I see where the author is coming from, but I find a healthy
| dollop of symbols to be very helpful for reading and
| understanding code at a glance.
|
| > Feeling recognition in the language you're programming is so
| powerful.
|
| This is the feeling I had the first time I used Python, and later
| Rust. It's a wonderful feeling!
|
| > [As] Kent Beck said at RailsConf in 2020, "Software design is
| an exercise in human relationships."
|
| Especially true given all of the components involved in
| supporting a language: compiler, docs, standard library, third-
| party libraries, package managers, frameworks, formatters,
| profilers, ...
| woodruffw wrote:
| The blog post (and Ruby's) emphasis on programmer happiness
| really resonates with me: other than Rust (which induces
| programmer happiness for fairly different reasons), I've seldom
| run into a programming language and ecosystem that tries so
| _hard_ to make programming mirthful.
|
| (Does that make Ruby a _good_ programming language? That 's
| unclear to me; what's clear is that I have fun writing it.)
| atomicnumber3 wrote:
| I love Ruby too. It's a great language, and as a language I like
| many things about Ruby a lot more than python. In particular,
| chains of functional operations like: arr
| .map{|o| ... } .reject{|o| ...}
| .reduce(init_acculm){|init_acculm, o| ...}
|
| are super super clean and expressive. Very similar to what I like
| about Java streams.
|
| And the library ecosystem is great, I like how it shares
| spiritual similarities with python where libraries are very "no
| nonsense" (you don't need extensive configuration and builders
| and researching a million configuration items etc etc... looking
| at you, Java) and you typically just import and go. Rails, of
| course.
|
| I keep picking python over ruby though, for things I'm going to
| have to actually maintain. And I typically pick Java over python
| if I smell I'm going to care even an iota about performance.
| (Often I don't, though). But ruby vs python, I keep coming back
| to the divergent opinions they've taken on gradual typing. I like
| that python3 lets you include the types as part of the program,
| part of the grammar. Ruby relegates them to a separate file. I
| guess the intent is that it's more for libraries, like how js
| libs will ship typescript type files? But I don't like that, I
| want types for myself. Sorbet exists, of course, but I don't like
| that it's a) a gem and b) still not a first-class part of the
| grammar but is instead just operating "in-language". I know it
| works and e.g. Stripe uses it to great effect (I worked there)
| but I just don't like it, personally, and I find that python3
| with its built-in type hinting tends to get typed more readily
| than ruby where it's a much further reach away.
|
| But I really love ruby. I hope it improves its type-hinting story
| because I like most other things about it. But I was pretty
| unenthusiastic about python prior to it getting its type hinting
| built-in, so apparently this is a big deal for me.
| woodruffw wrote:
| Blocks and `yield` are a killer feature; I regularly pick
| Python over Ruby for similar reasons as you, but I consistently
| find myself missing those two (and all the things that get
| built out of them, like the `Iterator` APIs).
|
| Python is a lovely language, but context managers often feel
| like a shabby substitute for what I can do with `yield` in Ruby
| :-)
| endgame wrote:
| This is basically how I feel about true first-class functions
| when I have to wrangle ruby and care about blocks, procs, and
| lambdas.
| MichaelDickens wrote:
| I love the syntax of Ruby blocks (IMO it's the best syntax
| for higher-order functions in any language) but I don't
| understand why they were implemented the way they are,
| where some things are blocks, some things are procs, and
| neither one is really a function. I would prefer if Ruby
| blocks were just functions.
| soulbadguy wrote:
| I agree that pipeline functional stream processing are in many
| case simpler and clear than weird nested loops with early exit
| conditions. However, besides maybe the needs for lambda
| expressions, this is mainly a function of good API design as
| opposed to something code to the language. In particular here i
| don't think the niceness of this approach is related to
| anything core to ruby. C# with link, F# with computational
| expression (and haskel monadic structures) and as you mentioned
| java stream do the same thing and even a bit better in my
| opinion
| neonsunset wrote:
| You can do this in C#, F#, Rust and many other languages too
| with 10x better performance (in Rust in particular those
| usually get completely optimized away).
| thegabez wrote:
| No language is more fun to write in than Ruby.
| bakuninsbart wrote:
| I think the point about expressiveness is _exactly_ what makes
| ruby so divisive: It is great when you are deep within the
| ecosystem or do exactly what the ecosystem expects you to want to
| do, and an absolute pain if you want to do anything non-standard.
|
| The supports_feature-method is probably defined somewhere 5
| abstractions deep. If you are lucky that is, it might also be
| part of some library's weird meta-programming of supports-* that
| no LSP can point you towards. I've never worked in an ecosystem
| that celebrates implicitness as much as ruby does, and it is
| driving me nuts.
|
| The fact that finished code looks great and reads well doesn't
| balance the scales in my book.
| pqdbr wrote:
| In my experience this is almost never the case.
| #supports_feature? would be defined right there where you'd
| expect - in that Subscription model.
|
| Even tough you can reach for metaprogramming (like
| define_method or method_missing), that's really not how the
| entire ecosystem of guides and tutorials will point you.
|
| Anyways, when in doubt, just plug a debugger and call
| "@subscription.method(:supports_feature?).source_location`, and
| generally that's all it takes.
| mplewis wrote:
| Rails is the biggest Ruby project and it's heavily based on
| metaprogramming. Even Rubymine has trouble finding the
| canonical definition of a named method sometimes - it has to
| guess. I love Ruby but I totally understand this criticism.
| chihuahua wrote:
| It is mind-boggling to me to see all the low-value features that
| Ruby has, but no enums. So every time an enum is needed, there's
| some ugly code that tries to emulate an enum.
|
| The guiding theme for Ruby appears to be "let's give people a
| huge number of ways to write unreadable code" and it reminds me
| of JWZ's classic rant about PHP, "a fractal of bad design."
| jjgreen wrote:
| I disagree, but thanks for reminding me of that article, just
| splendid https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
| design/
|
| You couldn't _really_ find that many quirks, edge-cases and
| foot-guns in Ruby, could you?
| chihuahua wrote:
| For me, it's not so much that there are quirks and edge-
| cases, but rather that Ruby seems to have a lot of clutter
| (e.g. "unless", punctuation as part of function names, etc)
| while useful features are missing.
| jjgreen wrote:
| Fair enough, a matter of taste. Personally I'm a fan of
| "then" which I guess would give you the horrors :-)
| hu3 wrote:
| Even PHP has enums now and they are pretty cool:
|
| https://stitcher.io/blog/php-enums
| makeramen wrote:
| I actually dislike that Ruby reads like natural language. The
| complex logic in large systems would take many paragraphs to
| describe in english but is often much clearer and more succinct
| in code.
| mattgreenrocks wrote:
| Ruby's a great language, but the cult of personality is really
| strong there, especially in Rails. And that ultimately led me
| away from the ecosystem.
|
| I'm not looking for heroes to worship, just good tech.
| impulser_ wrote:
| Maybe this is just my experience, but the thing that sucks a lot
| about programming to me it that the most enjoyable programming
| languages are often the ones with the smallest job market.
|
| My job as a programmer would be infinitely better if I could
| spend it programming Elixir all day, but there is basically no
| Elixir jobs compared to Typescript, Python, and Java.
|
| But instead I hate my job working in Typescript all day solving
| problems that I wouldn't have to if I could just use Elixir.
|
| Ruby use to an exception to this, but almost no one is building
| on Rails anymore compared to how many people build on React, and
| NextJS.
|
| I'm talking about full stack application market, this is probably
| different for Rust users for systems, and Python for Data/AI.
| marcrosoft wrote:
| Take ruby vs go. Ruby can write expressions that resemble a
| sentence so you can skip commenting and it looks nice. Go is
| verbose and less English like. Which is easier to understand what
| the code actually does? Go may take a little extra time to digest
| but it is infinitely more clear what is going on. If you don't
| need to debug the ruby code or optimize it ruby wins because it
| is easier to digest and reads like English. It is a trade off
| like many things in software.
| shaftway wrote:
| I don't know Ruby at all, and maybe some familiarity with the
| language would help, but the biggest example code makes
| absolutely zero sense to me: RSpec.describe
| Ticket do context 'when the ticket is closed' do
| it 'emails the requestor with a confirmation' do
| ... end end end
|
| I have no idea what's going on here.
|
| I get that there are some blocks of code, though it was the
| indentation that told me that; "do" and "end" feel super verbose
| and bleed into the important parts of the code for me.
|
| Why is Ticket capitalized? Is this a variable? An object that
| we're about to work on that's coming into scope?
|
| `context `when the ticket is closed'` feels like it's setting me
| up. Is this an if block? Or is it some fancy way to set a
| listener on a property? Is this setting up a callback that'll
| persist across runs of the program? Or is this just a method
| named with spaces that could do anything?
|
| `it 'emails the requestor with a confirmation'` has got to just
| be a method name. But what is "it"? What was "context" in the
| previous one? And why does "emails the requestor with a
| confirmation" need to be a block? What happens in there? Is this
| just setting up some kind of call stack like thing that provides
| context all the way down?
|
| None of this is intuitive. And the impression that I get is that
| the author is calling methods with spaces in their names and
| unclear block semantics "expressiveness".
| nickysielicki wrote:
| I had to write some ruby at work recently and wasted a few hours
| on a bug caused by the following footgun:
| irb(main):028:0> value = false or true => true
| irb(main):029:0> value => false
|
| That really makes me want to write it off entirely. It's hard to
| think of a situation where this is the right behavior.
___________________________________________________________________
(page generated 2023-12-18 23:02 UTC)