5 ms·

Usefulness of inventing programming languages

125 points by emilis_info 16y ago

blahedo 16y ago
Interesting for its exploration of the idea of programming languages expressed in something other than linear text.
- ignifero 15y ago
  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 15y ago
    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.
  - meterplech 15y ago
    There are definitely advantages for our understanding. But, when writing highly parallelized code I always thought the linear style was somehow odd. It would be cool to see other ideas that would map more directly with that type of thinking.
keyle 16y ago
I'm all for writing more readable code. Why hasn't pseudocode won ages ago?
- apl 16y ago
  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.]
  - arethuza 16y ago
    Of course in the opposite direction you have people who insist that they can develop software as UML diagrams, and you don't want that either.
  - emilis_info 16y ago
    (OP here) I don't think plain-text source code will ever be replaced as the main way of writing programs. It is simple, transparent, has accumulated very large number of tools for analyzing and editing it (think of all the UNIX utilities or the complexity of IDEs). However most of the non-plain-text methods (like UML) help you get a bird-eye view of what you are creating. Also Humble can be embedded in rich text (like HTML) so it may have some niche uses as a real programming language. I have built a prototype blog that you could re-program with Humble via WYSIWYG editing some time ago. It was brittle (you could break the website by errors in the main template) and slow, but it was fun to do everything in the browser.
    - mckoss 15y ago
      Creating a programming system where the primary representation of a program is not text, but rather a dynamic data structure is the core idea behind Intentional Programming (Charles Simonyi's post-Microsoft company). http://intentsoft.com/technology/overview.html This is Charles's ultimate "going meta" idea to try to advance programming beyond our 1960's metaphor representing programs as raw text. It's not been widely adopted, so the company is selling it into markets where you want domain experts to be able to "write code" rather than have them hand off a spec to a programmer. It's kind of a domain specific language (DSL) compiler generator.
      - wladimir 15y ago
        Thanks, that's interesting. It is really hard to find these kind of systems in the wild. I've read a bit about the SCID (source code in database) paradigm, and it seems similar, representing the code as a graph database. But it seems mainly about people talking how great it would be instead of implementing it and putting it to the test :P
- gaius 16y ago
  It did. Have you ever read any COBOL? It reads just like stilted English.
russellperry 15y ago
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 15y ago
  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 15y ago
    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 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 15y ago
      Sure, but in my experience the challenge of describing imperative instructions with tabular data (in general) makes the Object/Relational problem look one-dimensional.
julian37 16y ago
Regarding programming with tables, see also Subtext: http://www.subtextual.org/ http://www.subtextual.org/
onan_barbarian 16y ago
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 15y ago
  You could still using something like org-mode style editing to have this "tables approach" and still keep the code in plain text.
wccrawford 16y ago
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.
zandorg 15y ago
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.
Peaker 15y ago
"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.
bhrgunatha 15y ago
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 15y ago
  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/ 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. )
St-Clock 15y ago
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 http://dx.doi.org/10.1016/j.knosys.2008.11.001
- emilis_info 15y ago
  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/Parnas:David_Lorge.html http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/p/...
scott_s 15y ago
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.

125 points by emilis_info 16y ago

blahedo 16y ago

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

ignifero 15y ago
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 15y ago
  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.
- meterplech 15y ago
  There are definitely advantages for our understanding. But, when writing highly parallelized code I always thought the linear style was somehow odd. It would be cool to see other ideas that would map more directly with that type of thinking.

keyle 16y ago

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

apl 16y ago
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.]
- arethuza 16y ago
  Of course in the opposite direction you have people who insist that they can develop software as UML diagrams, and you don't want that either.
- emilis_info 16y ago
  (OP here) I don't think plain-text source code will ever be replaced as the main way of writing programs. It is simple, transparent, has accumulated very large number of tools for analyzing and editing it (think of all the UNIX utilities or the complexity of IDEs). However most of the non-plain-text methods (like UML) help you get a bird-eye view of what you are creating. Also Humble can be embedded in rich text (like HTML) so it may have some niche uses as a real programming language. I have built a prototype blog that you could re-program with Humble via WYSIWYG editing some time ago. It was brittle (you could break the website by errors in the main template) and slow, but it was fun to do everything in the browser.
  - mckoss 15y ago
    Creating a programming system where the primary representation of a program is not text, but rather a dynamic data structure is the core idea behind Intentional Programming (Charles Simonyi's post-Microsoft company). http://intentsoft.com/technology/overview.html This is Charles's ultimate "going meta" idea to try to advance programming beyond our 1960's metaphor representing programs as raw text. It's not been widely adopted, so the company is selling it into markets where you want domain experts to be able to "write code" rather than have them hand off a spec to a programmer. It's kind of a domain specific language (DSL) compiler generator.
    - wladimir 15y ago
      Thanks, that's interesting. It is really hard to find these kind of systems in the wild. I've read a bit about the SCID (source code in database) paradigm, and it seems similar, representing the code as a graph database. But it seems mainly about people talking how great it would be instead of implementing it and putting it to the test :P
gaius 16y ago
It did. Have you ever read any COBOL? It reads just like stilted English.

russellperry 15y ago

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 15y ago
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 15y ago
  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 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 15y ago
    Sure, but in my experience the challenge of describing imperative instructions with tabular data (in general) makes the Object/Relational problem look one-dimensional.

julian37 16y ago

Regarding programming with tables, see also Subtext: http://www.subtextual.org/ http://www.subtextual.org/

onan_barbarian 16y ago

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 15y ago
You could still using something like org-mode style editing to have this "tables approach" and still keep the code in plain text.

wccrawford 16y ago

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.

zandorg 15y ago

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.

Peaker 15y ago

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

bhrgunatha 15y ago

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 15y ago
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/ 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. )

St-Clock 15y ago

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 http://dx.doi.org/10.1016/j.knosys.2008.11.001

emilis_info 15y ago
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/Parnas:David_Lorge.html http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/p/...

scott_s 15y ago

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.