IRB type completion comes as a result of a chain of events which starts from the incredible work done by Kevin Newton (et al) to write a new canonical Ruby parser called Prism in C99 with no dependencies [1].
With Prism, you can then create tool suites like syntax_tree [2], which then leads Prettier formatters [3], a new Ruby LSP [4], which unlocks a new Ruby LSP VS Code extension [5], not to mention a laundry list of other gems like Rubocop and of course Ruby itself that will benefit from a faster and more maintainable Ruby parser.
It's a beautiful illustration of the power of questioning conventions, going back to first principles to uncover better solutions to previously solved problems, whose new solutions create new capabilities which unlocks the ability to solve new problems.
syntax_tree was actually created before Prism. Ruby LSP also adopted syntax_tree first, and then switched to Prism (then called YARP) when it was mature enough.
But indeed, the type completor would've been much harder to build and maintain if without Prism.
If u have a ton money, it's cheaper to just live in US. Canada is very expensive for the plebs. The cost of living keeps rising and the politicians are very anti small businesses and pro oligarchy. They have a strangle hold on the country simliar to the Murdoch in Australia. Ironically, US is fairer in helping the small timers.
It was the saving grace, but I am not sure if that's the case now as the situation deteriorates. If I am already having the big tech insurance and I am gonna to fly to Mexico/India for some of the items anyway, why do I need it?
The politicians simply DO NOT care. They just let oligarchs keep eating the small palayers, and it will totally break the health system some day just like how they killed 3rd party internet providers. Telus is already making the play in the health sector.
As an H-1B holder, we are legally entitled (and required) to work for one specific employer and that's it. You cannot even think of starting a company, you cannot work a gig job, you can't work two "high-paying" tech jobs.
Everyone knows the "ton of money" doesn't come from working a salaried job, it's from creating something new / starting a company.
But only US green card holders or US citizens can even dream of considering that as an option they can pursue.
Ton of money is ill-defined, but it's quite possible to work a salaried job in tech in the US and achieve financial independence and an extremely high standard of living.
There was an internal joke / meme at Google that any announcement starting with "An update on X" == we are killing X, to the point that if someone was sending their resignation email the subject line of the email would be "An update on <name>"
My current favorite corp speak is “we can’t wait to share it with you”. Seems like it’s in literally every product announcement. At least this one is positive
Did it know that before the last LLM failure was posted on Twitter or Hackernews? Trawling tech media for LLM failures can be assumed to be part of the "human feedback".
Yes, the models are not constantly learning. They only update their knowledge when they are retrained, which is pretty infrequently (I think the base GPT models have not been retrained, but the chat laters on top might).
It's interesting to read the replies in this thread because a lot of people are proposing alternative "it's just this" solutions to the same problem being solved here -- the over abundance of plastics.
But the solution can be all of these proposed "it's just this" strategies combined.
We do need a:
- standardization of plastics,
- a switch to alternative materials that are more compostable,
- a research lab to more deeply understand the true nature of plastics and their reuse,
- a tax on environmentally costly materials such as plastics,
- depolymerizing,
- and more...
These are all solutions to the same problem. Let's work on all of these problems simultaneously and combine them for compound effects.
In a world with finite resources, and capacity to care prioritization goes a long way. This is why a huddle of engineers is just chaos sans a Product manager.
> However there is one caveat. If some of the data members are of a mutable class, Data does no additional immutability enforcement.
Seems like an area of concern / gotchas. Either restrict Data to not allow mutable nested objects, or provide immutable versions of stdlib object types as well and enforce that those types are used.
Yet another Rubocop-that-should-just-be-built-into-the-language coming in 3...2...1...
This is pretty common when adding immutability to a language that wasn't designed around it. Whether it's JavaScript's `const` or Java's `final`, languages almost always add shallow immutability rather than deep. My sense is that it's quite difficult to add deep immutability in later.
Rust is the main exception I'm aware of, and it had deep immutability from the get-go.
Scala has immutable types in the standard library too, but I don't think they make much sense without the language being statically typed. By which I mean adding immutable types to Python or whatever's stdlib would not be that hard, but it would most likely be confusing since you don't know for sure what you have until you look at it and see.
Rust's deep immutability is different than most in that it allows setting a reference as recursively immutable even if the data type it's pointing to has mutable fields.
Scala gives you immutable data types but unless I'm mistaken there's no way to say "recursively disable mutating functions for all elements in this list"—you just have a list that cannot be mutated. If you stick a Java object in a Scala list, it's liable to mutate, so Scala has shallow immutability.
Yeah that's true, it is different. Neat :). With Scala you would put immutable types in your list if you wanted to, but I get what you mean, it's not the same.
Scala's immutable types are also "shallow". For example you can put mutable objects inside an immutable container and change them when you want. Rust avoids this using lifetimes.
It would be interesting if mutability was actually part of Scala's type system, for example if immutable Seq was defined as
Accidentally mutating globals was a big problem with the language. Const didn't solve it completely: you can still implicitly create globals by forgetting to declare the binding locally. But at least if you have a global you can make it an immutable binding and get warned about mutating it some of the time (ie assignments). As far as I'm concerned that is all it is useful for. For a local binding you don't really get much benefit since it's not deeply immutable, and it isn't an improvement to the ambiguity of local/global scopes, so you're frankly better off not using it as it will trick newcomers.
The same argument doesn't apply to Data's shallow immutability. It will give you errors when mutating at least some of the fields. If your code can catch you mutating a number, then you can notice the bug and be reminded to make deep copies etc. It's an improvement, just like Object.freeze.
This is exactly the same problem that OP was drawing out with Ruby's Data: the references inside the Data object are immutable and cannot be changed to point to other objects, but once you've dereferenced the (immutable) pointers there are no immutability guarantees. Hence, shallow immutability.
The only conceptual difference between this and JS's `const` is that you can't use `const` to declare object properties immutable; for that you need Object.freeze().
Perhaps even more egregiously: given Ruby's dynamic runtime, we may take an apparently immutable instance of a data class and variously prepend, extend, refine or define methods upon that object's class or eigenclass such that, one way or another, different values are returned, for subsequent uses of that object, with your choice of lexical or global scope, including effecting mutability to the extent of providing viable setter methods.
Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language. As with Struct before it, a data class is merely a shorthand.
> Actually doing so breaks the covenant of Data, but an enforced prohibition breaks the language.
Fortunately in my almost 20 years of ruby, dark magic does not survive a reasonable amount of sunlight. Most of the time someone (including me) has written impolite ruby, they know what they are doing and why (laziness 90% of the time) and respond appropriately to a gentle prod to be more polite.
Ruby gives you footguns and you can certainly do ill-advised things... but in practice I just don't see it happening very often either in open source projects or in private corporate stuff.
Why?
Because IME there's rarely even a need to go down those paths at all, unless you are writing a framework or doing something else "meta."
99.99% of Ruby I have actually seen is either simple scripts or bog standard OO stuff.
We do find such horrors lurking in the bowels of Rails, unsurprisingly. ActiveSupport clamps on to several fundamental modules, but Rails only inflicts the worst of its metaprogramming gymnastics either upon itself, or client objects/classes that expect a ton of magic (viz. models, controllers, views). When peeking at some of the machinery I'm sometimes unsure whether to be appalled or astounded.
Agreed. And if you have a rigid tests-are-necessary-to-merge regime you end up finding that the simplest way to write quality tests are simple approaches to implementations.
Java made the same compromise with records, and likely for similar reasons. Limiting fields of such structures to only contain immutable objects ends up limiting their adoption too much even though it may be the way you would like people to use them in the long term.
HN discussion: https://news.ycombinator.com/item?id=43518462