HN user
Sorry to nitpick, but for a good Bayesian, absence if evidence is evidence of absence. If you want the aphorism to be technically correct, you should say "absence of proof is not proof of absence".
A note on the terminology: "evidence" is a piece of data that suggests a conclusion, while not being conclusive by itself. Whereas "proof" is a piece of data that is conclusive by itself.
Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature.
I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.
Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.
Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)
Congratulations and a big thank you to the OCaml team! I hope that multicore support finally ticks all the requirement boxes that had prevented many from taking a serious look at OCaml. The language certainly deserves it: it hits that sweet spot between expressiveness, performance, and pragmatism like no other.
I have to interject here for the sake of those unfamiliar with OCaml and who may take the parent comment at face value.
Saying "it has quirks like using ;; to end statements" is misleading to the point of just being bogus. The double semi-colon is only ever used in the REPL. In fact, I've been programming OCaml for fun and professionally for over 15 years, and I've never used a double semi-colon in my code, nor have I ever encountered one in the "wild".
Conversely OCaml is an interpreted functional language.
Correction: OCaml is not an interpreted language. OCaml programmes are compiled down to native code (or bytecode, or Javascript).
Quite on the contrary: The OO part of OCaml is hardly used at all in the wild!
Indeed. Considering the volume of transactions going to and from Coinbase, their adoption of Segwit would go a long way towards alleviating the current mempool situation, which would bring lower fees for everyone.
As others have pointed out, your understanding is backwards. Mining is heavily centralised already (in China of all places!), and larger block sizes would only exacerbate the mining centralisation, which is probably why the biggest fans of larger blocks are the Chinese miners.
Segwit isn't a a block size increase. It allows for a tiny amount more transactions but it's very clear it's not enough. An actual block size increase (say to 8MB) would solve the current problems.
But what about the new problems it would introduce? I run a full node and even now it eats a significant portion of my bandwidth. With even larger blocks I would probably drop off the network altogether. And I'm sure I'm not the only one out there in this situation. Therefore, I don't think Core developers are exaggerating in their concerns about the centralization pressure caused by overly large blocks.
Moreover, wouldn't increasing the block size simply kick the can down the road? One advantage of the current fee pressure is that it strongly encourages the development of 2nd layer solutions. There are right now at least three independent teams working on Lightning Network implementations and they seem to be making quick progress...
What about pandemics? (Either natural or engineered.)
It's a pyramid scheme in a sense that you depend on others to keep buying the bitcoin.
Please don't use the expression "pyramid scheme" lightly, because there are actual pyramid schemes out there, and we want the expression to keep its power so we can warn people against them.
Bitcoin may be in a bubble, but it's definitely not a pyramid scheme.
OCaml has great support for concurrency (check out Lwt or Async libraries). Do you mean parallelism, perhaps?
And yet the Pentium G4560 -- one of the cheaper models of their Kaby Lake lineup -- supports both ECC and non-ECC RAM. I suspect the only reason behind lack of ECC support on their mainstream processors is just market segmentation.
There was a recent thread on a sub-Reddit about using the threat of the Kessler Syndrome as deterrence:
https://www.reddit.com/r/CredibleDefense/comments/62n21j/wha...
In the case of OCaml, the structural subtyping of object fields can never cause a crash, because it is verified at compile-time.
I think the confusion in this discussion lies in different interpretations of the word "Ponzi". You're using an interpretation that defines as Ponzi any investment where the value is solely anchored on the collective confidence of the holders. In the interpretation I have (and which I think is the standard one), a Ponzi scheme is something else entirely: a scheme where old investors are paid from the arrival of new ones in such a way that is mathematically unsustainable.
Note that by this standard definition, Bitcoin is not a Ponzi scheme. You may doubt whether Bitcoin is a wise investment, but calling it a Ponzi is bound to cause confusion.
The article lacks a crucial bit of context: particularly in the North and Center of Portugal, the last 8 months have been even rainier than usual (many areas already over 2000mm of rain in this period, instead of the 1000-1500mm that would be normal), favouring of course hydroelectric power generation, which accounts for a huge percentage of the renewable total.
Not to dismiss this great news, but the country is still a long way from being 100% renewable on a continuing basis. There's however a huge untapped potential in solar, so that goal is reachable if the investment happens (and grid storage becomes cheaper).
IF the observed expansion of the universe is indeed due to dark matter as we think of it, and
The accelerating expansion of the universe is thought to be caused by dark energy, not dark matter.
That impression is incorrect. I don't think the core devs and the overall community have ever been as vibrant as they are now.
Take for instance compiler development: half a decade ago, updates were rare and marginal. Nowadays you can expect a new compiler version every single year with lots of exciting features.
Would you care to share an example? I've never encountered a justifiable need to write ;; outside the REPL. The only uses of ;; I've encountered "in the wild" were hardly reasonable: essentially top-level code that was not wrapped in a "let () = ..." statement.
(...) I think it's clearly dying out at this point.
You seem pretty adamant -- what makes you think that? I think it's quite the opposite: the language and the community never felt as alive and thriving as they are right now.
You should take a new/better look at OCaml, as most of the information you mentioned is wrong and/or out-of-date. For instance:
* F# is not a superset of OCaml. OCaml has a number of powerful features missing from F#, like functors, polymorphic variants, and first-class modules.
* I disagree that the ecosystem is "stale". There's lots of recent activity around the language, and you can find libraries for almost everything.
Single vulcano explosion releases more CO2 than entire mankind in a decade.
Funny, the scientific consensus is that on average, on any given year vulcano emissions represent only about 1% of human emissions [1]. I would very much like to know where you got your numbers. It's very likely that you are being misled.
[1] http://www.skepticalscience.com/volcanoes-and-global-warming...
OCaml.
What do you mean by "stagnation of OCaml"? There was a period some 4-5 years ago where it did seem like there was little development on the language, but things have changed quite a lot since then. Lots of developments in the core language (including first-class modules and GADTs!), and a blossoming of the ecosystem around it. To me, it seems OCaml has never been livelier than now...
Since F# was derived from OCaml, I think readers may also be interested in taking a look at the OCaml-Java project: http://ocamljava.x9c.fr/
(It's essentially what it says in the tin...)
There are several reasons why one would prefer OCaml over F#:
- OCaml is not tied to .NET. Obviously the converse also applies: if you need .NET integration then F# might be a better choice.
- F# does not support some of the more advanced features of the OCaml type system, like polymorphic variants (open unions) and functors. These are very useful OCaml features, IMHO.
- OCaml has gained some very interesting features since F# branched off, which again are not present in F#: modules as first class values, GADTs, and better control over module signatures.
Overall, my recommendation is that unless you are really tied to .NET ecosystem, then OCaml is a more interesting language to learn.
This is almost identical to the syntax used by OCamldoc, a tool for generating API documentation from OCaml sources:
http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual029.ht...