I wasn’t expecting to personally know two of the authors, but having Accelerate included makes sense.
497 karma · joined November 22, 2009
[ my public key: https://keybase.io/axman6; my proof: https://keybase.io/axman6/sigs/iW_swLHLPyPBft7t-R5kHZD3ZCHhIX-7pBUTbVj6yBQ ]
It actually reminds me of the the [OSS Sabotage book](https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...)'s section on General Interference with Organizations and Production (page 28):
(11) General Interference with Organizations and Production
(a) Organizations and Conferences
(1) Insist on doing everything through “channels.” Never permit
short-cuts to be taken in order to expedite decisions.
(2) Make “speeches.” Talk as frequently as possible and at great
length. Illustrate your “points” by long anecdotes and accounts
of personal experiences. Never hesitate to make a few appropriate
“patriotic” comments.
(3) When possible, refer all matters to committees, for “further
study and consideration.” Attempt to make the committees as
large as possible—never less than five.
(4) Bring up irrelevant issues as frequently as possible.
(5) Haggle over precise wordings of communications, minutes, resolutions.
(6) Refer back to matters decided upon at the last meeting and attempt
to re-open the question of the advisability of that decision.
(7) Advocate “caution.” Be “reasonable” and urge your fellow-conferees
to be “reasonable” and avoid haste which might result in
embarrassments or difficulties later on.
(8) Be worried about the propriety of any decision—raise the
question of whether such action as is contemplated lies within
the jurisdiction of the group or whether it might conflict with
the policy of some higher echelon."I'm a volunteer, my job is to choose where I volunteer my time, and I won't be volunteering it for free for this".
The output in their Mesa project bug report is outright misinformation, it sounds completely plausible but is absolute nonsense. This is the true danger of AI, it is so convincingly confident that people forget to question it, or in this case, don't even have the tools to begin questioning it. It's actively unhelpful at best.
Personally, the developers of both the LLVM and Mesa projects were far kinder and patient than I would have been, most OSS developers aren't just not paid to work on these projects, but are usually paid to work on other things. Taking up their time with this nonsense is very insulting to them, and the attitude that they owe the author anything at all is, as stated in the LLVM ticket, exactly what pushes many developers out of OSS development.
I also found it very interesting that their pics of this feature were with Davinci Resolve on the screen and not Final cut Pro - I guess when it comes to colour, there's no better tool.
No one is going to claim this. The fact the Pro gets 10Gbit USB 3 _is_ interesting (particularly for anyone using the phone for video), but certainly not revolutionary or genius.
You might have literally deleted people's whole businesses, companies, who employ real people, who have families, now need to figure out how to continue. Not least of which, your own. If the company survives until Christmas I will be shocked; no one can trust your company ever again - your core business is storing other people's data, and you deleted it, for many, completely without warning.
I guess people still use Mongo even after finding it doesn't achieve any property of the CAP theorem, maybe some people will keep using a database provider with a track record of intentionally deleting their paying customers' data.
There just aren't enough adjectives for astonishment to adequately describe this situation.
I hope you offer Jay Clifford some support, he's clearly been put in the awful situation of having to explain the decisions of others and deliver the awful news. If I were him, I would be in need of serious mental health support, this is an absolutely awful thing to have responsibility for without any ability to rectify.
Going the other way, there is an extremely well understood interface between all the processes which run in isolation: shared memory. Nearly by definition this must be well coordinated between the processes.
So the first step in moving to a multi-threaded implementation would be to change nearly nothing about each process, and then just run each process in its own pthread, keeping all the shared memory ‘n all.
You would expect performance to be about the same, maybe a little better with the reduces TLB churn, but the architecture is basically unchanged. At that point, you can start to look at what are more appropriate communication/synchronisation mechanisms now you’re working in the same address space.
I just don’t understand why so many people seem to think this requires an enormous rewrite - having developed as a multi-process system means you’ve had to make so much of the problematic things explicit and control for them, and none of these threads would know anything at all about each other’s internals.
I don't understand how a bug in GHC has blown up more than any bug in any recent GCC or clang - probably because the bug reporter decided that hyperbole was going to be their tool of choice instead of behaving like an adult.
I don’t have time to go into details but nearly every statement you’ve made here is in my opinion wrong, other than the difficulty in debugging (and there are very good reasons why this is difficult).
I’ e never found it hard to write fast Haskell, because I put in the effort to learn how to do it. People forget they also put in the time to learn how to write fast C++, and Java; it’s a very large portion of any software engineering curriculum, it’s literally what algorithms is all about. People find writing fast Haskell hard not because it is fundamentally hard, but because they were never taught how.
> due to the lack of native accommodations to bind into fast code, or even into GPUs.
I have no idea what you mean by this, GHC provides a very good FFI, and there are libraries for binding to Rust, R, Objective-C and others. We also have Accelerate for data processing on GPUs, which includes runtime compilation of native code for both GPUs and CPUs.
Well, it’s been paying my wages for the past eight years, so it’s incredibly useful to me. Are we services “very specific projects”? Are data processing systems? Are geospatial data munging? Are financial systems? Those all sound like mundane, every day projects, and they’re exactly what I’ve been working on.
And when it comes to “actual work”, that’s where Haskell truly shines - being able to fearless refactor code and iterate until the compiler is happy again is my favourite feature of Haskell. It’s not the “neat type system”, it’s the ability to not have to keep the entire project in my head at absolutely all times because I might forget to make a stupid change the compiler should have caught for me. The productivity is massive, once you’ve invested the time, but it does take time and it is an investment.
I use the lens library all the time and those docs make perfect sense, particularly if you apply just the teensiest bit of logic and thing “Could a setter, perhaps, set something?”. It’s a DSL, and you don’t understand the domain - I’m sure you’d have a great time explaining this function from LLVM without referring to any other part of the documentation to give it context https://llvm.org/doxygen/group__LLVMCCoreValueInstructionGet.... What’s a GEP? Under the rules you’re applying to the lens documentation, I’m not allowed to look that up, because it should be immediately obvious.
You are complaining that a single function within a library doesn’t describe the whole abstraction the library is built on? Should every single function, operator and type include the whole fucking lens tutorial so you don’t have to go and find it?
I suppose every web library should include an explanation of IP, TCP, UDP, HTTPS, url encoding, compression and anything else that is needed, on every single function too? Christ, I cannot believe how incredibly dumb your take here is. Libraries in every single language provide some kind of preamble in their documentation which covers what abstraction that library provides, and Haskell is no different; the particular library you have chosen to misunderstand is INCREDIBLY general, the documentation is actually amazingly precise, if you have taken the time to learn what an optic is.
I genuinely think you should be ashamed of this opinion, because it shows that you’re both willingly ignorant, and proud to state that fact publicly.