Home » forums » LtU Forum

Why languages and not systems?

Hi all!

I was pondering a question: why do we try and approach problems by building languages to code our solutions instead of simply engineering systems, libraries, and GUIs to achieve the same result?

The answer I give myself is that a language is:
- more general
- better to abstract descriptions and behaviors
- simpler to capture repetitive actions and automation

What do you think?

By giuseppemag at 2012-07-06 12:20 | LtU Forum | previous forum topic | next forum topic | other blogs | 5804 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Uh?

1) Only a small percentage of software developpers build a langage.

2) Usually they do it because they want to provide a "domain specific language" which is intended to be easier to use than libraries and a general purpose language.
Note the "intended", I started my developer life by using an awful "domain specific language": I would have been much more productive with a compiler and libraries.
More recently I had the displeasure of having to use XSLT another DSL, to be short: this is a nightmare.

3) The tiny minority remaining of those who build a language do it because they are not satisfied with existing languages.

By renox at Fri, 2012-07-06 14:33 | login or register to post comments

This is just a reformulation of the Turing completeness argument

The argument goes like this: Turing completeness proves all (non-trivial) languages are equally powerful, there for there is no advantage to developing in one language vr.s another.

The problem is that this is wrong. Turing completeness just says that if you can implement a solution in one Turing complete language, you can *theoretically* implement it in any other. It does not say how *easy* it is to implement in any other. We humans have limitations- there are some programs which are simply too complex for us to be able to develop, and many programs which are simply more complex to develop than is feasible/economic. What is important about languages isn't what they make possible to do in some theoretical sense, it's about what they make easy to do in a pragmatic sense. This makes sense once you ask why we don't all just program in machine code? Or Unlambda, or Brainfuck?

Systems and libraries and GUIs are expressions of the possible. I don't mean to undercut their importance. But languages are definitions of the possible. I am interested in developing new languages because there are programs I want to write that are just too hard to write in current languages.

By Brian Hurt at Fri, 2012-07-06 14:47 | login or register to post comments

Not to mention the sub-Turing

Programs in Turing-complete languages cannot be proven to halt. Yet there are many areas in life where we want to make sure that our programs halt (or, dually, that they're infinitely productive). You can't really "tack on" that kind of guarantee with a library.

By Kalani at Fri, 2012-07-06 21:09 | login or register to post comments

How can languages be

How can languages be definitions of the possible if all things are possible in all TC languages?

Languages are surely definitions of the convenient (as per your second paragraph)? But libraries & systems are also suppliers of convenience.

One role for languages then is to provide syntactic sugar to make it more convenient to call some common libraries (e.g. dictionaries in Python/JavaScript/et al vs the horror of std::map).

But the main distinction surely is that if the convenience functionality is part of the language, it is more formalized, and the compiler understands what the library does, allowing it to perform better static error analysis and better static optimization - making debugging and performance improvement more convenient too. Libraries by and large can't do that, and certainly not at compile time.

But ... here I'm conflating language and compiler. Perhaps there exists a type of library that can also participate at compile time, and perform its own optimization and type-checking. So, perhaps there isn't a fundamental difference - except insofar as current implementations are conceived.

But (and here's the rub): to develop this idea takes a new language, not a new library. Perhaps languages are important precisely because they enable the development of new compilers.

But compilers are systems. I fear the halting problem may apply to this line of reasoning.

By EddieEdwards at Sat, 2012-07-07 08:00 | login or register to post comments

Not all things are possible

Not all things are possible in TC languages. Only all computable functions are possible. Functions are a very small subset of what a good language provides.

Besides functions, we want expressiveness, modularity, composition, extensibility, security, efficiency, scalability, predictable performance, simplicity, persistence, portability, easy debugging, easy upgrade or live programming, effective IDE integration, etc.

Indeed, many of these things are more important than "all functions". We could abandon or constrain TC to make more things possible.

By dmbarbour at Sat, 2012-07-07 08:27 | login or register to post comments

I'm not sure ... if you're

I'm not sure ... if you're suggesting whether we should just stop investigating into new languages (Turing complete or not) and just stick to the status quo, simply content to compose and build things with the current legacy we're left with (?)

AFAIC, I'd almost say I tend towards the extreme opposite point of view. I actually think a better future is likely in allowing the building of systems and applications precisely out of many more languages yet to come, where language invention, extensions and composition are encouraged, provided it'd be way more seamless than today's state-of-art.

Today's main issue for such an agenda, though, as I see it, is of course that being able to building and composing languages in a not too chaotic or ad hoc fashion still isn't quite where we're at, w.r.t. tooling prerequisites. Language design and implementation being still way too much more of an individual craftman effort (more or less informed by PLT &/or engineering) than anything.

By Cyril at Fri, 2012-07-06 16:17 | login or register to post comments

In some sense UIs are more

In some sense UIs are more general than languages. You interact with a language via a UI (OS, editor, etc.). I think that in the future there are advances in programming to be had by considering the whole programming UI instead of just designing the language.

By Jules Jacobs at Fri, 2012-07-06 21:04 | login or register to post comments

Languages and UI's are dual.

There is no UI which is not a language. There is no language which is not a UI.

UI designers are defining "little languages" whose verbs are user actions like checking boxes and typing into web forms, whose nouns are the display and interface elements, etc, and the range of actions expressible in those languages is generally defined by the program.

Languages are just UI's for dealing with complexity. The many text files of a program express information in the same way as check-boxes and web forms do, and the range of actions expressible is defined by the compiler/interpreter. It really is the same thing. There are systems where people program using other UI elements, and there are systems where people prepare files to automate or 'script' actions normally directed by other UI elements.

There is no essential distinction between them, and neither is a proper subset of the other. Both are about the direction of computer activities by humans.

Bear

By Ray Dillinger at Thu, 2012-07-12 19:49 | login or register to post comments

Yes, everything that is

Yes, everything that is communication is dual to everything else that is communication. Very helpful?

A PXD is very different from a UXD given the nature of the job, even if you can say that both are doing design.

By Sean McDirmid at Fri, 2012-07-13 07:58 | login or register to post comments

For some context, I'm a PL

For some context, I'm a PL researcher working in a mostly systems group.

I once had an exchange with a very senior system researcher (from Redmond), who mentioned that the goal of systems researchers these days was to define new abstractions to support systems construction (since they don't build OS's anymore). Now, I point out that is what PL researchers do, are you moving in our turf?

I guess the point is that we are all in the abstraction business we just go about different ways of doing it. The "system", the "UI", the "langauge", they are all languages of abstraction to varying degrees.

By Sean McDirmid at Fri, 2012-07-06 23:30 | login or register to post comments

I agree strongly. PL is very

I agree strongly. PL is very applicable to system designs; it's really about developing a useful set of abstractions with as many ilities as we can squeeze in.

By dmbarbour at Sat, 2012-07-07 08:39 | login or register to post comments

We build new languages

We build new languages because it's fun. Most of the rest is rationalizing. :-)

By Dan Armak at Thu, 2012-07-12 14:09 | login or register to post comments

I certainly didn't get into

I certainly didn't get into language design because it's fun. (It is fun, but I didn't know that when I got into language design.) Rather, it was because other languages aren't fun, or sufficient for a purpose.

By dmbarbour at Thu, 2012-07-12 16:00 | login or register to post comments

What makes it fun is, in

What makes it fun is, in fact, building a fun language. Both building and using a fun language is fun.

By Dan Armak at Thu, 2012-07-12 16:08 | login or register to post comments

Scratching an itch is fun?

They usually call it 'scratching an itch,' i.e., someone was bothered by something somewhere sometime.

Personally, I was itched by the keywords 'ref', 'rec', and 'Monad'. As well as lazy evaluation.

By marco at Fri, 2012-07-13 10:26 | login or register to post comments

Ha!

I would tend to agree, but I would hope we can justify our work in a more scientifically likable manner :)

By giuseppemag at Fri, 2012-07-13 08:59 | login or register to post comments

A question of control

My current view is that language creation should be seen as an example of layered or stratified design where the designer changes control structures.*

Here I'm assuming that by "libraries" the original poster means new procedural abstractions and new data types.

Now, if languages are abstract machines then we could view the adding of new procedural abstractions or data types as enhancements of the abstract machine. Even when we pile abstraction upon abstraction, we see that each layer of the pile makes use of the same control structures offered by the base machine. Should we want new control structures then we would be forced to make a new machine.

For this model to work with setjmp/longjmp in C or call/cc in Scheme we have to view them as being an integral part of the language so in these cases a new language would be needed should we want a control structure not definable in these terms.

That was my 2 pence (and my first post).
Barry

* Bowles and Wilk, "Tracing requirements for Multi-layered Meta-programming", pretty much summed it all up for me.

[edit: I've just realised that this doesn't really make much sense if we look at assembly language. Since the lowest of all levels offers all possible control structures, the multiplicity of programming languages cannot be put down to a need for new control structures.]

By Barry Watson at Fri, 2012-07-13 11:39 | login or register to post comments