The Wake Programming Language

http://www.wakelang.com

by developer-mike • 11 years ago

81 57 11 years ago

bsurmanski• 11 years ago

the Wake language was on here a few days ago, in the form of an article titled: The Rewards of Creating a Programming Language.

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

developer-mike9• 11 years ago

Good memory!

Yeah, I had posted that to Reddit, where it didn't do too well, but someone posted it here where (for some reason!) it did much better.

Figured in addition to the story of creating Wake, I'd post the home page so people could look into it more!

girvo• 11 years ago

for some reason

I've typically found PL related articles do much better on Hacker News than Reddit, I think perhaps because of differing (but overlapping) target audiences. Always found it interesting what articles work here but not on Reddit (the converse isn't as interesting...)

vezzy-fnord2• 11 years ago

I'm deducing an Eiffel and design-by-contract influence from this, for some reason.

desireco42• 11 years ago

I really like premise of the language. It does look a little strange but that is just novelty.

developer-mike9• 11 years ago

Thanks! I think with programming languages its important that it looks just strange enough. Luckily I have a few simple ideas that drive most of those unique syntaxes, hopefully making the uniqueness both justifiable and attention-grabbing. Otherwise, its just the language that I want to program in every day, and I hope others feel similarly.

thecatspaw• 11 years ago

IMHO the website tries to hard to portrait wake as a better language than others. Its ok to compare yourself to other languages, but the bytecount (which doesnt really say much about a language) and the coloring of the boxes leave a bad taste with me.

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.

tines2• 11 years ago

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

RussianCow• 11 years ago

Having types does not imply type safety. I think you're confusing "type safe" and "typed".

vezzy-fnord2• 11 years ago

The terms are evidently murky: http://www.pl-enthusiast.net/2014/08/05/type-safety/#comment...

developer-mike9• 11 years ago

Correct, there is runtime typesafety in javascript. However, type-safety is a spectrum; truthiness and falsiness for instance is not very typesafe. I will revise this to be clearer (your nitpick is valid) but I think the heart of the issue is still 100% correct.

gliptic• 11 years ago

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

tines2• 11 years ago

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.

_random_• 11 years ago

JS is type-safe in a way that is not useful in any way.

iopq3• 11 years ago

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.

ahoge• 11 years ago

http://en.wikipedia.org/wiki/Type_safety

Aggressive type coercion is not type safety. It does not prevent type errors. It just sweeps them under the rug.

    5 - 'foo'

That's a type error. It's not a convenient shortcut for `NaN`.

zak_mc_kracken• 11 years ago

A language that allows

    var a = 1;
    a = "foo";

is not type safe.

cw0• 11 years ago

I think the top blurb would benefit from specifying what modern problems Wake is good at solving. Certainly, the rest of the docs give a better idea, but most programmers have a short attention span regarding brand new languages and won't get beyond the first paragraph.

Rodeoclash• 11 years ago

Agreed, I feel like every JavaScript framework of the week should have this as well. What advantages does this tool have over everything else that is similar to it?

0942v8653• 11 years ago

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 like Rust's take on this with the semicolons—just leave off the semicolon to return—it makes the semicolon actually useful.)

developer-mike9• 11 years ago

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

stormbrew3• 11 years ago

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.

pekk• 11 years ago

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.

rapala2• 11 years ago

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.

kyllo2• 11 years ago

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.

zem2• 11 years ago

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

developer-mike9• 11 years ago

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.

zem2• 11 years ago

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.

riffraff• 11 years ago

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

mahyarm• 11 years ago

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

developer-mike9• 11 years ago

Great question! I wanted to compile to js with a better interface than emscripten.

david-given• 11 years ago

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 you get when install it is a set of static libraries, which take forever to link against and lead to 150MB binaries. - LLVM's supported architectures set isn't great yet. C provides a portable, vendor-neutral intermediate language which works everywhere and is easy to read and therefore debug. - targeting C makes library integration trivial (as your output program can use the library's own headers, which means ABI issues become nonexistent).

I did contemplate a partial switch, where my compiler didn't link against LLVM at all but instead just spat out LLVM bitcode assembly --- but emitting C was the same amount of work and so much more flexible. The only downsides is that C can't do tail calls, and getting the debug information to match up is more work, but that's about it.

(For the interested: Cowbel is an experiment at producing a minimal static duck-typed language --- all types are anonymous; you refer to objects only by their interfaces. The compiler than uses type inference to determine the actual concrete type of the object. This allows it to, e.g. use a single machine word to represent a number if you're never going to do dynamic dispatch on it, which means you don't end up with the weird schizophrenia of C++ and Java where some types are scalars and some are objects and they have different semantics.

It's also an attempt at minimalism; I wanted to remove as many features as possible and still end up with a expressive language with Javascript-ish syntax. I'm really proud of the way I managed to unify scope blocks and objects...

It works beautifully, and produces tight, fast code, but the compiler became unmaintainably complex and needs to be rewritten from scratch, which I haven't done yet.)

fineline• 11 years ago

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.

prakashp• 11 years ago

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 ?

seanmcdirmid2• 11 years ago

As a PL designer, there is a lot to like here; the design seems quite reasonable and thought out.

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.

developer-mike9• 11 years ago

I'd absolutely be interested in that type of engagement, papers, and presentations.

I haven't written a technical paper before, but tried to make one on the testability here: https://docs.google.com/document/d/1hT761Cl2-r7cSJV4zR69PGAD...

seanmcdirmid2• 11 years ago

The Onward! deadline is early April (SPLASH will be in Pittsburgh in late October); the future of programming workshop (or whatever we call it) deadline will be sometime much later than that (maybe July?) and the presentation format will probably be flexible (video, paper, ...) with tracks at both strangeloop and SPLASH.

abecedarius• 11 years ago

The Javascript-for-comparison would help the case better if it didn't look unfairly poorly-coded. (And it doesn't express quite the same logic, though I don't think that makes it look worse here.) I'd have written

    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,
        };
    }

The language looks like it has much to like.

Veedrac• 11 years ago

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<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);
        }

    }

michaelfeathers• 11 years ago

It's great to see seams thought of at the language design level.

loop2• 11 years ago

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.

agumonkey• 11 years ago

Class as interface seems such an obvious thing to do.

danielscrubs• 11 years ago

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.

PSeitz• 11 years ago

Concise: "every RecordValidator is" I would expect a loop here not a declaration.

juhq• 11 years ago

And now we wait for the job ads to roll in. "5 years experience in wake language"

dajoh• 11 years ago

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.

The Wake Programming Language

Related Stories