61–70 of 102 posts
I wish OCaml had the libraries and community of Go or Rust, I think it'd be the most useful all-around language out there.
What's wrong with the libraries and community? There are thousands of libs in opam repository and although community may be smaller than Go's, the quality of OCaml community is incredibly high.
Earlier quoted context omitted.
No, addition is still commutative (i.e. a + b == b + a) Sadly, it is not associative (i.e. (a+b)+c != a+(b+c)) Imagine a being a large number, and b and c being so small that adding each single one to a will result in a, but adding their sum will result in just the smallest increment over a.
Actually, floating point addition isn't necessarily commutative[1][2], which is one of the problems of thinking of floating point as just a number. Although in this case, it's at least still addition, but the type of things being added have special conditions. It's more like doing calculations on scientific notation, where there are special rules for how to keep the right number of significant figures/precision after…
Now that you mention, there was this fascinating denial-of-service vulnerability in PHP which is (kind of) related... https://news.ycombinator.com/item?id=2066352 http://www.exploringbinary.com/why-volatile-fixes-the-2-2250...
EDIT: To expand on this: The following code is valid, and may print "weird":
double x = f();
double y = x;
if(x != 0 && y == 0) {
printf("weird\n");
}
Earlier quoted context omitted.
My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there…
This is some solid feedback, thanks for taking the time to write it up. I work on ReasonML, so a lot of this feedback describes problems we’d like to help the OCaml community solve. We are making progress on the popularity front by leveraging the JS ecosystem and it is proving to be an effective approach due to the size and openness of the JS community. Meanwhile the OCaml ecosystem (libraries, compilers, build syste…
I agree that OCaml has some brilliant libraries for problems which are, in other languages, difficult or unpleasant to solve (parsing being one of them). Menhir is wonderful. However, that doesn't preclude gripes 3 & 4 from above. If a language seeks to be general-purpose, the existence of some truly great libraries doesn't redeem a need for dependable solutions to a multitude of problems.
I think OCaml can have a place in an organization's software stack today - but it will not gain the spotlight until its library offerings have the variety, robustness, and accessibility of other ecosystems. Would I write an internal parsing service using Menhir and expose over Protobuf? Absolutely. Would I write a heavier-duty application server that had to parse something, then talk to Postgres? Perhaps not - and that's a shame.
Love Reason React. I'm a huge static typing proponent where possible, and combining the semantics of OCaml with React is a great move.
Writing the occasional typed FFI wrapper into a Javascript library isn't the worst thing in the world. Most of my complaints for libraries center around server side OCaml/ReasonML development, which is where I have the most experience. (and that experience is admittedly limited)
Earlier quoted context omitted.
Do you have concrete examples of things you are missing?
My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there…
10 minutes with angstrom and unixlib?
Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react.
>I can't in good faith recommend it for building production systems to interact with the outside world
Why is that so? I believe in exactly opposite. We are building quite a big telecom infra with ocaml, and it shines. In really critical systems (something beyond silly guest pages) you can't rely on low quality third party libs (which are usually provided by go), you have to write things by yourself or use some very generic stuff, and that is where ocaml shines. Both the language and major libs in opam are of an outstanding quality, people behind mirage, ocaml, angstrom, react, lwt are so collaborative and smart, and libraries are so transparent and beautiful that it is easy to understand how things work and what's happening under the hood.
Earlier quoted context omitted.
I never understood the complaint about static methods regarding not being OOP. It is not much different from class messages in Smalltalk.
Smalltalk is not a statically typed, nominally typed language, Smalltalk is dynamic and in Smalltalk classes are objects themselves, so any comparison to Java, C# or F# does not apply. This is relevant in the context of OOP because in OOP when you talk of methods, you talk of single-dispatching, polymorphism and the Liskov substitution principle. Static methods are just plain functions tied to classes from an era whe…
Which also apply to Smalltalk.
> Static methods are just plain functions tied to classes from an era when people thought having classes everywhere is actually a good idea,
Using GNU Smalltalk serialization syntax,
Object subclass: #MyClass.
MyClass class extend [
myClassMethod [
^ 'Hello from class method'
]
]
Transcript show: MyClass myClassMethod.
class MyClass {
public static string myClassMethod () {
return "Hello from class method";
}
}
System.out.println(MyClass.myClassMethod());
Better know C++, before bashing it.
In C++ operators can be defined as member functions and participate in inheritance resolution except for operator=.
I guess you are mixing C++ with C#.
Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is…
Dear z3t4, I write this letter from the distant past, late in the month of November in the distant pass of 2017. From your lofty throne upon a future so bright, I urge you to remember the sad lives we lead as a return code type mismatch caused every Mac OS X machine running modern software to be accessible by anyone with physical access by typing "root" into the login field then hammering on the Enter key like a 9 ye…
Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is…
How many multi-year running, 20,000+ LoC applications have you kept up to date? Or do you just start from scratch every year because it's impossible to upgrade your dependencies?
Earlier quoted context omitted.
What exactly are you talking about? OCaml has decent libraries for almost everything that you want to do. What exactly are you missing?
"decent" and "almost" are generous, and it's completely realistic to say that Go, Java, Python, and Ruby's ecosystems far outshine OCaml's. Love it as a language, but the ecosystem and community have a ways to go before even slightly widespread adoption.
Earlier quoted context omitted.
Do you write Scala, or have you even looked at Scala code any time in the past few years? I'm curious where this habit of spreading FUD over Scala being operator heavy came from. Maybe it was back when it first started reaching the HN front-page or something? Scala is a super approachable language, without any (that I can think of) strange operators in the stdlib. You could make a case for Cats, I guess, but writing…
https://github.com/scalaz/scalaz/blob/series/7.3.x/tests/src... It is a mystery.
But pointing at Scalaz is a bit ridiculous. It's a known test library for trying things out and basically not allowed in any Scala codebase I've been working on.
Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is…
If you don't make type mistakes, good for you, but why not let the compiler or interpreter provide a safety net, just in case? In addition, static typing makes refactoring easier because you can confidently redesign your code and let the implementation tell you which types you haven't yet adjusted. Besides, type inference means that you do not even have to write out the type yourself in many cases. (However, to do so…
JavaScript is the perfect enterprise language. And that's where $M makes most of it's money. But they do not fully control JavaScript, and they have little control over NodeJS. So what do you do ? Embrace, extend, and extinguish! You add enterprise feature! That will convert users back into your ecosystem again! While at the same time trying to hurt JavaScript and NodeJS. Interestingly though Samsung recently bought NodeJS and their new devices does have JavaScript support, so hopefully NodeJS and JavaScript will not be too easy to extinguish.