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 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.
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.
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.
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.
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.
If you go and look for such a thing as a server-side 2D rendering API that will work on a headless linux server and support a nice visualization API comparable to D3 and not pay someone several thousand dollars for a license, you will find that a headless browser that supports SVG is not such a terrible answer.
This is similar to how we do our email delivery of dashboards at Indicee (http://www.indicee.com)
We don't use D3 for our visualizations (I'd love to, but our users can use the dashboards "live" and, well... Internet Explorer 8) and we snapshot the entire dashboard - which isn't quite as clever as what is done here, but does have the advantage that the resulting mail is self-contained and does not require the dynamically generated images to be hosted somewhere.
Like these guys, I have nothing but good things to say about PhantomJS. We'd previously used another "headless webkit" - wkhtmltoimage - in a similar role but Phantom's design as a general purpose scripting engine for headless browsing tasks is much, much more useful.
There might be something to this. Despite Jobs' statements about the usefulness (or otherwise) of upright touch screens, accessory manufacturers have been catering to people who want to use their iPad upright literally since day one. Apple itself is doing this with the Smart Cover. So if that's OK, does adding a physical keyboard laid flat to the equation somehow turn it wrong? Seems like a stretch.
In this vein, it's also worth looking at Microsoft's "Reactive Extensions" (which have a JS implementation, too.) It's a similarly monadic approach to asynchrony, but deals in "observables" which produce zero or more events, compared to promises which produce only one.
(Edit: corrected "one or more" to "zero or more".)
I've been using GWT solidly for the past two years (not my choice for the project, but sometimes you just have to play the hand you are dealt) - and IMO GWT's biggest problem isn't so much that it is Java, but rather that it is Java without any dynamic features (i.e reflection, late binding etc.)
I could rant at length about the dark alleys that GWT's overemphasis on static analysis can take you, just a massive hairball of impenetrable compile-time code generation in order to provide features that would be trivial if you could just reflect on things. Ironic, given the fact that your code is actually running in Javascript.
So while I don't believe static typing is inherently a bad thing, you can definitely have too much.
The numbers you quote sound like large sums of money but MSF's total budget is $400M and 80% of it comes from private individuals. (source: Wikipedia.) So it seems like a stretch to say MSF "exists in part" due to the largesse of software companies.
While the example of Justin Bieber makes it seem to make sense to push the cost of following to the followed rather than the follower, I am not at all sure this makes sense in the general case. It puts the user at the mercy of spammers & bots and ISTM making the follower bear the cost of following would disincentivize this kind of bad behaviour.
Never tried Windsurf in it’s recent form but we did evaluate it when it was still called Codeium and everyone liked Copilot better.