3 ms·

I like it, but also recoil at the thought of using it. And I think that's a "professional programmer's instinct" talking, saying that I shouldn't settle for thi

I like it, but also recoil at the thought of using it. And I think that's a "professional programmer's instinct" talking, saying that I shouldn't settle for this one large dependency that boasts about being the future and has made room for so many little batteries-included features, I should be a big boy and use the most powerful library for every task...in JavaScript, a language that was, mind, designed in a few days and now has an ecosystem built on untrusted third-parties all depending on each other - a state of affairs that has already been demonstrated to fail. If I were primarily an Excel user, then maybe it would work for me. Working with figures, converting between common units, generating reports and forms, and doing it in a form that acknowledges programming other than "ALGOL derivative"...There is a known niche. Maybe the author knows the niche better than I. There are good ideas here, ideas I want to steal. That is enough to recommend giving it a further look.

blacktriangle 5y ago
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.
- ModernMech 5y ago
  > 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.
  - magicmouse 5y ago
    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.
    - zubairq 5y ago
      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

blacktriangle 5y ago

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.

ModernMech 5y ago
> 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.
- magicmouse 5y ago
  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.
  - zubairq 5y ago
    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