
Usefulness of inventing programming languages - emilis_info
http://emilis.github.com/2011/04/12/usefullnes-of-inventing-languages.html
======
onan_barbarian
This particular instance is a little grotesque (tables? really?), but I salute
the imagination involved.

It's at least _possible_ that we might be able to program with something that
isn't ASCII art. That doesn't mean that we have to do down the loony 'try to
program with pictures' approach, just that flat ASCII text isn't always that
fantastic. I'd love, for example, to be able to select exactly what a comment
refers to and ensure it doesn't get 'orphaned'. I'm also pretty convinced that
the world of graphic design may offer some tasteful-yet-extremely clear
assistance in resolving things like multiple nested blocks or
brackets/parens...

Text, IMO, is still king, but it'd be nice to see a little imagination and
experimentation in this area rather than the reflexive howling about how if
someone touches the Sacred Holy Text File we won't be able to use all our
other textual utilities from the 1970s and how it's all just a slippery slope
leading to UML "Programming for Managers" systems. :-)

~~~
tincholio
You could still using something like org-mode style editing to have this
"tables approach" and still keep the code in plain text.

------
wccrawford
I don't see it mentioned often, and I expected to see it here but didn't:

Writing harder code makes you better at writing easier code.

It's easy to continue at your same level and just go forever, not improving.
If you challenge yourself, even on a project that doesn't matter, your code at
lower levels will improve automatically. The lessons you learn from coding
harder things will translate into better coding all around.

------
blahedo
Interesting for its exploration of the idea of programming languages expressed
in something other than linear text.

~~~
ignifero
Maybe there's a good reason we like linear text: we are humans, we have with 1
stream of attention, we like to communicate serially and verbally. We don't
usually "understand" a map, although we can memorize it, in contrast to a book
which we can both memorize and understand.

~~~
david927
I've always thought it was the equivalent of writing an accounting system in
linear text. It think it's an abomination and I'm one of many working hard to
end it.

------
St-Clock
The idea of using a table to represent a function implementation was proposed
by Parnas, but in the context of software documentation.

This is quite nice if you can choose which function to represent with a table
(as opposed to having to represent all functions as tables).

A recent publication on this:

Parnas D., Document based rational software development, Journal of Knowledge-
Based Systems, 22(3):132-141, 2009.
<http://dx.doi.org/10.1016/j.knosys.2008.11.001>

~~~
emilis_info
Thank you. This looks very interesting.

Was trying to find a free version of the article and found more of Parnas
works here: [http://www.informatik.uni-
trier.de/~ley/db/indices/a-tree/p/...](http://www.informatik.uni-
trier.de/~ley/db/indices/a-tree/p/Parnas:David_Lorge.html)

------
julian37
Regarding programming with tables, see also Subtext:
<http://www.subtextual.org/>

------
Peaker
"It looks to me that dictionaries or mapping variable names to their values
fit into this definition."

This is indeed similar, but a dictionary is a function with an enumerable
domain. A function may not have an enumerable domain.

------
keyle
I'm all for writing more readable code. Why hasn't pseudocode won ages ago?

~~~
apl
Looking at Python, Ruby, Pascal or BASIC, I'm wondering how much closer one
can get to (what you call) pseudocode without sacrificing formal consistency
and, well, usefulness. AppleScript is lurking just around the corner, and you
_do not want that_.

Also, syntax is superficial. Sure, some languages remain clunky and verbose
even after getting to know them, but more often than not there's a reason why
a language "looks" the way it does. Take J, for instance. It's a syntactical
nightmare at first. But once you get used to the intricacies and discover the
semantics, its code becomes oddly efficient and you wouldn't want it any other
way.

[EDIT: Moreover, graphical representations of code aren't as desirable as
you'd think they are. You can find plenty of attempts at turning UML (and
similar stuff) into a proper programming language. It's about as cool and
helpful as using Word when you could have emacs and LaTeX.]

~~~
wladimir
Maybe we just haven't found a good graphical representation for code yet. For
example, UML is too heavily rooted in OO-extremism, which makes it less
practical for quickly building solutions to real-world problems.

If we had such a representation, it'd give interesting prospects for
programming with a tablet/touch interface.

~~~
onan_barbarian
We have found a good graphical representation for code, in my opinion. We make
'blocks' by tabbing in, draw lines with '/////', and desperately try to make
comments seem to hang next to the code to which they refer by putting
whitespace in the right place...Code is already 'sort of graphical';
unfortunately, the graphics in question are ASCII art.

I suspect the brain-to-computer interface for tablet/touch interface is too
narrow, at least for that kind of thing (input of a big bunch of discrete
symbols). Tablet/touch interfaces might be nicer for viewing or better yet
debugging code; I'm daydreaming of being able to pull out a variable and
'expand it' in some handwavy fashion.

~~~
wladimir
Yes, it will be awesome, imagine that you could draw real art in your code
instead of ASCII art! You could illustrate your code with cartoons instead of
stick figures using \ o / :)

On a more serious note, is there any _fundamental_ reason that we'd need a big
bunch of discrete symbols? If you look at the evolution of language
development, we already went from machine code, which is extremely verbose, to
languages like Python/Ruby which are pretty concise.

If we continue this, we'll eventually be high level enough to not think in
terms of statements but in terms of data transformations, filters, queries,
reductions, etc.

And with touch you could already do a lot with making input context sensitive.
Only show the options that make sense at that point. Hardly a need to show a
full keyboard unless typing some identifier for the first time.

Anyway, it's very interesting to think about what is possible if you leave
behind current assumptions such as code=text.

~~~
onan_barbarian
I think the reason that we need a big bunch of discrete symbols is because our
brains are good at spewing these things out in a stream.

For example, I just typed a bunch of words at you. I didn't have to 'interact'
with the computer at each step, even though I suppose I could have used a
touch interface where I typed the first letters of each word and then hunt
around from a list.

We're good at being able to say that something is going to be equal to (-b +
sqrt(b^2 - 4 _a_ c))/2a, for example, by blasting out a bunch of different
symbols that the input system is unlikely to be able to anticipate. I can't
type that formula as fast as I can gibber away in English... but I can still
do it pretty smoothly without having to drop into a 'select things from some
sort of menu' mode.

This is made worse by the myriad of perfectly useful operators in a language
like C, as well as all the variables that may be defined at that moment. I
think discrete symbols are a fine way of expressing this.

All those things that you talk about 'instead of statements' are fine things,
but just as information-dense as a good-quality statement and will still call
on you to express an idea drawn from a huge space of possibilities.

Definitely in agreement on how interesting this all is as a concept. This
would be my toy project if I had time for toy projects. :-/

------
bhrgunatha
2 bottles of beer on the wall, 2 bottles of beer.

Take one down and pass it around, __1 bottles__ of beer on the wall.

Oops. This bug is more to do with not taking enough care over the problem,
rather than the language. I _do_ like pattern matching for arguments - it's a
great feature of Haskell, but I suspect writing tables makes it more trouble
to express than some other notation.

~~~
jws
Programmers are, as a whole, fairly bad at making programs to print the lyrics
of _99 Bottles of Beer on the Wall_. You can peruse 1400 versions in nearly as
many languages at <http://www.99-bottles-of-beer.net/>

A few minutes spent there raises questions about how people communicate.

Even the C example, written in pthreads with 10 cooperating threads so it is
likely by a programmer that pays attention to details, gets the "2 bottles"
case wrong, it will pluralize the after takedown count.

Most examples think of the pluralization issues, very few notice that the "one
bottle" case has "take it down" instead of "take one down". Even the Haskell
crowd that has versions with guards, versions with monads, and a version as a
list comprehension missed this.

(Mine is correct. _does gloatey dance_ But it has, sadly, outlived its
language. )

------
russellperry
Anyone who thinks programming with tables is a neat idea hasn't had to write a
complex Windows Installer/MSI deployment.

The horror...the horror...

~~~
russellperry
Not knocking OP's efforts as a nifty academic excercise -- good stuff. But MSI
is a real world (admittedly MS) attempt at writing imperative instructions
into relational tables.

And, again...<shudder>

~~~
emilis_info
Humble is about writing HTML tables, not database tables! :-)

I haven't tried developing MSI installers, so haven't experienced the horror.

One more area where I saw tables used for describing processes was keyword
driven testing: <http://en.wikipedia.org/wiki/Keyword-driven_testing> Didn't
have enough experience with it so don't know if it is also horrific...

~~~
russellperry
Sure, but in my experience the challenge of describing imperative instructions
with tabular data (in general) makes the Object/Relational problem look one-
dimensional.

------
scott_s
_This raises some interesting questions. E.g. why this does not work:
[1,2,3].map({2:4}) (in JavaScript)?_

It seems obvious to me why, but the author's question made me realize that I
couldn't immediately express _why_ that's not possible. The glib answer is
that it doesn't make any sense, but that's not very useful. I think what is
more fundamental is that JavaScript, and most other languages, have separate
concepts of data and code. A dictionary is data, a function is code.

Forgive me that I don't know JavaScript, so I'm going to switch to pseudo-
Python for my examples.

    
    
      def f1(n):
        if (n == 2): return 4
        return null
    
      f2 = {2:4}
    

I said pseudo-Python because in real Python, when I query a dictionary for a
value that is not there, it throws an exception. In my pseudo-Python, I'm
going to assume that it just returns null. If we assume that, then f1 and f2
can be used to get the same result, even thought they have to called in
different ways:

    
    
      res1 = f1(2)
      res2 = f2[2]
    

Both res1 and res2 will have the value 2. In that way, dictionaries can be
seen as a kind of function. I'm going to posit that the main reason we don't
treat them the same in most languages is efficiency and simplicity.
Dictionaries can only represent a limited number of functions - functions with
integral and finite inputs. Even so, it will often be quicker to write a
closed-form function than to write the full dictionary for a task. For
example, if you want an entity that given an _N_ between 1 and 1000 it will
return to you the sum of all numbers from 1 to _N_ , it is much easier to just
say that this quantity will be _N_ ( _N_ \+ 1) / 2 than it is to exhaustively
list all options from 1 to 1000. (Of course, the dictionary could not
represent if we wanted something that could handle arbitrarily large _N_.)

Going back to the author's question, if we assume that question was asked with
this pseudo-Python, and we could query dictionaries in the same way as
functions, then the answer would be [null, 4, null]. Is that useful? I'm not
sure. But perhaps there is value in unifying how we call functions and how we
query a dictionary. That is, if I give it a value, and it returns a value, it
should be invisible to me whether it's a function or a dictionary. I know I
can achieve this in C++ with operator overloading, and I think Python gives
mechanisms for me to define classes that can behave like this, but there is
still a fundamental difference in the language.

Lisps, of course, don't have the data-code divide, so querying a data
structure and calling a function can look the same. But it's interesting to
note that other languages don't have to make the two look different, but they
do.

Finally, _[2,3] + [1,4] gives a string "2,31,4" in JavaScript, but shouldn't
this produce [2,3,1,4] (which is equivalent to Array.concat([2,3], [1,4]))?_

In most languages I'm familiar with, you will _not_ get a string, but instead
a concatenated list. I think that fact is a byproduct of the fact that
JavaScript was designed for use in browsers. To the author, try exposing
yourself to more languages. What you observe there is a quirk of JavaScript,
not all programming languages.

~~~
emilis_info
(Author here) Thanks for the time you put into your comment.

I think there may be both advantages and disadvantages in unifying function
calls and dictionary queries. The reason I am asking the question is that I
haven't been able to try it for myself (or at least read about someones
experience with it).

And I will try exposing myself to more languages :-)

~~~
jkkramer
In Clojure, hash maps are functions of their keys. If you use keywords as
keys, then keywords are also functions of maps.

    
    
        ({:a 1} :a)
        => 1
    
        (:a {:a 1})
        => 1
    
        (map {2 4} [1 2 3])
        => (nil 4 nil)
    
        (map {:a 1 :b 2 :c 3} [:a :b :c])
        => (1 2 3)

~~~
emilis_info
Thank you! One more reason to use Clojure...

------
zandorg
In about 1988, I tried to write a language named after me, in Microsoft BASIC
on a Sharp MZ-700 (creaky 8-bit computer). I didn't get very far.

