"Visual Design"



  • Continuing the discussion from UI programming for the chronically distracted:

    @Maciejasjmj said:

    Huh. I've always thought it actually keeps the data separately and just generates the backing class based on a T4 template or something like that, but apparently the designer does actually parse the code.

    It's still hardly "visual design", but pretty clever, I admit.

    I'd like to see a definition of "visual design" that doesn't include what WinForms/WebForms does.





  • XAML? Or basically, any other type of declarative markup.

    Also, I'm a bit rusty, but is WebForms really doing the same thing as WinForms? WinForms basically generates pure C# (or whatever) imperative code, while webforms is based on an HTML-like markup. Although I guess they use some of the widget tags to generate html markup in imperative manner.



  • @blakeyrat said:

    I'd like to see a definition of "visual design" that doesn't include what WinForms/WebForms does.

    Uh, as in "you visually design your interface by moving controls around"? Is that not a thing?

    I'm gonna go with language barrier on that one.



  • @Maciejasjmj said:

    Uh, as in "you visually design your interface by moving controls around"? Is that not a thing?

    That's exactly the one feature that WinForms is MOST famous for. I really don't get your statement.

    You said WinForms "hardly counts" as visual design and I'm asking: why not?



  • @blakeyrat said:

    That's exactly the one feature that WinForms is MOST famous for. I really don't get your statement.

    @blakeyrat said:

    You can just edit the form's description directly in its C# code.

    That's what I was replying to. And you suggested tweaking the property sheets first. None of those really fit too well the definition I provided, which admittedly might or might not be right.

    Yes, you can use a visual designer for both WinForms and WPF, but especially in the latter case it doesn't seem to do a very good job by itself, which is what I was arguing.



  • @Maciejasjmj said:

    That's what I was replying to. And you suggested tweaking the property sheets first. None of those really fit too well the definition I provided, which admittedly might or might not be right.

    Ok I see what you're saying.

    I'd love to see a proposal about how to describe window resize behavior using only direct manipulation of controls. Maybe it's possible? But I can't think of a way to do it any better than Microsoft's way.



  • @blakeyrat said:

    I'd love to see a proposal about how to describe window resize behavior using only direct manipulation of controls. Maybe it's possible? But I can't think of a way to do it any better than Microsoft's way.

    I don't know. Maybe it's possible, maybe not. I'm not saying MS's visual designers suck specifically, but it's generally better to tweak code/properties/XAML/whatever if you want your design to do what you mean instead of trying to guess.



  • @Maciejasjmj said:

    I don't know. Maybe it's possible, maybe not. I'm not saying MS's visual designers suck specifically, but it's generally better to tweak code/properties/XAML/whatever if you want your design to do what you mean instead of trying to guess.

    Well my point in the other thread is that WinForms doesn't prevent you from doing that if you really want to. The only catch is you have to rebuild the app each time you make a change. (Then again, I think the same's true of XAML for all practical purposes.)



  • @blakeyrat said:

    The only catch is you have to rebuild the app each time you make a change. (Then again, I think the same's true of XAML for all practical purposes.)

    The selling point of XAML isn't that you don't have to rebuild, it's that a designer with less coding expertise can change just the UI part without writing any curly braces or semicolons. In my opinion, XAML is just as dense as any programming language, so I don't see the benefit.



  • s/XAML/UML/ for the reason why diagramming in UML before writing code is a dumb idea.


  • Discourse touched me in a no-no place

    @NedFodder said:

    without writing any curly braces or semicolons

    Curly braces and semicolons put hairs on your chest!



  • Good luck writing xaml without curly braces.



  • @blakeyrat said:

    I'd love to see a proposal about how to describe window resize behavior using only direct manipulation of controls.

    Qt with its layouts is very, very close to this state - IIRC the only thing you have to set in properties are behavior of spacers, and everything else arranges automatically.

    @dkf said:

    Curly braces and semicolons put hairs on your chest!

    And pythons have neither hair nor chests.


  • Discourse touched me in a no-no place

    @Gaska said:

    And pythons have neither hair nor chests.

    They just use braces and semicolons differently (set literals, optional statement separator). I don't know where they put their hairy chests.



  • @Gaska said:

    Qt with its layouts is very, very close to this state - IIRC the only thing you have to set in properties are behavior of spacers, and everything else arranges automatically.

    I don't see how setting the properties of spacers is different than changing the anchor properties. Either way, you're in a property sheet. To what sounds like the exact same extent.



  • Not quite - you just need to set behavior of spacers, as opposed to setting anchors of every single thing.



  • @Gaska said:

    Not quite - you just need to set behavior of spacers, as opposed to setting anchors of every single thing.

    By setting the anchors, you set how widgets resize themselves. By setting spacers, you set how the space between widgets resize themselves. Regardless of which you use, you have to do the actual setting in a property sheet or equivalent.

    I don't see what makes Qt better than WinForms here. If it is better, you sure haven't done a very good job of explaining why.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    By setting the anchors, you set how widgets resize themselves.

    Surely you'd be setting how the space parcel containing the widget resizes itself, or is that the wrong mental model?



  • @dkf said:

    Surely you'd be setting how the space parcel containing the widget resizes itself, or is that the wrong mental model?

    I love people who love to make things pedantic and more complex than necessary.

    Yes. If your "widget" is actually a custom widget which contains multiple native widgets, then it's "space parcel"(?) is resized and the custom widget controls the sizing of the native widgets inside it as part of a cascading layout-type thing.

    Let use 5485734583865783465783456734586345834 more words to describe this fucking easy, simple concept now!!!!!


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Yes. If your "widget" is actually a custom widget which contains multiple native widgets, then it's "space parcel"(?) is resized and the custom widget controls the sizing of the native widgets inside it as part of a cascading layout-type thing.

    It's not as complicated as all that. You've got a surface (like a window or something like that) and you want to put some widgets on it. OK, you subdivide the space into regions — usually rectangular because that makes the calculations easier — and those are the parcels of space, and they're hardly anything much at all, just a rectangle in a data structure. The widgets live in them, and might be stuck to the edges of the parcel or might float inside, or any of a number of other options. There might also be some border spacing involved.

    There are quite a lot of different ways to arrange the space parcels, absolute positioning, relative positioning, gridding (which can come in lots of variations), border-locking, etc. The code that arranges these things goes by different names in different systems, but is often called things to do with layout management or geometry management. Some widget toolkits hard-bind this layout management stuff to particular container widgets (which themselves usually have not much look of their own at all) and others let you mix and match.



  • @blakeyrat said:

    By setting the anchors, you set how widgets resize themselves. By setting spacers, you set how the space between widgets resize themselves. Regardless of which you use, you have to do the actual setting in a property sheet or equivalent.

    Yes, but there's much much less things to set properties of, thanks to layouts.



  • @NedFodder said:

    without writing any curly braces or semicolons.

    @ben_lubar said:

    s/XAML/UML/

    To generalize, every so often somebody has the bright idea that they can save some money on programmers by creating a 'visual programming' environment. The attraction of this is that people can focus on the semantic 'meat' of the problem, without becoming distracted by syntactical concerns, so the same net amount of work can be done by someone less skilled.

    But it often turns out that the kinds of problems that programmers are paid to solve are just hard problems, and you end up needing someone with the same level of expertise to operate the environment as the programmer you were trying to replace, so you don't actually end up any better off.


  • I survived the hour long Uno hand

    @tar said:

    The attraction of this is that people can focus on the semantic 'meat' of the problem, without becoming distracted by syntactical concerns

    I find that becoming a programming polyglot allows you to free your mind from syntax or paradigms of a given language just as easily. Honestly, I feel like any programmer who values their craft will have a good half dozen or so languages in their toolbox anyway; when someone says they only know one language, I tend to start using smaller words to explain to them what I'm talking about by default. You might be REALLY GOOD at Javascript, but odds are you're not great at software engineering if you're not the kind of person who's picked up another couple languages along the way.


  • :belt_onion:

    I wonder if there are any concrete data on how that worked out for QML. It's main idea is, given that it looks CSS-ish / is scripted in JS, and that it's easy to hook it up to a complex C++ backend without knowing the implementation details, people like web designers should be able to create functional apps using it without much effort.

    Honestly, I doubt it panned out. But I'm not complaining that it exists. It still has it's kinks being a relatively new language, true, but I like the fact that it's really easy to knock out a quick and dirty UI in it and mess around with prototypes without having to worry about all the cruft in the backend. Kinda like modern HTML5 frameworks, really, but for local apps rather than a web-based interface.


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    You might be REALLY GOOD at Javascript, but odds are you're not great at software engineering if you're not the kind of person who's picked up another couple languages along the way.

    Conversely, I'm not a great JS programmer, but I can code far better in it than most JS programmers because I've learned enough languages that JS is just one more with only minor differences from the rest (and some great deployment advantages for web-delivered client code).



  • "Visual programming" will end as soon as the managers will understand that syntax is the easy part. Which is probably never.



  • In the case of xaml the syntax actually is the hard part. Well, it's between that and knowing all of the library classes and properties that are available, which I think vs does a reasonably good job of letting you know about.



  • Click-and-drag programming solves both the problem of not knowing the library classes (they're right there) and the problem of having a powerful standard library (because you need to be able to find the thing you're supposed to drag into place).


  • I survived the hour long Uno hand

    Everyone secretly wants to write code like this!



  • By powerful do you mean disorganized?



  • Well, if having a powerful standard library is a problem, try a visual programming language!



  • Oh God, is that RunRevolution? Or whatever it's called now?



  • @dkf said:

    Conversely, I'm not a great JS programmer, but I can code far better in it than most JS programmers because I've learned enough languages that JS is just one more with only minor differences from the rest (and some great deployment advantages for web-delivered client code).

    I think the statement you're making is generally true. However, JS has the distinction of looking like a lot of other languages - but if you transfer your habits over from them, you'll regret it. For example, most bracket styles are absolute no-no's in JavaScript.



  • You have a strange definition of "most".

    My Go brace style works fine in JavaScript, and it also works in Java, C, C++, C#, ...



  • @Jaime said:

    For example, most bracket styles are absolute no-no's in JavaScript.

    How do you figure?



  • @blakeyrat said:

    How do you figure?

    If you put a carriage return before an opening brace, then you risk Automatic Semicolon Insertion separating the body from the declaration. ASI is evil.



  • @Jaime said:

    If you put a carriage return before an opening brace, then you risk Automatic Semicolon Insertion separating the body from the declaration.

    That's not true.

    @Jaime said:

    ASI is evil.

    Arguably true. But your example scenario doesn't happen in JS. Try it yourself.



  • @ben_lubar said:

    You have a strange definition of "most".

    My Go brace style works fine in JavaScript, and it also works in Java, C, C++, C#, ...


    "Most" meaning any brace style that doesn't put the opening brace on the same line as the lead-in. See above reply.



  • @blakeyrat said:

    That's not true.

    I didn't say it always happens, just you'll risk it. Here's an example. When it does happen, it's infuriating and usually takes a long time to figure out.



  • @Jaime said:

    I didn't say it always happens, just you'll risk it. Here's an example. When it does happen, it's infuriating and usually takes a long time to figure out.

    I've spent like 2/3rds of my career writing almost exclusively JS, and I've never managed to make that error before.

    EDIT: in fact, until just now when I read that blog post, I've never seen seen that error. In my entire career.



  • @Jaime is the kind of person who uses curly braces in Python and then gets angry at the parser when it returns an error.



  • @ben_lubar said:

    @Jaime is the kind of person who uses curly braces in Python and then gets angry at the parser when it returns an error.

    Riiiiight..... I'm totally imagining things, even though I provide a link to an actual example where brace style affects code execution.



  • @ben_lubar said:

    @Jaime is the kind of person who uses curly braces in Python and then gets angry at the parser when it returns an error.

    This is trivially resolved with just a couple of lines of preprocessor magic...

    #define { :
    #define }
    

    There. Now I can write Python as K&R intended, as follows:

    def python_is_trwtf(name) {
        print("Hello %s, how do I Python?" % name); # because % is for string formatting
    }
    

    Filed under: sed -e 's/{/:/g' -e 's/}//g', insert :smile<FFFFUUUUUU>: in my post again, motherfucker, I double dare you!


  • :belt_onion:

    Who the fuck creates objects inside the return statement? I mean, yes, fuck JavaScript for it's ASI bullshit. But fuck this obtuse way of writing code. Just create a new variable, this is JS, you're not optimizing it for embedded hardware, you can spend a few more bytes. Shit like this is something I expect a minimizer to spew out, not something I want to see in the code that's intended for humans to read.



  • If I wanted to have to preallocate each and every instance of object I'm going to use, I would write in C.


  • I survived the hour long Uno hand

    @blakeyrat said:

    is that RunRevolution?

    BlueJ. I was forced to use it for a class in my Masters' programme.

    @blakeyrat said:

    I've never managed to make that error

    Every example I've seen where ASI screws you over happens if you break up a return statement with a block... which most people don't ever have a reason to do. That said, fuck Javascript.



  • @Yamikuronue said:

    Every example I've seen where ASI screws you over happens if you break up a return statement with a block... which most people don't ever have a reason to do.

    And why would you do that? I mean even if it worked in JS, it looks atrocious. Return either goes by itself, or you use it like a function call, them's the rules.



  • If you use the common boilerplate jQuery widget function style, and add a global above it, you will get the ASI problem:

    var someGlobal = 7
    (function($){
        // some jQuery stuff
    }(jQuery));
    

  • :belt_onion:

    @blakeyrat said:

    I mean even if it worked in JS

    Well... it does, but...

    @blakeyrat said:

    it looks atrocious

    Yes.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.