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

51–60 of 80 posts

Re: The Senegal Programming Language

#51

Post by [deleted] »

zarzavat wrote: post #44
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…

I dislike implicit 'this' immensely. It is very common for local variables to shadow instance variables, e.g. in a constructor. Habitual use of shadowing can lead to bugs, for instance if you mistype a local variable declaration a later use of the intended name might default to the instance variable. Ruby is my favourite with @foo, it's concise but explicit. Because of this, languages with implicit this tend to have…

[deleted]

Re: The Senegal Programming Language

#53

Post by cageface »

Zababa wrote: post #6

As always, all languages, especially the new one, should have a "why" section. Small caveat: maybe it's still under construction and the person that posted it just found it too early. But once you're ready to show it to the world, please include the why! Note that anything is valid in the "why", even "just for fun" or "because I could". For now there is: > Senegal is a powerful, small-but-fast, concurrent, class-base…

Also picking a name that can easily and unambiguously searched on is a big plus.

Re: The Senegal Programming Language

#54

Post by wruza »

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…

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

Re: The Senegal Programming Language

#55

Post by ford_o »

zarzavat wrote: post #44
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…

I dislike implicit 'this' immensely. It is very common for local variables to shadow instance variables, e.g. in a constructor. Habitual use of shadowing can lead to bugs, for instance if you mistype a local variable declaration a later use of the intended name might default to the instance variable. Ruby is my favourite with @foo, it's concise but explicit. Because of this, languages with implicit this tend to have…

Mistyped variable will lead to unused variable warning. The swift example is problem of API, not shadowing.

Re: The Senegal Programming Language

#56

Post by Zababa »

pansa2 wrote: post #32
Zababa wrote: post #6

As always, all languages, especially the new one, should have a "why" section. Small caveat: maybe it's still under construction and the person that posted it just found it too early. But once you're ready to show it to the world, please include the why! Note that anything is valid in the "why", even "just for fun" or "because I could". For now there is: > Senegal is a powerful, small-but-fast, concurrent, class-base…

> Senegal is compiled and Wren is interpreted Senegal seems to use a bytecode interpreter: https://github.com/SenegalLang/Senegal/blob/22fe863ad234e43a...

I'm curious about what they mean by "Fast single-pass compiler". Maybe it's the compiler to bytecode?

Re: The Senegal Programming Language

#57

Post by Zababa »

crabmusket wrote: post #41
codefined wrote: post #11

Earlier quoted context omitted.

There are non-malicious issues related to prototype pollution. The most recent that comes to mind are packages overwriting each other. How do you handle two enhances that add the same function name? In JavaScript the second overwrites the first, which can cause issues if the functions do different things.

This may be apocryphal, but I thought JS's `Array.includes` method was so-named when it was added to the spec to avoid conflicting with popular libraries that were adding a `contains` method to the Array prototype. In order to avoid conflicting and breaking existing sites, a less-common name was chosen for the spec.

That was the case with Array.prototype.flat, that was supposed to be Array.prototype.flatten but flatten was already used by MooTools, and they respected the "don't break the web".

Re: The Senegal Programming Language

#58

Post by Zababa »

mcdonje wrote: post #33
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

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.

Re: The Senegal Programming Language

#59

Post by Zababa »

cageface wrote: post #53
Zababa wrote: post #6

As always, all languages, especially the new one, should have a "why" section. Small caveat: maybe it's still under construction and the person that posted it just found it too early. But once you're ready to show it to the world, please include the why! Note that anything is valid in the "why", even "just for fun" or "because I could". For now there is: > Senegal is a powerful, small-but-fast, concurrent, class-base…

Also picking a name that can easily and unambiguously searched on is a big plus.

That's true, though many languages don't respect that (Go, Java, Rust).

Re: The Senegal Programming Language

#60

Post by zarzavat »

ford_o wrote: post #55
zarzavat wrote: post #44

Earlier quoted context omitted.

I dislike implicit 'this' immensely. It is very common for local variables to shadow instance variables, e.g. in a constructor. Habitual use of shadowing can lead to bugs, for instance if you mistype a local variable declaration a later use of the intended name might default to the instance variable. Ruby is my favourite with @foo, it's concise but explicit. Because of this, languages with implicit this tend to have…

Mistyped variable will lead to unused variable warning. The swift example is problem of API, not shadowing.

It is possible to attempt use a variable more than once.

The Swift example was caused by shadowing. There was a global print() function and a instance print() method (taking one parameter, sender: AnyObject). If you called print() in a class not descending from NSView it printed the string in the console as expected. But if you called it in a class descending from NSView you got a print dialog as the instance method shadowed the global function. They fixed the issue long ago of course.

Post reply on HN