e-dant

What about Rust’s borrow checker (affine types) enforces the use of mutexes (or other sync prims) here?

Yeah, I don’t know how my filesystem watcher made it to the front page either

Looks like constant folding to me. What’s the difference exactly?

The solution is function composition.

Combine, reuse, rewrite as needed.

Eliminate control flow.

Use combinators!

This is the website containing the test: https://www.sapa-project.org/survey/start.php

I don’t know about you, but I definitely wouldn’t hit either of those buttons taking up most of my screen, and I definitely wouldn’t give out specific information on the second screen.

> 44% of 18- to 49-year-olds say they go online almost constantly

Depending on what people consider “going online,” this isn’t necessarily a problem.

Being glued to an endless feed of clickbait and advertisements is probably unhealthy.

Having a desktop running SETI in the background for the entire day probably isn’t.

I wonder what people mean when they say “going online.”

Reading over many of the comments here makes me sad.

Many of them seem to be about what I, the developer, can use.

Let me reframe it — what if you thought of FP techniques as something you could expose to a user of your API?

What if you viewed all your work in a language as a language. Borrowing concepts like affine types (aha, rust!), dependent types (hello, Agda!), composition (from pipes to combinators, this one is everywhere!) is important.

Strictly procedural or OO concepts might be useful in an implementation, but it rarely helps the user.

Some people here are feeling put off by an author pointing out bad practice.

Some people writing security vulnerabilities in C are feeling put off by a programming language with sanity checks.

For the record, runtime polymorphism is generally frowned upon in the most modern C++ practice.

The only difference between “modern, clean” C++ and the author’s switch is probably a concept that requires some type attributes.

The example is contrived, and the realization of “clean” code through runtime polymorphism is both dangerous and odd. The whole point of not using polymorphism is to catch runtime crashes at compile time, reduce overhead and improve readability. I know many people who wouldn’t use an object here anyway. Free functions would do nicely, and are infinitely compositional.

That’s a holiday sweater. Not a well-designed. Which is why it looks nice. Very human.

Programmers have a lot to learn from designers.

Programming is a form of expression between a human and a system. We should finally start treating it that way.

Write something beautiful.

Lots of comments here debating what’s legacy, what’s modern. Here’s my take:

Never use objects with behavior. (Ban OOP.)

Prefer monadic types.

Functions should only take or return moved values or const references. (These form linear types when you need state and ensure immutable values for stateless types.)

Never use a template without a concept.

Prefer the stack and ban mutable memory.

You end up with a functional language which resembles Haskell and competes with C. Not even rust has that level of generality.

Sure. But the point is that functional languages are more declarative, holding very little control flow state. Procedural languages are the opposite.

The computation I’m talking about is whether you’re for more of a von neumann target or a lambda calc target.

Algorithms != computation

Practically speaking, any algorithm that does the same thing given the same input is said to be stateless.

This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types.

Languages like Haskell and Agda have these properties.

Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardrails on ad-hoc state manipulation. C++ has linear-esque types in its pointers and higher-kinded types in the concepts and constraints features.

The argument is that we don’t compose enough functions to create value. Instead, we lean on (not always well defined) state, the result of operations on data

Balance in all things

Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs.

Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world.

But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture their context, and I’ll allow pass-by-reference in my APIs, but that doesn’t mean I encourage it.

I’d argue the best way to do that is to write stateless code and let the compiler figure out how to make it fast

Wouldn’t be hard to make a combinator with function pointers in C.

I do it regularly. They compose well (and you can pass them state for context).

Which abstractions?

I could see a monad being defined as a list of (typed) states with a functor. But they’re still stateless.

I could also see immutable data structures being implemented in a stateful way (they usually are in non-FP languages).

Woah — with all the declarative and functional languages, looks like someone has just discovered a (stateful) state machine. They’re trying to convince us that this is a useful thing in a hypothetical situation where people do ridiculous, unsafe things on an ad-hoc basis. Not sure I’m buying it.

Oh, wrong universe.

Edit:

I use state, too. I get it. I just dislike it. It doesn’t usually compose and is rarely safe.

Better question: Why do we endlessly produce so much state?

So, we have three (umbrella) paths to modeling intelligence:

- Pattern theory

- Abductive logic

- Machine learning

Do they converge?

Functions are universal. Choose them over everything else.

Functional F# syntax or bust.

I recently had a conversation with a colleague who mentioned:

“We can only be great at one thing. The rest we can only be good at.”

This doesn’t quite answer the question, but I think it’s related.

http and tcp aren’t very comparable.

Anyway, the whole OSI has problems. If it were up to me, I’d redo IP to include named ports and see what follows.

C strings are pointers to memory. There are semantics and assumptions encouraging null-character delimited strings, but not every API follows those rules (just got done working with a Windows API that doesn’t).

Often, you have to both null-delimit your string and store its length somewhere. That’s the dangerous part. Messing either of those up, or passing your string to an API that messes that up, is not safe.

C strings are pointers to memory, either the stack or the heap, and follow exactly the same rules as everything else in that chaotic space: Not many.

I guess it’s nice for a C string API, but what’s the motivation to use and create this? Wouldn’t externing some C++ symbols (or Rust) work more smoothly?

When I began this project, I started with kqueue. The performance was wanting and there were bugs with very large file trees.

I moved to a minimal std::filesystem-based watcher and optimized it from there.

There hasn’t been a formal head-to-head test between the two. That should be about halfway down my todo list. It’s worth revisiting more formally.

My response to this question should help here: https://news.ycombinator.com/item?id=33247155#33251437

In short, there’s no secret sauce. There’s an efficiency spread in (what I consider) edge-cases.

Every potential gain over other naive watchers implemented with kqueue is likely algorithmic. I store events in a historical map, compare differences to the current state of the file tree, prune them, and send events when they change. That’s the whole implementation: scan paths, record their attributes, check for differences in the map, and send events when they happen. I haven’t given much thought to exactly why it beats kqueue, nor are there any good tests showing by how much. (Again, this is worth doing.)