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

141–150 of 235 posts

Re: Beads: Computer language and toolchain

#141

Post by magicmouse »

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…

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.

Re: Beads: Computer language and toolchain

#142

Post by ModernMech »

throwaway894345 wrote: post #138
kortex wrote: post #48

- promises far fewer bugs - 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 b…

> declarative languages have almost no bugs 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.

In what way is Rust declarative? When I think of a declarative language, I think of Prolog or SQL. Rust to me would seem to be explicitly imperative.

Re: Beads: Computer language and toolchain

#143

Post by AnimalMuppet »

magicmouse wrote: post #122
rob74 wrote: post #22

Earlier quoted context omitted.

Since I saw the "replace the entire stack" image, I expect no less than that the website should be made in Beads, hosted on a server running Beads OS, and the frontend should be WebAssembly compiled from Beads.

Beads was going to be recoded in Web Assembly, however, the many restrictions on I/O to the user's hard drive inside the browser make it very to build a compiler inside a browser. Hopefully in the near future Web Assembly will become a fully capable virtual machine, that will unify all the different hardware and operating systems, effectively becoming a universal virtual OS. But any day now the dam will break, and We…

Any day now? That seems... optimistic. Are there objective reasons to think that this is true?

Re: Beads: Computer language and toolchain

#144

Post by [deleted] »

zem wrote: post #121
magicmouse wrote: post #114

Earlier quoted context omitted.

I consider the unified languages of the past to be VB6 and Borland Delphi as two successful environments that had many happy users who preferred to live inside that world and get things done without a lot of fuss. I know my friends when VB6 started to be disfavored by MS and they felt pressure to learn .NET refused to use .NET as it was just too hard compared to VB6. The reference manuals for .NET are 1000's of pages…

comparisons with vb6 and delphi add a lot more context to the philosophy and design of the language. i would consider making that point prominently on the home page.

[deleted]

Re: Beads: Computer language and toolchain

#145

Post by bawolff »

magicmouse wrote: post #141
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…

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…

No offense, but that's the most BS sounding pitch i've ever heard.

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.

Re: Beads: Computer language and toolchain

#146

Post by bawolff »

discardable_dan wrote: post #77
kortex wrote: post #48

- promises far fewer bugs - 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 b…

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

This solution looks ugly, but i don't think its "wrong". The point of fizzbuzz is to check they can write any trivial program. It works, its a pass.

Re: Beads: Computer language and toolchain

#149

Post by deckard1 »

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)

bignum as the default integer is quite common in lots of languages[1]. Notably, Lisp, Scheme, Erlang, Python.

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

Re: Beads: Computer language and toolchain

#150

Post by rst »

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)

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...
Post reply on HN