I don’t think that is an indictment of the moderation system. You can’t replace a dead community with excellent moderation. Slashdot’s dead because it failed to produce worthwhile content and not be an even uglier pile of ass. The mod system can’t do anything about that.

> The last time it hit, at a Chinese restaurant in SF,

Not to not take it seriously, but isn’t there a lot more stuff in American Chinese food other than MSG? Like of the 1000s of chemical substances that would be in a plate of Chinese food, why of all places would that be where you would isolate an MSG allergy?

> or adulterant that travels with commercially produced MSG

Then that wouldn’t be an MSG allergy. Oats are gluten free but celiacs have difficulty with them, not because of the oats but because of contamination.. we wouldn’t say they have an oat allergy though.

> the language designs are so similar that I could just as well imagine a world where Python is the web development lingua franca, and Ruby has all the machine learning libraries.

Well aside from the startling implication that Ruby is a web development “lingua Franca.”...the latter statement is reasonable, as it turns out language design isn’t actually that important here. But the former is pretty far off the mark. I mean, Ruby doesn’t even have first class functions and is very strongly smalltalkish in its OO purism, it has mutable strings a-la Perl. The async story is obviously quite different. Python has a much more complicated interpreter, which has contributed to it being more difficult to get even simple optimizations that are done in Ruby. They’re really only similar in the most superficial sense... in the same way that all current dynamic interpreted languages will do certain things similarly.

While I agree with most of your comment, "Ruby doesn’t even have first class functions" sticks out. Not because it's not true, but because it doesn't really matter as Procs are first class in Ruby and can be used in all the same ways, so it doesn't really affect things except introducing something you might need to learn coming from JS or any other language where functions are first class.

>it doesn't really matter

This way can be argued for almost every language, as they almost all allow some form of passing a piece of code to a function. The difference is what matters - whether that's elegant enough to be widely used or not. Ruby is, frankly, somewhere in between.

> Ruby doesn’t even have first class functions

I'm genuinely curious what is it that you miss in Ruby regarding functions (my Ruby is pretty OOPish and I try to avoid functional magic).

AFAIK you can do stuff like currying/partial application with lambdas and you can get a hold of any method by name and use it as a lambda, pass it to other functions, use it as a block etc. Is there something we're missing compared to, say, JavaScript?

You can pass a function as argument using its name in Python and then call it. You must pass it as a symbol in Ruby and then send to it.

  def f(x):
    return x

  def g(fn, x):
    return fn(x)

  g(f, 1)

Ruby can definitely pass around several varieties of closure and related constructs, including procs, blocks, lambdas, bindings, continuations, fibers, and both bound and unbound methods.

Whether we should is another matter, and the syntax and idioms certainly lean towards preferring a symbolic late binding, but the language is multi-paradigm, and one may write purely functional Ruby if desired, immutable values and all.

No, passing a symbol and sending is a different mechanism.

The send method is basically the same thing as calling a method by name, as in "obj.foo" == "obj.send(:foo)". If you only pass a symbol into your "caller" method, the symbol goes through the normal lookup: does the receiving object respond to this? If yes, then that implementation (at that exact moment) is called, if not, you get a method_missing.

You're right that that's not how you do first-class functions in ruby. Your example in ruby would be:

  def get_and_call(fn, x)
    fn.call(x)
  end

  def upcasinator_method(str)
    str.upcase
  end

  upcasinator_lambda = lambda {|str| str.upcase}

  get_and_call(upcasinator_lambda, 'foobar')
  => "FOOBAR"

  get_and_call(method(:upcasinator_method), 'foobar')
  => "FOOBAR"

As you can see there are two ways to do that -- either you create a Proc (a lambda if you care about arity), which is the first class function in Ruby, and you call that, or you define a method (but that's a method, an OOP concept, a procedure that implicitly operates on an object), you get a hold of it using the "method" method and then you call it.

The exact same thing in Ruby:

    f = ->(x) { x }

    g = ->(fn, x) { fn[x] }

    g[f,1]

or even¹

   h = g.curry(2)[f]
   h[1]

function composition is available:

   f = -> x { x * 2 }
   g = -> y { y + 4 }
   j = f >> g
   k = j << g

   j[1] #=> 6
   k[1] #=> 14

and, topically, the Y combinator:

    y = -> f {
        -> g { g[g] } [
        -> g { f[-> v { g[g][v] }] }
      ]
    }

hence

    fib = y[-> f {
      -> n { n < 2 ? Array(0..n) : f[n-1].then {  _1 << _1[-1] + _1[-2] } }
    }]

    fib[6] #=> [0, 1, 1, 2, 3, 5, 8]

although the more idiomatic Ruby might be

    fibo = Hash.new { |this, n| this[n] = n < 2 ? n : this[n-1] + this[n-2] }

    (0..6).map(&fibo) #=> [0, 1, 1, 2, 3, 5, 8]

in which the Hash self-converts to a closure via the & operator.

Anyone who says "Ruby doesn't have first-class functions" can fight me.

--------------------

⁽¹⁾ notwithstanding that I recall Matz once remarked the curry method is only included as an elaborate joke.

Thank you. I forgot the Proc#[] method.

I never thought I would ever write these words, but the Python equivalent is more beautiful. Ouch.

> You must pass it as a symbol in Ruby and then send to it.

This is just plain wrong. You can absolutely do this, as other commenters have pointed out.

It is common to see Ruby code passing around a symbol and sending it, but my guess as to why this pattern became common is that it can be serialized into plaintext like YAML, stored in a database, and called later, like for a background job in a web app. But there's no need to do it this way.

Another reason you don't tend to see it this way in Ruby is because Ruby optimizes for the common case: calling methods [1]. Because of this, you can easily create very concise DSLs in Ruby, which would never be quite as clean in Python.

1: https://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-ori...

Wait, Ruby doesn't have first class functions?

I'm pretty sure it does and that it is full-fledged, compared to Python's intentionally restricted `lambda` syntax.

Nope! You can't pass functions, return them from other methods and so on, so it's not first class.

What you do have in Ruby is Proc, that can be used kind of like first class functions, so you don't really miss out on much.

Maybe I misunderstand your use of the word "function" here, but in addition to Proc/lambda you can certainly reference a method, pass that around, return it, call it?

See:

  * https://ruby-doc.org/core-2.7.1/Method.html
  * https://ruby-doc.org/core-2.7.1/Object.html#method-i-method

    $ irb
    2.3.3 :001 > p = Kernel.method(:puts)
     => #<Method: Kernel.puts> 
    2.3.3 :002 > p.call "Hello"
    Hello
     => nil 
    2.3.3 :003 > def run_a_method(meth, *args)
    2.3.3 :004?>   meth.call(*args)
    2.3.3 :005?> end
     => :run_a_method 
    2.3.3 :006 > run_a_method(p, "Hi!")
    Hi!
     => nil 
    2.3.3 :007 > 

ps. this also works with the "to_proc" operator (&) so you can do this:

    [1, 2, 3].each(&Kernel.method(:puts))

(but I wouldn't necessarily recommend this since it's not very readable, at least to my eyes).

Yeah, and that's not what first-class usually means. I simply can't say "my_method = Kernel.puts" the same way I can say "my_class = Kernel". Ruby authors seemed to want to make parentheses optional by any price, and that killed the opportunity to make methods first class.

You can literally write my_method = Kernel.method(:puts) and it’ll give you the method to do what you wish with.

As far as defining anonymous functions, literally all you have to do is:

my_func = -> (input) { output }

That makes a “lambda” which is literally just a function you can pass around anonymously.

You call it via either my_func.call(input) or simply my_func[input].

That capability is used all over the place.

Ruby absolutely has first class functions, the only thing you can say is it the syntax is slightly different if you want to use them anonymously (with no object context).

> my_method = Kernel.method(:puts)

That's exactly what being first-class is not. You tell Kernel to wrap you a method called puts into an object of class Method, rather than assigning a method to a variable. You don't have to look further than JS for a counterexample.

Ruby has two kinds of functions. Methods are functions attached to objects. Lambdas are functions that are not. Ruby lambdas are exactly like javascript arrow functions, or python functions.

There's a _reason_ for the difference, since it determines the implicit self, which is a meaningful part of how Ruby works. Because that difference is meaningful it is reflected in the syntax. `lambda`, or the shorthand `->` creates a function not attached to an object, and `def` creates a function and attaches it to the calling context (making it a method).

Perhaps you don't like this, that's fine. But to say "nope I want my methods and functions to be interchangeable and not to be called lambdas" is purely a subjective argument.

Objectively, Ruby has first-class functions that can be assigned to variables and passes around and returned from other function calls etc etc. They're just called lambdas.

This is clearly a misunderstanding of what a first-class function is. If it doesn't meet your criteria in the colloquial sense of "first-class", that's one thing. But in computer science and programming in general, "first-class function" has a very specific meaning [1], and Ruby absolutely meets the criteria.

The other bit of confusion is that the actual syntax in Ruby optimizes for the common case, which is calling methods. Yehuda Katz wrote a good article explaining this [2]. Among other things, it allows you to create very concise DSLs in Ruby that would never be quite as clean in Python.

1: https://en.wikipedia.org/wiki/First-class_function

2: https://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-ori...

So the functionality is equivalent, but ruby's syntax is slightly longer. Is there something other than ruby's slightly longer syntax that you find lacking?

Ruby's Method class matches the design "everything is an object" (strings, numbers, modules & classes themselves...). Are regular expressions first class in ruby? There is top-level syntactic sugar for REs (/.../) but REs are just instances of `Regexp`. It's just syntax. I don't think you can argue Python REs are first class: I have to drag in `re` and then `re.compile()` a string (and my editor won't know to syntax highlight metachars or interpolation). I use REs more often than method references in either language...

But I'm not trying to "whataboutwhataboutwhatabout" here. I'm trying to say there's a difference of philosophy. Ruby Methods are just more objects (Method<Object). They aren't some sort of blessed type, just like everything else. Everything descends from Object. Kernel is just a module. Method is just a class. And so on. In that context, what does it mean to be "first class"? Objects are first class and methods are objects. QED. No?

(FWIW I agree on ruby's optional parens, too much inconsistency for a few less lit pixels on the screen).

> In that context, what does it mean to be "first class"

It's easy. First, what does it mean to be "first class"?

> a first-class citizen (also type, object, entity, or value) in a given programming language is an entity which supports all the operations generally available to other entities. These operations typically include being passed as an argument, returned from a function, modified, and assigned to a variable

Secondly, how does that apply to functions?

> [First class functions] means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures

In what way doesn't Ruby have first class functions? This article explains it better: https://codequizzes.wordpress.com/2014/05/19/ruby-methods-ar...

In practice, because of Proc, you can use Proc wherever you'd use functions and get the same effect in practice, so this is not a big issue. But just because Ruby has Procs, doesn't mean it has first class functions, which is a specific concept.

Thanks, I had also looked for a definition. Instances of Method fulfill both of the cited criteria -- example in this thread, above. Also: Method != Proc, but the article's comments help.

I, aha, notice this:

    $ irb
    2.3.3 :001 > Kernel.method(:puts).object_id
     => 47165335040720 
    2.3.3 :002 > Kernel.method(:puts).object_id
     => 47165334993360 # not the same!
    2.3.3 :003 > 

That is: #method doesn't return the Kernel.puts method, it returns a new Kernel.puts Method instance on each invocation. So the returned object from Kernel#method isn't the "real" (first-class) method object.

I feel like I'm a lot closer but I'd still like a better definition :)

Isn't the main issue that Ruby simply doesn't have functions? Ruby is pure OOP, and there is no way to define a method without the implicit 'self' argument. Maybe the reasoning was that methods themselves aren't really meant to be passed around. Because in today's idiomatic Ruby, they mostly aren't -- the late binding behavior of 'send' feels much more Rubyish.

Exactly. And Ruby methods are not even "functions with self" they are message-handlers. Like in Smalltalk or Objective-C.

Different heritage

Sorry, Ruby methods are not objects. They can surely be wrapped in objects of class Method, but this feature is used quite rarely. Whether this is due to the syntax, the confusion regarding the evaluation scope, or something else, I have no idea.

The only way of obtaining a method in Ruby returns it as an object. Whether or not they "are" an object is thus entirely an implementation detail.

I think part of the confuction here is that "ob.puts" for example, does not directly access a method. It denotes passing a message to "ob". That message may or may not be routed to a "puts" method.

But at no point does Ruby allow you to get hold of any kind of reference to a method that is anything but an object.

Yeah, you got it, see my reply to capableweb. Thanks!

> and my editor won't know to syntax highlight metachars or interpolation

IntelliJ editors do this and it’s insanely useful. Works with SQL, regex and any other language.

This is incorrect. If you want an anonymous function (with no object context) you can write a lambda, store it to a value, make other lambdas that call it and return yet another lambda etc.

You can do the exact same thing with object methods if you want, eg. my_puts = Kernel.method(:puts).

You can even do this in one line and stop the auto parenthesis behavior if you want.

foo = method def foo ... end

Now foo will reference the method and you have to use foo() to call it.

The reason that people don’t do a bunch of that in Ruby is that the support for anonymous blocks is so convenient That there aren’t that many cases where you really need anonymous functions detached from any object.

Ah, so it's the same then

Not really the same since lambda in Python is just a syntactic variant that is restricted. A function defined using `def` can be passed around without restrictions, which you simply cannot do in Ruby.

What are the restrictions on passing around a ruby `Method` object?

(Please see my sibling comment for example).

There is no practical difference in Python functions and Ruby lambdas.

> it has mutable strings a-la Perl

Yes, but they're not popular these days. Ruby 3 almost defaulted to frozen-strings by default (I wish it had) and a lot of the ecosystem moved to that style resulting in some nice memory saving. Rails enforces it on its code for example: https://github.com/rails/rails/blob/0f09dfca363410f51f6f6078...

You are talking about string _literals_, there is no motion nor interest I'm aware of in making all strings immutable in Ruby, thankfully.

new crew dialamac gotta be dissin / says Ruby first class functions are missin / tries it on in da y combinator / but

    y = -> f {
        -> g { g[g] } [
        -> g { f[-> v { g[g][v] }] }
      ]
    }

/ see ya later.

I’m amused that a number in this thread saw these observations as a “diss”... that’s more on you then me. I didn’t pass any value judgement on these differences, merely that they exist and demonstrate some fundamental differences in the history of these languages. While Ruby lambdas are essentially first class anonymous functions they were added late in the language and they are distinct from methods that predate them. You can’t just drop them in seamlessly where a method is used. The point stands that while both Ruby and python have accreted more stuff as time wears on, their initial design principles were starkly dissimilar.

Yo bro dialamac / Caught in a falsehood / Tryin' to dial it back / Feels misunderstood / Sez lambda came late / But changelog don't lie / Since v0.8 / Ruby so fly.

Or, in prose form: I don't see anyone disagreeing that Ruby & Python are dissimilar both in principle and in practice, but "Ruby doesn't even have first-class functions" was most unreservedly an epic howler, and once played, folks were inevitably gonna have some fun passing that football around, and despite most of the changelog from 1995 being in Japanese there are nevertheless references to lambdas that early on, although the more concise "stabby" syntax didn't rear up until ca.2008.

[See screenshot]

> "Functions in Ruby are methods"

RECORD SCRATCH. THE ROOM FALLS SILENT.

NARRATOR: A common assumption, but no. Equating object methods to functions is a furphy. The argument along the lines of:

"Ruby's object methods are Ruby's functions, but you can't pass them around, ergo they're not functions"

is using the term "function" in two different ways, but assuming they're the same; this is not an argument based on substance, but upon mislabelling. The conclusion is bogus because the premise is bogus.

It may arise from a category error, assuming that the thing depends intrinsically upon the literal representation of the thing, or (worse) the common name of the thing, but this is a) wrong anyway, and b) loses coherence entirely in a language in which function literals can be conjured and lexically rebound at runtime.

In actuality, Ruby's lambdas are functions, and first-class, by the only definition with substance: they are closures capable of higher-order expression, taking functions as parameters when invoked, and returning functions as results.

Which is why saying "it don't have them" on a forum named after a fixed-point combinator is to invite: a) ridicule, and b) lambda calculus expressions in rap battle form.

CROWD: Yeah!

MUSIC STARTS / GLITTERBALL CLOSEUP

I’m glad you think highly of your poetic abilities, but I have no desire to engage in that pointless argument.

Edit: and yes.. uh comment deleted as charged, since you had edited after I replied.

> I have no desire to engage

And yet,

> go full on neckbeard

Here you are,

> you seem to have balled up tightly in your own self worth

In full-on pompous balloon ad hominem mode,

> https://ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/fun...

With a reference page that is 22 years out of date,

> you can finish this argument with whatever hand you prefer

And a bitter, resentful, dick joke.

Well, I don't have a beard, and I ain't the dick here.

> How does one call a lambda after all

Why not fire up the interpreter and go

    f[x]

yourself.

Which is the title of this song.

POSTSCRIPT:

Oh look, a comment deleter / throws around shit / but too late for this meter / Yo' can check it all out / at https://inopinatus.org/i/all_the_sweeter.png

You win.

Old 78 records were produced with equipment from recording to cutting and pressing that is long since obsolete. Even if you overcome the challenges of dealing with laser equipment (dust, tracking).. what extra information are you really getting?. that it is useful signal more than even a dB or two above the noise I think is very wishful thinking.

> This is the trouble with audio in general: people not only prefer different sound profiles but also perceive sound differently, which makes it difficult to get rips (at least in my limited experience).

The problem with worrying about this is that even the same person perceives sound differently situationally and is simply not repeatable. In most cases when someone hears a difference it is often just a change in their perception from one moment to the next.. and that’s even when something measurable has changed! The bass sounds better because of that new amp.. well no.. you just happened to focus on it more the second time around. Longer term people’s physiology changes as well.

Only repeat, blinded A-B testing can clearly elicit an objective difference that is most likely not due to these perceptual inconsistencies.

What does this mean.. record it with decent equipment that captures as much useful raw information as possible (and yes 96khz is ridiculous as we’re not bats). People can EQ and mix to their preferences any given day.

It’s not clear there was something wrong with the cartridge. These are old 78 records.. they weren’t mastered with much to begin with and the useful fidelity in them is limited. If you want you can post-process them with whatever fancy shit, but I wouldn’t immediately assume the recordings weren’t the best given what they were working with for source material.

This is about C, not C++. Though I haven’t been there in years, I chuckle to think what would have happened if you made this mistake on that news group.

Pretty sure OP is referring to this part of the comment they were replying to:

> Users posting to comp.lang.c through Google Groups were a problem -- especially with the recent bug that caused GG posts to comp.lang.c++ to have the "++" quietly dropped.

> ⋯ seems to be more of a project driven by Linux hate ⋯

Not really. I never hear Linux mentioned in everyday chat.

I mean git is wildly popular because of GitHub, and probably that was something to do with it in the Rails community... a community that if anything is culturally the opposite of the kernel dev community (or at least very different). I don’t think any kernel dev influence had to do with it, even though it’s often stated as a fact.

No, even at the time of GitHub's founding Git was already the clear winner. Think about it, why did GitHub feel safe launching with only Git support, while its competitors (Google Code, Bitbucket, SourceForge) had support for multiple VCSs?

Disagree. Git wasn't the clear winner when GitHub launched - and in fact the entire category of distributed version control was still proving itself.

I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.

git was the clear winner when github released.

Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.

lots of people were using lots of things at that time, most were using git.

You have no evidence to back this claim up, because it’s not true.

Its competitors didn't have support for multiple VCSes. Sourceforge was CVS only, Google Code did SVN (and maybe CVS?), Bitbucket was hg only _and_ later. Many of these were later forced to add git support (and google code added hg iirc), but tying your source code host to a single version system was the norm when github launched.

Um.. no it wasn’t. Git was a complete trash fire on Windows when GitHub was founded for one.

I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.

Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.

GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.

It did. Torvalds had (has?) a lot of pull in dev circles, he's a sort of archetypal Dev Evangelist. Though I agree Github was the main reason. They polished the git experience and then promoted their platform a ton, which brought git with it.

Love that it was a “hacker” rather than a bored teenager or some casual idiot, or even a disgruntled former or current employee. Invoking the hacker term I guess is supposed to make it absolve gross negligence in even the most basic security practices. It makes me sad to think this spin actually works.

This is basically "some kid turned a control valve to fully open".

The question to ask is "why was the valve next to a public road with no fence and no lock?

What does the age or casualness of the hacker have to do with anything?

It has to do with how responsibility is percieved here. Different rhetoric will have different results for the same facts.

If the system is open to a l33t scr1pt k1dd13 who’s hacking knowledge consists of copy-pasting from 2600 articles, it speaks to a system that would stand no chance against a well-resourced adversary. This kind of thing may well be a new kind of front the next time we get into a shooting war “over there.”

It's an indicator for the level of incompetence of the hacked party.

I guess the issue is with the word ‘hacker’. I guess using a more descriptive and accurate word like attacker, vandal, or terrorist is more apt here.

Attacker and terrorist convey the same thing as hacker, that it was not negligence but a very motivated enemy. Vandal works better.

Hacker is someone that finds a way to use a thing out side of the designed purpose. There is no value judgement in the word alone, and the word does not say whether the hacker is hacking with an intent to do harm. This is normally not how news media frames criminals, as they tend to use words which assign guild to the guilty, (like criminal, thieve, burglar, sexual predator, etc.). Attacker, vandal, and terrorist all do that, while hacker doesn’t.

If it calls attention to vulnerable infrastructure in the US, good. We need to put a lot more tax dollars into securing these systems.

It will only call attention if the relevant municipalities are fined for negligence and/or the responsible managers punished.

Only if those dollars are used effectively.

If you’re just checking a checkbox and not actually securing the system, you’re no better off.

Right, but the concern is that if we focus too much on the "hacker" and not enough on the vulnerable infrastructure, we may spend all our tax dollars chasing computer criminals instead of preventing computer crime. As a general rule, I don't like blaming the victims of a crime for falling victim... but the real victims here are the people downstream of the water supply, and we shouldn't absolve industry or infrastructure operators of negligence because some scary hacker attacked them.

Or it could be a state actor from another country who executed a well planned attack.

I would think a state actor would be stealthier. But I suppose it could be a test of defenses against such an attack.

This was my gut instinct too. Some high school kid or just a random hacker who stumbled across it is just as likely as anything else.

The threat model is different. Any such system should not be vulnerable to someone that is not even trying very hard and is not an insider attacker.

You forgot Russians/N.Koreans or Iranians...it's a flavor question.

Have they really though? iOS has always shared the same underpinnings as OSX. Although much hyped with Big Sur, iOS features have dribbled into OSX since at least Lion (more than 10 years ago). They’re still distinct operating systems (thankfully IMO) and rather than unify, iPadOS is a distinct entity.