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

261–270 of 428 posts

Re: Dada, an experimental new programming language

#261

Post by luke-stanley »

steveklabnik wrote: post #245
luke-stanley wrote: post #43

Earlier quoted context omitted.

Maybe there could be something like a aprint() wrapper, if the authors wanted to make the async nature explicit? Or something else, probably not this for one of the most common things a programmer must do.

Why is aprint “non leaky” but print.await “leaky”?

Hey Steve, I wouldn't say that "print.await" is a leak abstraction. I think "print.await" is explicit and that's good, it communicates it's abstraction fairly clearly, presumably following a pattern used commonly in this, imagined language.

I suppose that a wrapper like "aprint" (a convenience function labelled async, like with an "a" prefix), would be a bit better than having people continually try using print, not await it, and not getting the expected output in stdout (or whatever stream it's sent to), while they are in the middle of trying to test something or otherwise get something working because I'm of the opinion that common things should be easy. Maybe "people would generally expect a print function to just work and not return a promise or something" is an abstraction? "aprint" might actually be the wrong name I'm not sure I've really thought about it right.

Re: Dada, an experimental new programming language

#262

Post by tialaramex »

benrutter wrote: post #97
pas wrote: post #86

Earlier quoted context omitted.

Runtime would be nice, but ... that's basically what Tokio and the other async frameworks are. What's needed is better/more runtime(s), better support for eliding stuff based on the runtime, etc. It seems very hard to pick a good 'number' (JS's is actually a double-precision 64-bit IEEE 754 float, which almost never feels right).

Yes, that's true - "number" is probably more broad than I'd really want. That said, python's "int", "float" and "decimal" options (although decimal isn't really first class in the same way the otherse are) feels like a nice balance. But again, its interesting the way even that is probably a bias towards the type of problems I work with vs other people who want more specification.

"Number" implies at least the reals, which aren't computable so that's right out. Hans Boehm's "Towards an API for the Real Numbers" is interesting and I've been gradually implementing it in Rust, obviously (as I said, they aren't computable) this can't actually address the reals, but it can make a bunch of numbers humans think about far beyond the machine integers, so that's sometimes useful.

Python at least has the big num integers, but its "float" is just Rust's f64, the 64-bit machine integers again but wearing a funny hat, not even a decimal big num, and decimal isn't much better.

Re: Dada, an experimental new programming language

#263

Post by mihaic »

naasking wrote: post #198
mihaic wrote: post #166

I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the horrible things that you can do with C++ - found almost every thing where it was different to have a harder to parse syntax, that I could never get used to. The implicit return at the end of a statement for instance make it harder for me to visually parse what's…

> Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, Have you tried Ada? > so something like "func" instead of "fn" would be mandatory. What about no keywords, like: x => ...func body

> Have you tried Ada?

I have tried Pascal in that sphere, which was on the too verbose side.

Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.

Re: Dada, an experimental new programming language

#265

Post by mplanchard »

sorenjan wrote: post #138

Changing a quote to change "his" to "theirs" seem like a very Rust community thing to do. > Updated to use modern pronouns. https://dada-lang.org/docs/about/

The policing of what other people should or shouldn't care about or advertise they care about is very boorish to me, but of course here I am doing the same thing.

Re: Dada, an experimental new programming language

#266

Post by gary17the »

MuffinFlavored wrote: post #257
gary17the wrote: post #53

Earlier quoted context omitted.

If you do not want to mess with Rust borrow checker, you do not really need a garbage collector: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang with Rust's expressivenes…

Can you help me understand when to use Rc instead of Arc (atomic reference counter)? Edit: Googled it. Found an answer: > The only distinction between Arc and Rc is that the former is very slightly more expensive, but the latter is not thread-safe.

The distinction between `Rc` and `Arc` exists in the Rust world only to allow the Rust compiler to actually REFUSE to even COMPILE a program that uses a non- thread-safe primitive such as a non-atomic (thus susceptible to thread race conditions) reference-counted smart pointer `Rc` with thread-bound API such as `thread::spawn()`. (Think 1-AM-copy-and-paste from single-threaded codebase into multi-threaded codebase that crashes or leaks memory 3 days later.) Otherwise, `Rc`[1] and `Arc`[2] achieve the same goal. As a general rule, many Rust interfaces exist solely for the purpose of eliminating the possibility of particular mistakes; for example, `Mutex` `lock()`[3] is an interesting one.

[1] https://doc.rust-lang.org/rust-by-example/std/rc.html

[2] https://doc.rust-lang.org/rust-by-example/std/arc.html

[3] https://doc.rust-lang.org/std/sync/struct.Mutex.html

Re: Dada, an experimental new programming language

#267

Post by sanderjd »

anentropic wrote: post #200
sanderjd wrote: post #100

Earlier quoted context omitted.

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.

Funny, because the semicolons and braces syntax is one of the things that puts me off Rust a bit, and I was not excited to see it in Dada

It isn't necessarily my preference either, but it's the most familiar style of syntax broadly, and that matters more for adoption than my personal preferences do.

Re: Dada, an experimental new programming language

#268

Post by mplanchard »

nu11ptr wrote: post #96

I like the idea, but please no "async/await". In a higher level language green threads like Go has are the correct answer IMO (and I'm not a Go fan, but I feel they got this part right). Gradual typing is interesting, but I wonder if necessary. Static typing doesn't have to feel like a burden and could make it hard to reason about performance. I think more type inference would be better than gradually typed (like OCa…

Personally I love explicit coroutines for their flexibility. It's great to be able to multiplex a bunch of IO bound operations on a single thread, defining some in chains and other to execute in parallel. It's great to be able to easily decide when I want to wait for them all to finish, to do something like `select`, or to spin them off into the background. Rust's ownership occasionally makes this a bit more of a challenge than I would like it to be, but I certainly wouldn't trade the ability for a more "convenient" syntax.

Re: Dada, an experimental new programming language

#269

Post by spankalee »

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.

The other problem I see here is that starting and awaiting the task are too coupled.

In JavaScript calling the function would start the task, and awaiting the result would wait for it. This lets you do several things concurrently.

How would you do this in Dada:

    const doThings = async () => {
      const [one, two, three] = await Promise.all([
        doThingOne(),
        doThingTwo(),
        doThingThree(),
      ]);
    };
And if you wanted to return a thunk to delay starting the work, you would just do that yourself.

Re: Dada, an experimental new programming language

#270

Post by sanderjd »

zozbot234 wrote: post #115
sanderjd wrote: post #100

Earlier quoted context omitted.

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.

Interesting! I'm actually unaware of this, but will look into it.
Post reply on HN