I'm still waiting for the programming language that doesn't take off on tangentially obscure ideas, but address the three fundamental dimensions of a computer program, state, functionality, and interaction dynamics, on an equal footing and with a clean orthogonal architecture. I've only met this mindset way back in Object-Oriented Modeling and Design 1st Edition, by James R. Rumbaugh et.al. The book is not about programming language design but about how to use these ideas when programming in existing languages. Despite it being otherwise somewhat immature I remember it as a very inspirational read.

Alternative theories of programming are exactly why I want to see new, innovative language concepts; not just for the wacky factor, but as an implementation of a different approach, hopefully one based in a logical theory rather than random tweaks.

I'm working on one! It's not ready to be shown off yet, but I outlined the core ideas here: https://www.brandons.me/blog/the-bagel-language

> To get down to brass tacks: Bagel will be a statically-typed, JavaScript-targeted language. It will keep many of the same syntaxes and semantics as JavaScript/TypeScript, except where there's significant benefit to breaking away from them. It will involve lots of nice little refinements and additions to the JavaScript paradigm, but it's mainly driven by two key ideas, which are really what make the whole project worth doing in my opinion:

> 1. A hard, enforced separation between stateless functional code and stateful procedural code

> 2. Reactivity as a first-class citizen

Hell yes, I'm in. These two features are interesting enough to try by themselves, I don't even care about the details.

The next most important thing is that JS/TS FFI just works, so I really hope it does.

I was originally planning not to expose FFI to users (only the standard library would use it), but I think I've come around on it. It undercuts some of the guarantees I want Bagel to provide, but you could say the same about unsafe blocks in Rust and those haven't stopped its safety-checking from being useful.

However going the other way - calling Bagel from JS/TS - has been on the roadmap from day one and should work pretty seamlessly. Bagel already compiles to TS in fact, including type info.

Looks promising, thanks for sharing!

Your idea of having functions that don't have effects and procs that don't return, reminds me of https://en.m.wikipedia.org/wiki/Command%E2%80%93query_separa... - so there's some prior work there for reassurance and reference.

First class reactivity would be extremely useful - I've thought the same thoughts as you around how reactivity is only partially solved with the current generation of UI libraries (or moreso with RxJS, but the syntax is full of baggage) so I wish you every success with solving it more comprehensively.

Thanks!

I have heard of Eiffel though I don't know much about it. I am honestly surprised this concept hasn't been explored more, given how long it appears to have been around.

The function vs procedure difference reminds me of VBA actually. In VBA, functions can return values and subs can't. That always made sense to me. VBA has it's issues, but there are some good qualities.

That's how I learned programming at the university. A function returns something, a procedure doesn't. Koka has something a bit like that with typed effects https://koka-lang.github.io/koka/doc/index.html.

This is one of the big things I love about Haskell. Its way of making effects explicit and easy to spot in the function signature always struck me as insanely useful for exactly those reasons (though, obviously, it goes a step further where every function always has to return something, even if it is an effect or an effected state). In retrospect, I wish Rust had adopted something like this since it took a lot of inspiration from Haskell anyways, but I am very glad that there are people like you out there that are trying to remind people of this insanely useful concept of making effects more explicit!

Wish you all the best with Bagel!

> In retrospect, I wish Rust had adopted something like this since it took a lot of inspiration from Haskell anyways

Aside from the traits (typeclasses), most of the inspiration actually comes from OCaml/ML rather than Haskell. The philosohpy is also way closer to the pragmatism of OCaml. I think Rust wouldn't be as popular as it is right now if IO needed a monad, like in Haskell. This would have been too much for a single language. I also don't think that monadic IO is the way. Maybe effects system will bring a more usable way of typing effects (Koka, OCaml soon), but I doubt that they'll come to Rust.

I agree, and I intend for Bagel to be a pragmatic language (striking a balance between idealism and pragmatism very similar to what Rust strikes), which is why I'm not going the monad route. I believe that the combination of the functional subset + reactivity to any state that does exist will get you 90% of the benefits without the learning curve

I only read the beginning as it's pretty late for me, but I like the idea, and it innovative. I think you also did a great job at converting quickly the "why".

He converted me just by having a "why".

Thanks!

And not less ideas that could improve usability of existing ones, like conditionals, loops and self-reference in object literals,

  {
    if (cond) set {a: 1},
    for (x of values) set {[x.name]: x},
    b: thisob.x,
    c: {d: thisob.c},
  }

enhanced data transfer,

  dest.{a, b, [key]} = src

default values,

  var x = arg ?? 1

optionality and mandatoryness,

  var x = f?(…)?.info![key] ?? "<not found>"

scope objects and flow control in these,

  function foo(a=1, b=2) {
    scope bar {
      let c = 3
      scope {
        let c = 4
        log(a, b, bar.c, c)
        baz(scope.this) // a, b, c, bar
        baz(scope.arguments) // a, b
        break bar

function environments,

  global.{*} = {a:1, b:2}
  var t = proxify({a:3, b:4}, global)
  withenv (t) foo() // 3 4

  function foo() {
    console.log(a, b)
  }

and so on. It seems everyone jumps on to “new same language” train when there is so much to do in what’s already not done.

We can get rid of the var and let keywords if we embrace single assignment like Erlang.

Maybe at least a partial explanation is in the article posted here:

https://news.ycombinator.com/item?id=28821498