HackerTrans
TopNewTrendsCommentsPastAskShowJobs

eftpotrm

no profile record

comments

eftpotrm
·8 เดือนที่ผ่านมา·discuss
Aside from the other commenter's point about this being a misleading comparison, you didn't need to reinvent the whole XML ecosystem from scratch, it was already there and functional. One of the big claims I've seen for JSON though is that it has array support, which XML doesn't. And which is correct as far as it goes, but also it would have been far from impossible to code up a serializer/deserializer that let you treat a collection of identically typed XML nodes as an array. Heck, for all I know it exists, it's not conceptually difficult.
eftpotrm
·8 เดือนที่ผ่านมา·discuss
What makes XSLT inherently unsuitable for an interactive application in your mind? All it does is transform one XML document into another; there's no earthly reason why you can't ornament that XML output in a way that supports interactive JS-driven features, or use XSLT to built fragments of dynamically created pages that get compiled into the final rendered artifact elsewhere.
eftpotrm
·8 เดือนที่ผ่านมา·discuss
I'm aware I'm in a minority, but I find it sad that XSLT stalled and is mostly dead in the market. The amount of effort put into replicating most the XML+XPath+XSLT ecosystem we had as open standards 25 years ago using ever-changing libraries with their own host of incompatible limitations, rather than improving what we already had, has been a colossal waste of talent.

Was SOAP a bad system that misunderstood HTTP while being vastly overarchitected for most of its use cases? Yes. Could overuse of XML schemas render your documents unreadable and overcomplex to work with? Of course. Were early XML libraries well designed around the reality of existing programming languages? No. But also was JSON's early implementation of 'you can just eval() it into memory' ever good engineering? No, and by the time you've written a JSON parser that beats that you could've equally produced an equally improved XML system while retaining the much greater functionality it already had.

RIP a good tech killed by committees overembellishing it and engineers failing to recognise what they already had over the high of building something else.
eftpotrm
·11 เดือนที่ผ่านมา·discuss
Passed with the support of the current governing party, it should be noted.
eftpotrm
·12 เดือนที่ผ่านมา·discuss
BMW tried that with the i3, it wasn't particularly popular. An engine, fuel system and a generator are all relatively complex additions compared to just putting the same cost and vehicle space into more batteries, and the public charging networks are definitely up to the task by now (having been EV-only for almost 5 years now).
eftpotrm
·ปีที่แล้ว·discuss
I can't help thinking more startups need greybeards around. (Of which, realistically, I'm now one.)

Largest table 100 million rows and they were paying 6 figures for database services annually? I have one now that sits happily enough on an 8yo laptop. I've worked on systems that had similar scale tables chugging along on very average for 20 years ago MSSQL 2000 boxes. There just isn't a need for cloud scale systems and cloud scale bills for that data volume.

The problems they're describing should never have got that far without an experienced hand pointing out they didn't make sense, and if they'd hired that greybeard they'd have spotted it long before.
eftpotrm
·ปีที่แล้ว·discuss
And yet it happens. A doctor in my family told the story of a patient they were treating in hospital who medically needed to lose weight, and who they found unable to get any reduction until they dropped below _200_ calories a day.

Metabolism is _significantly_ more complex than CI/CO, from experience.
eftpotrm
·ปีที่แล้ว·discuss
That's it! Thanks :-)
eftpotrm
·ปีที่แล้ว·discuss
HP did the same when migrating away from the PA RISC architecture.

IIRC as part of their testing they set it up so it would ingest, recompile and output code for the same architecture, and found that it could produce speed improvements due to context awareness.
eftpotrm
·ปีที่แล้ว·discuss
Nikon aren't doing much better on letting third-party lenses into the ecosystem, sadly - speaking as someone with three Nikon DSLRs and Sigma glass I'm very happy with.
eftpotrm
·ปีที่แล้ว·discuss
I'm a software engineer not a firefighter, but my understanding is that it's significantly an experience thing. Lithium battery fires clearly aren't trivial to deal with and do burn hotter than petroleum fires, but they're also very much less frequent and firefighters are learning how to handle them.

I'm not sure what the specific issue would be with race tracks. The average road course is very open and a very controlled environment; if you had to deal with a car fire, it's probably among the best places to do so, thanks to lessons learned in the blood of previous generations of drivers and track workers.
eftpotrm
·ปีที่แล้ว·discuss
Sure, it's a market with massive abuse potential, but we have a world full of them and we regulate to control the abuses. The underlying service is clearly of societal benefit and would clearly be profitable to all parties, so it's worth doing and working out the regulation to make it viable.
eftpotrm
·ปีที่แล้ว·discuss
That's incredibly short-sighted, not least because the number of fires per vehicle is orders of magnitude higher for combustion vehicles. I'd be astonished if that made actuarial sense if actually investigated.

I've seen and used underground car chargers in multiple European cities. They're definitely viable.
eftpotrm
·ปีที่แล้ว·discuss
Agreed, but they're not that complex to retrofit to a parking space. I can foresee a future where each space has a port and an account card reader - they'd make the buildings more valuable, the supplier to that space has a basically guaranteed income stream, and the government has an easy emissions reduction. Wins all round, so why wouldn't it happen?
eftpotrm
·ปีที่แล้ว·discuss
Yes, but it's also a breaking change to a very large legacy codebase. I can't see it ever happening, sadly.
eftpotrm
·ปีที่แล้ว·discuss
All Tesla's global sales cars are due for replacement, and none are in the offing. Tesla are circling the drain, fast, and are very unlikely to be around in their current form in 5-10 years time - the replacement product they'd need to survive takes too long to develop and should have already started, but hasn't. Best case for them IMHO is that someone spots a key asset they own (IMHO most likely the supercharger network) and buys them for that, but the stock price is currently wildly overinflated which prevents it. One day, that bubble will burst.

TBH if I were on Tesla's board I'd be pushing for a stock-funded takeover of a company that has an actual plan and ability to deliver it. Merge with (say) Stellantis and they'd have a survival plan.
eftpotrm
·ปีที่แล้ว·discuss
Because there's existing implementations that would interpret that as aliasing column names.

``` SELECT Field AS Renamed, OtherField AS AlsoRenamed ```

and

``` SELECT Field Renamed, OtherField AlsoRenamed ```

are semantically equivalent.
eftpotrm
·6 ปีที่แล้ว·discuss
I once worked on a project that only existed because the end users had seen the SAP web UI and rebelled, hard. In fairness I don't blame them; when we dug down it was easily the worst HTML I've ever seen and some impressively weird behaviour. I can't quite imagine which team at SAP thought it was appropriate to release as a tool.

So, we spent 6 months or so building a front-end that the users wouldn't refuse to touch. HTML5, responsive, attractive, flexible. I mostly worked on the toolkit side of the project to try and keep UIs vaguely standard across the multitude of screens.

And alongside us, the two highest paid contractors I've ever worked with (who seemed to be earning their money), were building what amounted to SQL stored procedures that went into a tool that let them be interfaced as REST APIs. The article talks about the amount to which businesses have to mash themselves around how SAP works - from what I saw and heard, that was even after they'd spent more customising SAP than I would expect to bill to have built very large parts of it from scratch.

So yes. I'm sure that, at a really large corporate scale, SAP has its advantages to organisations. But in a 20 year career it's probably my least favourite technology, including the email server which you could misconfigure so receiving an email would bring down the whole machine. I wouldn't be remotely surprised to see SAP disrupted into oblivion, and a bit of me would love to be part of the disruption.