Live data from Hacker News

Why OCaml, why now? (2014)

spyder.wordpress.com

131–132 of 132 posts

Re: Why OCaml, why now? (2014)

#131
post #116

Earlier quoted context omitted.

One thing I find interesting, is that our industry is basically a gigantic sea full of Java/C++ programmers. Within that ocean, there is a small portion of Functional Programmers who have come to a realization that a set of finer grained abstractions would improve the industry productivity at large. Within that small subset, you have a set of people who believe that static type systems aren't ready for widespread use…

Hi from "the sea". I think the Functional Programmers crowd overestimates how much better languages can really improve software development. Projects in the industry would be massively improved by: more focus on quality (eg. decoupling), technical debt awareness, enhanced communication, enhanced architecture, internal engineer mobility, more thoughts given on social dynamics and productive work environments. It pains…

> more focus on quality (eg. decoupling

> technical debt awareness

> enhanced architecture

I think all three of these can be improved and alleviated somewhat by better languages.

Some languages most certainly have cultures that promote properly taking care of all of these as central principles.

It's a bit shortsighted to think that since projects are hard for reasons other than language choices (too), we should just ignore languages all together.

At some point that'd just mean you end up realizing you could be even better with better tools, so why not start now even though everyone hates each other and can't talk to one another?

Re: Why OCaml, why now? (2014)

#132
post #130

Earlier quoted context omitted.

1. that's why I qualified it "proper". Of course there is unsafePerformIO, but in the presence of laziness, this is really unsafe . as opposed to ML, where doing IO may harm your ability to reason about stuff, but it won't be unsafe. Debug.Trace is also unpredictable; actually, it's perfectly predictable if you understand laziness, but it's still not what's really wanted in most cases. 2. ST is a single instance of a…

Could you say something about why `unsafePerformIO` is unsafe in the presence of laziness? I know `unsafePerformIO` can be used to violate the type system in combination with `IORef`s, for example, but I don't see what laziness has to do with it.

In the presence of laziness, it can be very difficult to reason about what code executes when. When you don't know when your unsafe IO happens, things can get out of order or have other unforeseen side effects.
Post reply on HN