The Wake Programming Language

But what I really like is the presentation: I like how all features are summarized, pointing out what is novel, and then everything is just discussed using examples and comparisons to other languages. This is something I'll have to try when I finally get my own language off the ground :).

I wonder if the author is interested in engaging with researchy PL designers. E.g. the testability orientation of the language would make for a good Onward paper, or maybe a Future of Programming workshop presentation.

(I really like Rust's take on this with the semicolons—just leave off the semicolon to return—it makes the semicolon actually useful.)

    function RecordValidator(sessionHolder) {

        function validateRecords(records) {
            return records.every(validate);
        }

        function validateRecord(record) {
            if (record.lastRevision !== undefined
                && record.lastRevision.user !== undefined) {
                return record.lastRevision.user.getAccounts().every(function(account) {
                    return sessionHolder.hasAccount(account);
                });
            }
            return record.revisions.map(usesLimits);
        }

        function usesLimits(revision) {
            return sessionHolder.hasUser(revision.user);
        }

        return {
            validateRecords: validateRecords,
            validateRecord: validateRecord,
            usesLimits: usesLimits,
        };
    }

> 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 writing no easier, and reading harder.

        return Record[].any({
            r -> return !validate(r);
        });

        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<Record> records) {
            return records.stream().allMatch(this::validate);
        }

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

            record.revisions.stream().filter(this::usesLimits).count() < 3;
        }

        public boolean usesLimits(Revision revision) {
            return sessionHolder.hasUser(revision.user);
        }

    }

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.

Other discussion here: https://news.ycombinator.com/item?id=9040029

Same in the "What Wake did without" section. Yes, you do not have those features, or bugs, but have you really "FIXED" a bug? There is no bugs you have fixed, just different design decisions.

edit: The language may or may not be actually worth something, but those things make it look like they try to hard to me.

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