Beads: Computer language and toolchain
beadslang.org
beadslang.org
"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.
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.
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.
EDIT: didn’t finish reading your comment when replying, but it’s telling we both used the phrase non-sequitur
- 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
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.0. https://github.com/magicmouse/beads-examples/blob/master/Exa...
No, the point of FizzBuzz, which is an interview practice is to make sure that the candidate has literally the minimum ability to translate a natural-language problem description into code.
There is no point using it for anything else. Not demos of languages or tools, not looking for a particular shape of solution, you don't even really need to let them finish writing a bug-free version of it. It is only to filter out the people who "learned a language" but cannot actually write a program. Which is unfortunately a ton of people.
https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de...
nums = list(range(100))
def fizzbuzz(n):
if n % 15 == 0:
return "FizzBuzz"
elif n % 3 == 0:
return "Fizz"
elif n % 5 == 0:
return "Buzz"
else:
return str(n)
print(" ".join(map(fizzbuzz, nums)))
I think it's far better than: nums = list(range(100))
for num in nums:
if num % 3 == 0:
print("Fizz", end="")
if num % 5 == 0:
print("Buzz", end="")
if num % 3 != 0 and num % 5 != 0:
print(num, end="")
print(" ")
EDIT: Formatting, typo input is n
| 3 divides n | 5 divides n | result |
|—————————————|—————————————|————————————|
| Yes | Yes | “FizzBuzz” |
| Yes | No | “Fizz” |
| No | Yes | “Buzz” |
| No | No | n.toString |
print result
The key points are:1. The logic is declarative: the order of the rows in the table doesn’t matter.
2. It tests for divisibility in words rather than a potentially confusing idiom (how does % behave for negative numbers? Is it defined for floats in this language?)
3. The structure allows you (or a compiler) to check that no case is missed.
4. It should be easier to convince oneself that modifications to the code do what they are supposed to.
The funny thing is that looking things up in tables is much more common in excel.
Not printing in the middle, return a string and afterwards print it.
Each step adds to the string, and if it's still empty by the end you just put the number in.
The next stages are often to add another number, then something more complex (if it's a prime number). As you do this, the concatenation version grows slowly while the first approach explodes in combinations.
I agree with your thoughts around the language constraints, but I see more room for what you once could have gotten from using FizzBuzz as a minimum-skill filter. It depends on the level you're hiring at.
From a novice engineer I would be content if they're demonstrating awareness that multiples of 15 represent an edge case without it being included in the instructions.
If I'm hiring someone more senior, I'd expect them to provide (or iterate to) a more optimized solution to FizzBuzz.
But in a further tangent - I think this using this type of question as a minimum-talent filter stopped becoming viable as soon as it became commonly used. In the time since, it's become more a minimum-knowledge filter -- and that doesn't tell you anything about the candidate's methods in solving a problem with derivable requirements.
You could express it also as an empty string, then concatenating as necessary: ''' // to those objecting to using a modulo-15 test, // we could have done the above code as follows: var ss = "" if mod(b.cell_seq, 3) == 0 "Fizz" &=> ss if mod(b.cell_seq, 5) == 0 "Buzz" &=> ss if ss == "" ss = to_str(b.cell_seq) '''
The problem with FizzBuzz as a programming language exploration is that it is far too short of a program to reveal the totality of a language, since it only consists of using the if/pattern match capability, modulo function, concatenating strings, and converting an integer to a string. The Stock market ticker program is a much better demo of the language, because it shows how to do client/server programming in a very easy way.
And as others mentioned, Fizzbuzz is merely a "can you program anything test." But I do prefer the "general" fizzbuzzjazz, which accepts a list of numbers and a list of words [fizz, buzz, jazz,...] and emits the strings for appropriate prime factors.
My preference is to have all behaviours be explicit in the declared code, rather than implicit or as a side-effect. Much simpler to read and reason about the program.
Clarity over cleverness. To that end, I prefer this version over 'hiding' the mod 15 case for the sake of saving a line of code.
I also appreciate languages that warn (or better, require) that all cases are covered.
if x % 3 == 0:
print("Fizz")
if x % 5 == 0:
print("Buzz")
if x % 3 != 0 and x % 5 != 0:
print(x)
print("\n")
i.e. no special "FizzBuzz" case for when it's divisible by 15, it just naturally falls out of the first two if's. It's a bit of a silly objection though, the it's fine to write it as the author did. print("Fizz", end="")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.
Is this even a declaritave language? Doesn't look like it to me at a glance.
But the nicest feature, invisible in the syntax because it is a property of the runtime under the hood, is that when you change your mutable state, any layout that used those variables is automatically scheduled for refresh. You thus declare what is on the screen, and how it is arrange, and the system knows what to do. In this sense it more like SQL, where you give it a goal, and don't specify the ordering of how to achieve the task.
There are also mini-solvers built into the language for the common tasks of solving for rectangles and points, which are quite handy.
Please take it for a spin, you might like it!
If the main facilities for writing logic in the language are procedural, than i'd call that a procedural language.
1) Changes are triggered through regular mutation, not special API calls
2) Reactive dependencies are automatically determined
The combination of these two traits is somewhat unique, and is offered by MobX and (apparently) Beads.
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.
Certain classes might be more or less likely, but no paradigm is magic and stops all bugs.
Also: imagine how much has someone learned from implementing all this.
The world isn't richer if you listen to feedback quite the opposite it makes you improve what you are making.
I agree about the learning aspect but overhyping something doesn't really pan out that well.
This kind of thing is why I'm so grateful to the founders of startups like Starsky, who are obviously still immensely passionate about the domain they were in. That even in the wake of the company failing, they've continued to advance the state of the art by sharing what they learned, especially where it's wisdom that goes against the current dogma (eg, that teleop is a hugely important part of a self-driving vehicle strategy, but that investors of the late 2010s were turned off by that focus because they wanted to see companies trying to shoot the moon on L4/L5 autonomy): https://medium.com/starsky-robotics-blog/the-end-of-starsky-...
But it gave me a new perspective and at times it was really fun learning so much. I think it has made me a better developer because I made so many complicated mistakes and now I can simplify things.
The author used to at least actively solicit feedback, I never once noticed acknowledgement of any of it though.
User suggestions and bug reports are promptly followed up on. There are almost no known errors at this point, so it is very good shape.
You are correct that it has elements of JavaScript, but that is inevitable given that the primary output of the transpiler is JS code for use on the web, so some JS functions have to be present for that to work, and to inter-operate with JS, one has to use their string system.
The attempt to offer an integrated programming system, where we return to the simplicity of VB6, or Borland Delphi, is actually quite ambitious, as in order to offer such an integrated product one has to build in a database (graph in this case), a layout engine (novel, Renaissance proportion based layout model), a drawing system, and a way of coordinating between client/server (a novel subscription to a single source of truth system, with remote procedure calls).
The language is primarily based on Modula-2, which the author of Beads used for 20 years quite successfully in large commercial products. There is nothing from COBOL or Ada that i can think of (although Prof. Wirth did contribute to Ada I believe), not sure what the M language is. There are some elements of PROLOG built in that are not readily apparent, as the core programming pattern is State-Action-Model (see sam.js.org), and if you change a state variable, then any drawing code that used that variable is scheduled for refresh.
I don't see why this is true (i also don't see it as a bad thing. Take what works and all that).
Beads is a fun an interesting project, but the over the top marketing language and hype is a bit silly. The author really is a rare mix of driven PL engineer and overly grandiose personally.
But this is supposed to replace Excel somehow? Along with basically every other language.
I can't accuse them of not being ambitious.
// this shows a persistent value FizzBuzz grid
// whatever cell you pick is remembered for a month
Wait, what?Classic FizzBuzz is just too simple a task to show off any language features, so the task was souped up so that it draws a 10x10 grid of the results, and lets you pick one of the 100 cells to highlight.
It persists this selection for a day to show how one can save up to 1kb of state information trivially inside the browser's cookie system, which is simpler to use than the IndexDB database (which is also available to use if you wish).
1Kb is enough to store a reasonable amount of data, and since Beads has a built-in graph database (not as fancy as Neo4J), you can store a subtree into the cookie with one line, and no encoding/decoding necessary, as that is performed by the runtime library for you (a nicety).
The convenience of working with a graph database internally, instead of the typical collection of data structures that one sees in older languages such as scalars, tuples, lists, dictionaries, queues, and pointers, is an advantage that only becomes apparent after some use of the language; i encourage you to take it for a spin.
var ss = ""
var color = ALICE_BLUE
loop across:WORDS index:wordx
if mod(b.cell_seq, PRIMES[wordx]) == 0
WORDS[wordx] &=> ss
color = COLORS[wordx]
if ss == ""
// plain cell
ss = to_str(b.cell_seq)Most of the older popular languages like C, C++, Java, have huge external libraries you have to learn to make graphical interactive software.
So for the target application area, which is graphical interactive software, Beads is far simpler, and has many features to avoid error at compile time, and keep running with fault tolerance at execution time.
I think this concept will be revisited from time to time in the future, although I agree with the skepticism about this particular project.
I think some healthy skepticism is fine but the mockery and out of hand dismissals seem like they should be beneath this crowd.
Still, there are others in this thread who should be ashamed of themselves. We have people implying the author is childish, outright calling him disrespectful, calling his project a joke and a parody... it's all really quite sad. I mean, here you have a guy who has put years of work into a project, who embodies the hacker ethos, and a community of self-described hackers can't push past his lack of marketing ability to engage with the technical merits of this diamond in the rough. Set the marketing on the main page aside, and you have a 136 page technical reference (linked helpfully on the front page) that contains a lot of great info. Yet the closest anyone came to engaging with it here was to complain that it's a PDF.
I think this twitter thread had it right about the community here: https://twitter.com/rikarends/status/1382759991162068995
Which baffles me to some degree. You'd think this community, of all communities, would be welcoming and inquisitive when confronted with strange new ideas, despite bad marketing. The community is not just technically focused, but built around a startup incubator whose founder warned of this exact dynamic! And yet all we seem to get is superficial discussion related to marketing.
Rik sounds like somebody who applies for 100 jobs and complains why companies never give him feedback without realizing that each of those jobs is getting 100s of applications and replying to them all is not remotely possible.
Then further, his market is developers who have been around awhile and seen some shit. This is an industry where everything old is new again; the reason people have a knee-jerk reaction to projects like Beads and Makepad is because we've seen things that look similar, probably used them ourselves, and been burned by them. People working on projects like this, when they are marketing to experienced developers, should try and place the project in the context of the history of similar projects and explain why this time they have it right.
Lastly, it doesn't matter if your project is asking for money or asking for developer attention, insulting your target market is never the right play. Startups spend massive energy honing and refining their marketing message, they don't expect potential customers to just magically get-it. Projects who want developer attention should view their marketing with the same importance. And if a project, just like a product, does not take their marketing seriously, I'm less inclined to take them seriously unless they are very clearly and obviously solving one of my immediate problems at which point I don't care if their marketing is a plain text document.
So that video is just part of 1 of 15 parts, and with some support and enthusiasm from people, we can continue the series, because it is o much nicer to watch a professional video with proper British narration. As the great George Bernard Shaw once said, "The United States and Great Britain are two countries separated by a common language."
I hope that people will overlook the homwbrew quality level of the videos, but the language for a spin, because you might like the language a lot. It has a lot of simplifications, and particularly for client/server web apps, where it is much easier to build reliable products.
Marketing: do a song & dance then pick style.
Engineering: just pick substance and get on with it!
It's definitely… interesting.
``` (\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.
People dont usually put them all in the same file. Html and css are mostly not even programming languages. And shell scripts commonly have sed or awk embedded in them.
I'm not saying that a more unified approach is bad, on the contrary there's pros and cons, but you're being a bit hyperbolic about it. Nothing about the current situation is that new or unique. Nor is proposing a more consistent environment new either. Computer world has been going back and forwards on this since forever.
"Group or digit" matches 0-9?
I dont think it helps that you're missing newlines. Try putting four spaces at the start of every line.
JS style: (\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}
Beads style:
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
As you can see the Beads pattern notation allow subroutines, uses keywords like 'digit' instead of \d, and is far more readable. There are plenty of examples, and the more complex the expression the more favorable the comparison.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.
My measurement of complexity includes both the syntax of the language, and also how many library API's you have to learn.
Haxe, which has roots in an open source version of Adobe's ActionScript is an excellent product. I often consider switching to Haxe for the implementation of the transpiler as it would yield Linux support. I currently emit AS3 or JS code, but Haxe is a very strong possible direction in the future as Haxe has a lot of portability.
I don't consider C a unified language. It had no database, no drawing model, no event model, and Berkeley Sockets was a library added in to support the internet, that unfortunately did not achieve complete standardization. C is the most portable language, but it just a step above Assembler, and full of pitfalls.
Tools do wax and wane in popularity; they are all useful in certain circumstances, and the more generally useful the tool, the more it gets used. VB6 was abandoned by its owner MS, when Gates retired (Basic was his pet project, as it was the original foundation product of MS' fortune). People used it as long as they could (and some still do). VB6 didn't make the jump to the Internet, but it could have if MS hadn't tried to force everyone into .NET (which was very complex).
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.
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.
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.
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.
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.
The entire Beads project is a symptom of the developer's disrespect for the depth and complexity of every other programming tool in existence.
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.
We need more people doing projects like this.
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.
[1] https://en.wikipedia.org/wiki/Rebol
[2] https://en.wikipedia.org/wiki/Red_(programming_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.
Rebol Technologies went bankrupt, and Rebol is de-facto dead since more than a decade; Red barely manages to get by thanks to a recent crypto spike.
> I would say the languages are very different in the sense that Beads is clearly aimed at graphical interactive software.
So is Red with it's native GUI engine. [1]
> Red exists as a systems programming language, a variant customized for building crypto contracts, and then as a general purpose language.
"Domain-specific languages" is the term you are looking for.
> They are so different that it is hard to compare.
Both share the same goal of replacing modern software practices with biased, batteries-included toolchain, varying only in implementation.
> Red being a concatenative language has more in common with FORTH than Algol.
Red is not concatenative in any sense of the word, nor any other language in Rebol family that I know of.
Red is the best funded language that i know of. Nenad did an initial coin offering (ICO) that was successful, and by my estimates will never have to work again. He has a good-sized team, and is building a very powerful product. Don't confuse his frugality with the financial independence he possesses due to his good timing at jumping onto the crypto bandwagon.
I don't know how you describe Rebol/Red. It a language made out of various subdomain specific languages, with a very unique syntax. It is very brief, and to me looking at it from a distance it more resembles FORTH or Postscript than any Algol derivative language.
Red has not prioritized graphical interactive products. I think its best subsystem is its amazing PARSE module, which is second only to Icon in text processing power.
There are other interesting projects like Enso, but they will probably run out of money, but i will wager Red will still be going strong 10 years from now.
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.
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.
To me, who has been in that community for years, it was entirely the correct action to take. Moderation is hard and no fun at all, but it needs to be done, or else a community will descend into madness.
The community didn't vote on it, Ivan exercised his power, because has a personal dislike for me. I met a few nice people on that discord group, but didn't enjoy being followed around by word police.
I don't know what you mean by a step backwards. This a batteries-included environment like VB6 and Borland Delphi, but emits to the current web app universe we live in, so it is definitely in the now.
In any event I engaged with the creator before and what I can say is the conversations are entirely one-sided, in fact some of the most I have personally experienced. Will take one or two words from your post or reply, briefly mention it and then go completely off on a tangent only concretely related to those words. I’ve never known them to become outright offended or insulted and yet are completely impervious to any feedback. The upshot is, this will greatly limit a widespread following, because not all their tastes are exactly mainstream.
And, really, that's the only kind of person that could make something of this encompassing but simultaneously incoherent nature, I think.
What indoctrination are you referring exactly? I don't understand the motivation for personal attacks on the author of a product you haven't even tried yet.
For those people who would prefer not to have to waste 100 hours of their time mastering CSS, the 10 hours it takes to learn Beads might be a better bargain.
I don't know how old he is, but there's enough grey hair there to know he's seen his share of things.
Waaay in over our heads.
Since then, I’ve realised it’s been tried and is being tried an inordinate number of times and seems to usually fail for some reason or another.
Kind of a wild goose chase for some (supposed) holy grail.
That describes the state of things before every innovation in history.
We both came out of it convinced that there had to be a way to make it much easier yet still as powerful to orchestrate logic & services…
The goal was to make something we could use to drastically simplify the development of all our future endeavours, thinking we might also be able to sell it to others.
Little did we know how naive we were ^^’
Edit: Nevermind Beads only works on Windows and Mac, It needs Wine to work on Linux.
The home page doesn't do a good job at explaining what its about and why I should care. I then looked at the sample code and I still don't think I get it.
> The next generation of languages is now possible: Declarative languages,
Ok, but declarative languages have existed for a looong time too.
But any day now the dam will break, and WebAssembly will get access to I/O and the full browser API (last time i checked web assembly runs on its own compute-only thread, and is not permitted direct access)
Portable generic VM (like the jvm but for anything), sure why not.
Having web browsers allow arbitrary access to hard disk? That's something else.
The index.beads and (I think!) corresponding index.html files are... quite something. I'm not 100% sure this will catch on.
The calculator example here makes rather more sense to me: https://github.com/magicmouse/beads-examples/blob/master/Exa...
Afaict its features are:
* a string matching DSL that the author thinks is more readable than regex (but what isn't more readable?)
* a very basic graph db
* a syntax that's more Algol like than c (matter of personal taste i guess)
*a declarative layout engine with strong reactivity support
*combining both the server and client side in one lang.
* support for a time travelling debugger
But its totally overshadowed by the utterly bizarre or dare I say "batshit", marketing material.
Beads is targeting web apps, mobile and desktop graphical applications.
You didn't mention time travel debugging, even on software running on remote customer machines. That's a neat idea.
I would describe the syntax as a mixture of Python and Modula2, which both contributed major features. But has deductive elements as well, which can be traced back to PROLOG.
There are also physical units of measurement such as 3 Newtons * 4 seconds / 3 meter * 2 ergs / 12 kg. I followed the spec from Van Snyder at JPL, who asked the FORTRAN committee to add it decades ago. Only Frink has a stronger unit system.
There are about 70 new things in Beads all told.
I hope that people take it for a spin. If people aren't willing to try new things, how are we going to move forward? You can learn the entire Beads product from soup to nuts in less time than to get half way through a CSS book. Simplicity is a virtue, and thankfully Beads has zero category theory, with no Functors and Monads or Java method factories, etc.
NASA lost the Mars Climate Orbiter due to a confusion of values being in feet or meters. https://www.simscale.com/blog/2017/12/nasa-mars-climate-orbi...
That is exactly the sort of mistake that the support for physical measurements mitigates.
There probably never will be a programming language that pleases all the syntax camps and all the semantics camps. Why not just use macro-assembler? It is the purest language that isn't binary machine code.
That's ok of course, no language can be all things for all people and its ok to have a niche. But when the primary example justification for the language is a problem that the language couldn't possibly address, it suggests that it is hardly a well thought out language.
Almost none of the criticism here has been about the language itself, it has been about the blatent disconnect between what the language is and what it claims to try and do. Maybe its a good language in and of itself, hard to tell. At a glance it doesn't seem particularly groundbreaking, but it doesn't seem terrible either. However, I stand by it being an abject failure in terms of the stated goals of its marketing material.
But really with web assembly, anything you want.
I get the appeal for a small program that fits in your head, but for anything more complex I don't want the code to take care of everything in a single module/file.
The entire purpose of the project is to build a world of software constructed by interchangeable parts. But to accomplish interchangeable parts, one has to make sure that there are as few external dependencies as possible, which is why the language has layout, drawing, event tracking, and database features pulled into the language, so as to not have one reaching outside, which would invariably break over time.
C proved that a standard library was a major feature of any language, and Beads has a well designed, but compact standard library, where you have a few functions, with lots of options so as to reduce the total number of functions one has to learn.
Not that that is a bad thing! I'm happy your working on it, but I don't think they or this will replace excel like tools until everyone decides to learn how to program instead of using an easy and familiar path.
There is a "blackbox_write' and 'blackbox_send" feature, which allows you to send session information sufficient to replay the user's session for debugging purposes.
This is a very powerful feature, and one that we are seeing more and more efforts to offer, because in a world with so many computers, being able to reproduce rarely occurring, data-dependent bugs, is very important.
The second aspect of time control, the more simple one, is that you can jump the clock forward, and change the scaling of time at will, so that you can write tests to see if the alarm clock would ring as expected. That feature is as simple the std library functions that control the clock value and scaling. (set_clock_scale(), and set_clock()).
The ability to speed up time by a factor of 10 or 100 is a great time saver for those programs that have key sections, and slowing down time to 1/20th the normal rate (slo-motion) is wonderful for debugging animations. Many languages can set the clock, but not many have time scaling; a nicety.
Beads has a small standard library (compared to OSX or Java), but it has the key features you really need.
I used to program in a declarative langauge a few decades ago, Prolog. Heck, even makefiles are declarative. Declarative programming isn't guaranteed to be bug-free in the way the page indicates.
Probably the best liked feature of Beads is invisible in the syntax, as it follows the State-Action-Model pattern (see sam.js.org), and when a state variable changes, any layout that used that variable is automatically regenerated. This is of immense value when you have 500 things on the screen, and knowing which part of the screen to rebuild on any perturbation of the state is actually a lot of work, and the source of many under/over refresh errors.
This might be called a sprinkling of PROLOG's deduction system, where logical implication is done in the runtime. I am not aware of any top 20 language with deduction. The layout system is declarative like CSS, but includes variables, looping, and IF statements to make it more flexible.
The simplification that Beads offers is really only apparent in graphical/interactive software, and client/server programs. Otherwise people will stick to Python, etc.
http://pages.cs.wisc.edu/~solomon/cs537-old/last/segmentatio...
Unix has Paging but not segmentation. Segmentation allows you to grow a memory block without having to copy as it grows, something that just plain paging cannot do.
Most of the time one will use a loop in a very simplistic manner. Because it is so tedious and common to need the count of the loop, the key value, or a pointer to the element being looped across, we give you implied declaration capability in the loop consruct.
It is a compact notation that has gone through many polishing steps, and is very ergonomic, easy to read, and downright handy. Loops are the bread and butter of computer software, and yes, there are a fair number of options (such as going in reverse).
Please take the language for a spin, you might like it.
RN does not qualify as "simple".
No Linux version. Maybe is it a language only for GUI apps?
Lack of linux support is only a worthy criticism because appearently portability is a primary design goal and this is going to "replace" linux, but in general that's criticizing the tress for lack of seeing the forest.
There are some people reporting that the Windows .EXE runs okay under Wine in Linux, but yes it would be nice to support Linux desktop natively.
So multiplication by an ERR is not an error (from what I understand from quickly reading the ref).
``` 3 * ERR yields ERR 3 * U yields U (3 times undefined yields an undefined value) ```
The mathematical truth tables are in the appendix of the reference manual.
It is quite useful in a language to have a universal bottom value (undefined) and a universal top value (error). The key point is to avoid undefined behavior
(I'm not necessarily sure I like the trade-off you've chosen here, but I think the viscerally negative responses people are having are because of that, rather than thinking through the trade-off on its own merits)
For symmetry reasons, the error and undefined values work across all types, which cleans up one of the messes in JS, where you have undefined, NaN, null, and goodness knows what else. That we have a uniform error value for nodes is a very minor point; it is almost impossible to generate an error value in the protected arithmetic world of Beads. Square root of -1 is one of the only ways I can think of.
There is no try/except in Beads, there are no exceptions as all functions are total, and all arithmetic closed (like Excel).
I'm I the only one who sees the irony in this statement?