Live data from Hacker News

The Wake Programming Language

wakelang.com

51–58 of 58 posts

Re: The Wake Programming Language

#51
post #33

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…

I hate implicit returns and don't even want them to be possible. A return is a major event. It's clearly a matter of taste.

Agreed that it's a matter of taste. After working with Ruby and Clojure I don't even want statements or void functions to be a thing. I prefer the "everything is an expression" paradigm.

Re: The Wake Programming Language

#52

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.

Yeah, I wonder why Rust needs to have statements at all--why can't it just have "everything is an expression" semantics?

Why aren't declaration statements in Rust just expressions that evaluate to the value being bound to the name being declared?

Would this mess up Rust's type checker somehow?

Re: The Wake Programming Language

#54
post #31

I wonder why you didn't use LLVM to help make your language?

Been there, done that --- my own pet programming language (we all do one, or several) is Cowbel, at http://cowbel.sf.net , and it's now on its third incarnation, generating C. The second used LLVM. The reasons I switched away from LLVM are: - the LLVM API is huge , not very well documented, and changes radically from version to version. - LLVM library consumers are not well supported by the project. Frequently what y…

> my own pet programming language (we all do one, or several)

I don't. Thanks to all those that do though. Interesting thought experiment, even as a spectator.

Re: The Wake Programming Language

#56
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.

It'd be `()` and make it so that every side effecting function would be at minimum two lines long, and be a visible wart. It's pretty easy to tell that if the function returns something, the last line evaluates to that expression even if there's no `return` since if it didn't, it wouldn't compile (or there'd be a dead code warning).

Re: The Wake Programming Language

#57
> We've both created and borrowed some cutting edge ideas.

What ideas are new? I'm not sure about provisions because the examples aren't really clear, but all the other features I've seen in other languages before.

> 3. Shadowing (concise, safe)

It doesn't seem like shadowing is the feature here, rather the use of '$' to prevent shadowing.

> Lists (called Arrays in many other languages)

There's a very good reason for this. Lists and arrays are very different data structures. Why create confusion by calling them lists?

> Since Wake blurs the line between variables and types, we can boast the smallest foreach loop of any language.

Really, the smallest foreach loop of any language? Come on.

> Self Executing

Why is this called 'self executing'? Also, I'd expect any language with lambdas to support calling a lambda right after it's created.

Re: The Wake Programming Language

#58
post #31

I wonder why you didn't use LLVM to help make your language?

Been there, done that --- my own pet programming language (we all do one, or several) is Cowbel, at http://cowbel.sf.net , and it's now on its third incarnation, generating C. The second used LLVM. The reasons I switched away from LLVM are: - the LLVM API is huge , not very well documented, and changes radically from version to version. - LLVM library consumers are not well supported by the project. Frequently what y…

Hi david. I had a look at the cowbel source code. It seems that you have used gc for the generated C code.

Can you please tell me which GC is that ?

Post reply on HN