Live data from Hacker News

Dada, an experimental new programming language

dada-lang.org

211–220 of 428 posts

Re: Dada, an experimental new programming language

#212

Earlier quoted context omitted.

Try writing a larger OCaml program and not using interface files. It definitely happens.

I've never used OCaml, so I'm curious to what exactly happens, and if language design can prevent that. If I download a random project and delete the interface files, will that be enough to see issues, or is it something that happens when writing new code?

If you delete your interface files and then change the type used when calling a function it can cascade through your program and change the type of the function parameter. For this reason, I generally feel function level explicit types are a fair compromise. However, making that convention instead of required (so as to allow fast prototyping) is probably fine.

Re: Dada, an experimental new programming language

#213
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 funny thing is that rust used to have things like garbage collection. For the kind of language Rust wanted to be, removing them was a good change. But there could always be a world where it kept them. https://pcwalton.github.io/_posts/2013-06-02-removing-garbag...

> the kind of language Rust wanted to be

That has changed through the years: https://graydon2.dreamwidth.org/307291.html

Re: Dada, an experimental new programming language

#214
post #139
post #46

Earlier quoted context omitted.

You might enjoy F#. It's a lot like OCaml (which others have mentioned) but being part of the .NET ecosystem there are libraries available for pretty much anything you might want to do.

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

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

Re: Dada, an experimental new programming language

#215
post #27

Earlier quoted context omitted.

To be precise: the contract depends on the implementation. Here’s an example: I write an in memory kv cache. It’s in memory so no async needed. Now I create a trait and implement a second version with file backing. Now the children are crying because async needs to be retroactively added and also why, makes no sense etc.

It does make sense if you want other types of resources, like time and memory, to also be part of the contract. Async annotations let you do this but hiding the asynchrony does not.

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 between traditional and pooled syscalls? The only difference is whether the runtime sits in the kernel or in user space. The only one who should care is the runtime folks.

My take has been for years that this is throwing complexity over the fence and shaming users for not getting it. And even when they do get it, they Arc everything anyways in which case you are throwing the baby out with the bathwater (RAII, single ownership, static borrowing).

Re: Dada, an experimental new programming language

#217
I think there isn't enough research into languages with affine/linear typing (the property of some types that they can't be copied - which is partly what the borrow checker ensures in Rust). I'm super sold on it for enhancing safety. Vale with its "Higher RAII"[0] is the only other example I was aware of until seeing this.

Rust is great but being an early adopter has made its usability imperfect in places. Combining substructural typing with gradual typing and OOP is interesting here. Others in this thread have also mentioned wanting a higher-level Rust, like Go. I'd like to see a purely functional Rust. Haskell has experimental support for linear typing[1], but I suspect a language built with it from the ground up would be very different.

[0]: https://verdagon.dev/blog/higher-raii-7drl

[1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line...

Re: Dada, an experimental new programming language

#218
post #72

Earlier quoted context omitted.

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 goe…

> 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

The problem is when it doesn't complain but instead infers some different type that happens to match.

Re: Dada, an experimental new programming language

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

Just going to be honest here:

“Zero complexity print to the screen”

Is, quite possibly, the dumbest argument people make in favour of one language over another.

For experienced people, a cursory glance at the definitions should be enough. For new programmers, ignoring that part “for now” is perfectly fine. So to is “most programming languages, even low level ones, have a runtime that you need to provide an entry point to your program. In Java, that is public static void main. We will go over the individual aspect of this later. ”. This really is not that difficult, even for beginners.

Personally, I find more “cognitive load” in there not being an explicit entry point. I find learning things difficult when you’re just telling me extremely high level *isms.

Re: Dada, an experimental new programming language

#220
post #31

Earlier quoted context omitted.

Surely `public static void main` has less congnitive load than if __name__ == "__main__": main()

You don't have to do this, though. You can have an entrypoint.py that simply calls `main()` without that if. You don't even need to have modules if you want to, so you can write your functions and call them right after.

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.

Post reply on HN