331–340 of 428 posts
It's a bit frustrating that I have to click around hunting for an example of the syntax. If you are making a new programming language, please do us a favor and put your Hello World syntax example right on the landing page.
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.
Earlier quoted context omitted.
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.
Yes! Thank you! Dunno what it is about Rust that makes everyone forget what premature optimization is the root of all of.
I tell everybody to .clone() and (a)rc away and optimize later. But I often struggle to do that myself ;)
Earlier quoted context omitted.
> actually creating a working language is a big overhead Languages, with first class values, pattern matching, rich types, type inference and even fancy RTS, often can be embedded in Haskell. For one example, it is very much possible to embed into Haskell a Rust-like language, even with borrow checking (which is type-checking time environment handling, much like linear logic). See [1], [2] and [3]. [1] http://blog.si…
Are you suggesting that creating a new programming language from scratch is a trivial exercise? If yes, wow. If no, I think the intention of your comment could be more clear, particularly regarding the quote you took from the original comment.
You need to use existing facilities (type checking, pattern matching combinators, etc) of a good implementation language as much as possible before even going to touch yacc or something like that.
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.
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.
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 explicit, rather than purely implicit. The result is that if you want to perform an IO operation, you need to explicitly say when you want to block, rather than allowing an elaborate stack of runtime buffers dictate what happens immediately, what happens later, and what going to block further code execution.
In short this completely exists in other languages like Python, you’ve simply not be aware of it, or aware of the nuanced was in which it fails. But if your someone whose wasted hours wrestling with Python IO system, then you’ll appreciate the explicit nature of Dada’s IO system.
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.
The key though is probably to have a strong Number interface, where the overhead of it being an object is complied away, so you can easily switch out different implementations, optimize to a more concrete time at AOT/JIT time and have clear semantics for conversion when different parts of the system want different concrete numeric types. You can then have any sort of default you want, such as an arbitrary precision l…
The SimpleLanguage tutorial language has a bigint style number scheme with efficient optimization:
https://github.com/graalvm/simplelanguage/blob/master/langua...
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…
Earlier quoted context omitted.
A smart print() implementation may check if there's enough output buffer, and, if so, quickly return a Future which has already completed. A smart scheduler can notice that and not switch to another green thread.
One can argue that in the VAST majority of instances, you'll never ever be printing so much that you'll fill the buffer. If you need that kind of control, just get a direct stream to stdout, otherwise make print() block if it needs to.
Earlier quoted context omitted.
You might like Kotlin. It'll also give you access to the entire JVM ecosystem.
Is that a blessing or a curse?
Most people don't. That's not the fun part of language design.