Live data from Hacker News

Beads: Computer language and toolchain

beadslang.org

151–160 of 235 posts

Re: Beads: Computer language and toolchain

#151
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"

Is this even a declaritave language? Doesn't look like it to me at a glance.

Re: Beads: Computer language and toolchain

#152

"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: ``` (\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…

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

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.

Re: Beads: Computer language and toolchain

#153

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…

"Graph databases are considered more powerful and modern than relational databases" vs. "Graph databases are quite hot"

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.

Re: Beads: Computer language and toolchain

#154
post #45

It's kind of reminiscent of 4GL languages ( https://en.wikipedia.org/wiki/Fourth-generation_programming_... ). The idea was, too, to have bigger application-building blocks that are composed in a more declarative way. I think this concept will be revisited from time to time in the future, although I agree with the skepticism about this particular project.

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.

Re: Beads: Computer language and toolchain

#155

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…

How you present your ideas are as important as the quality of your ideas. My suggestion is that your website's presentation does not present your ideas in a way that is likely to reach your target audience. That's an opinion of course.

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.

Re: Beads: Computer language and toolchain

#156

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)

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

Just to elaborate a bit, in CL, numbers are FIXNUMs by default but are promoted to BIGNUMs if needed. CL also has rational and complex numbers, which it probably got from Scheme but I'm not familiar with that history.

Re: Beads: Computer language and toolchain

#157

Earlier quoted context omitted.

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…

I agree that I hate this solution. However, are you saying that this is a bad FizzBuzz solution to you? (Python) 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…

I don’t want to argue in favour of the Beads solution but I think the right way to describe the logic is as follows:

  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.

Re: Beads: Computer language and toolchain

#158
post #153

Earlier quoted context omitted.

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…

"Graph databases are considered more powerful and modern than relational databases" vs. "Graph databases are quite hot" 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 a…

okay i have rewritten parts of it. I hope you folks take it for a spin; it has a lot of nice touches in it; worked very hard on the balance between concision and readability.

Re: Beads: Computer language and toolchain

#159
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" Is this even a declaritave language? Doesn't look like it to me at a glance.

The layout system is declarative (with escape hatch to looping and conditionals), and so is the finite state machine syntax DSL inside, and the regular expression syntax (a novel reformulation).

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!

Re: Beads: Computer language and toolchain

#160

Earlier quoted context omitted.

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

> You have an embedded graph database? Why? This is just a symptom of developers general disrespect for the depth and complexity of databases. 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 provi…

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 long as you aren't trying to time travel, and either limit yourself to very traditional COBOL era datatypes, or convert everything into string form like JSON has to do.

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.

Post reply on HN