Walter Bright wrote:
> The structure of the ASTs would need to match

You may be right: http://www.cs.brown.edu/publications/jgaa/accepted/99/Eppstein99.3.3.pdf

-manfred

On Mon, 19 Aug 2013 22:18:04 +0200
"Ramon" <spam@thanks.no> wrote:

> Sorry, this is a long and big post. But then, so too is my way that led me here; long, big, troublesome. And I thought that my (probably not everyday) set of needs and experiences might be interesting or useful for some others, too.

Thank you very much for this post.

I was considering to use D for quite some time for multi-platform gui project, but was not satisfied with the state of its GUI bindings (only gtkd although someone was working on wx bindings, but, afaik, nothing happened) as well as non-stability of the language itself.

That led me to research and try some other languages, starting with OCaml, then explored .NET/Mono platform and languages like F# (even Cobra).

On the other end of the spectrum I've tried some obscure ones like Nimrod and finally considered Ada as the most robust/safe option with decent options for GUI (GTK & Qt).

Your post and another thread 'DQuick a GUI Library (prototype)' makes me optimistic that it would be possible to use D as the 'general programming language' sutiable for writing GUI apps as well.


Sincerely,
Gour

-- 
A person who is not disturbed by the incessant flow of desires — that enter like rivers into the ocean, which is ever being filled but is always still — can alone achieve peace, and not the man who strives to satisfy such desires.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky wrote:
> On Wed, 21 Aug 2013 18:50:35 +0200
> "Ramon" <spam@thanks.no> wrote:
>> 
>> I am *not* against keeping an eye on performance, by no means. Looking at Moore's law, however, and at the kind of computing power available nowadays even in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance of performance is way overestimated (possibly following a formertimes justified tradition).
>> 
>
> Even if we assume Moore's law is as alive and well as ever, a related
> note is that software tends to expand to fill the available
> computational power. When I can get slowdown in a text-entry box on a
> 64-bit multi-core, I know that hardware and Moore's law, practically
> speaking, have very little effect on real performance. At this point,
> it's code that affects performance far more than anything else. When we
> hail the great performance of modern web-as-a-platform by the fact that
> it allows an i7 or some such to run Quake as well as a Pentium 1 or 2
> did, then we know Moore's law effectively counts for squat -
> performance is no longer about hardware, it's about not writing
> inefficient software.
>
> Now I'm certainly not saying that we should try to wring every last
> drop of performance out of every place where it doesn't even matter
> (like C++ tends to do). But software developers' belief in Moore's law
> has caused many of them to inadvertently cancel out, or even reverse,
> the hardware speedups with code inefficiencies (which are *easily*
> compoundable, and can and *do* exceed the 3x slowdown you claimed in
> another post was unrealistic) - and, as JS-heavy web apps prove, they
> haven't even gotten considerably more reliable as a result (Not that JS
> is a good example of a reliability-oriented language - but a lot of
> people certainly seem to think it is).

Moore's law is fine. The problem is power nowadays. Either the devices is mobile, which means we should try to save battery, or performance is limited by cooling.

MOre detail: http://beza1e1.tuxen.de/articles/power_wall.html

On Friday, 23 August 2013 at 05:28:22 UTC, Tyler Jameson Little wrote:
> I assume this is something that can be done at runtime:
>
>     int[] a = [1, 2, 3];
>     int[] b = [2, 2, 2];
>     auto c = a[] * b[]; // dynamically allocates on the stack; computes w/SIMD
>     writeln(c); // prints [2, 4, 6]

This would be pretty trivial to implement but the question is whether it's a good idea:

Heap allocation is out of the question as it's much too slow to be hidden behind what are supposed to be fast vector operations.

Explicit runtime stack allocation could work, but it's not something we do much of in D. I know Maxime (https://github.com/maximecb/Higgs) uses alloca a bit, but if I remember correctly it wasn't all smooth going.

What definitely should work, but currently doesn't, is this:
     int[3] a = [1, 2, 3];
     int[3] b = [2, 2, 2];
     auto c = a[] * b[]; // statically allocated on stack.

as it can be totally taken care of statically by the type system. Actually I think it's just a straight up compiler bug, because this *does* work:
     int[3] a = [1, 2, 3];
     int[3] b = [2, 2, 2];
     int[3] c = a[] * b[]; // statically allocated on stack.


It looks like it's rejecting the array op before it's worked out what to resolve auto to.

On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
[...]
>
> Probably making myself new enemies I dare to say that gui, colourful and generally graphics is the area of lowest quality code. Simplyfying it somewhat and being blunt I'd state: Chances are that your server will hum along years without problems. If anything with a gui runs some hours without crashing and/or filling up stderr, you can consider yourself lucky.
> Not meaning to point fingers. But just these days I happened to fall over a new gui project. Guess what? They had a colourful presentation with lots of vanity, pipe dreams and, of course, colours. That matches quite well what I have experienced. Gui/graphical/colour stuff is probably the only area where people seriously do design with powerpoint. I guess that's how they tick.
>
> You can as well look at different developers. Guys developing for an embedded system are often hesitating to even use a RTOS. Your average non-gui, say server developer will use some libraries but he will ponder their advantages, size, dependencies and quality. Now enter the graphic world. John, creating some app, say, to collect, show, and sort photos will happily and very generously user whatever library sounds remotely usefull and doesn't run away fast enough.
>
> Results? An app on a microcontroller that, say, takes care of building management in some 10K. A server in some 100K. And the funny photo app with 12MB plus another 70MB libraries/dependencies. The embedded sytem will run forever and be forgotten, the server will be rebooted ever other year and the photo app will crash twice a day.

Well, I'm a friend of GUIs simply because with a GUI everyone can use computers not just tech-savvies, and that's what computers are there for, aren't they? The problem are not the GUIs, I think, but the mentality. MVC hardly ever works in real life due to constraints in framework design or deadlines. Cocoa if used sensibly is great. But most of the time you don't have proper MVC because GUI frameworks "seduce" people to do sh*it like

bool saveText() {
  text = textArea.getText(); // View!!! You're mad!
  savek(text);
  return Arghhhh!;
}

instead of

bool saveText() {
  text = model.getText(); // Model! Good man youself!
  save(text);
  return fine;
}

It's the "bolt-on" mentality that ruins things, which is partly due to deadlines. As one guy once said to me (after I had complained about a quick and dirty implementation) "We have the choice between doing it right and doing it right NOW!" Ain't no more to say.

Also, sadly enough, technologies that were never meant to be for GUIs are being used for GUI design. PHP and JS (shudder!!!!) Much as I try to keep up a proper MVC pattern, it's useless. Things will always be dirty, disgusting, work-arond-y, unsafe, buggy, you name it. And you just stop giving a sh*t. Ain't no use.

And last but not least, a programmer can work for hours on end implementing a clever algorithm, using unit tests, component programming etc etc. Nobody will ever notice. If users see a button that when they press it the screen says "Hello User!", they are forever happy. What goes on under the hood is "boys and their toys".

On Friday, 23 August 2013 at 07:15:49 UTC, Gour wrote:
> On Mon, 19 Aug 2013 22:18:04 +0200
> "Ramon" <spam@thanks.no> wrote:
>
>> Sorry, this is a long and big post. But then, so too is my way that led me here; long, big, troublesome. And I thought that my (probably not everyday) set of needs and experiences might be interesting or useful for some others, too.
>
> Thank you very much for this post.
>
> I was considering to use D for quite some time for multi-platform gui
> project, but was not satisfied with the state of its GUI bindings (only
> gtkd although someone was working on wx bindings, but, afaik, nothing
> happened) as well as non-stability of the language itself.
>
> That led me to research and try some other languages, starting with
> OCaml, then explored .NET/Mono platform and languages like F# (even
> Cobra).
>
> On the other end of the spectrum I've tried some obscure ones like
> Nimrod and finally considered Ada as the most robust/safe option with
> decent options for GUI (GTK & Qt).
>
> Your post and another thread 'DQuick a GUI Library (prototype)' makes me
> optimistic that it would be possible to use D as the 'general
> programming language' sutiable for writing GUI apps as well.

Now, careful, Gour

What I wrote was written with close to zero D experience and
largely based on spec, gut feeling (W. Bright implements
languages since 2+ decades and says straightout that he
approached from a pragmatic view; which in my book counts as a
bik +) and some logical verification.
And it was said from someone who wants at least a large part of
Eiffels goodness in a more C/C++ way and look and feel and
practical useability.

So, this might be pretty far away from what you consider
reasonable, important, etc.

Yes, I think that D lends itself very well to GUI programming
and, more importantly (to me) it's one of the *very* few
languages in which a useful, professional and soundly designed
GUI lib could be implemented with adequate and reasonable efforts.

A warning though (and one I tried to get written in red permanent
marker like letters in my own head) when studying D somewhat more
(along the D book): Don't underestimate D! One might be led to
look at it as some kind of "easier C++ and better done"; it is
not. Or, more correctly, It is way more than that and offers a
lot of freedom paradigmwise.

If GUI is very important to you it might also be useful to look
at a small GUI (like lus'a IUP) and tinker along the lines of how
this would, could, and should be done in D and at how it was
actually done e.g. with the gtk binding.

I hope you'll enjoy D as much as I'm beginning to do ;)

On Friday, 23 August 2013 at 10:34:08 UTC, Chris wrote:
> On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
> [...]
>>
>> Probably making myself new enemies I dare to say that gui, colourful and generally graphics is the area of lowest quality code. Simplyfying it somewhat and being blunt I'd state: Chances are that your server will hum along years without problems. If anything with a gui runs some hours without crashing and/or filling up stderr, you can consider yourself lucky.
>> ...
>
> Well, I'm a friend of GUIs simply because with a GUI everyone can use computers not just tech-savvies, and that's what computers are there for, aren't they? The problem are not the GUIs, I think, but the mentality. MVC hardly ever works in real life due to constraints in framework design or deadlines. Cocoa if used sensibly is great. But most of the time you don't have proper MVC because GUI frameworks "seduce" people to do sh*it like

Oh, I'm not at all anti-GUI "politically". I don't like anything graphical (incl. X, Photoshop and pretty everything with pixels and colours) for *pragmatic* reasons.

Actually I *do* see the advantages of a GUI and value them. And I detest them for being sloppily designed along a set of criteria DTP guys or artist might consider great but missing simple, everyday needs. I detest them for usually being implemented in an unsound way and generously wasting Megabytes and resources and ... (*pushing brake*)

Just look at a modern browser. It happily eats up around 200 - 300 MB Ram and a good part of the CPU's cycles. And that for 1 person.
Now look at a server. It walks and works and dances with 1% to 10% of memory, a fraction of CPU cycles and serves hundreds of users.
Look at a smartphone ...

> It's the "bolt-on" mentality that ruins things, which is partly due to deadlines. As one guy once said to me (after I had complained about a quick and dirty implementation) "We have the choice between doing it right and doing it right NOW!" Ain't no more to say.

Right you are. But then, this is also true for anyone else. Pretty every software (in a company) is created with tight deadlines and "design", priorities, and features dictated by Marketing and product management (read: marketing/sales).

It's a sad state of affairs but quite probably the most efficient way to very considerably increase product and code quality within a very shiort time is to shot some marketing people.(No, Obelix, you may not kill some graphic artists "while we are at it")

> Also, sadly enough, technologies that were never meant to be for GUIs are being used for GUI design. PHP and JS (shudder!!!!) Much as I try to keep up a proper MVC pattern, it's useless. Things will always be dirty, disgusting, work-arond-y, unsafe, buggy, you name it. And you just stop giving a sh*t. Ain't no use.

Hey, didn't they tell you? PHP and JS are freedom technologies, enabling everyone to .... - well, now they actually *do* it and we know what the Bible was about speaking of hell and unbearable pain.
Where is Obelix? His attitude ("may I kill some?") might come in handy ...

>
> And last but not least, a programmer can work for hours on end implementing a clever algorithm, using unit tests, component programming etc etc. Nobody will ever notice. If users see a button that when they press it the screen says "Hello User!", they are forever happy. What goes on under the hood is "boys and their toys".

Nope. Unless, of course, Joe and Mary "I'll gladly click on anything and btw. Mr. Bob is cool" are your reference.

Listen: Your reference is quality, realiability, even elegance (an excellent indicator), maybe performance and yourself knowing you did it well. Don't give Joe and Mary any power they wouldn't know how to use anyway.
And btw: Probably Joe and Mary won't know about or even understand your work. But they *will* notice that your stuff works reliably and well.

On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
>
> Listen: Your reference is quality, realiability, even elegance (an excellent indicator), maybe performance and yourself knowing you did it well. Don't give Joe and Mary any power they wouldn't know how to use anyway.
> And btw: Probably Joe and Mary won't know about or even understand your work. But they *will* notice that your stuff works reliably and well.

Yes, of course. But shiney little buttons impress people and often the GUI logic is neglected due to a "Click, it works! Let's move on to something else" mentality. A lot of apps out there don't have a proper MVC architecture (look wxPython or Tkinter apps). It's just so easy to be neglegent.

On Friday, 23 August 2013 at 14:30:06 UTC, Chris wrote:
> On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
>>
>> Listen: Your reference is quality, realiability, even elegance (an excellent indicator), maybe performance and yourself knowing you did it well. Don't give Joe and Mary any power they wouldn't know how to use anyway.
>> And btw: Probably Joe and Mary won't know about or even understand your work. But they *will* notice that your stuff works reliably and well.
>
> Yes, of course. But shiney little buttons impress people and often the GUI logic is neglected due to a "Click, it works! Let's move on to something else" mentality. A lot of apps out there don't have a proper MVC architecture (look wxPython or Tkinter apps). It's just so easy to be neglegent.

Absolutely, Chris,

I get your point and I do not disagree.

But, to be fair: We *all* are in some way or another guilty of that sin. Do we, for instance, all really see, value and appreciate the math behind behind many good things? Or do we, let's be honest, usually just say "Wow, D has cool dynamic arrays, that makes my life easier or Yowza, TLS 1.2 offers considerable security"? Frankly, most and that includes programmers, do not even make the effort to properly learn and understand the basics so as to, e.g. user the proper chain mode.

I have an image that helps me. I see my "other" grandpa (actually a neighbour) having worked with wood, looking at his workpiece, refining it again a little until finally he looks at it and is content and everythings just fits nicely.

On Fri, 23 Aug 2013 15:35:19 +0200
"Ramon" <spam@thanks.no> wrote:

> If GUI is very important to you it might also be useful to look at a small GUI (like lus'a IUP) and tinker along the lines of how this would, could, and should be done in D and at how it was actually done e.g. with the gtk binding.

I explored that path - see e.g.: http://article.gmane.org/gmane.comp.lib.iup.user/368

so it's a no got for multi-platform app with required i18n support.

> I hope you'll enjoy D as much as I'm beginning to do ;)

Let's see...


Sincerely,
Gour

-- 
For him who has conquered the mind, the mind is the best of friends; but for one who has failed to do so, his mind will remain the greatest enemy.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810