Live data from Hacker News

The Wake Programming Language

wakelang.com

41–50 of 58 posts

Re: The Wake Programming Language

#41
The Java code appears to be broken (`validate(records[i])` should be `validate(record)`). Further, Wake does

        return Record[].any({
            r -> return !validate(r);
        });
shouldn't this be

        return Record[].all({
            r -> return validate(r);
        });
?

And the inequality seems to be strict in Wake's case but weak in Java's. Finally, Java won't always return from `validate`.

The Java would really benefit from the newest version. I'm no Java expert, but I think it would look a bit like:

    public class RecordValidator {

        public RecordValidator(SessionHolder mySessionHolder) {
            sessionHolder = mySessionHolder;
        }

        protected SessionHolder sessionHolder;

        public boolean validate(List records) {
            return records.stream().allMatch(this::validate);
        }

        public boolean validate(Record record) {
            if(record.lastRevision != null && record.lastRevision.user != null) {
                List accounts = record.lastRevision.user.getAccounts();
                return accounts.stream().allMatch(sessionHolder::hasAccount);
            }

            record.revisions.stream().filter(this::usesLimits).count() 

Re: The Wake Programming Language

#43
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).

A language that allows

    var a = 1;
    a = "foo";
is not type safe.

Re: The Wake Programming Language

#44
Types-as-variables is a very good insight. When I'd write C++ function headers where I could omit parameter names without losing any clarity, it'd feel really nice, but the implication never rose to consciousness.

Re: The Wake Programming Language

#45
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…

doesn't the same apply to $Type ? It seems like unnecessary extra syntax, I'd prefer a simple "if there is ambiguity, name the variables".

Re: The Wake Programming Language

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

The trick is that now the keyword return marks an early return. And as early returns are often exceptional, I find the added visibility nice. On the other hand, every function in Rust, except those that contain an infinite loop, returns something so the keyword at the end of the function body is redundant in my opinion.

Also, because function signatures are never infered in Rust, mistakenly adding or forgetting the last semicolon will always result in a type error.

Re: The Wake Programming Language

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

To me there is nothing major about a function returning. Every function does that. Implicit early returns on the other hand could be deceiving, but I don't know any languages that would support those.

Re: The Wake Programming Language

#49
post #15
post #11

Earlier quoted context omitted.

I wouldn't call JavaScript type-safe by any type-theoretic definition. It allows operations that really make no sense for the types involved ([]+{} ??).

I think that whether the semantics of the language make sense to a particular person isn't really the criterion for type-safety. The language does define what should happen in the case of the expression ([]+{}), so no violation of the type system occurs and the behaviour of the program is well defined.

More examples of js insanity here (1:20):

https://www.destroyallsoftware.com/talks/wat

How about {} + [], is that deliberately zero, and why is addition not commutative in this case if it is allowed? Or {} + {}?

I think most people would infer type safety to mean that attempts to coerce types which are meaningless result in an error, not meaningless output, like the result of "string" - 1, or {} + "string" or {} + []. Otherwise your type system isn't going to stop you doing something insane by mistake, and is therefore not adding any safety.

{} + "string" or similar just shouldn't be allowed, and in most languages (let alone type safe ones), it is not.

Re: The Wake Programming Language

#50
Sometimes I just have to remind myself that not everyone is from academia. It seems like a great language but where is its charm? It does lot's of small things correct but will it make me think differently? If not it has to get a huge following with every library under the sun (think python or C#) for me to even consider it.
Post reply on HN