Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beads: Computer language and toolchain

beadslang.org

Post reply on HN
Print view View original

221–230 of 235 posts

Re: Beads: Computer language and toolchain

#221

Post by bawolff »

catblast01 wrote: post #192
bawolff wrote: post #167

Earlier quoted context omitted.

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 anythin…

> 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) You can represent graphs in the relational model so that’s simply bullshit.

But can you do it well?

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.

Re: Beads: Computer language and toolchain

#222

Post by goatlover »

magicmouse wrote: post #218
goatlover wrote: post #50

Earlier quoted context omitted.

Wasn't Meteor.js trying to do that as well for the web a few years ago?

Meteor has a lot of users, and is still around. The problem with Meteor is that it uses JS, and that language has a lot of problems. Typescript has clobbered meteor, as people have realized that JS makes it far too easy to make a typographical error that crashes at runtime.

JS is still ahead of TS in usage according to the Tiobe Index and Github language commits. As far as typographical errors go, every already knew JS was a dynamic language, like Python and Ruby. I'd say other frameworks like React and Angular, or their predecessors out-competed Meteor.

Re: Beads: Computer language and toolchain

#223

Post by stonewareslord »

ithkuil wrote: post #137
jasonshaev wrote: post #113

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 da…

> 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)

That's definitely one way to solve the issue, but I wouldn't say it's the only way.

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.

Re: Beads: Computer language and toolchain

#224

Post by catblast01 »

bawolff wrote: post #221
catblast01 wrote: post #192

Earlier quoted context omitted.

> 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) You can represent graphs in the relational model so that’s simply bullshit.

But can you do it well? 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.

> Infinite self-joins are not elegant in relational algebra.

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.

Re: Beads: Computer language and toolchain

#225

Post by zubairq »

jasonshaev wrote: post #201
zubairq wrote: post #189

Earlier quoted context omitted.

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…

I am vaguely familiar with Light Table and Eve (coincidentally my college roommate grew up with Chris but I don't know him personally). It's been awhile but my recollection is Light Table/Eve had a more targeted set of selling points -- a killer IDE with some slick features I hadn't seen before and then a new language designed to be written as prose. Regarding Beads: time travel is definitely a cool feature. Most lan…

Sure, connect with me. You can find my details online.

Re: Beads: Computer language and toolchain

#226

Post by zubairq »

blacktriangle wrote: post #197
zubairq wrote: post #185

Earlier quoted context omitted.

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 wa…

The websites main video is a weird tangent about phones and desktops now both being 64bit. I don't think time travel debugging was even alluded to on the main page. Developers do not have time to dig through every project's poor marketing in hopes of finding the motivation. The burden is on the project to sell developers, either quickly through explaining their killer features, or for more complicated projects by act…

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

Re: Beads: Computer language and toolchain

#227

Post by zubairq »

magicmouse wrote: post #211
jryans wrote: post #203

Earlier quoted context omitted.

I don't think you're fully appreciating the context here... The moderator of that community had been trying over and over, both privately and in public, to get this person to follow community norms for years, but they just would not do so. 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…

I was kicked out of the future of coding chat group by Ivan Reese, who exercised his cancel culture powers to permanently ban someone for daring to say that Steve Jobs had cojones for ordering hundreds of millions of dollars in parts for his products before they even shipped and knew if people liked them, unlikes the cowards at HP who only bought 10k Idea Pads (which preceded the iPad). It is ridiculous to equate a c…

I do remember this incident well. I guess each community has to decide how it wants to operate when people in that community feel disrespected and criticised. But I also remember this comment from Steve Jobs: https://greatresultsteambuilding.net/impact-teamwork-steve-j...

Re: Beads: Computer language and toolchain

#229

Post by blacktriangle »

ModernMech wrote: post #200
blacktriangle wrote: post #199

Earlier quoted context omitted.

I think you have the wrong takeaway from this thread. The project marketing is terrible, it is confusing, lacks focus, makes senseless claims, and doesn't showcase the project's strong points. People are telling the author where his marketing is falling short, and the developer has already updated his marketing in a few places to make it better. What you're watching is improvement in real-time.

I have the opposite impression as you. Honestly, you're one of the only people in this thread who engaged with the author in a respectful way, and I thank you for that. I agree with you that the author needs to do some work on the marketing side, and the helpful pointers provided here by you and others will hopefully move him in that direction. Still, there are others in this thread who should be ashamed of themselve…

So at risk of being the exact type of crusty old guy the tweeter is complaining about, I think Rik is completely missing the point. Progammers are busy, and not just with work but with learning. Somebody said its a 60hr/wk job, 40hrs for your boss and 20hrs just keeping up with technology, and while probably a bit facitious most weeks it feels that way. So not only are we keeping up with the platforms we're working on, we're also trying to keep an eye on what technology is on the horizon, or even other technology that exists and is usable today that we probably should know about.

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.

Re: Beads: Computer language and toolchain

#230

Post by magicmouse »

ithkuil wrote: post #137
jasonshaev wrote: post #113

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 da…

> 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)

Excel achieves its robustness (and it hardly ever crashes) by protecting the user against arithmetic errors, and circular reasoning. Excel doesn't offer infinite precision arithmetic, that is rarely needed in practice.

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.

Post reply on HN