Comment by blacktriangle | Hacker News Reader

Comment by blacktriangle | Hacker News Reader

Parent Full thread

I have the exact same reaction. You never want to shit on somebody's ambition, after all they might be a revolutionary, but at the same time the whole batteries-included thing is just setup to fail.

You have an embedded graph database? Why? This is just a symptom of developers general disrespect for the depth and complexity of databases. There's a reason we have so many different different databases, those differences are important and choosing the correct database can make whole reams of code you have to write disappear though the correct database's functionality. Not to mention despite the great expansion of NoSQL databases, the relational data model and associated algebra is one of the most powerful reusable abstractions for organizing information ever invented. Graph databases can do some awesome tricks but are ultimately reproducing the ad-hoc semantics of object graphs.

Same goes for anything that says "deploy over web and native at the same time!" That network hop between you and the browser is real. Every technology that has tried to shove HTTP down into the bowels of the system and pretend that you're writing local, non-networked apps has crashed and burned.

Lastly, I don't want my code to be robust. Fail-fast is good, fail at compile time is best. Robustness like this is nice for people who just want a one-off script to solve a problem but terrible for long-term maintenance of software. Large-scale anarchic systems like the internet require that level of robustness, but that's not how I want to write all of my software, I much prefer stronger contracts between components.

> You have an embedded graph database? Why? This is just a symptom of developers general disrespect for the depth and complexity of databases.

I disagree. This is a recognition of the fact that the line between database, programming language, and operating system is very blurry. It's not that the programming language has a graph database tacked on, it's that the language is a database and leverages that fact to provide features impossible or hard to come by in more conventional languages (e.g. transactional updates, time travel debugging, what-if scenarios, etc.). Still, nothing would prevent you from using whatever database you want in the usual way.

If you use an external database you are not going to get time travel debugging, nor will you have a perfectly uniform internal representation of values. Beads has a primitive type of physical units of measure, so you can store 3 Newtons which internally will be stored as the magnitude 3 plus an array of fundamental units with their exponents. This datatype is not found in MySQL, so external databases work okay as long as you aren't trying to time travel, and either limit yourself to very traditional COBOL era datatypes, or convert everything into string form like JSON has to do.

Beads also has addresses that can be written to the hard drive, because addresses in Beads are not pointers to RAM. How can you store a traditional C pointer into a MySQL database? You can't, you have use a key. which creates baggage.

The virtues of having a simple database inside the language, and a layout/drawing/event model are myriad, and I invite you folks to take it for a spin.

Some of the batteries-included integrated environments like VB6 and Borland Delphi are beloved by their users. Simplicity is wonderful, and i have tried so hard to make Beads simplify the very difficult task of making graphical interactive software.

I think I mentioned the time travelling debugger part of beads earlier. Having built a time travelling debugger a few years ago in clojurescript I immediately understood that this would be the killer feature of beads (for me at least). I do also realise that a lot of the comments here are attacking the author of beads or the initial presentation based on the website. This means that people either like a good flame war or that they need to dig further into the product, which is quite solid. Anyway fixing the home page of beads and the messaging of beads is probably one of easier things to fix , compared with making beads itself

The websites main video is a weird tangent about phones and desktops now both being 64bit. I don't think time travel debugging was even alluded to on the main page.

Developers do not have time to dig through every project's poor marketing in hopes of finding the motivation. The burden is on the project to sell developers, either quickly through explaining their killer features, or for more complicated projects by actually building something with their tools.

Yes I 100% agree. The author of Beads needs to fix the marketing message.

> This is just a symptom of developers general disrespect for the depth and complexity of databases.

The entire Beads project is a symptom of the developer's disrespect for the depth and complexity of every other programming tool in existence.

I take exception to that inflammatory comment. You have never met me, so how could you possibly know what I do and do not respect? The integration of the database is so i can deliver time travel debugging properly, which i believe will be a mainstream feature within 5 years in almost every language, as the productivity improvement is just too great to ignore.

Please refrain from personal attacks, and take Beads for a spin, and let the work speak for itself.

It has very few errors at this point, is quite usable, compiles very quickly, and makes a great web app that stretches like rubber. There are a few products like Beads, such as Elm, and Yazz Pilot (now called visual javascript). but they are all sufficiently different to be an interesting avenue of study.

Reply on news.ycombinator.com