Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

Post reply on HN
Print view View original

241–250 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#241

Post by yawaramin »

muglug wrote: post #204
octachron wrote: post #164

Earlier quoted context omitted.

I think that it is better to not forget that expressiveness comes at the cost of a richer world of misbehaving code. If you are used to a world where functions have more than one argument and must be applied to exactly the right number of arguments and nearly never returns another function, starting a curried language suddenly throws you in a situation where many small mistakes like `plus 1` are not caught early anym…

Thanks for the work you’re doing — though it’s mostly too late for me, good to know that people are putting a lot of thought into these questions. The sense I have got from my experience is that OCaml is a great language for people who are slightly less error-prone than I am. My style of coding is to write a lot of slightly dodgy code in one breath, then use the typechecker to tell me all the things I got wrong. Even…

> My style of coding is to write a lot of slightly dodgy code in one breath, then use the typechecker to tell me all the things I got wrong.

That's exactly the style OCaml excels at.

> OCaml currently seems great for people who are better at getting it mostly-right first time

That's because they got it wrong a lot at first, then learned how to get it right. You've heard of people talking about how they internalized the Rust borrow checker's rules after some time, right? Well, internalizing a typechecker's inference rules works very similarly (faster if you read OP).

> I’ve seen a lot of OCaml code written by people with PhDs and backgrounds in type theory.

That's unfortunate, it's a nearly perfect language for industrial work. Tiny example of how easy it is to hack together useful tools with it: https://dev.to/yawaramin/practical-ocaml-314j#proof-of-conce...

Re: OCaml Programming: Correct and Efficient and Beautiful

#242

Post by yawaramin »

shikoba wrote: post #227
wiseowise wrote: post #208

Earlier quoted context omitted.

No. You don't need this anymore. > You can use -annot or -bin-annot when compiling and the Tuareg function caml-types-show-type in Emacs will be your best friend. Just open OCaml program in some editor with LSP(Vim, NeoVim, VS Code, Emacs) and it will instantly show you the error.

That's sad. I need dune to make it work.

Dune has its quirks but it's pretty good at its job. The community is standardizing on it and every time someone pops up on the forum asking for help with weird issues because they didn't use dune, I think they're just making thing hard on themselves for very little benefit.

Re: OCaml Programming: Correct and Efficient and Beautiful

#243

Post by yawaramin »

hutzlibu wrote: post #219
wiseowise wrote: post #133

Earlier quoted context omitted.

Define "productive output".

Producing code, that primarily solves the real world problem (not aesthetic ones).

What kind of code? People who want to solve real-world problems treat programming languages like tools in their toolbox. In the past week at work I wrote Scala, HTML, JavaScript, YAML, and Terraform. I also remove tons of code from my production systems whenever I get the chance as it solves a real-world problem for me (maintainability of the code base).

'Producing code' to measure 'superiority' is about as useful a metric as counting lines of code to measure productivity.

Re: OCaml Programming: Correct and Efficient and Beautiful

#244

Post by yawaramin »

frankohn wrote: post #69

As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…

> Functional programming with immutable values is a wrong pattern for programming languages.

Let me refer you to the most successful programming language of all time, by far–Microsoft Excel formula language. It's:

- Functional (data transforms are purely function applications, there's even a LAMBDA function now)

- Immutable (functions in the system can't change values, only consume incoming values and output outgoing values).

Re: OCaml Programming: Correct and Efficient and Beautiful

#245

Post by yawaramin »

pjmlp wrote: post #105
lairv wrote: post #44

Earlier quoted context omitted.

Nope, I must say I have only used a small subset of languages from the FP-language-zoo, so my opinion on OCaml might be biased But as an example when writing Typescript, I feel so frustrated of not having a clean way of doing pattern-matching

You will have to wait for JavaScript to add it first. The whole point of Typescript and why it is so successful, is because they only add type system on top of JavaScript. Pattern matching would introduce new language constructs beyond what is required for defining types.

Why wait? Just use ReScript. It's OCaml but adapted to fit natively in the JavaScript world.

Re: OCaml Programming: Correct and Efficient and Beautiful

#246

Post by yawaramin »

usrn wrote: post #70

I really want to like ML but I have some complaints about OCaml in particular: The stdlib is very weak so everyone uses this third party library. That really rubs me the wrong way. All structures share a namespace for their elements which is super wacky.

> The stdlib is very weak so everyone uses this third party library. That really rubs me the wrong way

So don't use the third-party library then? There's a lot of functionality in the default Stdlib, use what you can from there and find third-party libraries for the rest...

> All structures share a namespace for their elements which is super wacky.

Not sure exactly what you mean here, perhaps that all modules in a single compilation unit are globally namespaced. Simple enough to solve nowadays especially with everyone adopting a common dune-led convention of namespacing by the library name.

Re: OCaml Programming: Correct and Efficient and Beautiful

#247

Post by franz_kafkaagh »

0x69420 wrote: post #176
franz_kafkaagh wrote: post #157

Earlier quoted context omitted.

I write Elixir for work and I love most things about the language. The pattern-matching would still be made better with static checks. It sucks to have a function blow up at runtime because of something as trivial as args being swapped or some code somewhere changing its return types. Someone brought up Gleam earlier, but god why with that syntax? I'd still rather have dynamic checked pattern matching over the altern…

dialyzer and a liberal sprinkling of typespecs gets a decent chunk of the way there, meanwhile the problem with gleam and friends is the fact that they're altogether new languages -- the pragmatic solution would be a restricted subset of erlang (that a likewise restricted subset of elixir could comfortably compile down to) where your module has to be fully typed, but you would need some pretty gnarly logics to handle…

I'm hoping that https://github.com/josefs/Gradualizer and its Elixir counterpart get us closer to what "I" want. I find dialyzer often inscrutable compared to something like OCaml's or Haskell's type errors.

I do still use it and typespecs, because it's better than no checking.

Re: OCaml Programming: Correct and Efficient and Beautiful

#248

Post by akhmatova »

yawaramin wrote: post #240
akhmatova wrote: post #220

Earlier quoted context omitted.

You just need to word the postings appropriately and be willing to teach people what they don't know. OK, I'll grant that if you have that "magic skill" then you can in fact recruit developers for niche languages. Most companies don't, as we know, and frankly it's amazing to me how incoherent their communications are throughout their so-called hiring process.

If having sensible hiring practices is a 'magic skill', then I guess call me Harry Houdini!

Per this person's experience (which seems sadly far from atypical), you might as well be:

https://www.benjamistan.tech/2022/06/26/wasting-time-in-tech...

Re: OCaml Programming: Correct and Efficient and Beautiful

#249

Post by hnfong »

throwaway17_17 wrote: post #124
agentultra wrote: post #103

Earlier quoted context omitted.

> The optimal implementation might be imperative There are times when it isn't. I'm thinking of Richard Bird's functional pearl, The Smallest Free Number , where the divide-and-conquer algorithm is faster than the imperative one. From the conclusion: One of the differences between a pure functional algorithm designer and a procedural one is that the former does not assume the existence of arrays with a constant-time…

I tend to believe that there is an issue of map/territory confusion in teaching ‘programming’ and in general thinking about programming. Programs are usually envisioned as being statements which are performed in a sequence one after the other. This is comparable to the nature intuition about what an algorithm is, i.e. a series of steps to achieve a result when given some input. The problem then lies in the deeper exp…

Show me a non-imperative, in-place, efficient implementation of textbook quicksort and we'll talk.

Re: OCaml Programming: Correct and Efficient and Beautiful

#250

Post by agentultra »

hnfong wrote: post #249
throwaway17_17 wrote: post #124

Earlier quoted context omitted.

I tend to believe that there is an issue of map/territory confusion in teaching ‘programming’ and in general thinking about programming. Programs are usually envisioned as being statements which are performed in a sequence one after the other. This is comparable to the nature intuition about what an algorithm is, i.e. a series of steps to achieve a result when given some input. The problem then lies in the deeper exp…

Show me a non-imperative, in-place, efficient implementation of textbook quicksort and we'll talk.

Here's a direct translation of a C++ implementation into Haskell with no optimization: https://koerbitz.me/posts/Efficient-Quicksort-in-Haskell.htm...

Personally I think the Haskell code is a bit nicer. Mutation is inherently unsafe and you need to be more careful when performing such computations. Haskell code makes this painful to read by planting red-flag words like, "unsafe" around.

In C++ mutation is the norm and so it's much easier skip past such code. No indication that these operations are unsafe. The experienced reader will scrutinize this carefully or gloss over it at their own peril. The code is terse on the subject as the syntax maximizes efficiency for this case.

Here's another: https://stackoverflow.com/a/5269180

If you absolutely need in-place mutation, it's available. It's just not the default.

Post reply on HN