News for hackers. Stuff that matters.

mookid11

you might like diffr (https://github.com/mookid/diffr) (disclaimer: my project)
Re:Mathematics Guides Effect Handlers [video] on Tuesday March 12, 2024 @04:12PM (#39684350)
Matija Pretnar about the eff programming language and mathematical foundations for Effect Handlers.
Re:Difftastic: Syntax-aware structured diff tool on Thursday July 08, 2021 @05:43AM (#27769935)
I wrote diffr [0] for that purpose; it serves me well, especially if your team makes code with long lines.

In my opinion, a simple approach that does NOT make any parsing is more efficient (what about bugs in your parser? code with syntax errors? also, how fast would the parser be?)

[0]: https://github.com/mookid/diffr

Sort of related: as I never made diff-highlight work correctly on Windows, I wrote diffr[0] which goes a little bit behond what diff-highlight does.

[0]: https://github.com/mookid/diffr

Re:Immutable.rs: immutable data structures for Rust on Saturday April 07, 2018 @04:41AM (#16779952)
The point is to share intermediate state of your data structure without headache.

For instance, if you write an interpreter, representing variable bindings with a functional map allows to reason about scope super easily; when you change scope, you just create a new map with the new variable bindings, and when the scope ends you just get back the map at the scope beginning which is still valid.

With a stateful hashtable, you need to undo the changes you did in you scope; the value of the table when opening the scope that you want to get back to is gone forever. Now it ties you program to a certain execution order. One way to see that is that if you want to collect environment to each scope in some data structure for some reason, you need to make deep copies everywhere.

Re:Reflecting on Haskell in 2017 on Monday December 04, 2017 @03:00PM (#15846886)
> For example, you'd not get far in Rust without Result<>, Option<> or Future<> which are all make use of delayed resolution for their value.

Certainly not for Result<> or Option<>.

Re:Get Started with F# as a C# developer on Friday July 28, 2017 @12:30PM (#14875454)
It depends if you enjoy NullPointerExceptions.
Re:A deep dive into Multicore OCaml garbage collector on Sunday July 16, 2017 @12:27PM (#14782690)
Unless experienced, you have no clue how a piece of code will be parsed. With ocaml, where is very little ambiguity; and indentation tools can take care of proper formatting, you only need to break lines.

And it can be pretty bad with haskell, which has complex semantics compared to, say, python.

With whitespace sensitive syntax, I feel like in the dark age of manual indentation.

Re:A deep dive into Multicore OCaml garbage collector on Sunday July 16, 2017 @05:19AM (#14781244)
> Haskell has some nice things going for it. Its syntax is cleaner than OCaml's, for example.

While I find the ocaml syntax very far from perfect, the whitespace sensitivity of Haskell makes it immediately worse. What a silly design.

Re:Writing Performance Sensitive OCaml Code on Saturday May 13, 2017 @05:44AM (#14330151)
To allow IEEE compliant float with tagged pointers.

However, note that floats are not boxed in the OCaml's arrays. Boxing floats is a pain because it makes the price of defining subroutines taking float arguments high.

Re:Why OO Matters in F# on Wednesday March 22, 2017 @02:32PM (#13933441)
Interesting how the author avoids to mention OCaml's (far from perfect, but still) object system.
I think this is the first time I see anyone like the OCaml syntax.
Re:Buttery Smooth Emacs on Sunday October 30, 2016 @02:43PM (#12831472)
I think that you only need isearch + occur (M-s .), not ace-jump.

I tried ace-jump and have it configured for months, I never use it. neither do I use swiper, because it is too slow to start.

Also, don't forget C-M-{left, right, up, down} commands :)

Re:Why I’m dropping Rust on Sunday September 11, 2016 @03:36PM (#12475190)
> Yes, but hardly anybody uses that part of the language. We tend to stick with modules and variations over them.

You can have inheritance via polymorphic variants: see Garrigue's `Code reuse through polymorphic variants`.

Re:Ecaml – Writing Emacs Plugins in OCaml on Monday August 29, 2016 @07:13PM (#12386179)
You can use the ocaml toolchain (for instance: ocamllex and ocamlyacc) and stop writing ad hoc parsers.
Re:Ecaml – Writing Emacs Plugins in OCaml on Monday August 29, 2016 @05:07PM (#12385336)
I like: http://caml.inria.fr/pub/docs/oreilly-book

Real world ocaml is not so complete, and light on subjects such as C interop.