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

121–130 of 216 posts

Re: Little languages are the future of programming

#121

Post by scotty79 »

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…

I'd very much like to see someone coming up with nice syntax for hierarchical finite state machines and entity components systems just like people came up with nice syntax for queries in the form of linq and nice syntax for html generation in the form of jsx.

Doing these things in vanilla syntax of general purpose programing languages is not exactly great.

Re: Little languages are the future of programming

#122

Post by zelphirkalt »

LordHeini wrote: post #69

I disagree and would say DSLs should go away if possible. DSLs like SQL are the norm and you can see the problem of them in basically every project. You either use ORMs or you end up hand rolling SQL rows into Structs or Classes. The whole mapping usually looks like crap and contains a bunch of implicit corner cases, which eventually end up being a footgun for someone. Usually the SQL sever runs somewhere else, the p…

But your ORM example could be considered a DSL in itself, so it doesn't really work that well. ORMs can be implemented in various ways too, as a syntactically looking different DSL or as something like objects and method calls or whatever the language already provides.

Regexes can be abstracted from exactly by making a more readable DSL.

Config files and the stuff accepted therein are small languages as well.

What are the alternatives to making little languages?

Re: Little languages are the future of programming

#123

Post by BiteCode_dev »

cies wrote: post #85
BiteCode_dev wrote: post #64

Earlier quoted context omitted.

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…

> Small languages either become big, or are replaced by things that are big, for the same reason most people prefer a car to a horse to go shopping. So why are shell languages still around? Why are they not replaced by C#, C++, Java or another big (=general purpose) language? I find your horse->car comparison more akin to the sh->bash->zsh transition. Zsh is not as small as sh, but still it is in the small league is…

Shell languages are a very good example, because they have been replaced mostly by bigger languages. First by perl, then by python.

Now a day, most people don't write bash if it must be more than a few lines: it fits niche perfectly, like horse ridding.

But you are not going to do website with bash anymore, server swarm deployment with powershell or build your encoding pipeline in fish. Tasks that we used to do using those small languages, until we found out that we prefer a car to do shopping.

Re: Little languages are the future of programming

#124

Post by williamcotton »

adql wrote: post #102
eternalban wrote: post #77

Earlier quoted context omitted.

I only have only one experience to share. Back in mid 90s, was tasked with developing a webserver that provided targeted advertising. A requirement was providing the marketing team an accessible mechanism for defining rules. Basic stuff like encoding a marketing/ad-sale team rule such as "show ad of truck if user is male, at some age group". A little scripting language was developed, nothing fancier than conditional…

This could've probably just been Lua tho ?

Most of what Lua offers will not be a requirement for what the ad ops team needs to create and maintain campaigns and there will be specific requirements that are not easily expressed in Lua.

Re: Little languages are the future of programming

#125

Post by BiteCode_dev »

mcluck wrote: post #111
tester756 wrote: post #90

Earlier quoted context omitted.

>So why are shell languages still around? Are they? I don't use them more than once a year

I'd say you're in the extreme minority then. I'm not a bash hacker but I usually end up writing a little script for myself at least once a month. Even just doing `command && command` is technically using a shell language

So you are using bash once in a while (once a month is not a lot for a programmer) for niche use case (the specialty of bash: short scripts).

Hence, you are making the point "little languages are not the future". It has found its local optimum.

Re: Little languages are the future of programming

#126

Post by gumby »

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 a general purpose language, even though C itself derived from prior general languages (B & BCPL) and they had gotten the idea from their experience on Multics (written in PL/1, a radical idea at the time). So a 20 year old idea was still barely diffused into the computing Zeitgeist.

Most Lisp development (since the early 70s at least) is writing a domain-specific representation (data structures and functions) and then writing your actual problem in it. I used both Lisp and Smalltalk this way at PARC in the early 80s.

More rigid languages (the more modern algolish languages like python, c++, rust, C, js etc -- almost every one of them) doesn't have these kind of affordances but instead do the same via APIs. Every API is itself a "little language"

What are called little languages in the Bently sense is simply a direct interface for domain experts. And after all what was a language like, say, Macsyma but a (large) "little language"?

Re: Little languages are the future of programming

#127

Post by Akronymus »

pjc50 wrote: post #107
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.

SQL persists because it's an interchange format, not just a programming language. It's one of the few programming languages you'll see embedded in other languages - and generating SQL from other languages is a common source of security bugs. You can't upgrade away from SQL without changing both ends of that connection. You can write large programs in SQL, but it's generally considered good practice not to. (I feel I…

For LINQ, I personally vastly prefer the fluent version (IEnumerable.Select(..).Where(...) and so on) over the SQl like syntax.

Re: Little languages are the future of programming

#128

Post by cultofmetatron »

geysersam wrote: post #104
BiteCode_dev wrote: post #64

Earlier quoted context omitted.

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…

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.

SQL is a beast of a language and there's definitely room for improvement. Also it's not Turing complete

Re: Little languages are the future of programming

#129

Post by Octoth0rpe »

LordHeini wrote: post #69

I disagree and would say DSLs should go away if possible. DSLs like SQL are the norm and you can see the problem of them in basically every project. You either use ORMs or you end up hand rolling SQL rows into Structs or Classes. The whole mapping usually looks like crap and contains a bunch of implicit corner cases, which eventually end up being a footgun for someone. Usually the SQL sever runs somewhere else, the p…

> DSLs like SQL are the norm and you can see the problem of them in basically every project.

I think your points re: sql are true of straightforward crud apps, but not true at all of an analytics app. In those cases, the sql is often _very_ complex, and while the results of a query may be eventually mapped into a struct or something, the query generation is rarely a simple mapping of properties in an object to select columns.

> There are a billion dialects and every single one of them is basically unreadable, incomplete or just weird.

Sure, but in the vast majority of cases, one only has to deal with at most 3 dialects, and there's a good chance you won't be hitting the corner cases that make each dialect significantly different.

Re: Little languages are the future of programming

#130

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…

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 writing glue code that takes orders of magnitude more memory and CPU time.

2.) Static analysis. This means tools that are better at finding bugs, finding optimizations, visualizing structure, etc.

Post reply on HN