Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby adds experimental support for rightward assignments

blog.saeloun.com

Post reply on HN
Print view View original

161–170 of 172 posts

Re: Ruby adds experimental support for rightward assignments

#161

Post by wyuenho »

dragonwriter wrote: post #145
wyuenho wrote: post #140

Earlier quoted context omitted.

Complete English sentences in present tense are infix, with the subject and object clearly stated. Implicit subjects only follow after the first sentence in a paragraph or a phrase. Case in point is the words you've read so far. "are", "follow" and "is" are verbs. This is why most programming languages are in infix notation. Lisp syntax stayed is a historical accident. [1] Arabic is a prefix languages, and people don…

> Complete English sentences in present tense are infix. . Implicit subjects only follow after the first sentence in a paragraph or a phrase. This is true of the indicative mood, but not the imperative. Giving commands in the indicative mood is not typical.

Yes that's true. That's why most languages have infix operators and prefix function calls.

Re: Ruby adds experimental support for rightward assignments

#162

Post by SAI_Peregrinus »

dragonwriter wrote: post #134
hinkley wrote: post #114

Earlier quoted context omitted.

Where these conversations tend to break down is "you are using it wrong", which is technically correct but practically is a non sequitur. I can't control other people. Neither can you. Unfortunately saying that and acting like it's true are two separate things, and so we are chronically making decisions based on an illusion of control that is unhealthy to the point of self-harm. It just sets you up for disappointment…

> We put safeties on missiles And we put linters on code.

Sometimes. Often we don't. Putting linters on code is doing it right. But unless the language is opinionated and requires the linter there will be people who don't use it.

Re: Ruby adds experimental support for rightward assignments

#163

Post by wyuenho »

dllthomas wrote: post #156
wyuenho wrote: post #140

Earlier quoted context omitted.

Complete English sentences in present tense are infix, with the subject and object clearly stated. Implicit subjects only follow after the first sentence in a paragraph or a phrase. Case in point is the words you've read so far. "are", "follow" and "is" are verbs. This is why most programming languages are in infix notation. Lisp syntax stayed is a historical accident. [1] Arabic is a prefix languages, and people don…

> I think we've all learned in writing classes we should avoid it as much as possible because stating the active voice is clearer. Writing classes can be misguided. http://www.lel.ed.ac.uk/grammar/passives.html

No, in that example, the TA is very misguided and clearly didn't understand what passive voice is. Passive voice only applies to verbs, and it's often used to invert the object and the subject, occasionally used to emphasis one over another[1]. Unfortunately in English, there are a lot of adjectives that look like verbs in passive voice, examples like "interested" and "motivated" are given in the link you provided. The Edinburgh professor is not wrong either, he just thought every university teaches in America teaches passive voice the wrong way. Not in my case.

[1]: https://www.ef.com/ca/english-resources/english-grammar/pass...

Re: Ruby adds experimental support for rightward assignments

#164

Post by nemetroid »

thrwn_frthr_awy wrote: post #142
nemetroid wrote: post #113

Earlier quoted context omitted.

It will share with you its wisdom (the last line is printed by the interpreter): ?- FOO = 1, BAR = 2, FOO = BAR. false.

That’s neat. Is there a separate syntax for var to var assignment or are variables immutable in Prolog?

Variables are immutable, but note that it's the contradiction that leads to the "false" response, there's no issue with the assignment itself:

  ?- FOO = 1,
  BAR = 1,
  FOO = BAR.
  FOO = BAR, BAR = 1.

Re: Ruby adds experimental support for rightward assignments

#165

Post by jordoh »

stouset wrote: post #118
jordoh wrote: post #91

Earlier quoted context omitted.

`_` being assigned the result of the last statement evaluated is an IRB feature [1], not a ruby feature - hence the note that it is not a universal solution. [1]: https://github.com/ruby/irb/blob/master/lib/irb/context.rb#L...

So? Why does this need to be in the language when both major REPLs already support it? Why must this be yet another alternative way to accomplish the same thing as the way that’s existed since the first days of the language? There is no argument in favor of this addition. It doesn’t allow anything new, it provides a pointless alternative to the current way of doing things, and the one situation where it’s useful—REPL…

For better or worse, providing multiple ways to do the same thing is part of ruby's philosophy. [1]

[1]: https://www.artima.com/intv/ruby.html

Re: Ruby adds experimental support for rightward assignments

#166

Post by dllthomas »

wyuenho wrote: post #163
dllthomas wrote: post #156

Earlier quoted context omitted.

> I think we've all learned in writing classes we should avoid it as much as possible because stating the active voice is clearer. Writing classes can be misguided. http://www.lel.ed.ac.uk/grammar/passives.html

No, in that example, the TA is very misguided and clearly didn't understand what passive voice is. Passive voice only applies to verbs, and it's often used to invert the object and the subject, occasionally used to emphasis one over another[1]. Unfortunately in English, there are a lot of adjectives that look like verbs in passive voice, examples like "interested" and "motivated" are given in the link you provided. T…

The student paper is one of many examples of people inveighing against the passive while 1) providing incorrect examples, and usually 2) using it. It's amusing, but it's not the whole point:

"The passive is of course perfectly respectable, and there is no reason to try to avoid it. (To say that it shouldn't be over-used, or it shouldn't be used where it is inappropriate, doesn't distinguish it from any other construction or expression.)"

See the tremendous list of Language Log links at the bottom which deal with the issue from a host of angles. I recommend reading some of them - Geoff Pullum, in particular, is usually delightful.

"You should use active voice whenever possible" is bad advice - both active and passive are (nearly?) always possible but often one is clearer - and that can very much be the passive.

"You should use active except when passive is better" is arguably correct but fails to actually provide guidance about when the passive actually is better - which isn't rare.

That the passive is often overused may be useful to note, if that's actually the case.

Re: Ruby adds experimental support for rightward assignments

#167

Post by nitrogen »

the_other wrote: post #81
cma wrote: post #31

Earlier quoted context omitted.

synonyms in ruby seem to be a mistake. Searching code for certain usage patterns ends up needing more complicated regular expressions taking into account all synonym variations. If you've seen a method one way many times while learning, then see a synonym, you end up having to search up docs to make sure there isn't some subtle difference.

I find it really valuable to have different patterns of similar tokens to express different intent. My canonical example is early returns in JavaScript. Function f () { if(errorCindition) return if(normalBehavior) { return 1 } else { return 2 } } (I know, my use of braces and lack of semi-colons will cause flame wars!) The error condition looks different from the rest, so when I’m scanning quickly, I know where I am.…

shape of the code

This is an undervalued aspect of development. The tactile shape of a block of code conveys some aspects of intent, and overly aggressive linting tools destroy that intent.

Re: Ruby adds experimental support for rightward assignments

#168

Post by jbackus »

hardwaregeek wrote: post #109
jbackus wrote: post #58

Ruby's parser is notoriously complex; if I remember correctly, only a few members of the core team even know how to maintain it without introducing regressions. The craziest part of this is that Ruby does not provide a full featured Ruby parser, so its entire static and dynamic analysis ecosystem depends on a (actually very high quality) 3rd party parser, begrudgingly maintained by someone who (AFAIK) doesn't even wr…

Is Ripper dead? I attempted to do some minor work on Ripper and it was profoundly painful. My explanation for Ripper boiled down to a domain specific language in parse.y comments that gets translated into C via a very confusing Ruby script, which manually calls Ruby VM functions, that wait for it, are dynamically defined. This constructs a parse tree. If Ripper is still getting maintained, I'm seriously impressed.

Yeah. Been years since I even played with it, but even in 2016 I remember Ripper being completely unusable, failing to parse plenty of normal Ruby syntax. The Parser gem also maintains a separate parser for every Ruby version, so you can a program using Ruby 2.5 but tell it to parse code according to Ruby 2.2 syntax. It's also just way better built, tested, and has other nice features like tools for rewriting ASTs.

Re: Ruby adds experimental support for rightward assignments

#169

Post by jbackus »

YorickPeterse wrote: post #137
jbackus wrote: post #58

Ruby's parser is notoriously complex; if I remember correctly, only a few members of the core team even know how to maintain it without introducing regressions. The craziest part of this is that Ruby does not provide a full featured Ruby parser, so its entire static and dynamic analysis ecosystem depends on a (actually very high quality) 3rd party parser, begrudgingly maintained by someone who (AFAIK) doesn't even wr…

I helped out with parser as well for a while, though it was mostly documentation, triaging issues, that sort of thing. I think I still have push access to the Gem, as at the time the project had a bus factor of 1 (= whitequark). Anyway, I remember just how frustrated whitequark would get every time CRuby decided to make some random syntax change. I have a lot of respect for the current maintainer(s) for putting up wi…

Yeah, I don't remember any of the Ruby tooling ecosystem maintainers having nice things to say about the various syntax changes they've added over the years. I don't blame them.

These changes are always justified with a hand wave and a reference to "developer happiness" and ergonomics. I think that justification is seen as insulting when all the static/dynamic analysis tools obviously actually deliver a lot of value to Ruby devs, and yet the basic tooling to support this ecosystem (robustly parsing, traversing, annotating, rewriting, and unparsing an AST) is not provided by the language.

Re: Ruby adds experimental support for rightward assignments

#170

Post by wyuenho »

dllthomas wrote: post #166
wyuenho wrote: post #163

Earlier quoted context omitted.

No, in that example, the TA is very misguided and clearly didn't understand what passive voice is. Passive voice only applies to verbs, and it's often used to invert the object and the subject, occasionally used to emphasis one over another[1]. Unfortunately in English, there are a lot of adjectives that look like verbs in passive voice, examples like "interested" and "motivated" are given in the link you provided. T…

The student paper is one of many examples of people inveighing against the passive while 1) providing incorrect examples, and usually 2) using it. It's amusing, but it's not the whole point: "The passive is of course perfectly respectable, and there is no reason to try to avoid it. (To say that it shouldn't be over-used, or it shouldn't be used where it is inappropriate, doesn't distinguish it from any other construc…

The sentence "The passive voice is overused." illustrates this tension well. When you omit the subject, (implicitly we all know who that sentence is referring to), passive voice is more concise, but it's not clearer. It's actually less clear because there's less information available. I think this is the distinction most commentator miss.

In programming languages we often find better, we prefer explicitness over implicitness if the language is already designed to be very concise. Case in point: Python.

Post reply on HN