HN user

allertonm

411 karma
Posts3
Comments157
View on HN

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.

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.

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".)

Be careful what you wish for.

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.

Startup Stagnation 14 years ago

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.

I actually had a NewBrain, think it's still around in my parents' attic somewhere.

I did quite a bit of real paying work on BBC Micros back in the day, and think they were great - but reading the way people tell the story today, one would be given the impression that the NewBrain was some kind of grim socialist piece of junk. It was actually a pretty decent bit of kit, quite a bit better quality than many of the other micros on the UK market at the time.

In an ironic turn, the company I worked for doing the BBC stuff later moved into Grundy's old premises in Teddington after they went bust.

These are my choice for coding too, very good balance of sound isolation and quality. Very solidly made too. Hard to find in Hi-fi stores but music equipment places carry them (popular for monitoring & ENG work.)

Not sure that they beat high-end phones though. I have some HD650s at home, and trust me, they are nicer to listen to (but being open, would annoy the hell out of my co-workers.)

Title is incorrect, should be: "A story about me".

This seems kind of grouchy I know, but I am getting a bit tired of these wildly overblown titles attached to very thin blog posts. I knew what I'd see when I clicked the link and was just as disappointed as I'd expected to be. I guess I have a masochistic streak.

The actual stories of those three editors, their authors and how those stories intertwine would probably be pretty interesting. I guess I'll have to wait for This American Life to tackle it.

It's not true of Java - the bytecode generated by javac is very robust in the face of new JVM versions. This is one of the reasons that Java has had to move so slowly in terms of language features.

Neither Scala or Clojure's compilers generate byte code that is expected to work with that from another version of the respective compiler or with a different version of the language runtime.

In the case of Clojure this is mitigated by the fact that (since it is a dynamic language) that applications and libraries are generally delivered in source form and "ahead of time" compilation is seen as an optimization rather than a code delivery mechanism.

SAP Streamwork and parts of the BI On Demand offerings are written in jruby / rails.

(I used to work at SAP on Streamwork, which was done at the former Business Objects development centre in Vancouver.)