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

The Wake Programming Language

wakelang.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: The Wake Programming Language

#21

Post by iopq »

tines wrote: post #8

> Code as concise as javascript, with inheritance and typesafety and more Extremely minor potential nitpick: correct me if I'm wrong, but I think this sentence implies that Javascript is not type-safe, when it is indeed type-safe; it's just dynamically typed, and its type system gives meaning to all expressions (where that meaning is to signal an error in some cases).

That's true for everything by your definition.

"But wait a minute, Assembly is not type safe!" But yes it is, just every type is a binary number. It's not Assembly's fault that you're trying to use binary numbers to print characters to the screen or point to regions of memory and somehow get the two mixed up.

Re: The Wake Programming Language

#22

Post by developer-mike »

zem wrote: post #20

one very curious design decision is to allow type aliases either before or after the type. so, from the examples, you have > setIdThenSave(newid Num, Bool recursively) { ... } i like the idea of letting a type do double duty as a variable name if it's obvious in context, and being aliased by an explicit name if wanted/needed, but letting the order be irrelevant sounds like unnecessary flexibility to me - it makes wri…

This is covered in the FAQ. Partly, I allow it because there are no parsing ambiguities with it, so why not. But moreover, depending on type name & variable names, intelligently beginning or ending with an alias can lead to extremely fluent APIs. "that(expected Bool)Equals(actual Bool)" vs "writeTo(Linkable output)". This freedom can lead to more readable APIs in any language, not just English.

Of course, I do see where the complaints come from, and a part of me fears the day that someone releases a wake linter which requires aliases to follow the type. If that were to happen I think I'd nix the idea in favor of unity in the community.

Re: The Wake Programming Language

#23

Post by zem »

developer-mike wrote: post #22
zem wrote: post #20

one very curious design decision is to allow type aliases either before or after the type. so, from the examples, you have > setIdThenSave(newid Num, Bool recursively) { ... } i like the idea of letting a type do double duty as a variable name if it's obvious in context, and being aliased by an explicit name if wanted/needed, but letting the order be irrelevant sounds like unnecessary flexibility to me - it makes wri…

This is covered in the FAQ. Partly, I allow it because there are no parsing ambiguities with it, so why not. But moreover, depending on type name & variable names, intelligently beginning or ending with an alias can lead to extremely fluent APIs. "that(expected Bool)Equals(actual Bool)" vs "writeTo(Linkable output)". This freedom can lead to more readable APIs in any language, not just English. Of course, I do see wh…

that's a good point, and the line of code does read fluently. i'd still argue that blurring the "alias = noun, type = adjective" metaphor is a bad idea; you couldn't write

that(expected Bool, expected Int)Equals(actual Bool, actual Int)

to match on two values, for instance. on the other hand, constraining the adjective to come before the noun is an english-based convention, so you're probably right about seeing which way the community leans before doing anything.

Re: The Wake Programming Language

#24

Post by stormbrew »

developer-mike wrote: post #19
0942v8653 wrote: post #17

I'm not sure I like the closure syntax, with the explicit return. Most modern languages (Swift, Rust, Python (lambdas), Lisp if I can call it modern) support implicit returns and it looks much better. Maybe it's just the juxtaposition with the JS code, but I was confused for a second by the word "return" inside the closure, thinking that it returned from the original function with just the first result. (I really lik…

Thanks! Great comment, I'd planned on adding implicit returns, and may copy rust on that one!

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

Re: The Wake Programming Language

#25

Post by developer-mike »

stormbrew wrote: post #24
developer-mike wrote: post #19

Earlier quoted context omitted.

Thanks! Great comment, I'd planned on adding implicit returns, and may copy rust on that one!

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

I can imagine so; But as a counterpoint, isn't it worse with forced implicit returns, where you never have a choice but to return something, and you have to scan the code carefully to see if it was required?

Maybe I'll add a 'noreturn' keyword; single expresions are automatically returned, and you can use a 'noreturn' statement to explicitly return void despite running a non-void expression.

Re: The Wake Programming Language

#26

Post by stormbrew »

developer-mike wrote: post #25
stormbrew wrote: post #24

Earlier quoted context omitted.

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

I can imagine so; But as a counterpoint, isn't it worse with forced implicit returns, where you never have a choice but to return something, and you have to scan the code carefully to see if it was required? Maybe I'll add a 'noreturn' keyword; single expresions are automatically returned, and you can use a 'noreturn' statement to explicitly return void despite running a non-void expression.

Sadly I don't really have a perfect answer to that. I'm inclined to think making all returns explicit is the right choice, and is only really a problem in a language where long returns are common (specifically in my mind is ruby, where being able to return from the enclosing function is crucial to the common uses of blocks). Arguments against in languages that don't feature this sort of thing seem to be against the length/weight of the word return.

Something I've played with in languages I've worked on is named returns [1], which I like for that case.

[1] https://github.com/stormbrew/channel9/blob/master/sample/c9s... -- see the get function definition, '-> return' names the return 'channel' and 'return I do think a special case for single statements makes sense, though.

Re: The Wake Programming Language

#27

Post by iopq »

stormbrew wrote: post #24
developer-mike wrote: post #19

Earlier quoted context omitted.

Thanks! Great comment, I'd planned on adding implicit returns, and may copy rust on that one!

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

Most functions in Rust return, so you can count on the last expression to be returned the vast majority of the time.

Re: The Wake Programming Language

#28

Post by stormbrew »

iopq wrote: post #27
stormbrew wrote: post #24

Earlier quoted context omitted.

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

Most functions in Rust return, so you can count on the last expression to be returned the vast majority of the time.

Which begs the question, why even have the trick of the missing semicolon in that case? Why rely on one missing 5 pixel character to say that "this function defies your expectations"?

If it's not the norm, I'd rather have an explicit "nil" or something at the end.

Re: The Wake Programming Language

#29

Post by dbaupp »

stormbrew wrote: post #24
developer-mike wrote: post #19

Earlier quoted context omitted.

Thanks! Great comment, I'd planned on adding implicit returns, and may copy rust on that one!

Arbitrary two cents: Rust's approach to this bothers me a lot. A missing semicolon having such a weighty meaning strikes me as one of the worst warts to survive Rust's rapid evolution. It forces you to scan very carefully to determine outputs.

The rule only applies at the ends of blocks/functions. The semicolon can only be omitted on trailing expressions. And, when it's omitted, the block/function takes on the value of that trailing expression. E.g. this is not valid Rust:

  fn foo(x: bool) -> i32 {
      if x { 
          1 // no semicolon on the 1
      }

      let a = 2 + 3;
      return a * 4;
  }
It's not implicitly returning the 1 from `foo`. An early return would need to be written `if x { return 1 }`. On the other hand, the `return a * 4;` could just be written `a * 4` since it's at the end of the function.

This rule means the scanning required is just looking at the end of the function.

In any case, having a static type system means I have never personally encountered a bug caused by this sort of implicit return in Rust.

Re: The Wake Programming Language

#30

Post by iopq »

stormbrew wrote: post #28
iopq wrote: post #27

Earlier quoted context omitted.

Most functions in Rust return, so you can count on the last expression to be returned the vast majority of the time.

Which begs the question, why even have the trick of the missing semicolon in that case? Why rely on one missing 5 pixel character to say that "this function defies your expectations"? If it's not the norm, I'd rather have an explicit "nil" or something at the end.

Well, if you add a semi-colon where it's not supposed to be you'll get a compile error. If you omit a semi-colon, you'll also get a compile error. They're just there to separate statements (Rust is not whitespace-sensitive).

The most common pattern in my Rust code is:

`statement; statement; expression` where the expression is what I actually want to return from this function

it seems more noisy to say `statement; statement; return expression;`

Post reply on HN