Are we reading the same r/Haskell? I've never seen anything more than minor disagreements - any trolling gets down voted into oblivion, beginner questions are always answered constructively with usually more information than was originally requested.
I usually head straight to the comments, often before reading the articles to see what additional information has been added to the conversation.
I note that several of the names in the announcement are often front and centre of anything that could be flamewars - the rest of the community is very civil. This is really disappointing to see this sort of public division in the community, with as far as I can see no good reason.
As a side note, Galois have written an implementation of Tor which happily interacts with official tor, for use in HalVM based unikernels. So, if you want ephemeral tor nodes, HalVM is a pretty great way to get it working.
#haskell on freenode has always had s reputation of being open, welcoming and helpful. Try not to mistake pretension for someone talking about something you don't yet understand, which is very often the case when someone is accused of being an pretentious arsehole. Simon is by no means alone in his manner and friendliness within the Haskell community.
This is big news, PSMA was basically setup as a for profit government owned business which sold this data at great cost. I'm really glad the government has seen how valuable this data is to the Australian people and business. Great to see the government making genuine improvements to foster innovation in Australia today, really impressive stuff.
I've used a similar construct in dealing with some JSON data recently, using Either String a:
(?) :: Maybe a -> String -> Either String a
Nothing ? s = Left s
Just a ? _ = Right a
foo :: Value -> Either String Int
foo val = do
nested <- val ^? key "foo" . key "bar" ? "Could not find foo.bar"
mid <- nested ^? nth 2 . _Integral ? "Second element of foo.bar was not an Integral value"
return mid
which has really helped deal with the stringly typed nature of JSON. I should also mention I stole the idea (and operator name) from one of the Haskell parser combinator libraries which allowed you to name a whole parser expression, so errors would say "could not find ident" instead of "Expected on of a,b,c,d,e,d,f,g,h...., found X"
He seems pretty active in comments in the linked discussion... BUt I'm pretty sure John also carries a list around with him of reasons why he doesn't like Haskell, just in case he needs it. Truly unpleasant.
If this were true, then the patent is obviously invalid. But since this has never been the argument in court, I'm guessing your assertion mostly false. If you have proof that there was another company who had a product with this idea before the priority date of the patent, then I'd love to see it.
Your experiences are completely different to mine, and I've been a member of the community for about 8 years now. Haskellers are in general very aware of the flaws in the language, and this isn't limited to records - space leaks are the primary reason for the proliferation of streaming IO libraries. And for records, we've been lead to lenses, which are an extremely powerful abstraction which surpasses, IMO, whats available in most other languages in terms of being able to interact with nested data structures (giving them such a limited definition is doing them a disservice, because they're far more powerful than that). You keep mentioning the use of the "if it compiles, it works" phrase - this is clearly a meme, and often used as a joke, but is also used as a goal for writing reliable software: if we can encode enough of our problem domain into the type system, then we can be much more certain that if we write programs which compile, they likely do what we want them to. If it not a synonym for "If it compiles, it has no bugs and is perfect", which is how you seem to be interpreting it.
You're judging a whole community based on interractions you had with Haskellers most likely many years ago - dons almost never speaks publicly these days, since moving to SC (which is shame, he's someone I've looked up to and learned a huge amount from). If I were to characterise the OCaml community based on what jdh says, I'd be writing to politicians to ban all use of OCaml everywhere because his comments are toxic, and far more dishonest than I've seen from anyone in the Haskell community.
It's curious seeing you mention this, while completely ignoring how overwhelmingly negative the linked to thread is, devolving into personal attacks for no good reason - the other linked discussions between various language communities have been very civil and fun to read, but reading this bunch of OCamlers writing long lists of often minor deficiencies shows to me a level of insecurity I haven't seen elsewhere, and I find it very unappealing. It's enough for me to not want to try OCaml because the community seems very hostile. And it's not just jdh, even without his (your?) comments, it's overwhelmingly negative, and needlessly so.
In hindsight, yes, but the fact a solution is simple does not mean that it isn't inventive. There is the possibility of invention in the use of technology from one field in another unrelated field.
My primary point still stands - the test isn't whether physical analogs exist, it is whether someone WOULD be lead to reach the same solution to the problem. I'm not sure I agree that someone, at the time, would have been lead to the same solution when the existing art revolved around physical mechanisms such as buttons and switches, and did not involve interaction with the screen which the mechanisms has previously been in place to prevent.
It's making life easier for the user... this is one of the primary things that patents are here for, inventions which make life easier. And it's certainly not what would be considered "an algorithm" by any patent office - it has user interaction, in involves hardware, it is clearly not just a mere algorithm.
No, this is not one of a million nonsense patents, it one of a handful of patents which were close enough to be on the line between valid and invalid, and the decision fell on one side of the line. The vast majority of patents, even from Apple, are completely valid, and never see any time in court because they are valid. I hate this meme that patents are all awful because sometimes they are found invalid. Do some research, learn about the system, then talk about it because you clearly have no idea how successful the patent system is, and the benefits it provides to you.
I feel it would be easy for Apple to argue that is does have a physical effect - it makes it easier to access a locked phone than having to enter a pin, or one of the many other methods of unlocking electronic devices.
You're looking at the process backwards. Just because latches exist does not mean that, at the time the patent was filed, it was obvious to use a latch analog to unlock a digital device. A person skilled in the art would NOT be lead directly to that solution, but one which is already know: a pin, password, fingerprint, keycard, heck even facial or voice recognition. The test is not "did latches already exist" but "is it obvious to use them in the method claimed, as the time of application", and I would strongly argue that it is not, without some evidence to support the contrary.
I say this as someone who has worked as a patent examiner and understand the law (not the US law exactly, but they're quite similar world wide).
This is all mostly irrelevant though, and all of this discussion involves ex post facto analysis. The test for patentability is would a person skilled in the art come to the same solution without an inventive step - is the claimed invention what someone familiar with the art of human computer interaction do without doing something new. I would argue that the answer is no: there are many well known mechanisms for unlocking an electronic device (a pin, a password, a fingerprint, an identifying card or dongle, and so on) - using an analog of something that exists in the physical world such as a latch is not what someone skilled in the art WOULD do, there is some invention in taking the physical and bring it into the digital.
I just today had my Blunt umbrella[1] delivered, haven't had a chance to use it yet but it's certainly extremely sturdy and claims it'll withstand strong winds and i'm inclined to believe the claims after playing with it.
Duncan Coutts has been working on replacing the current fairly brain dead Data.Binary encoding for Haskell by using CBOR [1], which I believe is currently on the back burner (more important work to be done elsewhere). The results appear very promising and I'd love to see this announcement provide the impetus to keep the work going.
One way I could see to make this more generic is to provide the errWriter strict with a function to call on the error if it's not nil, but i'm not familiar enough with Go to know how we'll thug might work.
Like how Apple, Google, Intel, Nvidia etc. are exploiting the LLVM project? IMO, the need for GPL style restrictive licences isn't backed up by facts; more open licences encourage commercial use and open development.
I'd be surprised if Australia wasn't one of the first countries to get it; we've for a long time had very technologically advanced banks that are often years ahead of the US. Last I heard cheques were still used by most people to transfer money in the states, is that still the case? I've grown so used to being able to instantly transfer money to anyone for free from my phone that I can't imagine how tedious having to use cheques would be.
Seems everything is a fixed size so it probably would be an excellent fit. You'd probably also get constant time guarantees with Cryptol too right? From memory it wasn't too happy to do anything where the runtime varied.
Is that second implementation in Hacker's Delight? Also it'd be interesting to see how z3 handles the examples shown there too (the logarithmic time algorithms using
But the point of the representation is that locations can easily and unambiguously be stored in a single number, say a 64bit integer. A bit array necessarily has some overhead to specify the number of bits; something unnecessary in this proposal. Yes a standard using two bits per sector and specifying how many bits have been used in the actual representation is easier for a human to start to decipher, but it requires more information to be unambiguous and doesn't have as nice a binary representation (I'd rather have a fixed sized larger representation that the more complex one needed for an arbitrary sized bit array).