OWL Web Language

AlexMedia

After going through OWL's documentation I've gotten a better understanding of what a LockString is: it's a data type for parametrised strings. Think of it as a SqlCommand and its parameters collection.

The LockString itself doesn't do anything, it's up to a receiving party to convert a LockString into something useful. A database class would create a parametrised query, a text printer would invoke OWL's equivalent of String.Format, and so on.

I have to say I do like the idea of having a generic datatype for these kind of things, I think it's just shittily named. But then again, naming things is hard.

powerlord

@arantor said in OWL Web Language:

Everyone bitches about mysql_real_escape_string while forgetting we've had two different choices for prepared statements for a fucking decade already. I'll bash PHP for its actual faults like anyone else, but most of what people think of as PHP's faults were already fixed.

The funny thing is that it was mysql_escape_string that was the actual WTF. mysql_real_escape_string makes a call to the actual MySQL API to let the server do the quoting... like every other major database API in every other programming language that has DB support.

Oh well, the real WTF is continuing to use mysql_ or mysqli_ since they've basically been replaced by PDO for over a decade; 2004's PHP5 had it as an external PEAR module and 2005's PHP 5.1 and newer have it shipped as part of PHP itself.

dkf

@raceprouk said in OWL Web Language:

it solves fuck all

It means that they can be used as keys in mappings without any need to worry about them being mutated under the feet of the collection. Without that, equality would have to be on object identity (because you might change the string! OMGWTFBBQ!!!!!) and the mapping would need to copy on insertion.

Copy-on-write semantics would also work, but that's really not how C# (andJava too) rolls, and would be quite awkward to graft on now, as doing it efficiently requires a decision that is annoyingly complex in a multi-threaded environment. (You really don't want to increase the number of locks in use and the alternatives are also quite expensive given that there's usually a lot of strings about.)

dkf

@powerlord said in OWL Web Language:

let the server do the quoting

The actual right approach is to not use quoting at all but true parameterised queries. Alas, there were early versions of MySQL that didn't support them and PHP took that piece of idiocy, baked the consequences into their interface, made it all popular, and continued the stupid problems for years past the point where MySQL itself managed to largely get its shit together as all the trouble had by that point been baked into critical user code.

And almost all of that was for “good reasons” like compatibility with existing deployments. It's just that mere good reasons are not enough to keep code from being bad.

powerlord

@dkf Precisely... and PDO supports parameterized queries.

dkf

@powerlord said in OWL Web Language:

Precisely... and PDO supports parameterized queries.

Yes. The big problem now is the overhang of bad advice in rotting online tutorials, plus the ass-load of deployed user code.

Arantor

@powerlord I did acknowledge that we've had two different solutions (i.e. both MySQLi and PDO) for that time ;)

Arantor

@powerlord said in OWL Web Language:

@dkf Precisely... and PDO supports parameterized queries.

So does MySQLi. And yet people still fuck this up.

Mind you I saw a lovely bit of code this week that was to handle a multi row insert with PDO, which spent all its time assembling a string with the correct number of ? in the right place to perform the insert even though we have a query builder that accepts arrays and stuff (and does know how to escape things as parameteried queries do have limitations)

Arantor

@dkf a lot of the bad advice broke in PHP 7 by simply taking away the MySQL library.

Fixing established code is harder though.

dkf

@arantor said in OWL Web Language:

parameteried queries do have limitations

They do, but if you're letting untrusted users specify table and column names, you've got bigger problems anyway. ;)

Arantor

@dkf that wasn't what I had in mind. Doing a multi row insert where the number of rows is variable is a pain with parameterised queries.

asdf

@dkf said in OWL Web Language:

MySQL itself managed to largely get its shit together

[Citation needed]

I mean, we're talking about a database which allows you to mix tables that support transactions and foreign keys with ones that don't in the same database, and silently swallows CHECK constraints, because admitting that they don't support them would be too obvious.

dkf

@arantor said in OWL Web Language:

Doing a multi row insert where the number of rows is variable is a pain with parameterised queries.

I usually do those with either a loop and a parameterised query (which works pretty well if I'm keeping the transaction open) or by pushing the data to the DB directly as something like CSV. The latter is obviously better for major imports.

dkf

@asdf said in OWL Web Language:

I mean, we're talking about a database which allows you to mix tables that support transactions and foreign keys with ones that don't in the same database, and silently swallows CHECK constraints, because admitting that they don't support them would be too obvious.

OK, it was more of a “got a small fraction of its shit together” but even so… ;)

Arantor

@dkf in this case we're talking about reading a number of rows periodically from a web API, and inserting them into a DB-backed log. It's enough rows at a time that loops are annoying and not enough that really warrants the fart-assery of making CSV out of it for MySQL.

Zmaster

@lb_ said in OWL Web Language:

@zmaster wouldn't another solution just be to have a distinction between truly-immutable and mutable-but-not-through-this-interface?

Uhm? I don't understand what you're suggesting. What would this distinction be?

LB_

@zmaster well I suppose the actual representation depends on the language, but I'm trying to say you can have both immutable strings and read-only interfaces to mutable strings. There's no need to eliminate mutable strings just because read-only interfaces are confusing.

Zmaster

@lb_ yeah, nothing wrong with that. In fact, .NET also has a StringBuilder class, which you could consider a mutable string.
I guess the point is "immutable by default" is generally better.

RaceProUK

@zmaster said in OWL Web Language:

.NET also has a StringBuilder class, which you could consider a mutable string

I prefer to think of it as a tool that builds immutable strings efficiently.

Tsaukpaetra

@arantor said in OWL Web Language:

@dkf a lot of the bad advice broke in PHP 7 by simply taking away the MySQL library

Which several people promptly made shims to emulate all the calls anyways.

RaceProUK

@tsaukpaetra said in OWL Web Language:

@arantor said in OWL Web Language:
@dkf a lot of the bad advice broke in PHP 7 by simply taking away the MySQL library
Which several people promptly made shims to emulate all the calls anyways.

Human stupidity truly knows no bounds.

Arantor

@tsaukpaetra said in OWL Web Language:

@arantor said in OWL Web Language:
@dkf a lot of the bad advice broke in PHP 7 by simply taking away the MySQL library
Which several people promptly made shims to emulate all the calls anyways.

Me included on the basis that I couldn't conveniently replace out all the mysql calls with the correct calls owing to circumstances.

Onyx

So I read their basic example. Copy-pasta for the lazy:

// OWL will auatomatically call main() when the page loads.
function main() {

    // Get the current color from the URL
    let pageColor = Web.routeParam('color');

    // Output the full HTML document
    Web.sendPage({
        title: 'Color Picker',
        body: html(pageColor),
        css: css(),
    });
}

// In a function so you can easily add/remove colors in one place.
function colors() {
    return ['red', 'green', 'blue'];
}

// Main page content.
// Wrap content in <main> to get correct sizing & margins.
template html(pageColor) {

    <.colorBar style="background-color: {{ pageColor }}" />

    <main>
        <h1>> The {{ pageColor.upperCaseFirst() }} Page
        <ul>
        :: for (color in colors()) {
            :: let colorName = color.upperCaseFirst();
            <li>> <a href='/colors/{{ color }}'>{{ colorName }}</>
        :: }
        </>
    </>
}

// Include the OWL base stylesheet and add our own styles.
template css() {

    {{ Css.include('base') }}

    li {
        font-size: 2rem;
    }
    .colorBar {
        height: 4rem;
        background-color: #999;
    }
}

Oh for fuck's sake... okay, the tiny bit of code itself is fine. But...

What the FUCK are templates and CSS doing in the same file as the functional code? Are we (almost) back to doing the whole <div><?=somevar;?></div> shit?
We have something that looks like Mustache (and derivatives) syntax for printing out single variables, but looping is done by prepending :: to JS-looking code? So what you're telling me that you "improved" upon

<?php
    foreach($colors as $color) {
        $colorName = ucfirst($color);
?>
    <li> <a href='/colors/<?= $color ?>'><?= $color ?></li>
<?php
    }
?>

by adding some syntactic sugar instead of providing a proper templating system?

The fuck is <.colorBar style="background-color: {{ pageColor }}" /> about? Special syntax for a div with class colorBar? It would seem so but... why is it not div.colorBar then? Are you really providing your own quasi-elements rather than make a proper templating system?
Ah, yes, and all of CSS is in here, too! With an include to boot! I sure as fuck hope that generates a <link> tag, rather than just dumping it all as text, caching be damned!

This looks like it was "designed" by a PHP coder of the sort we laugh at around here. No, wait, that's everyone... Ok, the sort that me and @Arantor want to strangle while the rest laughs. Yeah, that's better.

In conclusion, 2/10, would strangle the author for free.

LB_

@onyx said in OWL Web Language:

Are we (almost) back to doing the whole <div><?=somevar;?></div> shit?

I'm out of the loop - what's wrong with that? I think I've heard other people say not to do it but I've never got an explanation why and I don't even know what to call it to look it up.

Onyx

@lb_ said in OWL Web Language:

@onyx said in OWL Web Language:

Are we (almost) back to doing the whole <div><?=somevar;?></div> shit?

I'm out of the loop - what's wrong with that? I think I've heard other people say not to do it but I've never got an explanation why and I don't even know what to call it to look it up.

It's a huge unreadable mess, basically. I don't think it's slower or anything (never cared to check though), but it encourages the horrible habit of mixing PHP and HTML into one file, which results in barely maintainable code after a while.

RaceProUK

@onyx ASP.NET has the same issue, but the impact is a lot less, as WebForms puts most of the code in code-behind files, and MVC puts most of the code in controllers. You still end up with C# in your HTML though.

Onyx

@raceprouk I don't blame neither PHP nor ASP(.NET) for having such functionality as a basic language feature. It's clear that it's intended as a basic feature you can build upon.

Owl, however, seems like it can't decide what it wants. First it lets you use one syntax to print out variables, then throws it under the bus by not letting you do loops or anything useful like that using the same syntax.

You could argue that PHP's <?= does the same, however it's just a shorthand for <? echo, or <?php echo if you have short opening tags disabled (<?= requires short tags to be enabled). It's a clumsy syntax that I don't really like either, FTR. But at least it's consistent, nothing's stopping you from writing <? for( ... ) { ... } ?> if you want. But here, we have {{ and ::, and I don't see any rhyme or reason to it.

wharrgarbl

@raceprouk said in OWL Web Language:

Fuck knows: in .NET, all strings are immutable, and it solves fuck all.

thread-safe mutable strings have poor performance because of all the locking

RaceProUK

@raceprouk said in OWL Web Language:

Fuck knows: in .NET, all strings are immutable, and it solves fuck all.

Note to self: don't talk about programming after drinking a whole bottle of Shiraz

Onyx

@raceprouk said in OWL Web Language:

Note to self: don't talk about programming after drinking a whole bottle of Shiraz

Come talk on Discord instead. I'm not recording all that shit, honest!

PleegWat

@onyx said in OWL Web Language:

nothing's stopping you from writing <? for( ... ) { ... } ?>

Or, for that matter, <? for( ... ) { ?>...<?=...?>...<?}?>

asdf

@onyx said in OWL Web Language:

<?= requires short tags to be enabled

That hasn't been true since 5.4:

PHP: PHP tags - Manual

Onyx

@asdf said in OWL Web Language:

@onyx said in OWL Web Language:

<?= requires short tags to be enabled

That hasn't been true since 5.4:

PHP: PHP tags - Manual

That'll show you how long ago I stopped using that shit :P

asdf

@onyx said in OWL Web Language:

That'll show you how long ago I stopped using that shit :P

You've obviously never had to use Magento. Because if you had, this would have been great news for you, and you'd know about it. ;)

Onyx

@asdf said in OWL Web Language:

Magento

@asdf said in OWL Web Language:

great news

DOES NOT COMPUTE

WernerCD

@brisingraerowing said in OWL Web Language:

Paul Krill / Jul 26, 2017

OWL: A 'better' PHP for single-server apps

OWL Web Language features a JavaScript-like syntax and compiles to PHP, promising more security and safety

Owl bet this thread is a hoot... full of the hoo's hoo... a right hoot.

Guess owl' start reading the actual thread now to find out if I'm right.

Onyx

@wernercd all those puns...

You're an owlful person.

WernerCD

@onyx You're talon the truth right there.

RaceProUK

Benjamin Hall

@wernercd @onyx aren't y'all such a hoot.

WernerCD

@benjamin-hall said in OWL Web Language:

@wernercd @onyx aren't y'all such a hoot.

I'm just sad that I committed the crime. I guess owl be by myself with the bad jokes then :(

Benjamin Hall

@wernercd Bad jokes are the only ones I can do. It runs in my family. Fortunately, teaching science gives me many opportunities for awful jokes:

I love teaching about circuits. It has such potential. In fact, although I get resistance every time I say this, it's all about current events.

Why are all Chemistry jokes bad? Because all the good ones Argon.

WernerCD

@benjamin-hall said in OWL Web Language:

@wernercd Bad jokes are the only ones I can do. It runs in my family. Fortunately, teaching science gives me many opportunities for awful jokes:

I love teaching about circuits. It has such potential. In fact, although I get resistance every time I say this, it's all about current events.

Why are all Chemistry jokes bad? Because all the good ones Argon.

What's worse than Dad Jokes? Dad Chemist Jokes....

0_1501518250978_walter-white-telling-stupid-dad-jokes-about-chemi-1-31737-1383057903-30_big.jpg

Benjamin Hall

@wernercd what's Batman's favorite element?

Sodium

blakeyrat

@arantor said in OWL Web Language:

@dkf that wasn't what I had in mind. Doing a multi row insert where the number of rows is variable is a pain with parameterised queries.

Pretty rare a web application would have to do this, isn't it?

If the number of rows are large enough that a simple loop isn't efficient, you'd be better off using whatever your database's Bulk Insert API is in that case, anyway.

blakeyrat

@onyx said in OWL Web Language:

auatomatically

That's really all I needed to pile this in the "junk" bin.

blakeyrat

@raceprouk said in OWL Web Language:

ASP.NET has the same issue, but the impact is a lot less, as WebForms puts most of the code in code-behind files, and MVC puts most of the code in controllers. You still end up with C# in your HTML though.

If you join the rest of us in the 21st century and use Razor syntax, it's not too bad.

But the real innovation is Code-Behind. If PHP had that from day one, there'd be a lot fewer complaints.

Arantor

@blakeyrat this is how I end up with muppets doing for loops to insert 50k rows at a time, one by fucking one.

But MySQL isn't designed for analytical use, it isn't OLAP, it's OLTP, and in its implementation, the most efficient way in a lot of cases really is a multi row insert rather than many rows individually into a transaction. Especially in the hundreds-to-few thousands category. The muppets doing 50k queries or 50k bulk inserts are largely doing it wrong and for the most part should rip out their schema.

blakeyrat

@arantor said in OWL Web Language:

@blakeyrat this is how I end up with muppets doing for loops to insert 50k rows at a time, one by fucking one.

I really don't get what you mean by "muppets" here, but I like you think you literally have Rowlf the Dog on your team so that is what I'll do.

@arantor said in OWL Web Language:

The muppets doing 50k queries or 50k bulk inserts are largely doing it wrong and for the most part should rip out their schema.

Yup.

I mean there are web apps that are like, "hey you can upload a CSV to me and I'll insert it into the database", but for that need you're much better off using the bulk insert functionality of your database. (And if you picked a database without some form of bulk insert, then that was stupid of you, wasn't it?)

But at least he plays the piano pretty well.

Arantor

@blakeyrat but in the late 1990s when this was shit out of someone's behind just for their personal website, none of that mattered. It's just unfortunate that no one thought to fix it after good ideas came along. And then people built shit on this shit because it was somehow less shit than the other shit at the time, and now we're all moving to JavaScript anyway and I want to get out of the fucking web industry because it's just shit all the way down.