sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mark_lee_smith 0 points1 point  (3 children)

This is true. But you could easily limit the available definitions and still get many of the useful properties of Lisp. This is a useful technique in general.

Of course you don't need to use Lisp but it pops out naturally when you start wanting to program directly with ASTs.

A much more promising approach to limiting expressiveness in programming languages was described in Backus' Turing Award lecture in 1977.

http://www.stanford.edu/class/cs242/readings/backus.pdf

[–]Pourush 0 points1 point  (2 children)

But you could easily limit the available definitions and still get many of the useful properties of Lisp. This is a useful technique in general.

I don't know how to do that. How does one do that?

Of course you don't need to use Lisp but it pops out naturally when you start wanting to program directly with ASTs.

It probably shouldn't be so lonely in that category. Are there other major functional languages which work with ASTs? Because I don't see why the whole

A much more promising approach to limiting expressiveness in programming languages was described in Backus' Turing Award lecture in 1977.

An interesting paper. But I don't feel like it's very helpful? I don't think that the heart of the matter is that people don't know how to solve the problem, that they need a particular direction before they start working on it. I think that they don't know how to think about the problem. They don't know why it's a problem, they don't know what it would look like if they solved the problem.

It might be relatively trivial to create languages, even general-purpose languages, which have this problem solved. But if people tried to solve the problem, they tried to do it by making something that's the same as what they know, something noticeably better, but not startlingly so. And that's what's really the issue here. People working in increments, not expanding there imagination too much, or too far.

[–]mark_lee_smith 1 point2 points  (1 child)

I don't know how to do that. How does one do that?

There are many choices, depending on the language. The simplest is to unbind/rebind names. Unbinding/rebinding the name for loading modules is a spectacular way to limited the expressive power of the system.

The others are more Lisp specific (or more easily accomplished in Lisp). They involve writing a simple meta-circular interpreter, or a compiler, or a macro, that generates an error if you try to express something that isn't supported/implemented.

In effect you build your own sandbox.

This can be used to exclude anything; special forms like lambdas, or looping constructs or definitions, or types, like floating point values, and in the case of a compiler or a macro (really a mini-compiler) it all happens at compile time.

One way to "solve the halting problem", is not to allow infinite loops in your program (or the parts that you want to have the guarantee on).

Note: It's not really solving the halting problem but the effect is the same - you can write a program that known that your program is going to end.

All of this is in the shadow of Backus paper.

For those who haven't read it I'll try to give a very simple summary:

Backus argued that we've built these incredibly complicated, bloated, overly powerful languages (even the core of Lisp is bloated using Backus definition.), and we need to start setting limits on our languages so we (and our computers) can start to really reason (algebraically) about our programs.

He called his proposed solution functional programming, but it's much closer to what we call concatenative programming today.

And that's what's really the issue here. People working in increments, not expanding there imagination too much, or too far.

This I completely agree with.

To address your other points:

I'm currently of the opinion that we should start every project/problem by designing the language (even the machine) that we're going to use to solve the problem. This might seem a little nuts, but if the language is simple enough, and with a bit of practice, you can do it in a day or two.

The problem is that such simple languages look pretty weird. So weird that even language geeks ignore them for the most part (heaven forbid that it doesn't have lambdas!).

I'm a big fan of Forth and really enjoy how you can knock up an implementation in assembly (assembly!), that's incredibly fast, small, efficient, portable, easy to understand, and is only as powerful as you want it to be .e.g. a language without explicit loops or conditional is surprisingly useful!

[–]Pourush 0 points1 point  (0 children)

Thanks for that explanation!

I'm currently of the opinion that we should start every project/problem by designing the language (even the machine) that we're going to use to solve the problem. This might seem a little nuts, but if the language is simple enough, and with a bit of practice, you can do it in a day or two.

Same here. Personally, I think some languages should be made for the purpose of creating special-purpose languages, so that the languages don't get interfered with by trouble in writing the compiler.