Whether or not that's a good trade off in your domain is a very different question.
Edit: although based on the docs, the graph db seems roughly a data structure where nodes can point to each other (i dont see anything about complex queries, or managing concurrency, or even persistence). By that definition, i think even c would be a language with an embedded graph db (structs and pointers)
In a graphical programming environment one is really listing and drawing the content for editing, versus making a list of something.
You can send subtrees across the wire conveniently, subscribe to a remote machine's subtree, etc. and you can write to the hard drive the trees.
However concurrency is not really present in the system as i am emitting JS which is a single threaded system for the most part. So Beads has almost zero concurrency support at present.
You can represent graphs in the relational model so that’s simply bullshit.
For certain types of queries, recommendation engines being a prime example, graph databases are awesome.
In any case you’re conflating a storage engine and a query language. There’s no reason an RDBMS implementation cannot be tuned for graphs, and there is no inherent lack of generality in the relational model which seems to be the prior posters claim. Whether Neo4j is a useful piece of software is a different topic.
Infinite self-joins are not elegant in relational algebra. They are very not elegant in SQL (recursive CTE's are soo ugly). Last of all, they are super inefficient in almost every RDBMS.
Somewhat ironic comment given the name of this site.
SQL stinks as a language in many ways, won’t argue there. However for many cases even PostgreSQL does just fine with recursive CTEs (though granted when it fails it does so hard). Oracle does better (and CONNECT BY has been around for over 40 years - someone’s been getting by with it). Graphs in RDBMSes are not uncommon.
Anyway, none of this has anything to do with the original claim. Are graph db implementations useful? Definitely (though often times sticking with the rdbms is the better choice). But they get their utility by being less flexible.
Regarding Beads: time travel is definitely a cool feature. Most languages have some kind of step debugger but the experience can often be improved. Having a built in graph DB could be an interesting selling point too. I'd love to see a quick example of what having a graph DB built into the language enables. For instance, this post https://news.ycombinator.com/item?id=27315018 cites a Neo4j demo that, in a few lines of code, shows me something their product does "better" than SQL. I would love to see, on the Beads front page, a small (5 lines max?) code blurb that shows me something Beads can do harder, better, faster, stronger (or whatever ;) ) than other languages. I don't quite know what that is, but I imagine the author has some thoughts :).
Happy to connect more if you'd like.
The only way would be to have arbitrary precision integers by default and thus no overflows ever. (IIRC smalltalk was something like that, but it was long time ago since I used it, so I'm not sure)
>>>(100000000000000000000000000000000000000000000000000/2+1) % 2 == 0
True
if you want to get an integer you have to use the relatively recent "//" operator:
>>> (100000000000000000000000000000000000000000000000000//2+1) % 2 == 1
True
in smalltalk you'd get a Rational or something like that.
Scheme is a bit interesting in that they have a "numeric tower", which contains rationals and even complex numbers (implementations were free to implement a subset of this tower, at least as far as R5RS, not sure today)
[1] https://en.wikipedia.org/wiki/List_of_arbitrary-precision_ar...
Null pointers are something that plagues Java, which are primarily caused by having some computation out of sequence. By using the State-Action-Model pattern, most of Beads code will be devoted to rendering the model on the screen, and that one-way transfer of information can be made very robust, provided you have a closed arithmetic, which it does.
In Rust, you can configure Clippy to ban the usage of +-*/ and require explicit behavior of each calculation. For example, 10u8.checked_add(10) returns an Option<> (similar to Maybe in Haskell) so you can handle overflows. You can also use 1u8.saturating_sub(100) which will not allow wraparound but values will saturate at the max/min.
For example you can skip using Unix Bash and use Beads like Python as a scripting language. You can build a very nice client/server product like the "Robin Hoody" app, using the publish/subscribe functions built into the language without ever learning how to encode/decode a packet, as the runtime makes it easy to do this. So in that sense the language does offer a virtual transport layer.
Sure, you may need to drop down and encode/decode a websocket message buffer, but the point of Beads is to permit writing in a single language, without having to learn CSS and the whole pile of complexity that accompanies modern development. You can't make an easier stock quoting system (one of the examples), because it has been reduced to the absolute minimum number of lines.
The protected arithmetic of Excel is of proven utility, and i am merely imitating it. I replace #UNDEF with U, and #ERROR with ERR to make it less verbose, but protections abound in Beads both at compile time, and at runtime. In a graph database universe, you don't need scalars, tuples, lists, dictionaries, queues, hashmaps, etc., because a single more general data structure accomplishes that you need.
Graph databases are quite hot; Neo4J has grown leaps and bounds, and Oracle was forced to come out with one. I am sure that most existing systems continue to use older tech, because that is always how it goes in computers. People are still running COBOL in some places, because it is so damn fast and works perfectly at what it was built to do. I have no doubt that we will see existing tech which works fine continue to be used for another 50 years.
It makes sense to make an easier environment that is still capable, but much simpler to learn and use, and that is the goal of Beads.
As for the skepticism of crowds, my product is out there, and has no major bugs in it, and hopefully will find an audience that likes this approach.
Your comment clarifies that you aren't claiming to replace UNIX but that you can use Beads as a general scripting language. Consider updating the big graphic on the front page that says UNIX to Say Bash (sh, zsh or whatever).
Lastly, your response is selling me on graph databases, but I never objected to graph databases as a technology, just your bold statement about them with no caveats or citations. Saying, "graph databases are considered more powerful and modern than relational databases..." is a good way to start a flame war but not a good way to convince someone to use your product.
All that being said, best of luck with your project! I do mean that sincerely.
These two statements are in no way equivalent.
I see what GP was complaining about. Even your opening para graph contains a fair bit of confusion. It reads like you are suggesting imperative languages were succeeded by object oriented, which were succeeded by functional in 'generations' - which is already incorrect on a couple of fundamental levels - and now the time is "ripe" for a "new paradigm" called declarative. Which is a language classification that has been around since nearly the beginning (first thing it makes me think of is Prolog, e.g. 1970s). So is this new or old?
This followed by a couple of pretty silly sounding assertions "almost no bugs" "10:1 reduction in life-cycle costs" which unsurprisingly are not supported.
Then we have the last sentence "For many graphical interactive or client/server applications, you can replace the entire development stack with one relatively simple tool.". Isn't that what you really want to convey?
When you get off on the wrong foot like that it's not hard to see why you've had some of the responses you have had. If you replaced the entire first paragraph with that last sentence you'd be far better off; the rest is poor communication, just getting in your own way.
COBOL generated a lot of billable hours. I did early years in my career as a consultant-for-hire in a SF body shop, and occasionally would have to fix some COBOL thing. I sure hated it. Woke up one day in a puddle of drool from passing out because of boredom, and then switched jobs.
Beads is from a word-count metric, is probably within 20% of the minimum word count for the sample programs i presented, if you exclude techniques that greatly obfuscate the logic such as those used in Oscar Toledo's famous chess program.
Substitution and concatenative languages like FORTH regularly win code-length contests, but they aren't very readable. Beads tries to find a happy medium between brevity and clarity. I think people writing it will enjoy the careful balance that was struck.
You're fixing the garbage-in, garbage-out problem? Have you also invented strong AI and solved the halting problem?
Edit: you should replace your website with the first page of your language reference pdf. That's a better pitch and more interesting than anything you've written here.
"Graph databases are considered more powerful and modern than relational databases," ... okay? According to what benchmark and for what workloads? A statement like that is an immediate turnoff because it is dismissive of 30 years of database development.
"In many languages the slightest error in input data can cause a program to seriously malfunction. Beads has special rules of arithmetic and a robust mathematical model, that makes it extremely difficult to have a serious malfunction." I don't see how "special rules of arithmetic and a robust mathematical model" makes it "extremely difficult to have a serious malfunction."
Replacing "Unix, SQL, Rails, Ruby, RSpec, Templates, HTTP, HTML, CSS, DOM, jQuery and Javascript" in one language? How does this replace Unix? HTTP? It's not an operating system or a transport layer.
My goal isn't to crush someones idea, but consider your audience: developers.