Perlis Languages | Hacker News Reader

Perlis Languages

blog.fogus.me

236 pointspepijndevos35 comments

I would strongly favor Forth over Joy, but either way concatenative languages are really worth exploring. It seems fair to compare Forth with C, as both deal with hardware and memory rather intimately. Compare a C implementation of a Fisher-Yates shuffle:

  void shuffle(int *array, int n) {
    int i, j, tmp;
    for (i = n - 1; i > 0; i--) {
      j = rand_int(i + 1);
      tmp = array[j];
      array[j] = array[i];
      array[i] = tmp;
    }
  }

With the same algorithm in Forth:

  : shuffle
    1- for
      i 1+ random over +
      over i +
      swap@
    next
  ;

The types, intermediate variables and many of the unnecessary details of the implementation fall away. It's an aesthetic distinction, since we're really trading these for "stack noise" words like over and i, but I find it very pleasing.

C is normally considered an extremely simple, lightweight language. I think the main lesson Forth has taught me is that we can design much simpler languages in the same space without sacrificing power and flexibility.

C is normally considered an extremely simple, lightweight language. I think the main lesson Forth has taught me is that we can design much simpler languages in the same space without sacrificing power and flexibility.

But perhaps at the expense of readability. Forth-like languages look quite elegant in small examples but C's more explicit syntax scales much better to larger code bases, IMO.

Could you please explain the Forth sample? For instance, which variable is the array?

It's implicit on the stack.

Ah, thanks :)

Sure thing.

  : shuffle

This starts a declaration for our word 'shuffle'. This implementation expects the address of the array on the stack with the length of the array on top. Some Forth programmers would leave a comment to this effect like so:

  ( addr len -- addr )

Anything in parentheses is a comment, and this shows the contents of the stack we want as input (read from right to left) before the '--' followed by the contents of the stack we'll get as output. (We leave the array address on the stack. If we want to be void like the C example, add a drop to the end of this definition to discard it.)

  1- for

Subtract one from the length given and begin a for...next loop. This will take the length value off the stack and repeat everything up to the matching next n+1 times. Equivalent to:

  for(int z=n; z >= 0; z--) {}

Our stack now looks like this:

  ( addr )

While we're in the loop, a copy of the loop index can be pushed onto the stack via the word i. This actually accesses a secondary stack, so if you nest loops you can obtain progressive indices by using i' and j (or j and k, depending on your Forth dialect.)

  i 1+ random

Add one to the loop index and generate a random number between 0 and this value, exclusive. Our stack now looks like:

  ( addr rand_int(i+1) )

  over +

Over pushes a copy of the second element of our stack. This sequence adds the address of the array to the random index, leaving the address of that cell of the array. Our stack now looks like this:

  ( addr (rand_int(i+1)+addr) )

  over i +

Make another copy of the array address and add the loop index to it. The stack now looks like this:

  ( addr (rand_int(i+1)+addr) (i+addr) )

  swap@

This is a helper word which swaps the contents of two memory addresses. It should be easy to see that this will swap array indices for us in exactly the same way the C code did.

  next ;

Close the loop and terminate the word definition, respectively.

Whoa..I'm definitely adding Forth to my "to-learn" list. The concept of a stack-based programming language is completely alien to me and would definitely be worth exploring further. On a side note, is it just me or is Forth's readiblity really low?

[Thanks a lot by the way!]

My pleasure. :)

It takes some time to get used to dealing with the stack. The stack plus the fact that there aren't many "structural" symbols like the parentheses and curly braces of ALGOL-derived languages can certainly make Forth harder to skim at first. On the other hand, idiomatic Forth code should be factored into many very small definitions. Aggressive decomposition wins back some readability since everything will be in tiny bite-sized chunks, and it promotes reusing code too. I think personal preference is part of it.

If you're serious about learning more, I'd recommend Leo Brodie's Starting Forth: http://www.forth.com/starting-forth/sf1/sf1.html

I hate plugging my own projects, but if you check out my profile I also have several Forth-related things on github.

Another stack based language worth learning might be Postscript (even if only to make your coworkers wonder why such a small file takes such a long time to print: http://warp.povusers.org/MandScripts/ps.html or http://www.physics.uq.edu.au/people/foster/postscript.html )

A great set of languages. It's true that languages should be mind-expanding, and for that reason I wish C would be included on principle --- everyone should understand pointers --- but I suppose most people have already seen that (the assembler included may make up for it, too).

I'm rather happy that many of these are "modern" languages: Qi, Oz, Kernel, and similar raise my hopes for the field showing that in the interceding 50 years, we have improved upon Lisp, ML, Prolog, and the like.

Inform7 is a another perlis language. It's designed for writing text adventure games, but the source code is designed to look like a natural english language.

Yeah, that's sort of mind-boggling.

Example: http://inform7.com/learn/eg/rota/source.txt

What will be a "Perlis language" will necessarily individual. What makes it so for you, is that it have some features that is conceptually new for you. For me BASIC, C, and Simula was Perlis languages, but none of them has features completly unique to them, but I learned new concepts from them. On the other hand Java, Python and Lua were not, because I had encountered their core features previously, and learned little from them for that reason. People with a different background would have a different experience.

Few concepts are unique to any computer language, so I would argue that it should be about learning new concepts rather that a new programming language.

Some of the examples he picks are rather good at that, since they contain concepts not part of the mainstream paradigms, and so will have new concepts for most programmers.

Tinkering with new languages is fun and worthwhile to a point, but I honestly feel that my time is now better spent learning new problem domains. Languages matter, but the less tangible skills I've developed working across different domains have been more valuable and fundamental. The things I've learned while studying Machine Learning and DSP over the last year are much more broadly applicable than I would have guessed.

What are some broadly applicable things you learned from DSP?

When you start to think of any stream of numbers as a digital signal, a lot of the techniques become useful. For example, user interfaces provide a fairly high-resolution stream of quantifiable user events, like touch positions. Often you want to smooth these in specific ways. If you understand how a low-pass filter works, this is easy.

Does one need a background in electronics to understand DSP?

Not at all. In fact I'd say most DSP these days is done entirely in software.

Any tips on where / how to start? Which books / tutorials worked for you? My background is in software engineering and the only thing I know about DSP is a very very basic understanding of the Fourier transform :)

This book is free online and is a pretty good intro: http://www.dspguide.com/pdfbook.htm

A few of my own reasons for thinking Joy is interesting:

https://github.com/raganwald/homoiconic/blob/master/2008-11-...

I think Smalltalk is an other language that's at least fun to explore. Especially if you want to know what OO is really about.

Its successor Self shows even more what OO is really about.

Its successor, Io, simplifies things even further

OO is on the way out according to some http://news.ycombinator.com/item?id=2708733

I spent quite a few hours a while ago trying to organize languages into different language groups in order to pick which languages to learn next. If you're interested in that see the blog post that came out of that: http://hacklash.posterous.com/how-to-choose-your-next-progra... .

Just be warned that I'm coming at it from the outside with most of these languages, to make your final decision try and find someone experienced in multiple languages from the paradigm and ask them which to learn the paradigm with.

Maybe this could be interesting to you. It was done by Peter Van Roy, of Concepts, Techniques, and Models of Computer Programming fame.

http://www.info.ucl.ac.be/~pvr/paradigms.html

PerlisLanguage(Prolog).

Don't operators have to start with a lowercase letter?

Oh. Yeah, I guess you're right. Oh well :-)

Reading the Eiffel entry, it mentions Design By Contract. This is interesting stuff and I should mention that .NET 4.0 includes Design by Contract in the framework itself.

Interesting set of languages. I would include a language focused on coroutines and concurrency as well: Erlang, Go, or Stackless Python for example. Many problems change significantly when seen in the light of concurrency.

Call me stupid, because I'm just a lowly PHP developer who's a bit confused as to what new things he wants to learn (for better career prospects), but the first reply just emphasises the balance between verbosity and terseness a language should attempt to maintain.

As a fun learning adventure it's interesting - and, as the article says a lot, mind-blowing - but I can read and understand what is going on in C.

Ask me to explain what Forth, or most if not all of the other examples are doing and you'd be lucky to get more than an, "eeeerrrrrrrrrrrrrrrr...." from me. I suppose that experimentation and innovation are more the point with this though.

You seem to think that the trouble you have reading some of this code reflects something inherent in the language (either it's too "smart" for you or simply too weird), but I would suggest the only thing it necessarily reflects is something about you — namely, that you have more experience in some areas than others.

PHP is based on C. It is not based on Forth. Thus, if you only know PHP, C code will be more immediately clear to you than Forth code.

There are some things that make languages easier or harder to read in absolute terms, but when you're brand new, similarity to what you already know pretty much dominates everything else. Similarly, English speakers tend to find Spanish easier than Russian or Chinese.

Forth examples can be more terse than C examples because Forth uses a stack for storing and manipulating intermediate values while C uses infix expressions and temporary variables. It's not just "shorter" syntax, it works in a different way. My real point with the Forth/C comparison is not that the Forth code is smaller but that it clearly has fewer "moving parts"- the for loop is simpler and provides fewer options, there's no need for special syntax to index array pointers, there's no need to specify method signatures, etc.

Language design is not simply a balance between terseness and verbosity, it's a complex series of tradeoffs between many paradigms and features- some allow you to express ideas more succinctly, flexibly or reliably.

Reply on news.ycombinator.com