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

Dada, an experimental new programming language

dada-lang.org

Post reply on HN
Print view View original

111–120 of 428 posts

Re: Dada, an experimental new programming language

#111

Post by MatthiasPortzel »

wtetzner wrote: post #87
yamrzou wrote: post #6

Their Hello, Dada! example: print("...").await I'm coming from Python, and I can't help but ask: If my goal as a programmer is to simply print to the console, why should I care about the await? This already starts with a non zero complexity and some cognitive load, like the `public static void main` from Java.

> If my goal as a programmer is to simply print to the console, why should I add care about the await? Because that isn't ever anyone's actual goal? Optimizing a language design for "Hello World" doesn't seem like a particularly useful decision.

It’s not an end goal, maybe, but if I’m writing a complex program and I want to print to the console for logging or debugging or status, I shouldn’t have to think about the design of that print-call. I would like to be able to focus on the main complexity of the program, rather than worry about boiler-plate complexity every time I want to print.

Re: Dada, an experimental new programming language

#112

Post by nu11ptr »

Doctor_Fegg wrote: post #49

> What if we were making a language like Rust, but one that was meant to feel more like Java or JavaScript, and less like C++? That would be Swift? Interesting experiment. But it does seem like there are increasing numbers of languages trying to crowd into the same spaces.

Yes, but languages don't compose well. For example, you can't take Swift because you like all the things the language does and then add in first class support for Linux and Windows. Thus, anytime a language doesn't align with EVERY thing you need it to do... a new language evolves.

Re: Dada, an experimental new programming language

#113

Post by color_me_not »

I don't understand the comment in the method print_point in the class Point of the tutorial.

    [...]
    # This function is declared as `async` because it
    # awaits the result of print.
    async fn print_point(p) {
        # [...]
        print("The point is: {p}").await
    }

    [...]
From the first page of the tutorial:

> Dada, like JavaScript, is based exclusively on async-await. This means that operations that perform I/O, like print, don't execute immediately. Instead, they return a thunk, which is basically "code waiting to run" (but not running yet). The thunk doesn't execute until you await it by using the .await operation.

So, what it boils down to is that async/await are like lazily computed values (they work a bit like the lazy/force keywords in Ocaml for instance, though async seems to be reserved for function declarations). If that is the case, that method "print_point" is forcing the call to print to get that thunk evaluated. Yet, the method itself is marked async, which means that it would be lazily evaluated? Would it be the same to define it as:

    fn print_point(p) {
        print("The point is: {p}")
    }
If not, what is the meaning of the above? Or with various combinations of async/await in the signature & body? Are they ill-typed?

I wish they'd provide a more thorough explanation of what await/async means here.

Or maybe it is a dadaist[0] comment?

[0] https://en.wikipedia.org/wiki/Dada

Re: Dada, an experimental new programming language

#114

Post by nu11ptr »

speed_spread wrote: post #75
usrusr wrote: post #21

Earlier quoted context omitted.

Still super weird, because the garbage collector tax that is avoided by the borrow checker that's decidedly not gone isn't all that big to begin with. But perhaps it's a viable "training wheels" approach for getting used to borrow-checker friendly patterns? And I guess a scripting interpreter option that is fully rust-aware in terms of lifetimes could be truly golden for certain use cases, even if it turns out to be…

Garbage collection is actually faster than generic malloc for allocating memory because it can work as a simple bump allocator. And there are ways to handle collection efficiently. Malloc is also not entirely deterministic in performance because the heap can get fragmented. Either way, if latency matters you end up having to care about (de)allocation patterns at the app level.

Agreed, it seems weird to me to avoid garbage collection in a high level language. It is one thing to use escape analysis to avoid creating garbage, but mallocing every object is going be slower than a well tuned GC.

Re: Dada, an experimental new programming language

#115

Post by zozbot234 »

sanderjd wrote: post #100
overstay8930 wrote: post #39

Earlier quoted context omitted.

You have awoken the ocaml gang

Yeah, ocaml is awesome! Frankly, if it had a more familiar syntax but the same semantics, I think its popularity would have exploded in the last 15 years. It's silly, but syntax is the first thing people see, and it is only human to form judgments during those moments of first contact.

> Frankly, if it had a more familiar syntax but the same semantics

That's what ReasonML is? Not quite "exploding" in popularity, but perhaps more popular than Ocaml itself.

Re: Dada, an experimental new programming language

#116

Post by couchand »

lkirkwood wrote: post #76
couchand wrote: post #47

Earlier quoted context omitted.

Printing directly to the console, even in a console app, is for debug purposes only. If your console app is writing output to any device, it must, for instance, handle errors gracefully. That means, at least in Rust, write! rather than print!.

What makes you say that? I almost always use println! over write!. From the docs: "Use println! only for the primary output of your program. Use eprintln! instead to print error and progress messages."

What makes me say that a well-built program properly handles errors?

Re: Dada, an experimental new programming language

#117

Post by MatthiasPortzel »

baq wrote: post #10
yamrzou wrote: post #6

Their Hello, Dada! example: print("...").await I'm coming from Python, and I can't help but ask: If my goal as a programmer is to simply print to the console, why should I care about the await? This already starts with a non zero complexity and some cognitive load, like the `public static void main` from Java.

I'd say you want something like 'debug_msg()' for this. 'print()' should be async because it does IO. In the real world most likely you'd see the output once you yield.

> 'print()' should be async because it does IO

What if I want to do synchronous IO?

Re: Dada, an experimental new programming language

#118

Post by sanderjd »

bradrn wrote: post #41
cmrdporcupine wrote: post #34

Earlier quoted context omitted.

... so OCaml or StandardML then

Or Haskell!

Ocaml, yes, but not haskell. It does include these things the parent wants, but similar to how Rust ends up being quite "captured" by its memory semantics and the mechanics necessary to make them work, haskell is "captured" by laziness and purity and the mechanics necessary to make those work.

Also, syntax does actually matter, because it's the first thing people see, and many people are immediately turned off by unfamiliarity. Rust's choice to largely "look like" c++/java/go was a good one, for this reason.

Re: Dada, an experimental new programming language

#120

Post by sanderjd »

yamrzou wrote: post #6

Their Hello, Dada! example: print("...").await I'm coming from Python, and I can't help but ask: If my goal as a programmer is to simply print to the console, why should I care about the await? This already starts with a non zero complexity and some cognitive load, like the `public static void main` from Java.

Also it immediately makes me wonder what `await` is... Is it a reference to a field of whatever the `print()` method is returning? Is it calling a method? If it's a method call without parentheses, how do I get a reference to a method without calling it?

(These kinds of questions are just unavoidable though; everyone will have these little pet things that they subjectively prefer or dislike.)

Post reply on HN