Recent submissions

Comment · 7 days ago
My main project is trying not to lose my mind, given all the things I can now create thanks to AI.

Jokes aside (although I'm not entirely joking about my mental health), my main project is https://auradistill.com: First-principles thinking for your AI agents.

It's not just about giving your personal AI agents "memory". It's about encoding memories in a way that can handle ambiguity and contradictions.

That project alone has got me completely hooked on building for and with LLMs.

I've got other projects too, but this is probably the one I've poured the most time and energy into.

Comment · 1 month ago
Approach: Build real SwiftUI interfaces and iterate on them visually until you achieve a near pixel-perfect result.

I’m not an expert in React or Vue, but we also set up the repo with components for both.

Comment · 1 year ago
Java is an amazing language, but about 4 years ago I moved to Kotlin (back-end): It has all the powerful Java features but it is way simpler to write and also nullability is embedded in the language (no more @NonNull @NotNull Optional<T> stuff). You might find a balance: the power of the JVM and its ecosystem that you can access through a beautiful language that is Kotlin.
Comment · 1 year ago
I see a mismatch between the library API `filter` vs the supported operator `| SORT rating desc"`. You could use the API to your advantage by separating concerns: add a new `.sort("fieldName")` method.

``` const recentGoodMovies = filterql .filter(movies, "year >= 2008") .sort("rating") .desc()

```

If adding helper methods for semantics and clarity is not the intent of the library, then I'd rename the `filter` method since it doesn't communicate the intention clearly.

The function executes a full pipeline filter expression + `|` operations like `SORT` and `LIMIT` (not just a predicate filter). So for instance naming it to `query` will match your README terminology and grammar (`query := filter | operation*`)

Comment · 2 years ago
It is indeed annoying. For Kotlin, its advantage is that it had the nullability concept from its inception. For Java, they need to make sure previous code behaviour does not change, meaning that they need to add an additional marker to the explicitly mark "not null" types.

Probably in some years from now once codebases exclusively use this feature, there would be a way to tell the compiler that the default type (without marker) it is a non-nullable type.

Comment · 4 years ago
The first thing they taught me in programming in uni was: "Divide and conquer". It took me some time to truly understand what that meant in terms of programming. I remember that when starting a software project, I always started to feel very anxious if I was unable to picture the WHOLE program in my head; after some time I understood that by dividing it into smaller problems, and solving each one of them one at the time (without thinking at all in the other parts), things will eventually be connected and work, like magic. By truly adopting this basic paradigm you start to think naturally about interfaces to connect these smaller parts of your program, and from there things just flow.
Comment · 4 years ago
I used to work for a mobile analytics company, and HLL made things SO much easier and fast that at the time we changed all our queries to be based on HLL. At the time, the ability of being able to sum uniques was like black magic, and still to this day I am quite impressed about HyperLogLog.
Comment · 5 years ago
Comment · 5 years ago
I also feel this effort is completely pointless. Java for instance has 52 reserved words. 52!!! the complexity of programming does not lie in the meaning of just 52 english words. That's actually the easiest part. As you get better you eventually will pick a production-ready language such as JavaScript or Kotlin, only to realise that you now have to learn the meaning of the words...
Comment · 5 years ago
If I were a mobile phone manufacturing company, I won't call 30% of European market a "tiny portion".
Comment · 5 years ago
Comment · 5 years ago
Absolutely. Think about iOS or Android (native) development. Sure, the ecosystem is quite big, however you do not have the level of flexibility that the web has. You are limited not only in terms of languages, but also certain architectural decisions are bounded by the limits imposed by Framework (the Android or iOS SDK), so there are many decisions that _are already taken_, and for better or worse you have to live with it.

That is probably what I hate the most of front-end development compared with back-end or Mobile. There are too many options, and that certainly does not promote consistency within the project.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton