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

141–150 of 216 posts

Re: Little languages are the future of programming

#141

Post by rng_civ »

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…

I think WASM is filling in that gap to some extent. From the spec:

> Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module

And IIRC, the core instruction set is reasonably compact.

Re: Little languages are the future of programming

#142

Post by dmux »

brundolf wrote: post #42

This is what I always heard Lisp was best at. Instead of making totally new languages (with parsers, tooling, etc) you'd create little DSLs within your own code in the form of macros: come up with a "little language" for describing one part of your app, write a macro for it, and then it integrates smoothly with everything around it Whether or not you agree this philosophy is a good one, and whether or not you like Li…

Lisp macros are nice, but as Gumby said above [0] a common approach is to use Lisp's quoting abilities to construct a data structure that represents the problem at hand (in its own terms) and then create functions to parse / manipulate that data structure.

A classic example comes from Peter Norvig's "Principles of Artificial Intelligence" wherein he defines a subset of English grammar as a data structure [1]:

  '((sentence -> (noun-phrase verb-phrase))
    (noun-phrase -> (Article Noun))
    (verb-phrase -> (Verb noun-phrase))
    (Article -> the a)
    (Noun -> man ball woman table)
    (Verb -> hit took saw liked)))
He then goes on to define a function "generate" that uses the above to create simplistic English sentences.

Additional rules can be added by a non-programmar so long as they understand how their domain logic has been mapped to Lisp.

[0] https://news.ycombinator.com/item?id=33705558

[1] https://github.com/norvig/paip-lisp/blob/main/docs/chapter2....

Re: Little languages are the future of programming

#143

Post by lolinder »

williamcotton wrote: post #130
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…

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.

Re: Little languages are the future of programming

#144

Post by francasso »

ssivark wrote: post #16

Here's something I don't understand: How are "little languages" different from a bunch of functionality wrapped into a library/module? Is it just that (with some convenient syntax sprinkled on top), or is there more to it? I would imagine that most of the value comes from being able to "refactor" thought patterns to match the best way to cleave the domain into composable concepts -- and it seems like we do this all t…

With a DSL you need to learn syntax, semantics and either the API for interacting with your GP language or the tooling for external DSLs.

With a library you just need to learn the new semantics. I much prefer this to a DSL.

Plus a library has all the debug tools the language has. DSLs usually don't have any debug tools except for printing when you are lucky

Re: Little languages are the future of programming

#145

Post by naasking »

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…

> And so on and so on. I just wished that the LUA approach of "if I don't give you a hook, you cannot do that" were just the default.

Yes, because languages are still not capability-secure. Memory-safe languages are inherently secure up until you introduce mutable global state, and that's how they typically leak all kinds of authority. If you had no mutable global state, then you can eval() all the live-long day and you wouldn't be able to escape the sandbox of the parameters passed in.

Examples of mutable global state:

* APIs: you can make any string you like, but somehow you can access any file or directory object using only File.Open(madeUpString). This is called a "rights amplification" pattern, where your runtime permits you to somehow amplify the permissions granted by one object, into a new object that gives you considerably more permissions.

* Mutable global variables: as you point out, eval() can access any mutable global state it likes, thus easily escaping any kind of attempt to sandbox it.

If these holes are closed then memory-safe languages are inherently sandboxed at the granularity of individual objects.

Re: Little languages are the future of programming

#146

Post by CyberDildonics »

A huge problem with this approach is that very few general purpose languages reach the point where they have big standard libraries, great external libraries and tools on top of them. Every time someone invents a new language it wipes away the decades of progress of the general purpose language that could be used instead, so it needs to have a massive advantage or be completely necessary.

Re: Little languages are the future of programming

#147

Post by falcolas »

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.

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/sql-2016-foundation...

Re: Little languages are the future of programming

#148

Post by williamcotton »

BiteCode_dev wrote: post #78

> SQL is a little language for describing database operations Yeah, SQL is not a little language anymore. It started as one, but because a lot has been added to it and SQL flavors for Oracle or Postgres are anything but tiny. Windowing, nesting, json handling... I think the author is kinda proving with this that a successful little language does not stay little, and hence little languages are not the future. And don'…

The reason why the author is using the term little language is because the term DSL doesn’t mean custom language any longer.

Yes, SQL is bigger than it used to be but it is still a domain specific language, which is what the article is actually about.

Re: Little languages are the future of programming

#149

Post by kwhitefoot »

I've always regarded the principal task when implementing a program to be creating the necessary data structures and a set of functions that represent a vocabulary for manipulating them. So every program I write contains a small domain specific language. Isn't this what everyone does?

'Official' small languages only make sense when the user base is large, this is why SQL exists but a mainstream language for manipulating Maxwell's equations does not.

Re: Little languages are the future of programming

#150

Post by 0x445442 »

015a wrote: post #45

Is the engineering footprint of an organization really better if everything is implemented in twenty different languages, versus just three or four? Everything else aside, quality of the language, scope, etc; just the number. You have to expect everyone to know each language; know the ins, outs, idioms, gotchas, etc. You have to be able to hire for the languages. You need the language runtimes in your environment, ev…

There’s a Groovy DSL that will allow you to perform operations on collections using SQL syntax. I’d argue it’s an improvement over the traditional procedural or functional approach’s.

https://groovy-lang.org/using-ginq.html

Post reply on HN