Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Senegal Programming Language

github.com

Post reply on HN
Print view View original

21–30 of 80 posts

Re: The Senegal Programming Language

#21

Post by Zababa »

brundolf wrote: post #13
beaconstudios wrote: post #12

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

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

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

Re: The Senegal Programming Language

#22

Post by smegcicle »

Zababa wrote: post #19
nemoniac wrote: post #15

What is a "modern" syntax?

For this one, JavaScript. For statically typed programming languages, it usually means ML-style type declaration, that TypeScript uses too.

and anything with significant-whitespace would ofcourse be a "post-modern" syntax

Re: The Senegal Programming Language

#24

Post by DrewRWx »

Zababa wrote: post #21
brundolf wrote: post #13

Earlier quoted context omitted.

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

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

Re: The Senegal Programming Language

#25

Post by Lerc »

I'm curious as to why they have 'this.' to access class fields.

JavaScript uses this because the architecture for accessing fields predates the existence of classes (even then I feel it should be extended to allow fields be accessed without 'this.' if the field and usage exist within the same class definition.)

Surely a compiler should be smart enough to not require a 'this.' if the name is in the scope of the class and not hidden behind something like a parameter with the same name.

Re: The Senegal Programming Language

#26

Post by brundolf »

Zababa wrote: post #21
brundolf wrote: post #13

Earlier quoted context omitted.

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

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

Thanks!

Re: The Senegal Programming Language

#27

Post by Calamity210 »

I was wondering where all the traffic on the repo was coming from after months of inactivity lol.

Most comments (so far) are asking "why?". Its honestly a fair question, what does this language offer that others dont? Nothing really, this project isn't anything serious I just wanted to have some fun with it. Regardless, I'll put up a why section.

Re: The Senegal Programming Language

#28

Post by eyelidlessness »

Lerc wrote: post #25

I'm curious as to why they have 'this.' to access class fields. JavaScript uses this because the architecture for accessing fields predates the existence of classes (even then I feel it should be extended to allow fields be accessed without 'this.' if the field and usage exist within the same class definition.) Surely a compiler should be smart enough to not require a 'this.' if the name is in the scope of the class…

> JavaScript uses this

Python goes one further and requires you explicitly name your this (commonly self) as a parameter. Which is one thing I particularly like about Python, as it’s clear class instance methods are just sugar over plain functions/routines without any magic.

I find the Java-style name resolution that doesn’t require qualification utterly confusing. It would be especially weird/probably a footgun in a JS-like language where functions are frequently used as values and where their names can be shadowed locally.

Re: The Senegal Programming Language

#29

Post by Kinrany »

brundolf wrote: post #13
beaconstudios wrote: post #12

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

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.

Re: The Senegal Programming Language

#30

Post by brundolf »

Kinrany wrote: post #29
brundolf wrote: post #13

Earlier quoted context omitted.

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

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.

Post reply on HN