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

191–200 of 235 posts

Re: Beads: Computer language and toolchain

#191

Post by pmontra »

magicmouse wrote: post #184
pmontra wrote: post #148

Is the manual a PDF file? No HTML pages? That was getting already old in the 90s. No Linux version. Maybe is it a language only for GUI apps?

PDF prints well, and has nice search features, and has a nice zoom feature to accommodate people of different visual acuities, which the web does not always do well. This is the first time i have ever seen anyone prefer the web. Maybe if i put a table of contents in the PDF that would help. There are some people reporting that the Windows .EXE runs okay under Wine in Linux, but yes it would be nice to support Linux d…

I share your surprise: are there any major languages with a PDF as their main documentation source? Nothing beats an hypertext at looking for something IMHO.

Re: Beads: Computer language and toolchain

#192

Post by catblast01 »

bawolff wrote: post #167
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…

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.

Re: Beads: Computer language and toolchain

#193

Post by GianFabien »

magicmouse wrote: post #117
danpalmer wrote: post #16

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".

I apologize that the intro video is so much nicer than my own homemade videos. After paying a pro do to make that first video of a series of a dozen videos explaining the theory behind it, i realized it was going to cost too much, and the money would be better spent on the product itself. 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's the old style vs substance argument.

Marketing: do a song & dance then pick style.

Engineering: just pick substance and get on with it!

Re: Beads: Computer language and toolchain

#194

Post by GianFabien »

magicmouse wrote: post #178
bawolff wrote: post #176

This seems like a mildly interesting project targeting visual displays type niche (is it something similar to the processing language? E.g. a language for making visualizations of data?) 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) *…

Beads follows the State-Action-Model pattern (SAM, see sam.js.org) very closely. 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…

Reading through Beads author's blog reveals him to be a person with decades of experience. To me it appears that Beads is a well thought out attempt to address the multitude of issues that the author has experienced over the years.

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.

Re: Beads: Computer language and toolchain

#195

Post by GianFabien »

knolax wrote: post #177

Not really a technical comment but this is the first time I've seen language syntax written down with graphs in documentation. I honestly would've preferred text but it is interesting. What tool did you generate them with?

That was the standard for Pascal. Apple even had a poster: https://3.bp.blogspot.com/-4Mvjg7-02Mw/W_HBzLA8hBI/AAAAAAAAA...

Re: Beads: Computer language and toolchain

#196

Post by ithkuil »

rst wrote: post #150
ithkuil wrote: post #137

Earlier quoted context omitted.

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

Integer types in current versions of Ruby and Python both have arbitrary precision (as is also true for lots of other languages these days). That's not enough to make either intrinsically bug-free...

python does have bignum integer, but there are subtle things, like if you divide an integer with an integer you get a float, where you do lose precision:

>>>(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.

Re: Beads: Computer language and toolchain

#197

Post by blacktriangle »

zubairq wrote: post #185
magicmouse wrote: post #160

Earlier quoted context omitted.

If you use an external database you are not going to get time travel debugging, nor will you have a perfectly uniform internal representation of values. Beads has a primitive type of physical units of measure, so you can store 3 Newtons which internally will be stored as the magnitude 3 plus an array of fundamental units with their exponents. This datatype is not found in MySQL, so external databases work okay as lon…

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 actually building something with their tools.

Re: Beads: Computer language and toolchain

#198

Post by blacktriangle »

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.

Neo4j had a great demo, load up the IMDB database, then solve six degrees of Kevin Bacon with SQL vs with Cypher. The Cypher is a one liner that runs immediately, the SQL is a mess that almost brings down the database.

For certain types of queries, recommendation engines being a prime example, graph databases are awesome.

Re: Beads: Computer language and toolchain

#199

Post by blacktriangle »

replwoacause wrote: post #51

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.

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.

Re: Beads: Computer language and toolchain

#200

Post by ModernMech »

blacktriangle wrote: post #199
replwoacause wrote: post #51

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.

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

Post reply on HN