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.
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.
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*`)
Hmm, maybe I need to think about this more, but since operations are a language feature (and could have any name, see custom operations), I don't think they could be attached to the filterql class like that.
You're right though, the naming of the `filter` method is confusing. I need to split off the filtering and applying of operations into two separate methods. And probably provide an additional `query` method like you said which would do what `filter` is doing now. Appreciate the feedback!
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.
"Our colleague Alex Buckley, specification lead for the Java language and JVM, likes to say that one of the surprising things is that Java managed to get all the defaults wrong and still succeed"
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.
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.
I'll strongly suggest changing the approach from character input to phonetic input like the stenotype machines.
Creating a nice set of rules prioritising writing speed is of course no easy task, however I think it is the only viable way in my opinion to make it usable.
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...
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.
