cgenschwap

Hey HN! I had a fun idea a few months back of building a forum which was only an API that people could interact with. This way, everyone who wanted to participate would have to build something, almost as a forcing-function for having a community of only builders and hackers.

I decided to finally build it, and this is the MVP. There is still quite a bit of work to do, but at this point it is usable (albeit missing a few features which I'd like to add, such as voting, editing an deleting!). Let me know what you think! And of course, it is fully Open Source and I welcome any PRs.

You are right that maintaining documentation tends to be the sticking point. The main difference between a graph approach versus a tree approach is the _amount of effort_ required to maintain. If the documentation is incorrect in a tree-based system, say to the point where it is in the wrong place in the hierarchy, it requires a significant amount of effort to fix and maintain. In a graph-based approach it is easier to fix the areas that need to be fixed -- the maintenance burden is lower.

It is also easier to phase out certain documentation, but writing newer, more correct documentation and deprecating the old. Of course this is still possible with a tree-based solution, but there is more flexibility in a graph-based approach.

You're right the type system isn't really the solution for catching dead code. But compilers can easily check for this, if the language is restricted enough.

The issue with a lot of dynamic languages is things like monkey patching and reflection, which means that functions can be called at runtime but otherwise there is no way of checking beforehand.

Some people swear by this dynamic flexibility and the benefits it brings, but there are some serious downsides in terms of refactoring.

I admit I have a bias here, as I use Rust full-time, but Java, Python and Go are not what I would call languages that require less discipline. For instance, Go's error handling is entirely reliant on discipline! All of the meta-programming and runtime reflection nonsense requires discipline to not abuse and misuse. The worst codebases I have seen in Rust are significantly better than the worst codebases I have seen in languages like Java or Python, and maybe its because Rust programmers are more disciplined on average, or maybe its because the compiler requiring clean code forces less disciplined developers to produce better code.

Perhaps there are two camps here: (1) Reduce discipline by making developers no longer have to consider certain situations (garbage collection fits here) and (2) Reduce discipline by shifting that to the compiler (types fit in here)

I was at a company that switched from Redshift to Snowflake. It was a night and day difference. Faster (orders of magnitude!), cheaper, and significantly easier to work with (since everyone had their own personal view of the data to mutate/work with).

As far as I can tell, it is a unique product in the database space. Extremely well executed ideas and design.

I think you make a good point here, that the majority of software jobs could be classified as software technicians. I feel that designers have a slightly different role that I can't quite put my finger on. For instance, I feel that clay is a different concept from Python or breadboards -- since clay design usually only has the abstract function designed, and doesn't actually implement it (ie. it is not prototype functionality).

I think Python and breadboards are rapid-prototyping materials (possibly similar to 3D plastic printing?), but especially with breadboards, I've found EEs tend to forgo them entirely during prototyping phase since once you've learned a proper engineering tool it is _really_ hard to go back.

Certainly many advanced tools are a pain-in-the-ass due to poor UX, but there is also the idea that a complicated problem can only get so simple. To deal with complex problems -- which advanced tools should do -- they will need to have some level of complexity that needs to be learned.

Julia is an exciting language, but even there it has its own levels of complexity. A complex problem can only get so simple, and proper engineering tools expose this leftover complexity to the engineer. Whereas beginners tools tend to hide this.