
Eliminating Errors with Little Languages - fogus
http://www.modernperlbooks.com/mt/2010/07/eliminating-errors-with-little-languages.html
======
gfodor
Giving parsers and lexers to the average man, or removing the need for them
altogether, will be the thing that pushes the bar forward next. I don't know
if Perl 6 is going to be the medium for this change, but it might be.

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.

~~~
coliveira
This is an idea that was pioneered by Smalltalk, where you don't need files to
organize your code. But I don't see why it can't be used in other languages,
such as Java, using a class-based editor (instead of a file-based one).

~~~
larsberg
Fundamentally, the problem comes down to the other 90% of the toolstack. Even
if you get people to use your language, are you really going to get them to
change their source code control, _every_ person's text editor, build system,
scripts that run over the code, the external localization service, the third
party code escrow service, automated performance and security assessment
tools, etc.? Anything that is more than a toy project has real requirements,
often with tools that are outside of the control of any one vendor or even the
company -- they are sometimes requirements of the industry.

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)

~~~
shaunxcode
Was this before the concept of "filing out"?

------
agentultra
Why not take the SQLAlchemy approach with its lower-level expression language?
Avoid string parsing, implementing specific dialects of SQL, etc.

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>

~~~
chromatic
_Why not take the SQLAlchemy approach with its lower-level expression
language?_

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.

------
scotty79
I have a much simpler idea that does not provide so much functionality but it
prevents sql injections.

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.

~~~
chromatic
That's essentially the same idea. See also "working with Unicode strings in
different encodings" or "working with values of different (but compatible
units)".

------
epochwolf
I can't help but think the specific problem mentioned has a specific solution.

It's only three letters: ORM.

~~~
chromatic
For some purposes, ORM works fine. I find ORM frustrating and unpleasant far
more than I find it useful.

~~~
wazoox
That. And the fact that ORM usually don't allow to structure your database
precisely the way you want, in the good ol' fashioned way.

