The copilot agent stuff in IntelliJ works relatively well in my experience, they managed to implement a quite cursor-like “accept/reject” UI in a plugin, you know, forking IDEA. There are some areas like getting it to use git tools where cursor works more smoothly but you can coax Copilot into producing the same results. I’m just generally happier working in IntelliJ vs VSCode so I’ve tended to favour Copilot.
Never tried Windsurf in it’s recent form but we did evaluate it when it was still called Codeium and everyone liked Copilot better.
The Cree bulbs - at least the ones in Home Depot in Canada - actually do have a warning about using in enclosed fixtures. It says (to my recollection) "Do not use in enclosed fixtures with other types of bulbs". So my take on this is that they are supposed to be OK providing you don't mix the Cree LEDs with CFLs or incandescents in the same fixture.
I am trying them out in some enclosed fixtures, too early to tell how that will work out.
I've uploaded a photo of both sides of the Cree product packaging here in the US. It's the same for 40W and 60W bulbs. There's no notice about not using it in any type of fixture. The only thing it says not to do is expose the bulb directly to weather.
It's interesting to compare this to CAL - an earlier Haskell-like language on the JVM that was a project of some of my former colleagues at Crystal Decisions/Business Objects back in the 00's: http://openquark.org/Welcome.html
I've worked quite a bit with CAL over the years and it has been used for some serious work. One of my big frustrations with it though has been the clunkiness of the Java interop, especially since this is one of the reasons you might choose to use a language on the JVM.
Looking at the Frege docs, I like the look of the way this has been handled - rather than using an FFI-style approach, things like Int, String etc map directly to Java types and Java classes can be used like ADTs, which would make life way, way easier.
Given the nature of the language calling Frege from Java is always going to be more complicated but it looks like they've done a nice "fluent" Java API for calling into the runtime.
Would be interesting to see how this performs relative to CAL, in terms of both speed and space.
Unfortunately it looks like you would have to build from source. The best place for that would be Rich Webster's fork - https://github.com/rdwebster/Open-Quark - which is the version maintained by Indicee.
I imagine the documentation is completely out of date.
Anyway, if you don't want to look at it, that's your loss - while I don't think CAL has much of a future a lot of work was invested in it by a very talented team and there is probably something to be learned from it.
Yeah, me too... TI-51 III (aka TI-55 in US) in the late 70s - belonging to my father, who had it for his job but never got to use it much because I was always playing with it. He later got me a copy of this book - http://books.google.ca/books?id=ySZhMJrzhw4C&pg=PT48&... - and that's really where my computing career began.
Rang so true for me too. Growing up in London, the valley seemed like the centre of the universe and somewhere I'd eventually want to move to, but when I first visited in 1993 for Apple's WWDC and went exploring I was massively disappointed. ISTR I described it to friends back home as "Like Slough but with better weather". On the other hand I totally adored San Francisco.
I've spent a fair bit of time in both places since then and it's not changed my view much.
See also Apple "Advanced Technology Group", pre-1997. One of Jobs' first acts on his return was to kill it. I remember all those cool demos we used to get at WWDC of things that never ever saw the light of day while the core OS was turning to crap.
To be fair to Jobs, he came into Apple and had a really short amount of time to turn it around. I believe they had something like 2 months of available cash. And their stock was in the single digits. He shut a lot of things down; if you weren't making money (ATG, Newton, and the consumer products) you were gone. He also cut off charity and left it to Cook to re-implement it.
This is why I believe Apple are holding onto so much cash. Far easier to ask banks for million dollar loans when you have billions in savings rather than begging private equity who'll strip you to pieces.
I guess the benefit of lazy by default is that (given Haskell is an experiment in purity) it sets the expectation that things will be side-effect free by default.
Were that not a design criteria it might have been better to make things strict by default and have a "lazy" monad rather than do lazy by default and use monads for all the side effecting stuff.
Total functions embed into partial ones, which is why we have a partiality monad. The opposite arrow doesn't exist, which is why we don't have a totality monad.
Now lazy and eager are properly adjectives that govern beta reduction, that is, the interaction between a function and its argument.
The short of it is that neither an eager nor a lazy monad makes any sense.
(Heh, I'm totally citing this in the monads class I teach as proof of why unpacking monads starting from functors is a win.)
Never tried Windsurf in it’s recent form but we did evaluate it when it was still called Codeium and everyone liked Copilot better.