

Show HN: Language proposal - dave - qixxiq
http://davelang.github.com

======
evincarofautumn
What is the advantage of this means of string escaping over strongly typed
strings? If there is no implicit way to convert between a String and an
XmlString or SqlString or what have you—or if an implicit conversion also
correctly handles escaping—then the problem is moot. Look at Yesod, for
instance, and how Persistent handles type-safe database access.

For those who haven’t seen it, the Programming Language Checklist[1] is worth
a read. Forgive me my cynicism, but I don’t see the point of Yet Another
Block-Structured Imperative Language. It’s _nice_ , and there’s nothing
_wrong_ with it, but nothing really sets it apart, and I for one value
innovation more highly than remixing.

[1] <http://colinm.org/language_checklist.html>

~~~
qixxiq
The Yesod method does seem interesting (best explanation I could find of it is
at [1]. Perhaps that would be a better plan, although you could look at the
encoding syntax as strongly typed strings. If you look at the 'boldheart'
example once the <strong>&lt;3</strong> is saved as an "type html" string, it
is not re-encoded when placed inside another "type html" string.

As for the "yet-another" argument - I know. Convincing developers to switch to
a language that is not leaps-and-bounds ahead of their choice language is hard
to impossible. The reality is that I'm simply not happy with any of my options
and decided it would be an interesting experiment to write my own. I'm not
planning on writing any serious applications in it myself -- unless somehow it
can pick up a community.

The remixing though I find interesting. This is simply an attempt at making
something "better" than the other options. Languages get stuck with broken
features in order to maintain backwards compatibility. I see this as a way to
take the good parts of any languages and turn it into something I would like
to use. I'd rather stick with what works.

[1] [http://yannesposito.com/Scratch/en/blog/Yesod-tutorial-
for-n...](http://yannesposito.com/Scratch/en/blog/Yesod-tutorial-for-newbies/)

~~~
tikhonj
I think that it's actually easier to get developers to switch to a language
that's a little bit better--e.g. Python vs Java or CoffeeScript vs JavaScript
--rather than "leaps and bounds ahead".

------
tikhonj
Here are a couple of my random thoughts, mostly based on preference rather
than anything objective.

First--try to make the language as small as possible and as extensible as
possible. This means that print should be a normal function rather than a
statement and you should be able to add your own types of string encoding.

The ?: operator seems identical to || in JavaScript; I am not sure why you
want to have it.

I think having functions return the value of their last statement by default
(e.g. making the return keyword optional) makes writing code in a more
functional style simpler.

In this same vein, you should have a nice and compact lambda syntax--one of
the most annoying things with JavaScript (a language I happen to really like)
is that even the simplest of anonymous functions is long, which makes certain
types of code harder to read. I personally like Haskell's style (where \ x ->
x is the same as function (x) { return x } in JavaScript), but anything short
would work.

If everything else uses curly brackets, why does the for loop have a colon? I
think you'd find this[1] post by Brendan Eich about braces interesting.

[1]: <http://brendaneich.com/2010/11/paren-free/>

Have you considered using Haskell's syntax for comprehensions over Python's? I
find the former easier to read and it's more extensible. Where in Python you
would write [x for x in xs if x > 10], in Haskell you would write [x | x <\-
xs, x > 10]. This doesn't look much different, but is easier to read in more
complex cases. The Haskell syntax can also be used for what they call
"parallel list comprehension" which act like a zip rather than a cross
product. (So zipWith fn xs ys would look like [fn x y | x <\- xs | y <\- ys]
while the normal version would be [fn x y | x <\- xs, y <\- ys].)

As far as object oriented features go, if you like JavaScript's approach, take
a look at Lua's tables.They're similar to but more flexible than JavaScript's
objects.

Something like pattern matching or at least "destructuring assignment"[2]
would be nice as well. This makes certain types of code _much_ easier to read
and write.

[2]:
[https://developer.mozilla.org/en/New_in_JavaScript_1.7#Destr...](https://developer.mozilla.org/en/New_in_JavaScript_1.7#Destructuring_assignment_%28Merge_into_own_page.2Fsection%29)

Overall, I like your idea and wish you luck implementing it.

------
serichsen
I don't understand the attractiveness of "no-semicolon" in the sense of "a
statement/expression ends at a line end, except if ...", with some arbitrary
rules replacing "...". This seems to be a current trend. Why can't we have
simple, unambiguous syntax with no pitfalls in new languages?

I want to point at the start of a statement/expression, ask "where does this
end?", and get back a single, general answer, like "at the semicolon" or "at
the corresponding closing parenthesis".

That is what punctuation is for. Imagine reading an english text with no
punctuation, where the author just made sure to end a line wherever he wanted
a sentence to end. Do you really want to stop at each line end and have to
answer the question whether it ends the sentence?

~~~
ismarc
(this is gonna sound bad, but) I'm a fan of how lines end in sh/bash. If there
isn't a matching close for every open symbol, or there's a slash (opposite of
/, my phone doesn't have the character on the keyboard) it ends after the next
line that doesn't meet these conditions. ; is then a command terminator that
separates different commands on the same line. I like it because it's
explicit, easy to see visually and doesn't require special understanding of
the semantics of the language to know if the line can be split there, only
understanding of the line endings. It also allows folks to explicitly include
the line endings if they want.

------
chubot
Take a look at ECMAScript quasi-literals -- they are solving the same problem
that you're trying to address:

<http://wiki.ecmascript.org/doku.php?id=harmony:quasis>

<http://www.2ality.com/2011/09/quasi-literals.html>

I think they are going further because they can do auto-escaping. From what I
see of your language, you still have to do html:"$var". What happens if you
mis-type the prefix? Do you get incorrect escaping and a security hole? Some
web devs won't even _know_ what language they're writing in.

FWIW I don't think it's worth building an entire language around this concept.
It's a feature, not a language. I think using Python plus a template language
with good escaping basically solves the problem.

Also, it would be weird if html: and sql: are built in to the language -- that
should be a layer on top of a smaller language (just like quasi-literals).

Also, a server-side language with special escaping support doesn't seem
compelling, because these days you would want special escaping support on the
client too. I'm not sure of the status of quasi-literals, but if they make it
into V8 then Node.JS will have this feature on the server.

------
indutny
Have you seen Candor: <https://github.com/indutny/candor> ? I think I'm trying
to accomplish pretty same thing as you're.

------
xd
Your article begins by linking to anti-PHP articles that are 6-8 years old ..
You might want to start by bringing your research up to date.

------
karterk
I really think you should consider using a shorter identifier than _function_.
_def_? Or take the dart approach.

~~~
dchest
I wonder why almost every language designer miss the fun opportunity to name
the function keyword "fun"? Even Go got it wrong with its "func"!

~~~
evincarofautumn
A lot of language designers seem averse to a little whimsy in a design, which
is a real shame. Programming should be fun. Then again, there are benefits to
being boringly literal, too: you know what “removeTrailingNewline” does by its
name, but not necessarily that “chomp” means the same thing.

------
tszming
What is the point of using "var" declaration in your language?

~~~
qixxiq
It enables javascript style scoping which I am a big fan of. Basically the
'var' statement defines the depth that a variable is available at.

~~~
tszming
I am just curious because the Global Variables and Scope are the Awful Parts
of JavaScript: [http://oreilly.com/javascript/excerpts/javascript-good-
parts...](http://oreilly.com/javascript/excerpts/javascript-good-parts/awful-
parts.html)

~~~
tikhonj
Having var implies nothing about automatically making variables global. If
you're familiar with Scheme, having var is like define and not having it is
like set!. (If you're not familiar with Scheme, you should be ;). Go read
SICP.)

Basically, having something like var lets you nest scopes. So you can have,
say, nested functions and work with variables declared above your current
fucntion but _not_ in the global scope.

If you leave out the var, you'll end up with Python's idiotic scoping, which
is annoying. (They've added a nonlocal keyword in the new version in an
attempt to fix it, but it's still relatively clumsy and awkward.)

Coincidentally, if you use the strict mode in JavaScript (with "use strict";)
it will prevent you from using global variables implicitly. This makes it even
more clear that var and JavaScript behavior regarding global variables are
orthogonal.

------
septerr
why is it called dave?

