Hacker News Reader

Comment by benrutter | Hacker News Reader

I love the idea of a "thought experiment language" - actually creating a working language is a big overhead, and its really fun to think about what an ideal language might look like.

The crazy thing with reading this and the comments, is that it seems like we all have been daydreaming about completely different versions of a "high level rust" and what that would look like. For me I'd just want a dynamic run time + simpler types (like "number" or a single string type), but it looks like other people have a completely different list.

Some of the additions here, like a gradual type system, I would really not want in a language. I love gradual type system for stuff like Python, Typescript and Elixir, but those are cases where there's already so much untyped code written. I would way prefer the guarantees of a fully static typed codebase from day one when that's an option.

View on HN

In college, my programming languages class used a language called "Mystery" (I believe created by my professor), which was configurable. Assignments would be like "write some test programs to figure out whether the language is configured to use pass-by-value or pass-by-reference". And there were a bunch of other knobs that could be turned, and in each case, the idea was that we could figure out the knob's setting by writing programs and seeing what they did.

I loved this, both as a teaching aid, and as an eye-opener that programming languages are just an accumulation of choices with different trade-offs that can all go different ways and result in something that works, perhaps a bit better or perhaps worse, or perhaps just a bit more toward or away from one's own personal taste.

This is sort of the lisp idea of "create the language that is natural to write the application in, then write the application". Or Ruby's take on that idea, with more syntax than lisp but flexible and "human" enough to be DSL-ish.

But somewhat to my sadness, as I've progressed in my career, I've realized that the flip side of this is that, if you're building something big it will require lots of people and all those people will have different experiences and personal preferences, so just picking one standard thing and one standard set of defaults and sticking with that is the way to go. It reduces cognitive overhead and debate and widens the pool of people who can contribute to your effort.

But for personal projects, I still love this idea of thought experimentation around the different ways languages and programming environments could work!

Don't be so quick to discount DSLs. Sure, you don't want a half-baked DSL when some simple imperative code would do. But if you watch your API evolve into an algebra and then don't formalize it with a DSL you might be leaving powerful tools for understanding on the table.

A poor-fitting language is terrible for abstract thinking, on the other hand an internally-consistent and domain appropriate language can unlock new ways of looking at problems.

I'd highly recommend Martin Fowler's work on DSLs to see how you can apply these techiques to large projects.

A related notion is that you need strong, well-thought out, and when the system is changing, regularly refactored abstractions. You might not need a DSL but your class/type/trait designs needs to be sane, your API needs to be solid, etc ... DDD principles are key here.

Yes, eat your vegetables!

A question of philosophy: If you have all that, don't you already have a DSL, using a deep embedding in the host language?

I certainly think so. Or at least I find it very helpful to think about interface design that way. It's DLS's all the way down.

Yes, but the language in which you create your framework can do a lot of the heavy lifting. For example, if your main interface is a REST API, there is a large body of knowledge of best practices, educational resources, and existing tools for interacting with it.

With a new DSL, you need to create all of that yourself.

The point I (and it seems several others here) are trying to make is that your API already is a DSL, the question is just whether it's a good one or a bad one.

A good one is internally consistent so that users have predictability when writing and reading usage. A good one uses the minimum number of distinct elements required for the problem domain. A good one lets the user focus on what they're trying to do and not how they need to do it.

The principles apply regardless of interface. Physical device, software UI, API, DSL, argument over HN, it's all a continuum.

The problem a lot of people have with DSLs is… well, just look at a prime example: SAS.

If you’re an experienced programmer coming in to SAS, your vocabulary for the next LONG time is going to consist primarily of “What The Fuck is this shit?!?”

What do you mean? Computations very naturally organize into batches of 40 cards each.

I hated SAS with a passion when I was forced to work with it for 2 years. One of the biggest problems I faced was, it would take me a long time to find out if something was doable or almost impossible in that language.

It wanted to be more than just SQL, but the interoperability with other languages was awful, we couldnt even work with it like SQLite.

Given that the GitHub repo is almost three years old, I expect Martin Fowler to already have Dada Patterns, Refactoring in Dada, Dada Distilled, Dada DSL and Dada Best Practices ready to publish.

Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeholders of the project the idea of trusting one person for all the development.

So in addition to the skill of creating a DSL, you need the skills of thoroughly documenting it, training other people to use it, creating tools for it, and explaining the benefits in a way that gets them more excited than just using an existing Boring Old Programming Language.

Which is certainly possible. You can get non developers excited if they can use it for answering their own questions or creating their own business rules, for example. But it's a distinct skill set from cranking out code to solve problems. It requires a strong understanding of the UX (or DX) implications of this new language.

I’m of the mindset that API and DSL are more of a continuum than categories. As soon as you write your first abstraction, you’re making a little language.

In the same way, what you listed isn’t a distinct skill set from cranking out code to solve problems. What happens is those skills are now levered. Not the good vibes “leveraged”. I mean in the “impact to success and failure is 100x baseline” sense. If those skills are in the red, you get wiped out.

Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor.

This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html

No, for Boring Old Language other people have already solved those problems for you.

Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is.

So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor.

You don't get buy-in with technology, you get buy-in with ideas.

amen to this … i recommend thinking about your problem in terms of effective data structures and then apply even a very simple DSL to handle access and transformations … fwiw the built in Grammars and Slang support in raku https://docs.raku.org are fantastic tools for this job.

Was your professor Amer Diwan? His Principles of Programming Languages course was amazing.

This is one of his papers in Pl-Detective and Mystery for anyone interested: https://www.researchgate.net/publication/220094473_PL-Detect...

Yep :) I thought there would probably be some folks here who would recognize this.

Is this Mistery this Mistery [1]?

[1] https://blog.brownplt.org/2018/07/05/mystery-languages.html

Nope, but if you click into their paper[0] and follow the link to PL-Detective[1] there, that's the one! (Hat tip to another commenter who was also familiar with this.)

0: https://cs.brown.edu/~sk/Publications/Papers/Published/pkf-t...

1: https://dl.acm.org/doi/10.1145/1086339.1086340

> 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.sigfpe.com/2009/02/beyond-monads.html
  [2] https://www.cs.tufts.edu/comp/150FP/archive/oleg-kiselyov/overlooked-objects.pdf
  [3] http://functorial.com/Embedding-a-Full-Linear-Lambda-Calculus-in-Haskell/linearlam.pdf

Work in [3] can be expressed using results from [1] and [2], I cited [3] as an example of what proper type system can do.

These results were available even before the work on Rust began. But, instead of embedding Rust-DSL into Haskell, authors of Rust preferred to implement Rust in OCaml.

They do the same again.

> instead of embedding Rust-DSL into Haskell, authors of Rust preferred to implement Rust in OCaml

why? and how much does it matter, if the goal is to have a compiler/interpreter? (as I assume is the case with Dada, and was with Rust)

R&D. Bootstrapping.

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.

I suspect the GP was merely suggesting a less-costly alternative. Perhaps building a complete standalone compiler or interpreter is hard, but we're all designing APIs in our programming languange of choice day in and day out.

Both strategies are very hard, but one of then is "build a prototype in a weekend" hard and one of them is "build a prototype is a month" hard.

It is interesting to consider how much the lower abstraction influences the higher abstraction. If you are building on a existing language/runtime/framework then you can inherit more functionality and move faster, but also you implicitly will inherent many of the design decisions and tradeoffs.

Very good point. See, for instance Kiselyov's embedding of his tagless final form: https://www.okmij.org/ftp/tagless-final/course/lecture.pdf

totally. for me the interplay between the host language and the target language is hardest thing for me to manage when bringing up a new environment. it really doesn't seem like it should be a big deal, but it comes down to the sad reality that we operate by rote alot of the time, and completely switching semantic modes when going between one world and the other is confusing and imposes a real cost.

I'm still not that good at it, but my best strategy to date is to try to work in a restricted environment of both the host and the target that are nearly the same.

You can have target language to be as far fom host language as you like.

For one example, again, borrowed fom Haskell universe, is Atom [1]. It is a embedded language to design control programs for hard real-time systems, something that is as far from Haskell area of application as... I don't know, Sun and Pluto?

[1] https://hackage.haskell.org/package/atom-1.0.13

I'm sorry - of course you can. my problem is that switching back and forth I internally get them confused. and I start moving the target language to be closer to the host. while this might be my failing alone, I've seen this happen quite a bit in other language design projects.

Right - in theory any turning-complete-language can bootstrap any other turning-complete-language. But in practice some of the convections and approaches are going to be mixed via some combinations of cognitive load, laziness/inertia, ease of development, etc ...

Creating a "new" programming language isn't that difficult - creating something that is interesting, elegant and/or powerful requires a lot of thought and that is difficult.

For me, creating a new programming language which is suitable for general purpose programming would be extremely hard, regardless of how novel or good it is. But, fair point that "hard" is always subjective.

I think I was being over literal about the "language" part - it's certainly possible to create a very simple language in a short time but actual productivity would require a lot of libraries and tooling and I suspect that is much more work than the core language.

Quite the contrary.

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.

Runtime would be nice, but ... that's basically what Tokio and the other async frameworks are. What's needed is better/more runtime(s), better support for eliding stuff based on the runtime, etc.

It seems very hard to pick a good 'number' (JS's is actually a double-precision 64-bit IEEE 754 float, which almost never feels right).

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 library, or decimal or whatever, but easily change the declaration and get all the benefits, without needing to modify downstream code that respects the interface and doesn't rely on a more specific type (which would be enforced by the type system and thus not silent if incompatible).

That sort of stuff is easy to do with Truffle (which, ironically, lets you define a language using what they call the "truffle dsl").

The SimpleLanguage tutorial language has a bigint style number scheme with efficient optimization:

https://github.com/graalvm/simplelanguage/blob/master/langua...

"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 big num integers, but its "float" is just Rust's f64, the 64-bit machine integers again but wearing a funny hat, not even a decimal big num, and decimal isn't much better.

I don't know why you think it implies reals. Most people would assume BigDecimal

Probably most people want accurate fractions (1/3), so they likely want Rationals. Of course machine-adjacent minds probably immediately want to optimize it to something faster.

I've never needed accurate fractions, except for one case where I should have stored the width and the height of the image as the original figures instead of trying to represent it as a fraction. But that's not a big issue, there's literally no downside to having width and height of the image as integers.

I see no reason why I would need to represent it as an accurate fraction instead of two numbers, even if I divide it later I can always just do that inaccurately since the exact aspect ratio doesn't matter for resizing images (<1% error won't affect the final result)

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.

> (but then why not complex? etc)

Note parent said "at least the reals"

"God made the integers, and all the rest is the work of man."

- Leopold Kronecker

For what it's worth, Moonbit (https://www.moonbitlang.com/) is a really nice take on this. Designed by the guys who created Rescript for OCAML, but for WASM-first world.

Wow, that's nice. I didn't know about that one. Thank you for posting!

Have you played at all with Gleam?

https://gleam.run/cheatsheets/gleam-for-rust-users/

This was my first thought too. I've not used it (just clicked through the tutorial) but it has a strong flavor like "Rust, but pleasant".

The gradual type systems you're referring to are bolted onto the languages, or in Elixir's case, the runtime. If you want to see what a language with a deeply integrated gradual type system is like, take a look at Julia. I've found it to be both expressive and precise.

The challenge of thought experiments, in a statically typed language, is ensuring soundness. The first version of Java Generics, for example, was unsound: https://hackernoon.com/java-is-unsound-28c84cb2b3f

I agree, fantasy and play is needed. Since we humans have a brain area for play and imagination, why not explore.

Isn't Rust a "high level rust"?

Reply on news.ycombinator.com