81–90 of 94 posts
I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.
Question 1: Do you actually know Haskell? Question 2: How the F#*$ are you a software developer in Mountain View without a job?
Earlier quoted context omitted.
That's a very insightful comment. I 100% agree. And I'd add that I'm still completely baffled to see that some very obvious data support issues are still not resolved in the industrial world (e.g Java) : * Computing with units (which is tough to put in a language, but so is compilation) * Computing with dates in a sensible way Of course one can make computation on those types, but it is so un-natural that it scares m…
> Computing with units (which is tough to put in a language, but so is compilation F#'s units are nice. > Computing with dates in a sensible way The new Java time API is pretty good. But honestly my favourite datetime API would have to be Postgres'. > BigDecimal for currency, let me laugh Out of curiosity, why?
For BigDecimal, my grief is that it makes code horrible (at least in my experience, I'm still locked in JDK 1.7).
BigDecimal has the problem I see with the rest of my griefs : it is possible to compute things correctly with code (obviously), but the way the code is written is ugly (and painful).
BigDecimal yearly_amount = new BigDecimal("1000.00");
BigDecimal daily_amount = yearly_amount.divide(new BigDecimal("12")); // Beware the rounding issue
money yearly_amount = 1000.00 EUR; // 4 decimals
money daily_amount = yearly_amount / 12; // Beware the rounding issue !
Earlier quoted context omitted.
Dropbox has Rust at the core of their product now. We have a fair amount of production use.
Aren't they sold to Go? https://twitter.com/jamwt/status/629727590782099456 https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-...
Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…
Are you saying that you never hire anyone at all to work on your project, or that you think so little of the community that created the language your project uses that you lie to them about job openings?
Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…
> I often get requests from people from the OCaml academic community asking if we have any available positions, and the answer has so far always been no. I don't understand what you're saying. Are those applicants to Red Hat, or developers asking to contribute to libguestfs that you say no to.
Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…
I understand why one would avoid first class modules (I don't use them a lot either). However I fail to see why functors are too complicated, since they are basically just functions. Could you explain ? Also, according to this[1], There are basically three main contributors, including you, so I fail to see how training would be an issue ... [1]: https://github.com/libguestfs/libguestfs/graphs/contributors
Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…
>In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. If you're hiring OCaml programmers who can't understand (or learn to understand) functors, you're probably doing something wrong. Even using the stdlib Hashtbl requires an understanding of functors.
I arrived in Mountain View tonight. I want a job. It must involve Haskell. Anything else is a waste of time. My prediction: Haskell will be ready for production when people are ready to engineer code that lasts 1000 years.
Earlier quoted context omitted.
Is there any good article on how Haskell got into a situation where there are multiple different string types? I understand how it happened with C/C++ (e.g. on Windows), but Haskell is much more modern than that. I feel there must be some sort of story or interesting thing to learn here. Or is it just the usual str vs widestr type problems? Also was interested to see the comment about huge records and the memory pres…
I don't know an article, but the overall situation is pretty straightforward to understand. The original Haskell strings were linked lists of characters. This was simple and elegant and worked well with the functional programming approach of the time (1980s, by the way, so maybe Haskell in its origins isn't quite so modern as you think). Nobody was much concerned about high performance string operations in Haskell at…
By "should the types be lazy or strict", you mean, if you do a string operation like uppercase/lowercase/substring/replace/etc, is that operation lazy or strict? Or are you meaning decoding bytes to characters or ... what aspect of the type itself can be lazy or strict?
Earlier quoted context omitted.
I don't know an article, but the overall situation is pretty straightforward to understand. The original Haskell strings were linked lists of characters. This was simple and elegant and worked well with the functional programming approach of the time (1980s, by the way, so maybe Haskell in its origins isn't quite so modern as you think). Nobody was much concerned about high performance string operations in Haskell at…
Thanks. By "should the types be lazy or strict", you mean, if you do a string operation like uppercase/lowercase/substring/replace/etc, is that operation lazy or strict? Or are you meaning decoding bytes to characters or ... what aspect of the type itself can be lazy or strict?