Eliminating Errors with Little Languages
modernperlbooks.com
modernperlbooks.com
Arguably, lisp should have given us a world filled with little languages, but it hasn't taken hold. People like syntax, and people like compile time checks.
I have yet to dig into the Perl 6 features that make this possible, but having a low-barrier-to-entry way to create DSLs that are compile-time checked and usable opens the door to something big. Domain experts who are not programmers may finally have a lever in the process stronger than the "spec" and weaker than the code. Give them a DSL, with a good compiler, and let them wreak havoc.
The big question here I still have is: text? Perl 6 gives us little languages, but they are still shackled by ASCII-based notation. Solve that problem, and you've got something big.
I agree but am also going to say-- I'll believe it when I see it. The article was very light on details. What they're claiming is already facilitated by libraries in many existing languages (including Perl 5)
Generally, the barrier to entry for designing and implementing your own language is not the difficulty of understanding how lex and yacc work, it's the need for a thorough and precise understanding of the DSL and every step of the compilation process. Error checking, for example... It's understanding what the compiler knows about your program, and what you can do to figure out things about the program, and how expensive that figuring is going to be. The details here are going to be different for every DSL.
A text editor is just one way of viewing the bytes that represent source code. Theoretically, any language supports other ways of viewing and editing code. It's just the tools that are missing.
Actually, although it's fashionable to sneer at it, I think that TeX (http://www.tug.org) provides perhaps the most compelling example of a little-language maker. The languages that one can make on top of it are perhaps rather specialised to text markup, but I think it's telling that LaTeX (http://www.latex-project.org) was designed, not by fiddling with the source, but rather as a macro layer on top of TeX. LaTeX's not little by any means, but I think it would be hard to find many other examples of such successful languages implemented literally on top of existing languages.
Finally, I'm not really familiar with Perl 6, but I'm pretty sure it's still dynamically typed. (After all, it targets Parrot, which is specifically advertised as being a low-level target for dynamically typed languages.) As such, I don't see it solving people's problems with lack of compile-time guarantees from Lisp. (Of course, there's no denying that Perl, in every version, does offer gobs and gobs of syntax. :-) )
Perl 6 allows optional typing.
After all, it targets Parrot, which is specifically advertised as being a low-level target for dynamically typed languages.
Parrot allows type checking. Very few languages of which I am aware perform it to any degree, but nothing about Parrot rules it out.
This code-stored-not-as-text-thing came up so often (it was a recurring Serious Question about once a year while I worked on Visual Studio) that it was simply referred to as the Emacs/grep barrier. Any tool solution that prevents the use of Emacs and grep out of box is just dead unless you have a from-scratch codebase and team.
The old Smalltalk hands (some of whom worked on original Smalltalk systems) also like to relate the biggest single issue they had. At one point, they needed to reconstruct the basis library for a new implementation... but there was no code. How do you do a review of a system where the code was (in this case) completely gone, as it had long since become something interpretable as a jump point in a heap image but not as code? (Punchline: they rewrote most of it from scratch, recreating decades-old bugs)
Good notation is a prequisite to clear thinking. The kinds of notation we have available to use is severely limited by the medium we write software in.
"People like syntax" has not been tested. I think it's safe to say that people like syntax that's like syntax they've already learned.
We don't really know why Lisp hasn't taken hold, and we don't know that it won't take hold at some point in the future.
Latin-1 in truth, but a fair point. Even so, what's wrong with text that alternate input forms (graphics, speech) can fix? You can be inspecific with speech, and you can organize volumes of text with far more efficiency than you can images.
Arguably, ruby does this. Look at RSpec, Sinatra, and Rails (Rails 3 especially).
If so, you could make the argument that an ORM library does the same thing.
I don't make either argument.
I love perl, but why strings? Writing SQL is not that fun. The cognitive leaps one has to make is annoying. Why not write queries in natural perl statements and translate them to SQL?
That being said though, modernperl++ and yay for perl 6. :) </fanboyism>
You can indeed do that. I prefer SQL to ORM; de gustibus non est disputandum.
I love perl, but why strings?
Even structured data, such as a nested data structure serialized to JSON, is a string until you parse it. I don't understand the question.
We should have datatype for SQL, and special literal for it. Functions that execute queries should take only parameters of type SQL (never strings). There should be almost no way to construct SQL from string. There should be 'formatting' operator that allows you to put values in SQL and it should do default escaping on them.
As for XSS attack I'd suggest HTML datatype with its own literals. Output functions should only accept HTML (not strings). Similarly there should be almost no way to convert string (or any value) to HTML without escaping it.
It's only three letters: ORM.