5 ms·

so many new programming languages come out that are almost identical to existing ones. Where's the crazy ideas (aside from the esoteric languages, which are dif

so many new programming languages come out that are almost identical to existing ones. Where's the crazy ideas (aside from the esoteric languages, which are different because they're intentionally difficult). I'd love to see more entries in the areas other than OO or procedural languages (or even just a variation on those, like an actor-model language). There's so many ideas in the programming language theory space that deserve a swing.

brundolf 5y ago
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 https://www.brandons.me/blog/the-bagel-language
- Zababa 5y ago
  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".
  - DrewRWx 5y ago
    He converted me just by having a "why".
  - brundolf 5y ago
    Thanks!
- Kinrany 5y ago
  > 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.
  - brundolf 5y ago
    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.
- mcdonje 5y ago
  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.
  - Zababa 5y ago
    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 https://koka-lang.github.io/koka/doc/index.html.
    - hedshodd 5y ago
      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!
      - Zababa 5y ago
        > 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.
        brundolf 5y ago
- beaconstudios 5y ago
  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_separation 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.
  - brundolf 5y ago
    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.
jonsen 5y ago
Maybe at least a partial explanation is in the article posted here: https://news.ycombinator.com/item?id=28821498 https://news.ycombinator.com/item?id=28821498
jonsen 5y ago
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.
- beaconstudios 5y ago
  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.
wruza 5y ago
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.
- kwhitefoot 5y ago
  We can get rid of the var and let keywords if we embrace single assignment like Erlang.

brundolf 5y ago

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 https://www.brandons.me/blog/the-bagel-language

Zababa 5y ago
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".
- DrewRWx 5y ago
  He converted me just by having a "why".
- brundolf 5y ago
  Thanks!
Kinrany 5y ago
> 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.
- brundolf 5y ago
  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.
mcdonje 5y ago
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.
- Zababa 5y ago
  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 https://koka-lang.github.io/koka/doc/index.html.
  - hedshodd 5y ago
    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!
    - Zababa 5y ago
      > 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.
      - brundolf 5y ago
beaconstudios 5y ago
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_separation 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.
- brundolf 5y ago
  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.

jonsen 5y ago

Maybe at least a partial explanation is in the article posted here: https://news.ycombinator.com/item?id=28821498 https://news.ycombinator.com/item?id=28821498

jonsen 5y ago

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.

beaconstudios 5y ago
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.

wruza 5y ago

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.

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