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

361–370 of 428 posts

Re: Dada, an experimental new programming language

#361

Post by int_19h »

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

A failure to write to stdout should not be unexpected given that stdout is routinely redirected to files or to pipes, both of which can be suddenly closed or otherwise fail from the other direction. Yes, you can't recover in this case, but you should at least properly report the error to stderr before exiting, in a way that lets the end user (rather than app dev) properly diagnose the error.

Now if you fail to write to stderr, yeah, that's a good reason for a console app to panic. The onus is on the user to provide something that is "good enough" in that case.

IMO the real problem is that print() etc defaults to stdout historically, but is used mostly for diagnostic information rather than actual output in practice, so it should really go to stderr instead. This would also take care of various issues with buffering etc.

Re: Dada, an experimental new programming language

#362

Post by gpderetta »

naasking wrote: post #240
klabb3 wrote: post #215

Earlier quoted context omitted.

Make sense might be an overstatement but ok. Then why do functions with sync syscalls (ie file, timers or mutex ops) not expose the same contractual differences? They’re just regular functions in most languages including Rust. Perhaps anything involving syscalls should be exposed and contractual. I doubt it, but maybe it’s important for some obscure ownership-of-resources reason. But then why the inconsistency betwee…

> Then why do functions with sync syscalls (ie file, timers or mutex ops) not expose the same contractual differences? They’re just regular functions in most languages including Rust. Because the kernel doesn't expose that contract, so they don't have that behaviour. > The only difference is whether the runtime sits in the kernel or in user space. In other words, what contracts you have control over and are allowed t…

>>[mutexes] are just regular functions in most languages including Rust.

>Because the kernel doesn't expose that contract, so they don't have that behaviour

Which OS are we talking about? Linux doesn't really have mutices as primitives. You can build async mutexes on top of eventfd and soon even on top of futexes with io_uring.

Re: Dada, an experimental new programming language

#363

Post by jerf »

munificent wrote: post #344
jerf wrote: post #174

Earlier quoted context omitted.

"Gradual typing is interesting, but I wonder if necessary." Open question: Are there any languages that can be used in a (decent [1]) REPL, that are strongly typed, but do not have Hindley–Milner-based type inference? We have multiple concrete proofs that you can have a REPL with Hindley-Milner inference, but I'm curious if this is perhaps a concession to the difficulty of a strongly-typed REPL without a deeply infer…

I'm not aware of any technical reasons why a given language would profoundly struggle to have a good REPL. I think it's mostly a matter of culture where REPLs aren't a priority in some language ecosystems because programmers there don't generally work that way.

I'm not immediately aware of one either which is why I asked. HM does have its advantages but static languages are generally pretty clear on the type of an expression without annotations and just giving a variable the type of what it is set to achieves most of what you're looking for. It just occurred to me I couldn't name an instance of a static language without HM that does that, though. (At least I'm assuming LISP REPLs generally operate dynamically.)

Re: Dada, an experimental new programming language

#364

Post by int_19h »

spankalee wrote: post #290
n2d4 wrote: post #127

Earlier quoted context omitted.

They borrowed it from Rust: `.await` is special syntax, roughly equivalent to `await print(...)` in other languages. https://rust-lang.github.io/async-book/01_getting_started/04...

I wonder why not do `await print()` though? It reads more naturally as "wait for this" and is more clearly not a property access.

Postfix operators are much more readable when chaining or composing. I used to write a lot of async C#, and it quickly gets tiresome to constantly have to write stuff like (await (await (...) ...), and reading such code requires jumping back and forth to unravel.

Amusingly, this is history repeating itself. These days we consider the X.Y syntax for object members quite natural, but historically if you look at the earliest examples, it was actually prefix. The first ALGOL-60 dialects to add records used functional notation, so you had to do Y(X). In ALGOL-68, they made it an operator instead (which allowed for proper namespacing), but it was still prefix: Y OF X; very straightforward and natural. But then people pretty quickly found out that (Y OF (X OF (...)) does not make for readable code in practice.

What I think they did wrong was require a period there - that is the part that makes it look like a property access. It would have been better as `print() await`, making it clear that it is just a postfix operator.

Re: Dada, an experimental new programming language

#365

Post by int_19h »

bmitc wrote: post #301
pama wrote: post #296

Earlier quoted context omitted.

In Python if you carelessly print within a multiprocess part of an application you may end up getting a nonreproducible mess on stdout with multiple streams merged at random points. So the cognitive load in this example is that this new language is meant for multithreaded coding and can make multithreading easy compared to other languages.

That's a great example of the "simplicity" of Python being anything but.

This is not at all unique to Python, and a footgun present in any language that allows multiple threads.

But if you're spawning multiple threads - in Python or any other language - you're already past any semblance of "simplicity", threads or no threads.

Re: Dada, an experimental new programming language

#366

Post by int_19h »

elevatedastalt wrote: post #351
wredue wrote: post #220

Earlier quoted context omitted.

So in python, you need to understand not 1, but at least 3 different versions of “an entry point”, and to you, this is “less cognitive load”? I had the same issue with Swift. There’s 30 ways to write the exact same line of code, all created by various levels of syntax sugar. Very annoying to read, and even more annoying because engaging different levels of sugar can engage different rulesets.

You don't "need" any of the entry points when you are beginning Python. print("Hello World") is a perfectly valid and runnable Python code. And when you are working on a small part of a large code base, you usually don't care about __main__ either. So yes, it's complexity but it's complexity that you don't need to encounter right away. Python is intuitive off the bat. public static void main(String[] args) is not.

Interestingly, C# (which began its life as a sort of Java/Delphi crossover syntactically) agrees. It used to be that you had to write:

   class Program {
      static void Main() {
         Console.WriteLine("...");
      }
   }
But these days, we can just do:

   Console.WriteLine("...");

Re: Dada, an experimental new programming language

#367

Post by int_19h »

rcxdude wrote: post #170
amw-zero wrote: post #73

Earlier quoted context omitted.

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.

Reference counting and locks often is the easy path in Rust. It may not feel like it because of the syntax overhead, but I firmly believe it should be one of the first solutions on the list, not a last resort. People get way too fixed on trying to prove to the borrow checker that something or another is OK, because they feel like they need to make things fast, but it's rare that the overhead is actually relevant.

If it's syntactically messy, though, it's not really the easy path. Ergonomics matter just as much as semantics.

I do think that a superset of Rust that provided first-class native syntax for ARC would be much more popular.

Re: Dada, an experimental new programming language

#369

Post by pie_flavor »

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.

The expressive type system of Rust is backed by use-site mutability; use-site mutability is backed by single ownership; single ownership is made usable by borrow checking. There's a reason no language before Rust has been like Rust without being a functional language (and if that's no object, then you can use OCaml).

Re: Dada, an experimental new programming language

#370

Post by int_19h »

cmrdporcupine wrote: post #173
sanderjd wrote: post #151

Earlier quoted context omitted.

Exactly right. I quite like haskell in theory, but in practice I quite dislike both reading and writing it. But I like ocaml both in theory and practice (also in part due to having my eyes opened to SML about 20 years ago).

I actually preferred SML/NJ when I played with writing it, but OCaml "won" in the popularity contest. Some of the things that made OCaml "better" (objects, etc.) haven't aged well, either. Still with OCaml finally supporting multicore and still getting active interest, I often ponder going back and starting a project in it someday. I really like what I see with MirageOS. These days I just work in Rust and it's Ok.

OCaml's object system is very nice, though. Structural typing with full inference is pretty awesome, and it also cleanly decouples subtyping from implementation inheritance.
Post reply on HN