I would seriously consider toning down the marketing speak. This project is making very bold claims, without citations, while trying to appeal to an often skeptical crowd (developers).
"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.
Honestly, i think graph db being more powerful is one of their more reasonable claims. Graph db trade off a more flexible data model (which some people would call power) against performance/scalability.
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)
Hi, I would like to chime in here on your comment on the marketing speak of the Beads project. I know the author of Beads, and was happy that he gave me a shoutout for my own project, Visual Javascript. Anyway, I have been following this new coding space for a while and I was also the initial angel investor for a project called Eve (the follow up for Light Table) which was an excellent project made by someone called Chris Granger (https://news.ycombinator.com/item?id=12817468). Anyway, I agree that the presentation of the Beads language could be improved massively, but the Beads language itself has some very interesting features, so should not be ignored. I think reading through all the comments on this hacker news thread it would be very useful to know what parts of Beads actually interest readers, and how they would present/market Beads themselves if it was their own project. This could be very constructive. For me personally it is the time travelling debugger that it interesting in Beads. What is it about Beads that you find interesting?
> I don't see how "special rules of arithmetic and a robust mathematical model" makes it "extremely difficult to have a serious malfunction."
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)
Beads is like VB6, and Oracle Delphi, an all-in-one language that shields you from the complexities of learning all these external tools and having to learn so many languages. To someone whom i guess a long-time developer, you might dismiss it as too simplistic for your purposes.
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.
It's very strange to me that the first pitch is that because desktops, laptops, and phones, are now all 64-bit, that is why we can now create a cross-platform language... that replaces scripting-ish languages.
I could understand if this was saying the 64-bit transition made things like Zig/Rust much simpler, but this seems like a non-sequitur for what Beads appears to be for.
I'm a little confused as well. A cross-platform language can work on any platform, like I can take my C++ code and run it on 64-bit or 32-bit, and this is true with plenty of other languages as well. I don't understand the relationship there at all.
Yeah color me skeptical. I love experiments, but I prefer those that under-promise and over-deliver. People have been promising unification languages since there were only two languages. People have been promising cross-platform since there were two platforms. And people have been promising to replace Excel since...Excel
The thing that really bothered me was the FizzBuzz example [0]. The core logic is:
cell
// this routine will be called 100 times, and the implied block variable
// b will hold values, like the sequence number b.cell_seq
var ss : str
case mod(b.cell_seq, 15)
| 0
ss = "FizzBuzz"
draw_rect(fill:LIGHT_SKY_BLUE)
| 3, 6, 9, 12
ss = "Fizz"
draw_rect(fill:LIGHT_GREEN)
| 5, 10
ss = "Buzz"
draw_rect(fill:YELLOW)
else
ss = to_str(b.cell_seq)
draw_rect(fill:ALICE_BLUE)
// we just set the string in the case statement above
draw_str(ss, size:0.7, color:BLACK)
// if this is the selected cell, highlight with a red frame
if b.cell_seq == my_state.selected
draw_rect(thick:3 pt, pos:0.7, color:CRIMSON, corner:2 pt)
The entire point of FizzBuzz, as a programming practice, is to ensure the programmer does not try to write this exact code: you check mod 3 and print Fizz, mod 5 and print Buzz. This "solution" makes me worry the language itself will impede the simple solutions.
Beads does not replace Excel, but it can close the gap between Excel and the popular programming languages, which have a great deal of unnecessary complexity in them. For example, in HTML/CSS/JS, the comment syntax varies between the 3 languages. Why are there 3 distinct languages in one source file? When in history was this ever done? I can remember mixing 2 languages, but 3? that's just ridiculous.
Code which doesn't execute has very few bugs in it in my experience. And those bugs tend to be easier to fix, than say a register clobberation bug in assembly language which i have had to wrestle with before. Telling the computer what to do, but not telling it how, does cut out a lot of effort (and potential errors).
You have every right to be skeptical, but i hope you can overcome your initial skepticism to at least take it for a test drive.
That one piqued my attention. It's one thing to say "fewer bugs" and quite another to say "almost none". Rust is a declarative language with one of the more rigorous static analysis checkers (for pedants: among mainstream languages) and I still write buggy code.
We need these kind of experiments. If you learn too much about contemporary software engineering, then it is almost certain that you'll end up with a React front-end talking to a NodeJS/Java back-end hosted on Kubernetes. Which is obviously the right thing most of the time :) but the world is richer because of these super-ambitious, super-naive experiments.
Also: imagine how much has someone learned from implementing all this.
Probably, but I think that's also a little dismissive. Maybe they have received plenty of feedback but still think their ideas take precedence over that feedback. I don't think we should confuse outside-the-box thinking with thinking that hasn't received feedback.
A lot of the authors verbiage is straight out of the 4GL talking points, so that's unsurprising. I agree it's probably a topic that is probably evergreen.
A lot of bold claims here. As someone who's worked on a lot of Excel business tools I can tell you there's no way something like this could replace anything in the companies I've worked for.
I think this project is really cool and am disappointed by so many of the negative sounding comments. They kind of remind me of the infamous Dropbox comment.
I think some healthy skepticism is fine but the mockery and out of hand dismissals seem like they should be beneath this crowd.
The marketing effort here feels so unbalanced. On the plus side, there's a marketing video with a professional sounding voiceover. But then there's a website titled "Beads Language Home Site", with a barebones design, and which talks repeatedly about "Macintosh" and "Windows OS".
"Some people, when confronted with a problem, think 'I know, I'll u̵s̵e̵ ̵r̵e̵g̵u̵l̵a̵r̵ ̵e̵x̵p̵r̵e̵s̵s̵i̵o̵n̵s̵ invent a new programming language that will unify everything.' Now they have two problems."
Funny you should mention Regular Expressions. In Beads there is a complete rewrite of the syntax for regular expressions, replacing the meta characters with a more readable vertical format that facilitates comments, and offers subroutines. For example, compare the IPv4 address regular expression as done in JS:
The Javascript version is extremely hard to read. I can't change the underlying engine that supports regular expressions as that is built in to the Browser runtime, but i can at least make notation friendlier.
Unified languages in the past like VB6 and Borland Delphi were beloved, and many people were productive in those environments, and clinged to them long after MS for example wanted to migrate people into .NET, because they were so much simpler.
The current complexity level that people have to endure is unnecessarily high. Never before in history did people write in 3 different languages in the same source code file (as they routinely do in JS + CSS + HTML), where they don't even agree on how comments are notated.
The current situation benefits the large incumbents like Google, Facebook and Amazon.
Not to mention not researching your problem space seems to be an afterthought for these types of people. It's not a novel problem or solution.
Haxe already exists [1] to unify everything, similar to beads' claims. It doesn't.
Unifying has been done better before with it, C (it does run almost everywhere!), Java, Flash/Flex, and JS+HTML. Many have entered. Few win for a little while, and eventually everything loses.
I don't have time to watch the video right now, but after skimming the language reference I get the impression that is is sort of a modern-ish take on the 4GLs from 80s/90s - not the sexiest thing but I feel like there's definitely room for something like this. Of course, the painful lesson of 4GLs was the consequences of vendor lock-in... I didn't see any links here to the sources.
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.
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.
Not even looking at the way the language and tool chain works, the home page is very confusing, with each following paragraph making almost no connection to others. What's worse, the YouTube video makes is mostly based on a fairly convoluted argumentation that doesn't seem to be logical to me.
If the page is supposed to draw attention of any fairly technical folks, it definitely needs some more thorough reasoning and argumentation to do so.
Rebol and is rebirth Red, is a very concise and powerful language. They are well funded, and will be a force to reckon with going forward. I would say the languages are very different in the sense that Beads is clearly aimed at graphical interactive software, with a layout/drawing/event model built into the language, while Red exists as a systems programming language, a variant customized for building crypto contracts, and then as a general purpose language.
They are so different that it is hard to compare. Red being a concatenative language has more in common with FORTH than Algol.
The closest thing to Beads is Elm, or visual javascript (was called Yazz)
(https://yazz.com/visifile/index.html), which is another integrated product.
This is kind of a cool project, and I have no doubt it is a good language for the type of programming the author surely does.
However, the design of the language feels like it's a imperative language with a few a few additional features (declarative solver) bolted on to facilitate sub-problems within its use case: well within the paradigm, but lacking real coherent design, or an innovation that would merit non-trivial adoption.
That said, I would be interested at pursuing the source code: it's an interesting hobby language.
It looks like a functional(ish) reactive programming language, with an embedded database, and an SDK for compiling to JS and cross-platform binaries. Do I have that right?
A few months ago, I watched some videos by Brett Victor and decided I wanted to develop a visual programming language. That led me to https://futureofcoding.org/ and its slack channel.
There was some cool stuff happening on the server, and the admin was doing his best to elevate things, but that slack channel was also the last stop for some people before they descended into templeOS levels of madness.
Right around the time I was joining, the admin posted in the meta channel that, with a heavy heart, he had finally banned [the developer of beads, I feel weird calling him out by name]. Apparently he had been too argumentative and stubborn for the server to further tolerate.
It left a weird taste in my mouth about the future of coding slack channel. On one hand, you don't want toxic people in your community. On the other hand, the server was clearly a channel of last resort for a lot of people with a lot of crazy ideas. Kicking out one if its more prominent members to toil in solitude felt kind of gross.
Its interesting to see that, a few months after being banned, the beads project seems to be materializing.
[+] [-] jasonshaev|4 years ago|reply
"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.
[+] [-] bawolff|4 years ago|reply
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)
[+] [-] zubairq|4 years ago|reply
[+] [-] ithkuil|4 years ago|reply
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)
[+] [-] magicmouse|4 years ago|reply
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.
[+] [-] Koshkin|4 years ago|reply
https://en.wikipedia.org/wiki/Weasel_word
[+] [-] danpalmer|4 years ago|reply
I could understand if this was saying the 64-bit transition made things like Zig/Rust much simpler, but this seems like a non-sequitur for what Beads appears to be for.
[+] [-] koprulusector|4 years ago|reply
EDIT: didn’t finish reading your comment when replying, but it’s telling we both used the phrase non-sequitur
[+] [-] jb1991|4 years ago|reply
[+] [-] kortex|4 years ago|reply
- promises to replace entire stack
- ...and Excel
- "declarative languages have almost no bugs"
- built-in database
Yeah color me skeptical. I love experiments, but I prefer those that under-promise and over-deliver. People have been promising unification languages since there were only two languages. People have been promising cross-platform since there were two platforms. And people have been promising to replace Excel since...Excel
[+] [-] discardable_dan|4 years ago|reply
0. https://github.com/magicmouse/beads-examples/blob/master/Exa...
[+] [-] magicmouse|4 years ago|reply
Code which doesn't execute has very few bugs in it in my experience. And those bugs tend to be easier to fix, than say a register clobberation bug in assembly language which i have had to wrestle with before. Telling the computer what to do, but not telling it how, does cut out a lot of effort (and potential errors).
You have every right to be skeptical, but i hope you can overcome your initial skepticism to at least take it for a test drive.
[+] [-] bawolff|4 years ago|reply
Is this even a declaritave language? Doesn't look like it to me at a glance.
[+] [-] throwaway894345|4 years ago|reply
That one piqued my attention. It's one thing to say "fewer bugs" and quite another to say "almost none". Rust is a declarative language with one of the more rigorous static analysis checkers (for pedants: among mainstream languages) and I still write buggy code.
[+] [-] jeroenvlek|4 years ago|reply
[+] [-] sz4kerto|4 years ago|reply
Also: imagine how much has someone learned from implementing all this.
[+] [-] daenz|4 years ago|reply
[+] [-] jb1991|4 years ago|reply
[+] [-] _ea1k|4 years ago|reply
But this is supposed to replace Excel somehow? Along with basically every other language.
I can't accuse them of not being ambitious.
[+] [-] OskarS|4 years ago|reply
[+] [-] JustSomeNobody|4 years ago|reply
[+] [-] js8|4 years ago|reply
I think this concept will be revisited from time to time in the future, although I agree with the skepticism about this particular project.
[+] [-] ska|4 years ago|reply
[+] [-] snoopen|4 years ago|reply
[+] [-] replwoacause|4 years ago|reply
I think some healthy skepticism is fine but the mockery and out of hand dismissals seem like they should be beneath this crowd.
[+] [-] danpalmer|4 years ago|reply
[+] [-] zellyn|4 years ago|reply
https://youtu.be/4WYxAfX_fTw
It's definitely… interesting.
[+] [-] bumbledraven|4 years ago|reply
[+] [-] vogon_laureate|4 years ago|reply
[+] [-] magicmouse|4 years ago|reply
``` (\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5]){3}| ```
with the Beads notation:
``` pattern octet group or digit // matches 0..9 set:'1-9' digit // matches 10 .. 99 '1' digit digit // matches 100 .. 199 '2' set:'0-4' digit // matches 200 .. 249 '25' set:'0-5' // matches 250 ..255
pattern IPv4 octet '.' octet '.' octet '.' octet ```
The Javascript version is extremely hard to read. I can't change the underlying engine that supports regular expressions as that is built in to the Browser runtime, but i can at least make notation friendlier.
Unified languages in the past like VB6 and Borland Delphi were beloved, and many people were productive in those environments, and clinged to them long after MS for example wanted to migrate people into .NET, because they were so much simpler.
The current complexity level that people have to endure is unnecessarily high. Never before in history did people write in 3 different languages in the same source code file (as they routinely do in JS + CSS + HTML), where they don't even agree on how comments are notated.
The current situation benefits the large incumbents like Google, Facebook and Amazon.
[+] [-] jackcviers3|4 years ago|reply
Haxe already exists [1] to unify everything, similar to beads' claims. It doesn't.
Unifying has been done better before with it, C (it does run almost everywhere!), Java, Flash/Flex, and JS+HTML. Many have entered. Few win for a little while, and eventually everything loses.
1. https://haxe.org/
[+] [-] chhickman|4 years ago|reply
[+] [-] megameter|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] nerpderp82|4 years ago|reply
We need more people doing projects like this.
[+] [-] toboche|4 years ago|reply
If the page is supposed to draw attention of any fairly technical folks, it definitely needs some more thorough reasoning and argumentation to do so.
[+] [-] tromp|4 years ago|reply
[1] https://en.wikipedia.org/wiki/Rebol
[2] https://en.wikipedia.org/wiki/Red_(programming_language)
[+] [-] magicmouse|4 years ago|reply
They are so different that it is hard to compare. Red being a concatenative language has more in common with FORTH than Algol.
The closest thing to Beads is Elm, or visual javascript (was called Yazz) (https://yazz.com/visifile/index.html), which is another integrated product.
[+] [-] larzang|4 years ago|reply
[+] [-] wespiser_2018|4 years ago|reply
However, the design of the language feels like it's a imperative language with a few a few additional features (declarative solver) bolted on to facilitate sub-problems within its use case: well within the paradigm, but lacking real coherent design, or an innovation that would merit non-trivial adoption.
That said, I would be interested at pursuing the source code: it's an interesting hobby language.
[+] [-] tofukid|4 years ago|reply
[+] [-] tavoe|4 years ago|reply
There was some cool stuff happening on the server, and the admin was doing his best to elevate things, but that slack channel was also the last stop for some people before they descended into templeOS levels of madness.
Right around the time I was joining, the admin posted in the meta channel that, with a heavy heart, he had finally banned [the developer of beads, I feel weird calling him out by name]. Apparently he had been too argumentative and stubborn for the server to further tolerate.
It left a weird taste in my mouth about the future of coding slack channel. On one hand, you don't want toxic people in your community. On the other hand, the server was clearly a channel of last resort for a lot of people with a lot of crazy ideas. Kicking out one if its more prominent members to toil in solitude felt kind of gross.
Its interesting to see that, a few months after being banned, the beads project seems to be materializing.
[+] [-] throwaway894345|4 years ago|reply