mkleczek

27 ms·

121.
by mkleczek 3y ago
What you are describing is a pipe dream of software reuse. People try to do it from the very beginning of IT industry with mixed results. The devil is in the details - your mixture of features is different than mine. We have constant upgrad
122.
by mkleczek 3y ago
It is difficult for me to dispute this as I don't think I am in any way entitled to define what problems are "meaningful". BTW - lack of an authority deciding what problems are meaningful is the core idea of capitalism. And I
123.
by mkleczek 3y ago
What I am trying to say is that even if computers are going to be able to solve todays database design problems (which I am sceptical of by itself) - we are going to have bigger/more capable databases and other problems that computers
124.
by mkleczek 3y ago
To be honest, now when I'm thinking about it - it seems to me Nix main weakness here is that it is a separate language and runtime. Writing a Maven plugin (ie. a reusable piece of configuration management logic) is easy because you can
125.
by mkleczek 3y ago
I don’t believe it will happen at all. There will always be some problems that only a human can solve because it’s a human that defines them. It is always _by definition_ a game between humans where computers are just tools. At least as lon
126.
by mkleczek 3y ago
Until a computer can solve the problem “how to redesign this particular database design (tables/partitioning/indexes/queries) so that it can handle expected load in next 5 years” I can safely assume it does not hold :)
127.
by mkleczek 3y ago
That would mean 95% of problems are already solved. I don’t agree with this - the space of problems to solve is as big as that of solutions (both are programs in the end). I don’t think suggestion about lack of experience deserves any respo
128.
by mkleczek 3y ago
I am quite confident my job is not in danger. Sure - scaffolding and boilerplate can be automated using ML - but problem solving - not at all. The reason is simple - to find a solution is to create a program that has a specific set of prope
129.
by mkleczek 3y ago
Indeed - that’s very often the case - the right balance between too many and too big is not easy to find. Having said that - Java is in general IDE targeted language and once you have an IDE - many small files is not an issue anymore.
130.
by mkleczek 3y ago
There are attempts like https://flake.parts/ or https://github.com/nix-community/flakelight Their aim is to create an ecosystem of reusable Nix libraries. But it is tiny.
131.
by mkleczek 3y ago
In Java/Maven ecosystem a lot of things is simple because there is a huge ecosystem of easy to integrate libraries/plugins. Want a packaged spring boot application? There is a plugin for that. Want to package it in a container ima
132.
by mkleczek 3y ago
Nothing got lost: both Nix and Maven are dependency management tools. Both are also build tools. The difference is that Maven was created as a Java build tool (and it stayed that way in general). What we have today is that there is a multit
133.
by mkleczek 3y ago
The question is if there actually _is_ a rich ecosystem of such libraries - similar to the rich ecosystem of Maven plugins.
134.
by mkleczek 3y ago
And what's the story with generic libraries that can later be used in your nix files to produce desired output? I am aware of flake-parts that are supposed to offer that but the ecosystem of flake-parts is on the smaller side of things
135.
by mkleczek 3y ago
Does Nix make it difficult to properly modularise nix files (flakes or not)? Because it certainly looks like the things you listed are separate/orthogonal and should be in separate modules/files. Having many years of Java experien
136.
by mkleczek 3y ago
> Often in the real world you need tree-like structures, which are fundamentally not able to be represented by a table/relation. No amount of joining can produce anything other than a table/relation. The n+1 problem is introduc
137.
by mkleczek 3y ago
To say it is light on details is to say nothing… But big claims require much more and the claims are huge (ie. It is a perfect DBMS)
138.
by mkleczek 3y ago
I’ve taken a brief look at the website and the GitHub repo. Could not find any description of the architecture, algorithms used, any references to research papers or anything like that. It does not build any confidence as the topic of distr
139.
by mkleczek 3y ago
IMHO the only really interesting alternative to Git currently is Pijul ( https://pijul.org ) as it is not a more-or-less Git clone but a different approach to the problem itself. Pijul allows for very interesting development and c
140.
by mkleczek 3y ago
> Apart from that, it looks like Java RMI allowed remote objects returning other remote objects, rather than only immutable values. Actually this is a very powerful concept as it allows one to achieve high level of reuse. Jini ( https:&#
141.
by mkleczek 3y ago
Let's be honest - deployment story with J2EE application servers was total mess and I still have nightmares. But you're right - today's world of YAML programming is no better. Nix and Guix are steps in the right direction (bu
142.
by mkleczek 3y ago
Mobile code and "agent systems" were very fashionable 20 years ago. Java introduced built-in RMI with automatic stub downloading. In 1998 Sun published https://en.wikipedia.org/wiki/Jini that was an extension
143.
by mkleczek 3y ago
I think it would be worth mentioning GraalVM and https://github.com/oracle/truffleruby in competitors section.
144.
by mkleczek 3y ago
What's old is new again but in new clothes. 20 something years ago "mobile objects" and "agent systems" were a thing and one of the practical incarnations was Jini: https://jan.newmarch.name/java&#x2
145.
by mkleczek 3y ago
> if you want to design classes for serialization that is agnostic to serialized format You mean XML/JSON/binary etc? This is impossible :) - the only thing that comes close is ASN.1. But serialisation can be easy: just don&#x2
146.
by mkleczek 3y ago
The premise of the sentence you cited is that it is necessary to call application code (constructors) to maintain security/integrity. What I am saying is that it is NOT necessary to implement secure serialisation and deserialisation be
147.
by mkleczek 3y ago
The point is that security and bypassing constructors are completely orthogonal as serialisation by memcpy is completely viable strategy and is no less secure than calling constructors on objects.
148.
by mkleczek 3y ago
This is really exciting and I hope to try it out at my company ASAP.
149.
by mkleczek 3y ago
Why? Zero copy state transfer is a viable and high performance alternative. Security and integrity can (should?) be implemented at a different layer.
150.
by mkleczek 3y ago
If by "an API" you mean "JSON sent over the network" then I don't really see too much of an advantage in: database -> server side program -> JSON -> network -> client side program -> HTML -> browse

More ›