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

351–360 of 428 posts

Re: Dada, an experimental new programming language

#351

Post by elevatedastalt »

wredue wrote: post #220
abdusco wrote: post #31

Earlier quoted context omitted.

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.

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.

Re: Dada, an experimental new programming language

#352

Post by kaba0 »

sanderjd wrote: post #350
kaba0 wrote: post #312

Earlier quoted context omitted.

Scala is an absolutely small language. It is just very expressive, but its complexity is quite different than, say, Cpp’s, which has many features.

In my view you have compared it to the only other language for which it is small by comparison :) But different strokes for different folks! I have nothing against Scala, its multi-paradigm thing is cool and impressive, it just isn't for me except by way of curiosity.

Could you list all the features you are thinking of?

Re: Dada, an experimental new programming language

#353

Post by sanderjd »

steveklabnik wrote: post #237
sanderjd wrote: post #107

Earlier quoted context omitted.

Honestly, I think syntax for Arc (and/or Rc or some generalization of the two) and more "cultural" support for writing in that style would have benefitted rust back when 1.0 was being finalized. But I think the cow is out of the barn now on what rust "is" and that it isn't this.

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 for reference counting, I honestly think it might have been an ok fit.

Or maybe not, I'm ambivalent. But the syntax thing in my comment is more of a red herring for what I think is more of a cultural "issue" (to the small extent it is an issue at all), which is that most Rust projects and programmers seem to try to write in a style that defaults to only choose reference counting when they must, rather than using a style of optimizing them out if they show up in a hotspot during profiling.

Re: Dada, an experimental new programming language

#354

Post by iopq »

nu11ptr wrote: post #212
BoppreH wrote: post #192

Earlier quoted context omitted.

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.

Just require it for public functions. Your own code can be as messy as you want unser the hood

Re: Dada, an experimental new programming language

#355

Post by iopq »

sanderjd wrote: post #107
afavour wrote: post #55

Earlier quoted context omitted.

I like Rust’s type system just fine but for me it’s types combined with language features like matching that draw me to Rust. When I was still learning I made an entire project using Arc with no lifetimes at all and it was actually a great experience, even if it’s not the textbook way to use Rust.

Honestly, I think syntax for Arc (and/or Rc or some generalization of the two) and more "cultural" support for writing in that style would have benefitted rust back when 1.0 was being finalized. But I think the cow is out of the barn now on what rust "is" and that it isn't this.

@gc references were Arc under the hood!

Re: Dada, an experimental new programming language

#356

Post by iopq »

keeperofdakeys wrote: post #179
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 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 @blah references were actually just Arc sugar

Re: Dada, an experimental new programming language

#357

Post by int_19h »

tialaramex wrote: post #262
benrutter wrote: post #97

Earlier quoted context omitted.

Yes, that's true - "number" is probably more broad than I'd really want. That said, python's "int", "float" and "decimal" options (although decimal isn't really first class in the same way the otherse are) feels like a nice balance. But again, its interesting the way even that is probably a bias towards the type of problems I work with vs other people who want more specification.

"Number" implies at least the reals, which aren't computable so that's right out. Hans Boehm's "Towards an API for the Real Numbers" is interesting and I've been gradually implementing it in Rust, obviously (as I said, they aren't computable) this can't actually address the reals, but it can make a bunch of numbers humans think about far beyond the machine integers, so that's sometimes useful. Python at least has the…

I would argue that what "number" implies depends on who you are. To a mathematician it might imply "real" (but then why not complex? etc), but to most of us a number is that thing that you write down with digits - and for the vast majority of practical use cases in modern programming that's a perfectly reasonable definition. So, basically, rational numbers.

The bigger problem is precision. The right thing there, IMO, is to default to infinite (like Python does for ints but not floats), with the ability to constrain as needed. It is also obviously useful to be able to constrain the denominator to something like 10.

The internal representation really shouldn't matter that much in most actual applications. Let game devs and people who write ML code worry about 32-bit ints and 64-bit floats.

Re: Dada, an experimental new programming language

#358

Post by int_19h »

avianlyric wrote: post #336
MatthiasPortzel wrote: post #111

Earlier quoted context omitted.

It’s not an end goal, maybe, but if I’m writing a complex program and I want to print to the console for logging or debugging or status, I shouldn’t have to think about the design of that print-call. I would like to be able to focus on the main complexity of the program, rather than worry about boiler-plate complexity every time I want to print.

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…

It's trivial to tell Python to block on all stdout writes, though. You don't have to do it on every call.

Re: Dada, an experimental new programming language

#359

Post by sanderjd »

dartos wrote: post #238
sanderjd wrote: post #103

Earlier quoted context omitted.

> The whole point of rusts type system is to try to ensure safe memory usage. It isn't though. The whole trait system is unnecessary for this goal, yet it exists. ADTs are unnecessary to this goal, yet they exist. And many of us like those aspects of the type system even more than those that exist to ensure safe memory usage.

It is the first and foremost goal of every language choice in rust. I think traits muddy that goal, personally, but their usefulness outweighs the cost (Box ) I should’ve probably said “the whole point of rusts type system, other than providing types and generics to the language” But I thought that went without saying

> It is the first and foremost goal of every language choice in rust.

It ... just ... isn't, though.

I mean, I get what you're saying, it's certainly foundational, Rust would look incredibly different if it weren't for that goal. But it just isn't the case that it is "the first and foremost goal of every language choice in rust".

I followed the language discussions in the pre-1.0 days, and tons of them were about making it easier and more ergonomic to create correct-if-it-compiles code, very often in ways that had zero overlap with safe memory usage.

Traits don't "muddy that goal", they are an important feature of the language in and of themselves. Same thing with the way enums work (as arithmetic data types), along with using Option and Result for error handling, rather than exceptions. Same thing with RAII for tying the lifecycle of other resources to the lifecycle of values.

The memory safety features interact with all these other features, for sure, and that must be taken into account. But there are many features in the language that exist because they were believed to be useful on their own terms, not in subservience to safe memory usage.

And it's not just about "providing types and generics to the language", it's a whole suite of functionality targeted at static correctness and ergonomics. The ownership/lifetime/borrowing system is only one (important!) capability within that suite.

Re: Dada, an experimental new programming language

#360

Post by iopq »

jokethrowaway wrote: post #60
DinaCoder99 wrote: post #20

Earlier quoted context omitted.

I personally find the semantics of javascript a lot harder to internalize than rust due to its scoping and very unintuitive object system. I can't imagine this is any more difficult than that.

I agree but most modern JS doesn't use prototypal inheritance. JS has plenty of bad parts you shouldn't use. Classes are the main one.

I had a coworker who wrote

    return 
        { ... }
And JS helpfully inserted a semi-colon after return

This is a feature you need to know about and you have to go out of your way not to get rekt by it

Post reply on HN