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

101–110 of 216 posts

Re: Little languages are the future of programming

#101

Post by benj111 »

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…

Would you (mis)use c to do text processing, or would you use shell tools?

I suppose all this leads me to the suspicion that little languages fill in for shortcomings in big languages. Big languages can absorb the things that work, this negating the need for small languages in that sphere.

Although how far can that go? Can we keep making ever bigger languages? Or at some point does it crumble under its own weight?

Re: Little languages are the future of programming

#102

Post by adql »

eternalban wrote: post #77
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 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 ?

Re: Little languages are the future of programming

#103

Post by adql »

kaba0 wrote: post #62

While I also believe several commenter’s opinion that libraries, frameworks can easily become DSLs themselves (e.g. isn’t Java streams basically a DSL for stream processes inside another language?), one really can’t talk about polyglottism without mentioning the ingenuity of GraalVM. You basically write a dumb, easy parser and AST interpreter for your language, and it will magically turn into a JIT compiled dynamic l…

Yes but library that turns a part of syntax of language into DSL to solve certain problem have advantage of developers already knowing that language, developers needing to learn only one language, and ability to use with that DSL anything else language libraries offer.

The problem is really "does the language app uses works for target audience that will be doing the DSL". If it does (Ruby makes pretty decent one), job done, if it doesn't, we end up in the mess of making toy languages (usually because developers want to do something fun and writing new small language can be pretty fun) or plugging something like Lua into it.

Re: Little languages are the future of programming

#104

Post by geysersam »

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…

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.

Re: Little languages are the future of programming

#105

Post by nigamanth »

Wouldn't that require programmers to use 50 languages in a project though? Assuming that this is the future of programming, the number of languages that a programmer would have to learn to create a simple project would be ridiculous.

Why use many languages when you can do the same process in one? Sure, even if the "big" language isn't specifically made for a certain job, doing that job in a little language requires time for the programmer to learn the little language.

The syntax may be different, so to convert from the big languages to little languages it would take time. This is why this hasn't happened yet; people are lazy to learn new languages so they just learn the "big" languages that can complete all the tasks that they require.

Re: Little languages are the future of programming

#106

Post by bvrmn »

It seems DSL proponents grow from environment without rich standard library.

And classic Knuth argument, of course. It's so hard to count words. General purpose language:

    >>> from collections import Counter 
    >>> import re
    >>> Counter(re.findall('\w+', 'boo foo  boo +dfd zii')).most_common(1)
    [('boo', 2)]

Re: Little languages are the future of programming

#107

Post by pjc50 »

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 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 ought to mention LINQ here, not to make any specific point but just to fanboy about it)

Re: Little languages are the future of programming

#108

Post by girvo »

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…

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!

Re: Little languages are the future of programming

#109

Post by eternalban »

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 ?

modulo binding to (extant) c++ runtime, yep.

But this was in spring of '95. Ruby released later in December of that year. Lua was first publicly released in '94. I learned about the existence of these two a few years later (Lua first, and then Ruby via RoR).

mea culpa: there was no reddit or github or HN back in '95. Usenet would have been helpful but it wasn't on my radar in those days. I was just 2 years out of architecture grad school, and not exposed to the CS communities in my student years.

Re: Little languages are the future of programming

#110

Post by pjc50 »

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 have "must be easy to type in execution order" and "must integrate with random programs on the filesystem" as an overriding consideration. You're not going to get that with Java.
Post reply on HN