
Perlis Languages - pepijndevos
http://blog.fogus.me/2011/08/14/perlis-languages/
======
RodgerTheGreat
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.

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

~~~
RodgerTheGreat
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.

~~~
x64eva
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!]

~~~
RodgerTheGreat
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.

------
pavpanchekha
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.

------
rmc
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.

~~~
akx
Yeah, that's sort of mind-boggling.

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

------
alephnil
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.

------
cageface
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.

~~~
gruseom
What are some broadly applicable things you learned from DSP?

~~~
cageface
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.

~~~
x64eva
Does one need a background in electronics to understand DSP?

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

~~~
x64eva
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 :)

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

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

[https://github.com/raganwald/homoiconic/blob/master/2008-11-...](https://github.com/raganwald/homoiconic/blob/master/2008-11-16/joy.md)

------
tvorryn
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...](http://hacklash.posterous.com/how-to-choose-your-next-programming-
language) .

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.

~~~
stralep
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>

------
tete
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.

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

~~~
richcollins
Its successor, Io, simplifies things even further

------
ScottBurson
PerlisLanguage(Prolog).

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

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

------
sgt
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.

------
SoftwareMaven
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.

------
FuzzyDunlop
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.

~~~
chc
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.

