[nercury]

I am PHP developer, but that first "Overview" example looks all sorts of wrong to me.

I know this is just an example, but programming without view/controller separation, view models, writing queries inside views, mixing business logic in views? No no no I saw so much horrbible stuff like this I can't unsee aaaah God help me...

:D

Ok, on serious note: I think this language looks interesting. But I do not like built-in templating, for various reasons. The fact that you have implicit "out" channel for printing stuff means clunky ways to control it, like "ob_start" and friends. In my humble opinion, templating should be turned on only explicitly. Then you could use the same language for views (excelent!), without a risk of outputing strings where you shouldn't.

Also "{" and "}" in templates are not very elegant. I know us programmers got used to them, but a designer would be much better with simple statements like "if", "else", "endif", like Twig templates do, or even like we used to do in php:

<?php if (x): ?>

<?php else: ?>

<?php endif; ?>

[benastan]

View/controller separation, view models and query abstraction are framework-level features. The author of this language is seeking to take the qualities of PHP that make it a 'hypertext preprocessor' and mixing in the no-frills syntax and vocabulary of ruby or python.

I don't understand why you wouldn't just use a framework like Sinatra. It's simple in every way that qualifies it to contend with a 'hypertext preprocessor'. Add it to your gem file, bundle, git commit, push to heroku, deployed! It even has inline templates[1].

You could argue it has a learning curve, but is resistance to learning a good argument against a solid & simple, versatile framework?

[1] http://www.sinatrarb.com/intro.html#Inline%20Templates

[nercury]

I am a big supporter of building applications in consistent way, and the big part of that is being able to code components which do not know anything about the presentation layer. Building these components on hypertext preprocessor is exactly the thing I would not want and would avoid at all costs. We already have it with PHP, and we have learned to follow some practices to live with it.

Well, you may say, this is just for small stuff to run some scripts easily. Well, the reason behind the PHP was the same. And look what it has become :)

Please don't assume I will not use Sinatra just to plug Sinatra here :). I might.

[code_duck]

I don't use that syntax for control structures at all. It's like the worst take on Python ever.

JavaScript uses curly braces. Any designer who knows anything about coding is going to have to learn JavaScript. How about one syntax?

[adamors]

You're missing the point.

  <?php if($condition){ ?> 

and just an

  <?php } ?> 

gets illegible and confusing very fast, even from 20 lines of HTML in between. And that isn't even that much. endif, endfor, endforeach etc. are much more noticeable, plus every editor/IDE worth their salt will highlight it properly.

[code_duck]

I disagree with you about which looks worse is more confusing.

[vezzy-fnord]

C-like delimiters are much more logical than the verbose Algol-like delimiters, in my mind.

[meepmorp]

Is that because you are primarily a user of c-style languages?

[vezzy-fnord]

No, not necessarily. What is a "C-style" language, anyway? Most imperative languages today are descendants from the ALGOL syntax, it's just that C modified some of the more inelegant aspects and made them more terse. Whereas Pascal stuck directly with ALGOL operators and blocks.

Just look at environments like Delphi and VB.