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

181–190 of 216 posts

Re: Little languages are the future of programming

#181

Post by P5fRxh5kUvp2th »

Akronymus wrote: post #127
pjc50 wrote: post #107

Earlier quoted context omitted.

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.

same, and in fact, despite using C# since before LINQ even existed, I don't even know how to write the sugar candy version of it.

Part of that is me coming from C++ and its algorithm header and the other part is that the code is just easier to read and understand than the sugar candy version (to me, atleast).

Re: Little languages are the future of programming

#182

Post by beefok »

I've always enjoyed reading this book that espouses this same idea:

Constructing Language Processors for Little Languages 1st Edition by Randy M. Kaplan [1].

It's no longer being produced, but used it's $6 or less.

It's dated, from 1994, but it is a fun enjoyable discussion on the benefit of tiny specific languages. It also has a nice tutorial on the use of lex and yacc.

[1] https://www.amazon.com/gp/product/0471597546

Re: Little languages are the future of programming

#183

Post by falcolas »

paulryanrogers wrote: post #156
falcolas wrote: post #147

Earlier quoted context omitted.

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

Forest for the trees, my dude.

Re: Little languages are the future of programming

#184

Post by williamcotton »

hinkley wrote: post #180
williamcotton wrote: post #167

Earlier quoted context omitted.

What does any of what you’ve written have to do with the concerns raised by the author of the article?

> 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. From the top level comment. It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego). Once you no longer have…

So every new language is written be a fool on an ego trip? Or are you calling me the fool?

I'm having a very hard time separating what seems to be a painful personal experience from a productive conversation about the future of programming languages.

Re: Little languages are the future of programming

#185

Post by hinkley »

williamcotton wrote: post #184
hinkley wrote: post #180

Earlier quoted context omitted.

> 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. From the top level comment. It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego). Once you no longer have…

So every new language is written be a fool on an ego trip? Or are you calling me the fool? I'm having a very hard time separating what seems to be a painful personal experience from a productive conversation about the future of programming languages.

    - Hard to onboard new hires
    - Code breaks because of lack of understanding of dependencies
    - Code changes become harder to manage
Anyone who finds these problems improved by a DSL isn’t spending time looking at what is actually making life hard for their coworkers, and therefore arrogance.

What helps me with those problems is tool selection. Picking community supported tools that fight some of these problems by allowing me to hire people who already know part of our system, and who can use a wider community as a knowledge base instead of just internal folks who have run off to work on other interesting things and don’t have the time anymore for something cool they did three years ago.

A veterinarian explained part of the dynamic to me quite some time ago: it’s better for your emotional relationship with your pet if a stranger does an uncomfortable procedure rather than you. If we use a tool with poor support at least we can bond over it as a team. If it’s Steve’s baby and he’s terrible at support that animosity turns inward, which is not just a problem, it’s the beginning of the end.

Re: Little languages are the future of programming

#186

Post by redanddead »

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

Maybe the term modular would be more appropriate than little? Every solution that has gained widespread dominance, take the shipping container, has been thanks to its flexibility, and modularity.

Re: Little languages are the future of programming

#187

Post by williamcotton »

lolinder wrote: post #179
williamcotton wrote: post #173

Earlier quoted context omitted.

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…

> 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 extending to language servers, etc. Yeah, I could see this happening, to a point. I'm not convinced it will happen, because what would be the impetus? > I remember a time when CSS and HTML had yet to be consumed by…

> what would be the impetus?

That there are many issues with general purpose programming languages such as those outlined by the author in the article?

> I suspect this is the fate of any little language that successfully eliminates the need for engineers: if we can take a piece of a domain and describe it in a DSL that is streamlined enough for no-effort onboarding, it won't take very long for the DSL to be made redundant by GUI tools that are even easier to use.

That seems ideal! Domain-specific languages have always benefited from GUI tooling alongside anything that is less clunky as textual representation.

Re: Little languages are the future of programming

#188

Post by P5fRxh5kUvp2th »

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…

funnily enough, PHP has had some version of your request for years.

Re: Little languages are the future of programming

#189

Post by kelseyfrog »

scotty79 wrote: post #73
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…

There are some modern success stories like LINQ or JSX.

or CSS (and every one of it's derivatives), GraphQL, SQL, regex. Maybe I'm misinterpreting, but each one is a language and something I'm currently using or used in the past. Little languages are everywhere.

Re: Little languages are the future of programming

#190

Post by 015a »

0x445442 wrote: post #150
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

Well, maybe this will start a flame war: I will absolutely die on the hill that SQL is shit. But, like shell, is old (48 years old!) and omnipresent; so it sticks around.

Like, the thing I find comical about the original article is: they reach for shell, regex, and SQL as Prime Example of "mini languages done right". Be more domain specific, look at this its already happening. All of those examples are kinda shit languages! They're popular because of their omnipresence. Maybe regex is "fine", though the line "try to solve a problem with a regex and now you have two problems" is well known for a reason.

But my broader opinion is: if you're building an application, service, tool, whatever in LANGUAGE_X; having to "dip out" of that language into an entirely different language should be viewed as, fundamentally, a Negative Thing. There may be reasons why you should; the good may outweigh the bad; but there is Bad there. There will always be an interpretation layer; extra tooling; that's More Things that can go wrong, have to be configured, statically analyzed, tested, its a failure point. SQL injection is a thing. Why? Because, for a time, people had the thought "hey, its a string, lets just template the string"; but that's no good, so now we have A Layer between the Java and the SQL to keep us safe. We can only support So Many Layers; we need to make things simpler, not more complex, there needs to be Fewer Things.

Its time is gone, but I'll always view Heroku Buildpacks as a paragon of system design. Consider: You could write a nodejs application in javascript, write a package.json in json (also javascript), and end-to-end get that thing on a URL on the internet, all in one language. Fantastic! Today, a typical app will have the app (say, Golang), a go.mod (different syntax than go itself), dockerfiles (language 3), kubernetes yamls (language 4), maybe helm or cdk8s (language 5), shell scripts, makefiles, maybe you're also writing sql... this isn't better and it doesn't have to be like this. But right now, it is, and to some degree I'm happy for it because its 80% of the reason why I get paid six figures.

Post reply on HN