Some more little language not listed by the article: Elm (browser apps w/o runtime errors).
The creator (BDFL?) of Elm, Evan, specifically avoids making it general purpose.
Little languages are the future of programming
71–80 of 216 posts
Re: Little languages are the future of programming
#72People 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 would add to that when people move to next job DSL dies I don't have a need for that DSL in next company. I could try to implement there - but IP rights would prevent that, getting new people on board with my ideas is just so much work that it is not useful.
That is like learning some SaaS application ins and outs you switch jobs and that specific experience is not useful at all for you.
General purpose language on the other hand is useful even if you move from one country to another and take job in different business niche.
As a developer there is no upside for me to spend my time on diving into some DSL I wont use in next job.
As a business person there is no upside for me to spend my time learning DSL or specific application interface in and out that I won't use in next job or in different position.
Re: Little languages are the future of programming
#73People 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.
Re: Little languages are the future of programming
#74Calling SQL a "little language" must surely be a joke. Even if you ignore the differences between its many dialects, SQL is only "little" in that it is domain-specific rather than general purpose.
In fact the entire article seems to boil down to "DSLs are the future", which I'm sure I've seen articles about back when Ruby on Rails was dominating web technologies, Cucumber (and its various ports) created "BDD" testing fad and DevOps started gaining traction on top of various "Ruby DSLs" used as configuration formats.
I don't think DSLs are going to go away any time soon. But there is a trade-off between domain-specific "little languages" and general purpose programming languages (or "DSLs" that are actually subsets of the latter). It can be fun to have to work with a little language, it's not so fun to work with dozens of them, each with different rules you have to memorize, instead of just being able to use the same language for all (and in truth, this was the source of the Ruby DSL craze because developers were already using Ruby on Rails).
Re: Little languages are the future of programming
#75People 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…
It's much easier if your first step is to write a grammar for your DSL.
Re: Little languages are the future of programming
#76I don't think it's so much "little" languages (commonly DSL) that matter. It's more the jumps in expressivity. You don't use a full on Turing-complete language when you need to match strings written in a regular language. Instead, we write the language we want as a regexp, and then use a regexp engine to match it. I agree with much of the problems listed in the article. The author even manages to stumble onto some of…
What's a “total language”?
To slightly oversimplify: A language in which every function provably terminates.
Re: Little languages are the future of programming
#77People 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 branching was involved on the surface. And the user base immediately got it and started using it, because it was a "little language".
Sometimes a DSL is really the right solution.
Re: Little languages are the future of programming
#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't get me started on DSL in general. Just lookup my username and "DSL" on hackernews for endless rambling.
Re: Little languages are the future of programming
#79This article claims the problems it's trying to solve are: Hard to onboard new hires, code breaks because of lack of understanding of dependencies, and code changes become harder to manage. In my experience SQL, regexes, unix shell, and listening to Alan Kay, far from solving those problems, are the very things that most exacerbate them. General-purpose languages that are expressive enough to let one write business l…
I have to agree, many small DSLs won't do anything to fix this IMO:
> Hard to onboard new hires, code breaks because of lack of understanding of dependencies, and code changes become harder to manage.
If on-boarding requires knowing more languages that are less widely known or used then it will be harder.
Re: Little languages are the future of programming
#80Join any company and organisation and look at their build and deployment tooling. Unless they are using Kubernetes and even then, you shall find a very complicated bunch of languages: - shell scripts - Dockerfiles - Kubernetes YAML - Makefiles - Bazel - Ansible - python scripts - Jenkins XML - Groovy scripts - Ruby scripts - CloudFormation - Terraform - Fabric or other deployment deployment script It's very hard to f…
Can you expand on you mean when you say that Lisp is not ‘how [you] think about computation’. I have never seen that phrase used regarding Lisp, usually it’s mentioned in regards to logic or other much less mainstream paradigm than the imperative/semi-functional paradigm in Lisp.
I see LISP as being useful for codegen and intermediate representation and AST representation but I wouldn't want to program with it directly without a tool to create a structure that is understandable to me. All the parenthesis!
I wouldn't want to maintain or work on a large Clojure codebase written by other people. I've done that three times.
For reference, I think Python is easy to write and read and understand.
I wrote a simple toy multithreaded interpreter and I've written part of a compiler that does codegen to target the imaginary interpreter. It's basic but my AST is a tree that could be represented in LISP. I use a handwritten recursive descent pratt parser. The language looks similar to Javascript.
I know it can fixate your thinking if you think of it too much in this manner, but I think of modern computers as turing machines. They loop or iterate through over memory addresses which are data or instructions and execute them.
That said, my perspective is not traditional. I design and try implementing programming languages. I am interested in the structure of problems and code, asynchrony, coroutines, parallelism and multithreading more than anything else. Even more than type systems.
I think the expression problem is a huge problem that doesn't have good solutions for managing complexity.
I find other people's LISP code to be difficult to read whereas I can understand a Python, Java algorithm.
What am I trying to say? The structure of the program in the developer and compiler's head is different from the instructions actually executed by the computer. LISP is nearer to the instructions executed by the computer than what exists in my mind. In my mind exists relationships, ideas more complicated and not structured in post order traversal. A post order traversal of LISP is the codegen.