On 14.05.2011 23:20, Adam Ruppe wrote:

> Can you show me a PHP example showing what you mean? I can't think of anything you can do in PHP that D can't do at least as well.

  Something like this: http://core.trac.wordpress.org/browser/trunk/wp-content/themes/twentyten/header.php

> If by communicating with other pages you mean something like php's include(), that's trivial (just include the file here too!)

  No, I mean state/data exchange.

  Say, somewhere on the page you set a variable, and it's values is visible on all other pages.

/Alexander

On 15.05.2011 01:25, Adam Ruppe wrote:

> #1: Wordpress /is/ horrible. One of the worst projects I have to deal with for work...

  It works, and does it well enough. There are many projects which look horrible in the code, but the fact is - they work.

  But, perhaps, you may suggest an ideal blog engine? Where everything is done right?

> #2: Even Wordpress doesn't mix code with output very often - it uses a template system too - the themes folder. Sure, PHP is it's template language, but it does separate the main code from the template code.

  That's where I see the mixture of language and templates. XML templates look horrible - but this is just a question of taste :)

  In some of my projects, I want to have code on pages, so I can transform and manipulate the data - because sometimes business logic fits perfectly into pages, not the application, especially when you don't have source for application and want to
change/extend something.

  If someone would ever make D to work exactly like PHP or ASP does (I mean - integration into templates) - then it would be perfect for me. Yes, may be "horrible" (to you or some others) - but I'll be more productive than with DOM-XML templates :)

/Alexander

On 15.05.2011 06:28, Nick Sabalausky wrote:

> There's always shitty programmers out there. *Especially* in web development.

  Looks like most of them are, right? :)

> Not familiar with drupal. Wordpress is pure shit. And no, popularity does *not* equate to quality.

  From end user point of view, "quality" is something that defines how good application is performing, not how it is written. IMHO.

>>  Perhaps, you could tell me this "good reason"? I see no good reasons, to be honest.
> 
> Do it professionally for a few years and you'll see the reasons.

  WordPress developers (not all, of course, but some) do it professionally for many years, still, whatever they do, you call it "pure shit", and they don't see the reasons you see.

  That's why I asked about "good reason" - a guideline to follow, which is rational for anyone.

/Alexander

On 15.05.2011 06:42, Nick Sabalausky wrote:

> All of that *was considered acceptable practice*. But the fact they found it acceptable obviously doesn't change the fact that those are horrible practices: it just meant they were a bunch of complete fucking amateur morons.

  Until and unless we have clear definition of "good practice", which is acceptable and practiced my majority, the definition of "good" and "bad" is purely point of view and extremely subjective.

  Sorry, but the only thing I wanted to say - is that in some cases D is not good for dynamic web (don't want to repeat myself - why).

  You don't think so? Good, follow whatever you believe is good - no questions, no problems. Just recognize that there are many people and many opinions and practices, which are good or bad for any particular application - that's all.

  Really, I don't want to start a flame - what is good or bad. Just expressing my opinion :)

/Alexander

On 2011-05-13 17:19, Adam D. Ruppe wrote:
> Jacob Carlborg wrote:
>> How is it working out with a static type system, compared to a
>> dynamic, for web development?
>
> It's *much* better, especially for rapid development. The compiler
> will tell me if my changes anywhere break things anywhere else,
> so I can modify with confidence.
>
> I can't tell you how many times I've made a minor mistake in PHP,
> Ruby, or Visual Basic and had it slip through to production because
> the code path was obscure enough to evade testing.

That's what I really miss when doing web development in a language with a dynamic type system. It's hard to do any refactoring, always the possibility to break some code you had no idea would be affected.

> Sometimes, something similar does happen in D - to!int("") throws -
> but, the compiler catches the majority of incompatible changes
> instantly.
>
> If I had int addUser() and change it to User addUser(), I don't
> have to hunt every instance down myself. Just hit compile and
> the compiler tells me where the change causes problems. (Rarer than
> you might think - thanks to auto, a lot of the program is already
> duck typed in a way. The actual return value name is rarely used.)
>
>
> It also helps documentation to have good types. I often see stuff
> like this in dynamic language docs:
>
> function doSomething(options);
>
> What does it return? What options are available? Maybe the text
> will tell us that options is an associative array. UGH, I hate
> that! Now, there's even less knowing what's going on.

Actually that's one thing I really like with Ruby and Rails, that you can put different types of values in arrays and hashes. But I can agree, sometimes it's hard to know what options are available.

> D's documentation is a lot more helpful, and easier to keep up to
> date.
>
> string doSomething(Options options); // not much better yet....
>
> struct Options;
> int speed;
> bool strictMode;
> bool caseSensitive;
>
>
> Ahhh, now I know!

But that way you would need to declare different types of Options structs all over the place?

> Another thing that the static types enable that I don't think is
> possible with dynamic functions is the automatic forms you see
> on my link.
>
> http://arsdnet.net/cgi-bin/apidemo/get-a-box
>
> I didn't write any html for that. The library made it for me.
>
> In the source, you can see it's prototype:
> http://arsdnet.net/apidemo.d
> 	Element getABox(Color color);
>
>
> The reflection was able to say "it needs a Color, and there's only
> a handful of valid Colors - enum Color - so I can automatically
> create a<select>  box for this."
>
> Dynamic types for return values can still do most the stuff my
> api generator does. Whether it's a static function/template toHtml
> or a dynamic property doesn't matter much.
>
> But the parameters... I don't think it can be done without the
> static types there.
>
> (Another nice thing is the library checks the type too. Coming
> off the request parameters, you have strings; dynamic types. But
> going into the function, it knows it must be a Color, so it
> checks. If not, an exception is thrown.
>
> By the time you're inside the function, you can be guaranteed that
> Color color is indeed a Color. Thus, to!string() to insert it into
> the html attribute that I did here is perfectly safe. It's a
> whitelist based filter, all done automatically.)
>
>
>
> There are a few cases where dynamic types are helpful or needed.
> D lets us opt in to them with only a minimal amount of fuss.
>
> The places where I use it are:
>
> 1) Data from the user. Form variables are of type string coming
> into the program. Once decoded, you have string[][string]. Your
> program probably wants something else.
>
> The to!() template in Phobos makes this pretty easy, or if you
> want default value and get/post combined, my cgi class has a request
> template:
>
> int a = cgi.request!int("a");
>
> That's similar to this in PHP:
>
> $a = 0;
> if(isset($_POST['a']))
>    $a = (int) $_POST['a'];
> else
> if(isset($_GET['a']))
>    $a = (int) $_GET['a'];
>
>
> PHP is so outrageously verbose. And the PHP is buggy compared to
> the D... if you do cgi.request!int("a", 10) and the user does a=txt,
> the PHP result is wrong. It's not quite fair to compare a function
> to a code collection though. A php function could do it right too.

I think there are other languages available that is far better than PHP that you could compare with instead. Ruby on Rails:

a = params[:a].to_i

Depending on what you need this might not be the best way to write it. If :a doesn't exist in "params" it would return "nil" and "nil.to_i" would give you 0. If you use the Rails methods it will to the right thing most of the times without you need to worry about it. For example:

Post.find(params[:a])

This will try to find a Post with the given id and automatically converted the given value to an integer. If it fails to convert the value to an integer it will return 0 (this is not the best solution and I don't like it).  When it can't find a Post with the given value (you most likely won't have a an id in the database with the value 0) it will through an exception.

> Annnnyway, I'm digressing. Hell, I'm going on about weak types
> instead of dynamic types! Even in Ruby, you'd have to do a to_i
> since the url value simply is a string.
>
>
>
> Back to dynamic types. The three other places where you see them
> are databases and interfacing with external services.
>
> 2) Databases
>
> With databases, you probably expect a certain type anyway. If the
> column is typed as INTEGER, you probably don't want 'lol' in there.
> But, the database takes care of that for you.
>
>
> In my libs, I just use strings.
>
> auto line = mysql.query("SELECT id FROM users WHERE id = 10").front;
>
> res[0] == "10"
>
>
> Conversions are now done the same as URL parameters:
>
> int id = to!int(res[0]);
>
>
> Oftentimes, I don't really care about it though; if I'm outputting
> it to html, I'll just say:
>
> table.appendRow(res["id"], res["name"])
>
> and the like anyway. You want a string there, so it just works.
> (appendRow is in fact a variadic template so it'd just work
> regardless, but you get the idea anyway).

I've been thinking for a while to try and create something similar as Rails' ActiveRecrod for D but every time I tried to do it turns out to work quite badly with a static type system. Either you would need to specify the columns and the types in the model class (which I would like to avoid) or you would have to use Variants all over the places. And if you use Variants all over the place then I don't so much reason in using a language with a static type system compared to a dynamic type system.

> Thanks to static checks though, if I were to later change my mind
> and wanted ints, or made the database return Variants or whatever,
> no problem - the compiler will point out trouble spots to me.
>
>
> Inserting data is the same:
>
> mysql.query("INSERT INTO users (id) VALUES (?)", 10); // works
> mysql.query("INSERT INTO users (id) VALUES (?)", cgi.post["id"]); // works too
>
>
> Or using the data object class:
>
> auto obj = new DataObject(mysql, "users");
>
> obj.id = 10; // works
> obj.id = "10"; // works just as well
>
> obj.commitChanges();
>
> (The DataObject can read too, offering database fields as obj.id
> style properties. They always return string, just like plain query,
> but are also read/write.)
>
>
> DataObject can also be specialized automatically to use static
> types if you like.
>
> db.sql:
> create table users(id integer primary key, name varchar(30));
>
> file.d:
>
> // parse out that create table to map the names and types automatically
> alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;
>
> User a;
>
> a.id = "12"; // type mismatch, fails to compile
> a.name = "hello"; // works
> a.nmae = "sad" // typo caught at compile time
>
> a.commitChanges(); // otherwise it is still based on DataObject
>
>
>
> In short, I have the best of both worlds, with the only extra effort
> being writing to!() here and there and that one line to import the
> sql definition.
>
>
> 3) HTML
>
> I *want* strict typing when working with html in almost all cases.
> It helps catch encoding bugs.
>
> The one place where I want dynamics - fetching an element off
> the html template - I have it, this time provided through classes.
>
> auto table = cast(Table) document.getElementById("data-table");
> assert(table !is null); // fails if it isn't a<table>  tag
>
> // use the table class's special functions
>
>
> Forms, Links, and other types of nodes are handled similarly. The
> Element base class though does most the simple operations. Being
> plain old inheritance, the virtual functions act dynamically
> enough.
>
> Of course, if the HTML changes, that assert/enforce will trigger
> at run time. We're still ahead of dynamic languages though: the
> compiler will tell me what breaks if I remove the cast, with one
> exception: I use an opDispatch there for attributes. That will
> break some functions.
>
> Table t = ...;
>
> t.caption = "Hello!"; // changes the<caption>  tag child
>
> Element t = ...;
>
> t.caption = "Hello!"; // sets a caption="" attribute
>
>
> But meh, in this case, I like the flexibility of accessing
> attributes like that. The compiler still catches more than it
> doesn't - we're still ahead of the mistakes possible in dynamic
> languages while keeping the convenience.
>
>
> 4) External services
>
>
> This is where dynamic types are the most useful. Accessing Facebook,
> Twitter, etc., returns xml or json with types that change based
> on a lot of things. Is the user logged in? What url is it?
>
> In this case, it's like the database, but the types tend to be more
> complex. Simple string cowboying won't cut it.
>
> Thankfully, D's Variant is up to the task.
>
>
> Variant userRet = fbGraph(token, "/me");
>
> // we know /me returns a json object from the docs, so fetch it:
>
> auto user = userRet.get(Variant[string]);
>
> auto name = user["name"].get!string;
>
> // name is a string == "Adam D. Ruppe"
>
>
> Not terribly hard. Robert Jacques IIRC has written an improved
> std.json patch to make this work almost just like Javascript:
>
> auto user = fbGraph(token, "/me");
>
> user.name.get!string; // same as above
>
>
> So D's definitely up to the job. The only difference is that final
> use of get!string. I believe Phobos' to! works as well.

As I said above, I don't see the big advantage if I have to use Variants all over the place .

> In the end, there's nothing web related in my experience that a
> dynamic language can do that D can't do almost or just as well,
> and plenty that D and it's static types can do that dynamic types
> can't do, or require piles of painful tests and manually written
> code or documentation to do.
>
>
> D kicks the Web's ass. (And my web related libraries go even further
> than seen here. My custom DOM offers a lot of things that are way
> cool, enabling new CSS stuff, filling forms easily, in about 1/10
> the code of doing it similarly in PHP, and without mucking up the
> HTML. The web api/site generator makes D accessible through urls,
> forms, javascript - view the source here for a glimpse of that
> lib:
> http://arsdnet.net/cgi-bin/apidemo/javascript
>
> 20 kb of javascript, including the auto generated API bindings!
>
> And more stuff is packed in there too. Best of all: D, through
> CGI, consistently does well or better than mod_php in my speed
> benchmarks. I've barely tried to optimize too; there's a lot of
> untapped potential.
>
>
> If your host doesn't suck, dive into D on the web. You won't want
> to go back.)

I don't know what your experiences are but since you mention PHP a lot I can agree with you, PHP sucks. Compared to PHP you can do a lot better, also with a dynamically typed language. Actually all the "native" languages in web development (HTML, CSS, JavaScript) are quite horrible. I don't know if it's just me but I try to hide those native languages as much as possible. I'm currently now uses Ruby on Rails with the following languages:

* Ruby as the server side script (obviously)
* HAML, generates HTML - http://haml-lang.com/
* SASS, generates CSS - http://sass-lang.com/ (I'm using the sass syntax and not the scss syntax)
* CoffeeScript, generates JavaScript - http://jashkenas.github.com/coffee-script/

Every language is compiled to its native format automatically when needed and cached in production. I just tried Rails 3.1 beta yesterday and now SASS and CoffeeScript are default. I think these languages make web development a less of a pain, but in the end they all compile to their native languages and there is no way to get away from that.

-- 
/Jacob Carlborg

On 2011-05-14 04:17, Adam D. Ruppe wrote:
>> I haven't used it yet, but I think you've got the right approach
>> with your DOM stuff.
>
> For people who haven't read about this, I just wrote up a quick
> document about it:
>
> http://arsdnet.net/web.d/dom.html
>
> I really rambled at points, but I wanted to cover all the bases.

I can agree with some of this but not all of it. I quite like Rails' Model-View-Controller pattern which allows the view layer to contain logic but which you should try to avoid as much as possible. I guess this fall under "PHP (Disciplined)".

I don't see anything wrong with the view layer containing simple logic, like this (written in HAML):

%ul
    - @posts.each do |post|
        %li= post.title

Or, if you prefer, you can a partial:

posts.html.haml:

%ul
    = render @posts

_post.html.haml:

%li= post.title

-- 
/Jacob Carlborg

Alexander wrote:
>  Say, somewhere on the page you set a variable, and it's values is
> visible on all other pages.

My simple implementation does that.

The way it works is say you have this file:

===
<?d auto title = "hello"; ?>
<title><?= title ?></title>
===

It scans through and turns the stuff outside <??> into string literals and wraps the whole thing in a main function. So that becomes:

/* snip imports */
void main() {
   auto title = "hello";
   write("<title>");
   write(title);
   write ("</title>");
}


When it runs, you get the result you expect coming from PHP. Thank's to D's nested functions, classes, etc., you can do just about anything with the language, despite it all being inside one big main function once generated.


In PHP, pages share data by having one include the other. Even Wordpress templates ultimately work that way - the main code includes the template's code after defining a bunch of functions and variables.

If you did the same here, the variables from before would be visible in your scope.

   auto title = "hello";
   write("<title>");
   write(title);
   write ("</title>");
// include a similar file that says <?= replace(title, "h", "H"); ?>
   write(replace(title, "h", "H");

And it'd work - the title variable hasn't disappeared.



There is one thing Wordpress does that would *not* work here though: including a file based on a dynamic variable.

include("file.dph"); // works fine - the string can be pulled out
                     // by the preprocessor and compiled

include(file-from-user); // wouldn't work


You could make it work by providing a pool of available files though, then picking one of them from the list.


I only wrote that little program as a toy a while ago. Someone on the newsgroup said it was impossible... I rather like showing the possible in D instead, even if I find it useless.

But since I do find it pretty useless, I never finished it. Still, even in it's unfinished state, most of this works already. Sharing data is easy.

Alexander wrote:
> XML templates look horrible - but this is just a question of taste

But Wordpress' code *is* an xml template, just with other crap mixed in.

One of the downsides of me writing my document in notepad is adding code examples in a pain. I didn't want to manually write <div> over and over again, so I just sidestepped it.

But, here's a template from my D demo: http://arsdnet.net/apidemo-document.html

It's standard HTML, nothing more. The same stuff you'd write in an ugly PHP file, but without the ugly PHP.

The main difference is I didn't have to repeat myself over and over. Didn't have to separate the header, the footer, and the content (though, I could have. Most my real sites actually do that.)

I didn't have to write

        <div id="page-content">
            <?php output_page_content(); ?>
        </div>


And a corresponding function in the code. The id on the div is everything it needed to know.


Another one:

        <table class="striped" id="our-data">
        </table>


That's all that's needed to be said in the template. The program uses the ID to fill in the data, and the class is caught in a generic post-processor to add class="odd" to every other row. (that is like unobstructive javascript for progressive enhancement, but done server side instead of on page load.)

Such with PHP's Smarty templates would look like this:
       <table>
       {foreach from=$rows item=row}
       <tr class="{cycle values="odd,even"}">
          <!-- output data here -->
       </tr>
       {/foreach}
       </table>


Ugh. (and I forgot a closing tag there in my first draft! Would have broken the site. With the DOM, such things are rare since you write less xml (ironically), cleaner code, and if you mess up anyway, you get a clear message on where the missing tag is.)


The D side, btw, looks like so:

auto table = cast(Table) document.getElementById("our-data");
foreach(row; data)
   table.appendRow(row...);


Much easier than the PHP equivalent too - it's all clear. And all properly closed and entity encoded with zero effort.

Jacob Carlborg wrote:
> I don't see anything wrong with the view layer containing simple
> logic, like this (written in HAML):

I don't think it's bad - I just think it isn't as good as we can get.

On 15.05.2011 17:04, Adam D. Ruppe wrote:

> In PHP, pages share data by having one include the other. Even Wordpress templates ultimately work that way - the main code includes the template's code after defining a bunch of functions and variables.

  This is not what I mean. What I mean is something like:

page-a.html:

<?d var = "value" ?>

page-b.html:

<?= var ?>

And this I expect to work. Just an example of what I mean, of course. I.e., *all* pages share the same namespace, and all values stored on one page are accessible on all other pages *and* persistent.

Sure, we can use database or shared memory to implement persistence - but this will be way too slower comparing to some in-memory state, not talking about complex objects which cannot be stored (easily) in the database.

To implement this, you would need a "bit" more than your dhp does (while PHP and ASP provide out of the box).

/Alexander