the contrast of the links against the light background is pretty poor
Dada, an experimental new programming language
211–220 of 428 posts
Re: Dada, an experimental new programming language
#212Earlier 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?
Re: Dada, an experimental new programming language
#213It'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...
That has changed through the years: https://graydon2.dreamwidth.org/307291.html
Re: Dada, an experimental new programming language
#214Earlier 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. :)
Re: Dada, an experimental new programming language
#215Earlier 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.
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
#216Re: Dada, an experimental new programming language
#217Rust 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
#218Earlier 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…
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
#219Their 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.
“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
#220Earlier 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.
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.