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

71–80 of 428 posts

Re: Dada, an experimental new programming language

#71

Post by jeroenhd »

DinaCoder99 wrote: post #17
baq wrote: post #10

Earlier quoted context omitted.

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.

Huh, typically print is the debug message function vs explicitly writing to stdout

Print is a debug function in some languages, but it's usually just stdout. You can add all kinds of logging libraries that wrap around print() with prefixes and control sequences to add colours, but I generally don't bother with those myself. In those circumstances, I would use something like logger.debug() instead of plain print(), though.

I personally find myself using print debugging as a last resort when the debugger doesn't suffice.

Re: Dada, an experimental new programming language

#72

Post by BoppreH »

bananapub wrote: post #67
BoppreH wrote: post #63

Earlier quoted context omitted.

I've always wondered if global type inference wouldn't be a game changer. Maybe it could be fast enough with caching and careful language semantics? You could still have your IDE showing you type hints as documentation, but have inferred types to be more fine grained than humans have patience for. Track units, container emptiness, numeric ranges, side effects and idempotency, tainted values for security, maybe even e…

one of the other reasons global inference isn't used is because it causes weird spooky action at a distance - changing how something is used in one place will break other code.

I've heard that, but never seen an example*. If the type system complains of an issue in other code after a local change, doesn't that mean that the other code indeed needs updating (modulo false positives, which should be rarer with granular types).

Or is this about libraries and API compatibility?

* I have seen examples of spooky-action-at-a-distance where usage of a function changes its inferred type, but that goes away if functions are allowed to have union types, which is complicated but not impossible. See: https://github.com/microsoft/TypeScript/issues/15114

Re: Dada, an experimental new programming language

#73

Post by amw-zero »

gary17the wrote: post #53
happens wrote: post #25

It's weird, I want pretty much the exact opposite of this: a language with the expressive type system and syntax of rust, but with a garbage collector and a runtime at the cost performance. Basically go, but with rusts type system. I'm aware that there are a few languages that come close to this (crystal iirc), but in the end it's adoption and the ecosystem that keeps me from using them.

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…

A language has a paved road, and when you go off of that road you are key with extreme annoyance and friction every step of the way.

You’re telling people to just ignore the paved road of Rust, which is bad advice.

Re: Dada, an experimental new programming language

#74

Post by withinboredom »

nine_k wrote: post #64
withinboredom wrote: post #36

Earlier quoted context omitted.

It MIGHT or might NOT be valid, it depends. In a lot of cases, I might just want to print, but not yield "right here," but later (if at all in the current method). Further, writing to i/o is usually non-blocking (assuming the buffers are big enough for whatever you are writing), so in this case, the await literally makes no sense.

A smart print() implementation may check if there's enough output buffer, and, if so, quickly return a Future which has already completed. A smart scheduler can notice that and not switch to another green thread.

One can argue that in the VAST majority of instances, you'll never ever be printing so much that you'll fill the buffer. If you need that kind of control, just get a direct stream to stdout, otherwise make print() block if it needs to.

Re: Dada, an experimental new programming language

#75

Post by speed_spread »

usrusr wrote: post #21
brabel wrote: post #2

If the claim that its performance will be similar to Rust's if you add type annotations, this could become a really attractive language! As easy as JavaScript to write, as fast as Rust when the extra effort to write it justifies it.

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.

Re: Dada, an experimental new programming language

#76

Post by lkirkwood »

couchand wrote: post #47
dartos wrote: post #35

Earlier quoted context omitted.

I don’t think so. Normally print isn’t a debug message function, people just use it like that. (it normally works on non debug builds)

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

Re: Dada, an experimental new programming language

#78

Post by yamrzou »

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.

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” — Brian Kernighan, co-creator of Unix
Post reply on HN