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

251–260 of 428 posts

Re: Dada, an experimental new programming language

#251

Post by couchand »

myrmidon wrote: post #161
couchand wrote: post #116

Earlier quoted context omitted.

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

Panic is a perfectly proper way for a well-built program to stop execution. There is no point in juggling around Result types if a failure means that you can not recover/continue execution. That is in fact exactly what panic! is intended for [1]. [1]: https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

Panic is perfectly fine in certain cases, but it's absolutely not a general error-handling mechanism for Good Programs (TM). (Some contexts excluded, horses for courses and all that)

You can and should recover from bog standard IO failures in production code, and in any case you'd better not be panicking in library code without making it really clear that it's justified in the docs.

If your app crashes in flames on predictable issues it's not a good sign that it handles the unpredictable ones very well.

Re: Dada, an experimental new programming language

#252

Post by posix_monad »

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.

There are a bunch of languages that fit-the-bill already. F#, OCaml, Haskell and Scala all come to mind.

You might have to lose a few parens though!

Re: Dada, an experimental new programming language

#253

Post by rugina »

couchand wrote: post #123
sanderjd wrote: post #93

Earlier quoted context omitted.

In college, my programming languages class used a language called "Mystery" (I believe created by my professor), which was configurable . Assignments would be like "write some test programs to figure out whether the language is configured to use pass-by-value or pass-by-reference". And there were a bunch of other knobs that could be turned, and in each case, the idea was that we could figure out the knob's setting by…

Don't be so quick to discount DSLs. Sure, you don't want a half-baked DSL when some simple imperative code would do. But if you watch your API evolve into an algebra and then don't formalize it with a DSL you might be leaving powerful tools for understanding on the table. A poor-fitting language is terrible for abstract thinking, on the other hand an internally-consistent and domain appropriate language can unlock ne…

Given that the GitHub repo is almost three years old, I expect Martin Fowler to already have Dada Patterns, Refactoring in Dada, Dada Distilled, Dada DSL and Dada Best Practices ready to publish.

Re: Dada, an experimental new programming language

#254

Post by gpderetta »

School-Cotton wrote: post #169
gpderetta wrote: post #62

Earlier quoted context omitted.

You still want RAII and unique references, but rely on GC for anything shared, as if you had a builtin refererence counted pointer. I do also believe this might be a sweet spot for a language, but the details might be hard to reconcile.

I haven’t used Swift so I might be totally wrong but doesn’t it work sort of like you describe? Though perhaps with ARC instead of true GC, if it followed in the footsteps of Objective-C.

Possibly, yes. I haven't used swift either though. Does it have linear/affine types?

Edit: I would also prefer shared nothing parallelism by default so the GC can stay purely single threaded.

Re: Dada, an experimental new programming language

#256

Post by posix_monad »

asplake wrote: post #214
jug wrote: post #139

Earlier quoted context omitted.

Yes, F# is an often forgotten gem in this new, brighter cross-platform .NET world. :)

:-) Is F# a contender outside the .NET world?

There aren't many languages that can do server-side and browser-side well. F# is one of them!

Re: Dada, an experimental new programming language

#257

Post by MuffinFlavored »

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…

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.

Re: Dada, an experimental new programming language

#258

Post by estebank »

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

Syntax in programming languages are a question of style and personal preference. At the end of the day syntax is meant to help programmers communicate intent to the compiler. More minimalist syntax trades off less typing and reading for less redundancy and specificity. More verbose and even redundant syntax is in my opinion better for languages, because it gives the compiler and humans "flag posts" marking the intent of what was written. For humans, that can be a problem because when there are two things that need to be written for a specific behavior, they will tend to forget the other, but for compilers that's great because it gives them a lot of contextual information for recovery and more properly explaining to the user what the problem was. Rust could have optional semicolons. If you go and remove random ones in a file the compiler will tell you exactly where to put them back. 90% of the time, when it isn't ambiguous. But in an expression oriented language you need a delimiter.

Re: Dada, an experimental new programming language

#259

Post by rayiner »

benrutter wrote: post #65

I love the idea of a "thought experiment language" - actually creating a working language is a big overhead, and its really fun to think about what an ideal language might look like. The crazy thing with reading this and the comments, is that it seems like we all have been daydreaming about completely different versions of a "high level rust" and what that would look like. For me I'd just want a dynamic run time + si…

The challenge of thought experiments, in a statically typed language, is ensuring soundness. The first version of Java Generics, for example, was unsound: https://hackernoon.com/java-is-unsound-28c84cb2b3f

Re: Dada, an experimental new programming language

#260

Post by gpderetta »

mtsr wrote: post #22
yamrzou wrote: post #19

Earlier quoted context omitted.

It's a leaky abstraction ( https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... ), but maybe there is no helping it and for some reason it is a necessary tradeoff for performance?

Maybe it’s actually a non-leaky abstraction because it makes the async-nature explicit. The alternative is hiding it, but it’s still going to affect your code, making that effectively a leaky abstraction.

Why is I/O so special that need to be explicitly marked across the call stack? What about memory allocation, that can arbitrarily delay a process? Should allocating functions be transitively annotated? What about functions that lock a mutex or wait on some synchronisation primitive? What about those that signal a synchronization primitive? What about floating points, that can raise exceptions? What about panicking functions?

Either all side effects should be marked or none should. Ret-connecting await annotations as an useful feature instead of a necessary evil is baffling.

Post reply on HN