Future standard GUI library


M

Michael Torrie

Modularization and layers were a brilliant idea long before the web came
around.

True. Though it seems like it fell out of fashion for a long time. I
went to school before the advent of web development and though we talked
about modularization and coupling in software engineering, really it was
all rather monolithic. Web development changed our focus back to where
it should have been all along.
 
Ad

Advertisements

C

Chris Angelico

Chuckle. Simple CRUD, eh. Almost all apps involve database CRUD
interactions. And often in highly complex ways using business logic.

Right. Sturgeon's Law of Applications.

ChrisA
 
W

Wolfgang Keller

Your back end exposes services and business logic, and your front end
can be in HTMLv5 and Javascript, or QtQuick, PyGTK, or Visual
Studio. If you do need a native interface, it's a heck of a lot
easier to rewrite just the frontend then the entire stack.

Any decent database CRUD framework will allow to implement the
application model as "behaviour complete" domain objects, with a
persistence layer totally independent from the GUI layer. In many
Python RAD frameworks, this is done using SQLalchemy.
Who cares how the RPC is done;

As an end-user I do care for how much an application makes we watch the
cursor animation.
that's an implementation detail. HTTP does happen to work well
though. Why do you say it is not suitable?

Because from personal experience I know too well that it does definitely
not "work well though".
suppose I now want the app natively on my phone (because that's all
the rage). It's an iPhone. Oh. Apple doesn't support Python.
Okay, rewrite the works, including business logic, in Objective C.
Now I want it on my android phone.

Those are gadgets, not work tools.

Sincerely,

Wolfgang
 
W

Wolfgang Keller

HTTP handles that just fine, with your choice of XML,

And XML is definitely not suitable as a marshalling format for a RPC
protocol.

XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless
moron.

Sincerely,

Wolfgang
 
M

Michael Torrie

And XML is definitely not suitable as a marshalling format for a RPC
protocol.

XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless
moron.

Hmm. Well I think there are a lot of very smart developers that are
using xml to marshal rpc and it's working fine. So either they know
something you don't, or maybe they are just busy making code that
functions and functions pretty well, instead of making inflammatory
statements on USENET. Sure XML is not very efficient or compact, but it
does handle unicode intrinsically through standard encodings, and a
plethora of parsers makes it a decent choice. It's like what they say
about the book: "for though it has many omissions and contains much that
is apocryphal, or at least wildly inaccurate, it scores over the older,
more pedestrian work in two important respects.
First, it is slightly cheaper; and second, it has the words Don't Panic
inscribed in large friendly letters on its cover."

I've used LBER-encoded wire protocol before, and it was fine, but hard
to debug on the wire, and didn't haven anything in it to handle unicode
except base64-encoding utf8 byte streams.

That said, all this reminds me of a good saying, "XML is like violence;
if it doesn't solve your problem you're not using enough of it."
Fortunately none of this really matters. Who cares what is used to
marshall RPC over the wire? As a developer I certainly don't care. I'll
use whatever is convenient and well supported. One reason I do like
xmlrpc, though, because it's pretty much available to all web-based back
ends for free (or at little cost) and you don't need to set up a special
server process to handle it, or deal with odd port numbers that might be
blocked, doing ssl yourself, etc. Having HTTP do the transport frees me
from having to worry about all that, since in the case of a web app I am
already using a web server.
 
M

Michael Torrie

Those are gadgets, not work tools.

As a professional programmer I'm afraid you're going to soon find
yourself out of work if you really see things that way. I honestly used
to feel that way about graphical user interfaces.
 
Ad

Advertisements

C

Chris Angelico

Hmm. Well I think there are a lot of very smart developers that are
using xml to marshal rpc and it's working fine. So either they know
something you don't, or maybe they are just busy making code that
functions and functions pretty well, instead of making inflammatory
statements on USENET. Sure XML is not very efficient or compact, but it
does handle unicode intrinsically through standard encodings, and a
plethora of parsers makes it a decent choice.

I'll use XML when I have to, but if I'm inventing my own protocol,
nope. There are just too many quirks with it. How do you represent an
empty string named Foo?

<Foo></Foo>

or equivalently

<Foo/>

How do you represent an empty list named Foo? The same way. How do you
represent an empty dict/mapping named Foo? Lemme look up my
documentation... ah, the same way. Does this seem right to
you?</JubalEarly>

ChrisA
 
R

Roy Smith

Chris Angelico said:
I'll use XML when I have to, but if I'm inventing my own protocol,
nope. There are just too many quirks with it. How do you represent an
empty string named Foo?

<Foo></Foo>

or equivalently

<Foo/>

How do you represent an empty list named Foo? The same way. How do you
represent an empty dict/mapping named Foo? Lemme look up my
documentation... ah, the same way. Does this seem right to
you?</JubalEarly>

XML doesn't represent strings, or lists, or dicts. It represents trees
of nodes with labels. If you wish to invent some richer semantic
meaning to impose on those nodes, that's up to you.

JSON isn't better or worse than XML. They solve different problems.
 
D

Denis McMahon

I'll use XML when I have to, but if I'm inventing my own protocol,
nope. There are just too many quirks with it. How do you represent an
empty string named Foo?

or equivalently

How do you represent an empty list named Foo? The same way. How do you
represent an empty dict/mapping named Foo? Lemme look up my
documentation... ah, the same way. Does this seem right to
you?</JubalEarly>

<Foo type="list" />
<Foo type="mapping" />
<Foo type="string" />
 
C

Chris Angelico

XML doesn't represent strings, or lists, or dicts. It represents trees
of nodes with labels. If you wish to invent some richer semantic
meaning to impose on those nodes, that's up to you.

Sure it doesn't, but it's very often used that way. So I guess what
I'm really saying is that XML is wrong for 90% of the places it's
used.

ChrisA
 
8

88888 Dihedral

Chris Angelicoæ–¼ 2013å¹´5月28日星期二UTC+8下åˆ3時11分55秒寫é“:
Sure it doesn't, but it's very often used that way. So I guess what

I'm really saying is that XML is wrong for 90% of the places it's

used.



ChrisA

Please check the annual sales in Ebay or similar sites and the
advertizement fees collected by Google and Yahoo.
 
Ad

Advertisements

G

Grant Edwards

Modularization and layers were a brilliant idea long before the web came
around.

Once again USENET proves to be an unsuitable RPC protocol for
implementing irony. :)

[OTOH, perhaps Micheal wasn't being ironic...]
 
W

Wolfgang Keller

What is "screenwork"?

Actually productive work of significant intensity at a computer screen.

As opposed to leisurely "clicking around" like managers, administrators
or home users (gaming, "webbing",...) do.

Sincerely,

Wolfgang
 
M

Michael Torrie

I won't give you an example, but just some very basic criteria:

- It must be very efficient for very small "datagrams"

I won't argue for XML here, but sometimes space efficiency is simply a
premature optimization.
- It must provide connections

How would you do this? Connections can and do get dropped regularly.
To rebuild connections you need another layer to track them.
- For asynchronous programming it must provide for callbacks

What do you mean by this? A transport layer has nothing to do with
callbacks. All a client can do is make the call, and wait for the
answer. The client library can make it look asynchronous of course.
And I suppose one could implement an RPC system using UDP where answer
packets are dispatched as they come in.
 
C

Carlos Nepomuceno

----------------------------------------
From: (e-mail address removed)
Subject: Re: Future standard GUI library
Date: Tue, 28 May 2013 19:26:55 +0200
To: (e-mail address removed)


I won't give you an example, but just some very basic criteria:

- It must be very efficient for very small "datagrams"

Interoperability is much more expensive than efficiency. That's why you won't get the most optimized protocol for speed or size.
- It must provide connections

What do you mean?
- For asynchronous programming it must provide for callbacks
No RPC-over-HTTP protocol that I know of does this.

XHR implements asynchronous callbacks over HTTP.
Besides, no one needs RPC just to logically separate GUI and
application layer. And between application logic and database, you use
the native database API for the RDBMS in question, of course.

The whole idea to centralise application logic (and even the GUI with
"web applications") is backwards, it dates from the 70s/early 80s when
desktop computers weren't able to run application logic. Today, to make
an application responsive (minimise latencies and maximise throughput),
it's just obvious to *de*-centralise as much as possible. In fact,
if Postgres-R was available for production, you could even distribute
the persistence and run an entirely "serverless" application.

"web applications" is so nowadays! All of my recent software development projects (last 10 years) focus on business processes integration.
In all of them the BLL (Business Logic Layer), or "application logic", is run on server side (as a controller in MVC) due to security and performance reasons.
None of my clients want their business rules and internal workflows exposed, so the old ways of the 70/80's ain't gonna change.
 
Ad

Advertisements

8

88888 Dihedral

Grant Edwardsæ–¼ 2013å¹´5月29日星期三UTC+8上åˆ2時25分08秒寫é“:
Oh. You mean emacs.



--

Grant Edwards grant.b.edwards Yow! Will it improve my

at CASH FLOW?

gmail.com

Check http://www.pyamf.org/index.html for Python +flash
in browser applications. Annyway the virtual server part
can be obtained from the Adobe system in the cloudy services
or whatever.

As long as it is scalable in fees to provide services
to web users in PCs or mobile phones,
then it might be very profitable than 10 to 15 years ago.
 
W

Wolfgang Keller

suppose I now want the app natively on my phone (because that's all
As a professional programmer I'm afraid you're going to soon find
yourself out of work if you really see things that way.

As a "domain expert", I come from the end-user side of "enterprise
applications" and again; those are not tools for screenworkers to get
actual work done, but consumer crap for fad-driven gadget-addicted kids
(regardless of nominal age).
I honestly used to feel that way about graphical user interfaces.

A GUI that can not be used without taking the ten fingers off the
keyboard is indeed entirely unusable for any half-proficient
screenworker. And anyone doing actual productive screenwork every day
for more than just a few months will inevitably (have to) get proficient
(unless completely braindead).

Sincerely,

Wolfgang
 
C

Chris Angelico

A GUI that can not be used without taking the ten fingers off the
keyboard is indeed entirely unusable for any half-proficient
screenworker. And anyone doing actual productive screenwork every day
for more than just a few months will inevitably (have to) get proficient
(unless completely braindead).

My ten fingers stay on my keyboard, which looks somewhat thus:

http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg

See the red dot in the middle? Mouse. See the keys all around it? My
hands are all over that. I can casually mouse and keyboard at the same
time. Doesn't bother me.

THIS is a professional programmer's workspace. :)

ChrisA
 
Ad

Advertisements

W

Wolfgang Keller

A GUI that can not be used without taking the ten fingers off the
My ten fingers stay on my keyboard, which looks somewhat thus:

http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg

See the red dot in the middle? Mouse.

I didn't mean "trackpoints" or similar devices, but full keyboard
"navigation" of the entire GUI through shortcuts etc.

A "touch-type" GUI is a "must have" for any application that's supposed
to be used productively. The mouse is nice to "explore" a GUI or for
occasional/leisurely use, but once you use an application daily to earn
your living, it's a hopeless roadblock for productivity.

As is the "response time" behaviour of "web applications".

Besides that pathological non-operating system MS (Not Responding),
btw.

"No cursor animation ever" is an absolute "must have" requirement for
productivity applications.
THIS is a professional programmer's workspace. :)

And by "screenworkers" I didn't refer to programmers. Those people
rarely have to use the stuff that they implement.

Sincerely,

Wolfgang
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top