No post body was provided.
Little languages are the future of programming
191–200 of 216 posts
Re: Little languages are the future of programming
#192Earlier quoted context omitted.
I think one of the biggest counter examples to your argument is SQL. It's been around a long time. It's not general purpose. It's considered the best option there is if your setup allows you to use it.
As to not repeat the same argument: https://news.ycombinator.com/item?id=33704199
It's still quite little compared to general purpose languages with similar expressive power in the same domain.
Re: Little languages are the future of programming
#193Earlier quoted context omitted.
I think one of the biggest counter examples to your argument is SQL. It's been around a long time. It's not general purpose. It's considered the best option there is if your setup allows you to use it.
Somewhat pedantic argument: SQL is kinda dead. Sure, modern databases use upgraded dialects of it, but they are custom to each database and often incompatible with plain SQL. There are even many cases where modern databases don't support even standardized SQL constructs. The easiest example of where databases and SQL part ways: UPSERT. It doesn't exist in standard SQL. ref. https://jakewheat.github.io/sql-overview/sq…
Many modern products use SQL. Supabase and BigQuery comes to mind, but the examples are basically inumerable.
There are others of course. But I'd rather call SQL challenged (by graphql etc.) than dead.
Re: Little languages are the future of programming
#194Earlier quoted context omitted.
Regarding CMake’s horrific documentation: I will literally be willing to pay money for someone who can show me how/if it’s possible to wire in a different language to CMake! I believe it’s possible, I’ve seen some functions deep in the crappy docs that make it look like it is, but I cannot for the life of me work it out. The language in question produces C object files!
CMake is pretty simple internally. Every "keyword" is a function call. Every function call is implemented as a class. The simplest way to hijack it would be to have a function that calls out to your external interpreter/tool with the state you want. I could see doing that in a couple of ways: * Add a builtin command [1] that takes a string or filename and calls the interpreter with any additional data you want to pas…
Champion! That’s exactly what I’ve been looking for haha
I’m trying to remove the need for external commands to compile Nim when used with ESP-IDF for embedded firmware development, which is dependent on CMake.
Going to take a crack at this today :)
Re: Little languages are the future of programming
#195Earlier quoted context omitted.
SQL has MERGE
Forest for the trees, my dude.
Then let me address the forest. Modern DBs offer SQL as an on-ramp for the most common DML and querying. This further entrenches it as a data language and why SQL just won't die.
There are always more proprietary methods where one needs them. That doesn't mean SQL is dying, it means SQL will likely grow to include some of those too.
Re: Little languages are the future of programming
#196This is a “deepity”. We already do this. We constantly do this in programming: “The idea is that as you start to find patterns in your application, you can encode them in a little language—this language would then allow you to express these patterns in a more compact manner than would be possible by other means of abstraction. Not only could this buck the trend of ever-growing applications, it would actually allow th…
Maybe the author is trying to predict that there will be boom in DSLs like there was for JS frameworks? Funnily enough, I'm just wrapping up a DSL for our in-house web component engine that creates an abstract data layer all components share. The pattern was easy enough that I'll probably build more DSLs like it when an API isn't flexible enough
No post body was provided.
Re: Little languages are the future of programming
#197DSLs and general purpose languages are not comparable. DSLs are generally designed to handle data, while general purpose languages can handle everything. Where DSLs fall apart is when you either need to (a) work with I/O in a different format than the DSL handles data in (including working with hardware) or (b) the scope of data changes into something that now incorporates information outside the DSL’s domain.
For (a), a simple example is an application that reads information from a DAQ, stores it in a database in a compressed format, and later sends the data to a printer. We have a DSL that can easily implement the database, but we need to translate the data from the DAQ into a compatible input, so that requires a different language. Furthermore, the printer requires postscript, so we need some other language or tool for that. Then we need to figure out how to glue it all together. In some cases, it becomes tempting to try to ‘hack’ the DSL into trying to do things it was never designed for.
Or we could just use a general purpose language and libraries.
Re: Little languages are the future of programming
#198Earlier quoted context omitted.
The better the programming language, the less need for a custom language. You can then create the DSL inside of the host language. This requires flexibile syntax to some degree and a fairly advanced typesystem if it should be statically typed - hence not too many languages are a good choice here.
I don't think there's anything in that comment to indicate that they didn't do it that way. There's a robust discussion about this elsewhere, but people making embedded DSLs is basically routine. They just don't always call them that or have awareness that what they're doing fits that description. But almost all of those will be written in the "host language" of just whatever the containing system happens to be writt…
Right - but to me it sounded more as if there would be specific new languages being invented, since the author gave Lua and Dhall as examples.
Re: Little languages are the future of programming
#199People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. The problem is that your DSL has to be understood by other people, including future you. Programming tasks are vast, combinatorially explosive state spaces full of weird potential interactions between features…
That's not the way to see the process. We have been highly successful at little languages already: they are, in essence, why when I write something like "a = a + 1" I can assume it works identically in C, Javascript, and Python. (Semantically, it doesn't! But it is a portable intent.)
You might object and say, "but variable assignment and addition, that's a big language thing." It isn't, though; it's just an infix expression. And infix didn't pop out of nowhere; it had to be invented as part of the gradual creep upwards from machine level "coding" into a more abstract semantics. Infix parsers are small, and while the complete language is larger, what it's presenting is infix-compatible. "Regex" is the same way: there is a general definition of regular expressions, and then there are some common variants of regex, the implemented semantics.
The boundary between "the language needs its own compiler and runtime support" and "the language exists as an API call you pass a string into, which compiles into data structures visible to the host language" is a fluid one. And the most reasonable way of making little languages involves seeing the pattern you're making in your host and "harvesting" it. In the previous eras, there were severe performance penalties to trying to bootstrap in this way, and so generating a binary was essential to success. But nowadays, it's another form of glue overhead. If you define syntactic boundaries on your glue, it actually becomes easier to deal with over time.
Documentation-wise, it's the same: if the language is sufficiently small, it feels like documentation for a library, not a language.
Re: Little languages are the future of programming
#200Earlier quoted context omitted.
My point isn't that the big languages can do everything that a little language could theoretically do, it's that the little languages won't have the resources to pull them off, nor will they have the resources to even do what the big languages do. Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little langu…
Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them. I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion ext…
It is a fruitful area for research! Truffle is an example of the sort of framework you mean. Implement a parser+interpreter using Truffle and you get JIT compilation, GC, debugging, profiling and more stuff for free on top of the JVM.