Live data from Hacker News

Dada, an experimental new programming language

dada-lang.org

371–380 of 428 posts

Re: Dada, an experimental new programming language

#371

Earlier quoted context omitted.

A long time ago, it did have specialized syntax! We fought to remove it. There’s a variety of reasons for this, and maybe it would make sense in another language, but not Rust.

For Arc/Rc? I don't recall that! What was it? I recall it being `&borrowed`, `~boxed`, `@garbage_collected`. Aaaah, I'm realizing in typing this that the `@foo` syntax was actually implemented via reference counting? I think my intuition at the time was that the intention was for those to eventually be backed by a mark-and-sweep GC, which I did think was a poor fit for the rest of the language. But as just a syntax f…

Yes, I’m referring to @foo, which IIRC maybe in the VERY old days had a GC but from when I got involved in 2012 was reference counting, iirc.

Regardless of the specifics here, the same problems apply. Namely that it privileges specific implementations, and makes allocation part of the language.

Re: Dada, an experimental new programming language

#372
post #263

Earlier quoted context omitted.

> Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, Have you tried Ada? > so something like "func" instead of "fn" would be mandatory. What about no keywords, like: x => ...func body

> Have you tried Ada? I have tried Pascal in that sphere, which was on the too verbose side. Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.

IMO the main thing that made Pascal verbose is begin...end for all compound statements. If you ditch that - as even Wirth himself did in the next iteration, Modula-2 - the rest is much more palatable. Consider:

   (* Pascal *)
   if a > b then
   begin
       blah;
       blah;
   end
   else
   begin
       blah;
       blah;
   end;

   -- Ada
   if a > b then
       blah;
       blah;
   else
       blah;
       blah;
   end if;

   // C
   if (a > b) {
       blah();
       blah();
   } else {
       blah(); 
       blah();
   }
Pascal is clearly very verbose here, but the other two are pretty similar.

That said I think that punctuation to delimit blocks makes more sense because it makes program structure clearly distinct. Although by the same token I think I'd prefer conditionals and loops to also be symbolic operators, so that there are no keywords inside executable code, only identifiers. Basically something like "?" instead of "if", "@" instead of "while" etc.

Re: Dada, an experimental new programming language

#373
post #263

Earlier quoted context omitted.

> Have you tried Ada? I have tried Pascal in that sphere, which was on the too verbose side. Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.

IMO the main thing that made Pascal verbose is begin...end for all compound statements. If you ditch that - as even Wirth himself did in the next iteration, Modula-2 - the rest is much more palatable. Consider: (* Pascal *) if a > b then begin blah; blah; end else begin blah; blah; end; -- Ada if a > b then blah; blah; else blah; blah; end if; // C if (a > b) { blah(); blah(); } else { blah(); blah(); } Pascal is cle…

{} are isomorphic to 'begin' and 'end' in that snippet, though. Part of the reason why early programming languages were comparatively heavy on keywords is that the symbol set was not standardized across machines, so you couldn't count on some symbols being available. It's why C still supports as digraphs for curly braces, or for square brackets. Also why languages such as COBOL go as far as supporting syntax like DIVIDE X INTO Y, because the machine character set might not have a slash or divide sign.

Re: Dada, an experimental new programming language

#375
post #363

Earlier quoted context omitted.

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…

One thing that does make it kind of weird is that a lot of statically typed languages that aren't from the ML family have a grammar top level that isn't imperative. In C#, Java, Dart, etc. The top level of a source file is purely declarative.

That can make a REPL sort of semantically weird. Do you allow variable declarations? If so, are they local or global? Do you allow class declarations in them? If so, can they access previous declarations?

All of that's easier in a dynamically typed language where the top level of a program is more or less just regular imperative code.

It's not insurmountable though, because you can be a little hand-wavey about semantics in a REPL if needed.

Re: Dada, an experimental new programming language

#376
post #286

Earlier quoted context omitted.

I’m in the middle of working through The Rust Book, and I haven’t written any serious code with it yet, so interpret this through that lens. When I looked at rust code before, it all seemed a bit weird. I couldn’t immediately understand it, but I’ve since come to realize this was because the dozen or so languages I can read well don’t really resemble rust, so my pattern matching was a bit off. The more I learn about…

Yeah, I think at some point we all have some internal wiring that is hard to change, while other parts are flexible. For instance, I'm fine to write C++, Javascript or Python (with types at least). Ruby or Rust for some reason do rub me the wrong way, no matter how much I try to tough it out.

It's interesting that you mention Ruby, because Ruby is another language that just fits the shape of my brain for some reason.

I've always really struggled with the various Lisp variants.

Re: Dada, an experimental new programming language

#377

Earlier quoted context omitted.

Non .NET server-side?

You can do Node.js with F# But these days .NET is a great server-side option. One of the fastest around, with a bit of tuning.

Fable compiles F# to Python, Rust, and Dart now, too, in addition to JS. I haven't tried Dart or Rust, but when I tried compiling its output to Python it was actually quite good!

Re: Dada, an experimental new programming language

#378
post #99

Earlier quoted context omitted.

> If my goal as a programmer is to simply print to the console, why should I add care about the await? Because that isn't ever anyone's actual goal? Optimizing a language design for "Hello World" doesn't seem like a particularly useful decision.

sure, but it seems useful to be able to opt-in/opt-out of async easily. ie. if I want a short/simple program it would be cool to put a stanza on the top of the file to auto-await all futures.

I'm not a big fan of async/await in general, I just didn't think this specific complaint was particularly compelling.

Re: Dada, an experimental new programming language

#379

Earlier quoted context omitted.

You seem to be making the assumption that in other languages calling print is a blocking function that guarantees the printing of a string. Which it isn’t. In python print adds your string to the stdout buffer, which eventually gets written out to the console. But it not guaranteed, if you want that guarantee you need to call flush on the stdout IO handler. Dada has taken the approach of making blocking IO operations…

Would waiting on a mutex or signaling a semaphore require explicit awaiting in Dada? What about faulting in an mmaped memory buffer?

I honestly don’t understand why you seem to be getting so upset about this. Dada isn’t a real language, it’s a thought experiment. It’s whole purpose to ask exactly these questions, and discuss the consequences, so those learnings can be used to inform other languages.

Arguing that a particular design choice is silly from a purely ergonomic or usage perspective is kind of absurd, given you literally can’t use the language at all. Maybe waiting for a mutex, signalling a semaphore, or waiting for page faults should require an await (although it’s literally impossible for a language to await a page fault without a lot cooperation from the OS). The whole point of Dada is you can make those design choices, then work through the consequences. Maybe it turns out they’re actually fantastic ideas, once you get past the surface level issues, or maybe they’re terrible ideas. But once again, Dada doesn’t actually exist! It’s a thought experiment to test all kinds of ideas, but without having to waste all the time and energy building those ideas to discover issues that could have been discovered by simply having a conversation.

Re: Dada, an experimental new programming language

#380
post #368

Feel like there would be fewer posts and languages like this if people just took 10 seconds to read about modern C#.

If only it played well with Linux, but Mono is always playing catch-up

The latest dotnet plays reasonably well with Linux and supports latest framework and language version.
Post reply on HN