Show HN: Language proposal - dave | Hacker News Reader

Show HN: Language proposal - dave

davelang.github.com

24 pointsqixxiq24 comments

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

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

Yeah, I’m not saying remixing isn’t important and valuable at all. A lot of languages have arisen to fill the wants and needs of their designers, then gained traction among like-minded folks. C++ was Bjarne Stroustrup’s take on “Simula in C”. And hell, I make one-off experimental languages for fun all the time, so I can’t blame you. I just have my own preferences, and I gave my honest critique in the hope it’ll be helpful.

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

Perl's tainting is also an excellent thing

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

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

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?

> Why can't we have simple, unambiguous syntax with no pitfalls in new languages?

Yeah, s-expressions should be more widely adopted.

Maybe a better solution would be to have a syntax for writing and a different syntax for reading, i.e. the editor would automatically add the semicolons at the line endings where they would be appropriate.

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

Imagine reading an english text with no punctuation

I don't think this is a good analogy considering that each statement usually go on a separate line. Punctuation is helpful if there are multiple statements on the same line, but finishing each statement with semicolon and new line just adds noise.

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.

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

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.

I really think you should consider using a shorter identifier than function. def? Or take the dart approach.

I think using "function" for named functions makes the code more readable than something like "def" and is not super important. Now, you should really have a concise lambda syntax (not like JS or Python!), but that is a different story altogether.

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

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.

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

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.

I am just curious because the Global Variables and Scope are the Awful Parts of JavaScript: http://oreilly.com/javascript/excerpts/javascript-good-parts...

Having `var` keyword doesn't imply automatic assigning to undeclared globals.

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.

why is it called dave?

Reply on news.ycombinator.com