Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Little languages are the future of programming

chreke.com

Post reply on HN
Print view View original

151–160 of 216 posts

Re: Little languages are the future of programming

#151

Post by garethrowlands »

btschaegg wrote: post #22

On that note: Am I the only one that's constantly surprised by the absence of proper sandboxing solutions when so many programming languages now provide (otherwise pretty useful) means of running code dynamically in a script-like fashion? In C#, I can pull in Roslyn, and compile a string on the fly as a C# script; but the way the .NET standard library is structured makes it pretty much unfeasible to prohibit outside…

Your best approach is to run untrusted code in a separate process in a sandbox. Language developers don't normally deal with hostile users in the same way that os developers do.

Re: Little languages are the future of programming

#153

Post by williamcotton »

lolinder wrote: post #143
williamcotton wrote: post #130

Earlier quoted context omitted.

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is wr…

Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.

Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.

Re: Little languages are the future of programming

#154

Post by giraffe_lady »

oscarb92 wrote: post #152

I am very familiar with DSLs but had not heard them called "little languages". I cannot say I find it fitting as it makes me think more of languages with reduced syntax or semantics.

I haven't done any research on this but I suspect that usage predates "DSL," or at least was popular before the term DSL was widely known and used for it. I mostly see "little language" used in older sources, mid-90s or earlier.

It seems to be making a comeback though! I prefer it too. It's not really more descriptive than DSL but it's not much less, and is less jargony and just cuter.

Re: Little languages are the future of programming

#155

Post by williamcotton »

BiteCode_dev wrote: post #64
AlotOfReading wrote: post #11

People 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…

Indeed. That's why we have languages with functions now, because people didn't want to manually do a register dance in assembly. That's why we have name spaces, because naming conventions only take you so far. That's why we have map and filter (or equivalent) because that's what most loops are doing anyway. Generation after generation, we discover that we all use common abstractions. We name them design patterns, the…

The irony of your horse analogy is that a horse is more general purpose than a car. A horse can travel along train tracks, roads, sidewalks, and hiking trails.

Re: Little languages are the future of programming

#156

Post by paulryanrogers »

falcolas wrote: post #147
geysersam wrote: post #104

Earlier 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…

SQL has MERGE

Re: Little languages are the future of programming

#157

Post by giraffe_lady »

valenterry wrote: post #58
Spark_Ed wrote: post #18

Earlier quoted context omitted.

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

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 written in.

Some languages are particularly suited for this but other than racket and ruby it seems mostly accidental/incidental to their design.

Re: Little languages are the future of programming

#158

Post by dinosaurdynasty »

lolinder wrote: post #143
williamcotton wrote: post #130

Earlier quoted context omitted.

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is wr…

Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.

There are certain kinds of analysis a non Turing complete language can have that a Turing complete language can never have.

Re: Little languages are the future of programming

#159

Post by packetlost »

Verdex wrote: post #133
gumby wrote: post #126

Little languages are the past and yes, the future. We just don't recognise them. It was common in the 60s and 70s to have the hardware manufacturer ship all the OS and languages with their hardware. The languages were often designed for specific problem domains. The idea of general purpose languages (FORTRAN, PL/1, etc) was uncommon. You can see this in K&R (the original edition anyway) where they justify the idea of…

> Every API is itself a "little language" I came to this conclusion early in my career. It went something like this: A - "To do this, just create this object, fill in these properties, and call these methods." B - "Okay, I did that, but it crashed." A - "Yeah, it's because you set the properties in the wrong order. This property relies on this other property under the hood. Set them in this order." B - "Still crashes…

DSLs and API are fundamentally the same thing, they're making decisions for the user so they can be sped up and reduce cognitive load. The only difference is the manner in which it's expressed. It turns out functions and interfaces are a pretty good way to express... most things you want to do in a program. Lisp acknowledges this and runs with it.

IMO we need a language (or library?) that forces builders of an API to make incorrect behavior hard or impossible. Here's some scribbled out ideas: https://packetlost.dev/blog/lang-scribbles/

Re: Little languages are the future of programming

#160

Post by williamcotton »

dinosaurdynasty wrote: post #158
lolinder wrote: post #143

Earlier quoted context omitted.

Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.

There are certain kinds of analysis a non Turing complete language can have that a Turing complete language can never have.

I think I figured out the issue in this discussion. The article is actually about general purpose vs domain specific and not really about big and little… and unfortunately since most “DSLs” are APIs written for in general purpose languages the author resorted to using the term “little language”.
Post reply on HN