Exactly. We heard for years they wouldn't do generics it until they could do it right, and that was perfectly fine with me. Who wouldn't want a well thought out implementation? Then they released generics and it was like, "this is what you thought was the right way to do it?!"
Generics being omitted wasn't pitched as a feature that I ever saw. The discussion was mostly around "hic sunt dracones" with generics. The Go authors were very aware from the get-go that generics are an incredibly difficult thing to implement well, and the commitment was always to not do it until they were really ready to tackle it. The bizarre thing to me is that when they did tackle it, they left this massive implementation gap, and then what little they did implement didn't seem useful enough that anything meaningful was added to the standard library. So all this talk about generics for years was a big nothing-burger. That is, I hope, until 1.27 when this gets released. Flags is one in particular I think is in desperate need of proper generic methods.
As far as I can tell with oils, they haven't fully defined what YSH is going to be yet - you basically have OSH (the bash compatibility syntax), with the option to add YSH features as a bolt on. It'd be like Zsh shipping with a built-in Fish-mode to create hybrid scripting. The interesting thing with shells like Xonsh and now rubish is that theoretically the shell language isn't some new thing you have to learn like with elvish and nushell, but is a known programming language with shell features. Rubish looks like it takes the most interesting parts of Oils and Xonsh, in that it's bash compatible, but you could also do a Ruby statement like `ls.each { |f| printf "%s: %d bytes\n", f, File.size(f) }`.
Scott Forstall here. I’ll resign before I apologize for the choices we make at Apple. All our research shows you’re gonna love it, and if you say you don’t it’s because you’re wrong, not me.
> Moving the request to the Start Centre is not an escalation, but a change in location and frequency.
I support LibreOffice and what they're trying to do here, but this statement that it's not an "escalation" out of one side of their mouth and then admitting it's a "change in location and frequency" out of the other tells me that they are being disingenuous about it. An unobtrusive notice on where to donate seems like a reasonable direction, but if they don't view this obvious escalation as such, then what else will they do that they don't view as an escalation?
Wow... that's... incredible. I've used Hammerspoon forever and never knew that existed.
Just messing around I found you can extend the grid size with `hs.grid.setGrid('4x4')`, which you also may then want to shrink the text size with `hs.grid.ui.textSize = 30`, and finally if you use an alternative keyboard layout (eg: Colemak), you can set the grid to use it with `hs.grid.HINTS`. They really thought of everything with this feature.
Tahoe will be gone in 7 months when macOS 27 comes out. Meanwhile we've been talking about ads in the Windows 11 start bar since 2021 and Gnome 3's Gnaval gazing since who knows when?
Apple tries something weird every now and then and then a year later we get something different. Yes, Tahoe was a giant miss, but I'd wager macOS is not what really attracts devs to Apple anyway - it's the hardware that makes Macs such an appealing dev machine. Large glass trackpads with incredible touch controls, aluminum bodies, long lasting batteries, cool and quiet, great screens, years of support - the list goes on.
Snapdragon is only just now finally taking off in the Windows/Linux space, so the landscape could finally change here soon, but for now anyone who's gone ARM is not looking to ever go back to x64 hardware - at least for development (gaming is another convo).
> it's the hardware that makes Macs such an appealing dev machine. Large glass trackpads with incredible touch controls, aluminum bodies, long lasting batteries, cool and quiet
Probably so, but I've seen more than a few Macbook Pro keyboards dome up due to heat so bad that you couldn't close the lid.
I am at that age were I do not want anything new. Windows is still basically what it was when I was young- with the caveat that you have to spend a few hours tweaking it. Which is not a huge deal for something you do once every 5 years.
Same as anything else installed as a binary package - you trust the people packaging/providing the binary. If you don't, build it yourself. The source is publicly available.
`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.
Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's).
In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.
> Python 2 features were reintroduced in basically every P3 version until at least 3.5
If they had just done this from the beginning there wouldn't even have been such upgrade drama in the first place... like, as an obvious example, removing u'' syntax for unicode strings immediately at 3.0 was just idiotic: if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all (a la Ruby 2's Unicode reboot, which concerned a lot of people but was a nothing-burger next to the insanity of Python 3).
Sure but importantly they did realise they had erred and course-corrected.
> if it weren't for some dumb decisions like that one there would have been almost no upgrade discontinuity at all
Having been there and done that, nah, the text model changes alone required significant work to square up in most packages. And there were plenty of other semantics changes.
But you could have made those changes incrementally in a way that more cleanly worked across both Python 2 (which already had this split: the default type was just wrong; all of my code, for instance, worked great!... it was just super awkward, as it had tons of u's thrown all over the place). Where they ended up with the language (after, like, 3.7) was much more incremental from Python 2 than the early path to how they got there. To be explicit: it isn't about having to put in upgrade effort, it is about upgrade discontinuity.
I’m not talking as a user, I’m talking as a person who ported 350kLOCs of python from 2 to 3.
Django absolutely would have been ported: it was ported without six by Vinay Sajip (building on an earlier work of Martin von Löwis). In fact a limited shim layer was initially committed based on Vinay’s efforts: https://github.com/django/django/commit/5e6ded2e58597fa324c5...
The team ultimately decided to use and re-export six for the convenience of the ecosystem, not out of any sort of necessity.
So if Google is to learn from others’ past mistakes, it ought to be able to leverage Gemini as long as the user can easily and fully swap out Gemini for an alternative. That was the problem regulators had with IE and the App Store.
reply