Thoughts on the future of Python and graphical interfaces
medium.com
medium.com
It's good that we've finally been able to agree on a common set of tools to make UIs, it's just too bad it had to be this one.
The HTML/JS/CSS/DOM mess is a pretty terrible solution that we seem to be stuck with.
History is peppered with UI authoring tools that were better but stewarded by companies that held to tight licensing that stunted their growth. Hypercard, delphi, adobe flash (and FLEX - which looks a lot like react), even unity has more intuitive wysiwyg UI tools that could have proved versatile with the right stewardship.
The difference is vertical integration. These companies made their tools complete solutions and often went so far as to put virtual machines on everything to interpret them correctly every time.
The article's author touches on the license problem with python's own pretty damn good QT lib.
If only someone could find a way to make a good tool without fucking up licensing.
The licensing for Qt itself is very simple: if you redistribute and don't go GPL, you have to pay. It's one of the fairest arrangements out there. PyQt has similar terms.
The way that makes most sense to me is charging for the authoring tools and making the language/VM completely open (e.g. MIT license).
Maybe that's too idealistic?
You're implying that they should charge others for the parts that you don't care about? If only they had been a bit more creative...
Keeping the underlying language open simply means that it would have been more usable and extensible.
Not saying it was super easy to use (took me a while to get drag & drop working the way I wanted, I even ended up subclassing XmText to get rectangular highlighting) but it sure was nice, I wonder what would've happened if it had not been commercial but had been available on an open licence to start with.
I don't have a fully-formed hypothesis, and I like native apps better than WebKit/electron based apps just like the next guy, but there has to be something to it, no?
HTML is actually one of the most powerful layout engines out there, Javascript is as versatile and powerful a language as you might want to ask for in 90% of the cases, CSS has it's flaws but they are being addressed and is fine for most styling issues and DOM is just a very easy to understand albeit crude way to handle objects.
All in all a combination of tools that makes it extremely easy to get started and se results right away. I believe this is also on of the reasons why PHP is so popular. It's ability to seamlessly integrate with that "mess" either to take over the formatting or to fit into the existing formatting.
It's a conceptual framework thats closest to what we as humans understand.
Pythons problem like most other programming languages including Objective-C and Ruby is that while they are elegant and powerful computationally they are horrible for most people to get started with because just setting it up in itself is a big task.
So I don't think we are stuck. In fact I believe that if Python would take the same laize faire approach to the mess as PHP it would be much more popular than it is today.
There are things it's optimal for but luckily we don't live in a world were people only do what things were originally meant for.
I am using gmail in the browser. I am discussing this with you. I am transferring money between accounts, playing games, filling out surveys, controlling projects, looking up routes on map, enjoying streaming music, video etc.
It's all good.
I can write medical-imaging software in sed, because sed is Turing-complete, but if I did that I would be insane.
Using HTML, JavaScript and CSS for general-purpose software is only slightly saner.
If the web was such a terrible application platform then it would not have been able to stomp the traditional desktop as much as it already has so far.
But quite a big part of those apps uses webview to render information in.
We are now in the year 2016, not 1996. Browsers moved past the "networked document viewer" stage well over a decade ago and have been deliberately evolving into full application platforms ever since.
But it's terribly verbose and isn't extensible. XML was extensible, but even more verbose.
Also, I wouldn't say that HTML is a layout engine; CSS is the layout engine while HTML denotes the structure to be laid out.
> Javascript is as versatile and powerful a language as you might want to ask for in 90% of the cases
Erm, no. It's a terrible little language with some horrible misfeatures (==/===, {} &c.) which has one virtue: near-universal deployment.
> DOM is just a very easy to understand albeit crude way to handle objects
I've never really thought the DOM was all that easy to understand. Attributes vs. nodes, text nodes in unexpected places — it's a mess compared to a nice tree of strings and trees would be.
> It's a conceptual framework thats closest to what we as humans understand.
No, it's the conceptual framework we ended up with, so we all have taught ourselves and been taught to understand it.
> Pythons problem like most other programming languages including Objective-C and Ruby is that while they are elegant and powerful computationally they are horrible for most people to get started with because just setting it up in itself is a big task.
sudo apt-get install python
python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "hello world"
'hello world'
>>>
Your answer perfectly illustrates my point.
You focus on the wrong things. None of your distinctions or interpretations of what I say are wrong per-se, they are just not important distinctions.
The fact is that people can quickly build a webpage with all the bells and whistles in an environment they undertand without having to install anything or rely on dependencies to get started.
They can fiddle around, experiment with it in real time etc. they can play around with it so to speak.
It doesn't take itself too serious. It doesn't have a "guardians of the right way" saying how it can and can't be used.
You can still go to town and go crazy in making perfectly optimized code but it's not demanding that from you.
These are the important bricks in creating something that is powerful. It's ability to function as a toy for the very novice people. To easily provide them with visual feedback with assets they can relate to (cat pictures, video they saw somewhere) etc.
This is what VB had this is what HTML/CSS/JS/DOM/(PHP) has in spades. The non-judgement of the experts.
We're stuck with this cobbled together mess of mostly broken shit in browser-land, and there is no bigger-and-better thing we can graduate to.
Learning 1 single (and relatively simple) language vs HTML/CSS for presentation (and all its headaches) and JS for logic/interaction? The browser is a stack, not a single piece of tech.
Most projects don't need python to be successful.
Feel free to replace is with any other language. The point still stands.
I think we must be talking past each other.
If you go back and see what I originally responded to, perhaps the context becomes a little clearer.
There was nothing in the OP this thread devolved from about Python itself, other than it having a great QT library. And as far as context is concerned, this particular comment trail was a response to the ease of using Python, not anything at all related to it being "serious" compared to web-stack.
How are we so far apart regarding what is actually being discussed in context? We can both read the comment thread we each keep replying to. Your context (and points) keeps changing.
A. Open your favorite terminal emulator
2. Type "python"
D. Press "enter"
Also, I think you meant laissez-faire.
Even after that is solved it's still hard for people to understand exactly why they should choose Python vs. HTML/CSS/JS/DOM.
In fact I don't think you can give one example of why they in 90% of the cases should use Python unless they are doing fairly complex stuff.
Most people don't know anything about HTML, CSS, JS, the DOM, how we got here, how it works, etc. They are neither the target audience of the article nor of the discussion happening here.
One fucking language.
Looked the same on every device.
And it wasn't hard to get a project going. We are making a fucking computer application, not boiling water for tea.
Now everyone thinks it's progress and noteworthy and oh-my-fucking-gods-amazing to do this shit with fucking HTML, CSS, and JavaScript. What. The. Fuck.
Can't Silicon Valley startups afford developers who can...you know...learn technology and write some code? Is SV only able to disrupt the world by leveraging a browser every damn step of the way?
We are fucking modern-day wizards of techromancy who bend electrons to our will. We are the closest we've ever been to magic (since 1969). We come up with ideas. We make them something fleshy bags of water can poke at with their greasy, grubby, sausage-like fingers while they chortle and snort and spit their Cheetos on their screens. All by just futzing about with some incantations we spill out via keypresses. We can make just about anything that doesn't violate the laws of physics, and we keep defending HTML/CSS/JS as anything other than a horrible fucking wreck that steals our babies in the night, and thus our joy.
Nothing about the browser stack is a conceptual framework that is closest to what we humans understand. That CSS has made slower progress in not being a shitshow than Python 3 is fucking abominable. That everyone is clamoring for JS to get all these proven-to-be-holy-rocket-ship-to-the-heavens features other languages have had for-fucking-ever, and had better, is just sad.
What we seem to be creating is an entire decade of developers who can't seem to work without the browser stack. And that's a problem. Because we are going to be reaping the rewards of this for a long while. Browsers need to move beyond, developers need to move beyond. HTML is great when all you want is a motherfucking website.[1] CSS is fine if you're looking for a better/best motherfucking website.[2] JS was cool ... once upon a time.
All three being the primary path taken for building every new thing just feels sad.
[1]: http://motherfuckingwebsite.com
[2]: https://bestmotherfucking.website
[3]: While it's always good to use the best tool for the job, that shouldn't mean we stop creating better tools. Right now, the browser stack just seems content to keep adding more tools into the toolbox, instead of inventing the fucking cotton gin and automated harvester.
Most people are finding value in very very simple even simplistic things.
Instead of being offended by that instead find solace in the fact that you can create things most other cannot.
I am also not offended that people find value in simple things.
To place myself in my own line of fire:
There are languages I like, and others I don't. There are languages I use daily that I love and hate. I'd love to have a solid, cross-platform GUI toolkit in my language of choice. I want to be able to write applications by my own subjective measure of what I think is good for the job, how much I like the language, etc. I find it pretty sad that I can't just do that—say, write a truly native desktop app with Elixir, or Go, or Python, or what-have-you. But then I realize there are languages and tools that are already built for doing this. I just don't want to use/learn them. Or don't feel like I have the time. So, I'm just as guilty of wanting to use my pet technology of choice on all my problems. However, I recognize this, and I don't try to rationalize it as wanting to use a better paradigm or conceptual model. I just want to use the tools I want to use. Sadly, they don't always fit.
I can't help but wonder what cool tools we'd have to practice our magecraft if all the time invested in bringing JS everywhere had been put elsewhere.
Objective-C, to reuse that example, has plenty of warts. But it really outshines using the web stack to build native apps for desktop/mobile. Swift is even more pleasant in many ways. You use one language that's built for the job. You always think in that language. You don't have to create style sheets, use a DOM, or use JS bridges to things already made to do the job and do it well. Someone else already said in the thread that using a document model for applications is simply not the write paradigm. But we've grown so accustomed to shoehorning our ideas into a document model, we struggle to recognize this is flawed.
Cross-platform and sans-browser development would be so much easier if there was a single GUI toolkit used on all OSes. Electron has grown so popular because people want to build desktop apps, and they want them to run on as many platforms as possible, while looking and functioning identically. But it brings problems, overhead, and other pains because you're building an application for desktops using the browser stack.
Maybe one day we'll see this situation improve. Or maybe I'll give in like everyone else. Despite my ire, I am frequently impressed when someone creates yet another do-thing-in-JS tool ... and depressed.
Lastly, I think you meant find solace, not solitude.
That's the point.
People aren't going to care one bit what you or I for that matter, consider crushing towards the bottom or what you want to see less of.
They do what they consider most easy for them to get started with.
You keep jumping all over the place in each of your comments here, throwing out one assertion after the other, making up what you think applies 90% of the time, then constantly rebutting with whatever you've chosen to be "the point" in a given comment. It makes for very tiresome and fruitless conversation.
So you are right it's fruitless if all you want is change the premise for the discussion.
You however illustrate the very reason why HTML/CSS/JS/PHP/DOM are popular and Python still haven't found it's way into the mainstream.
Seriously, if anyone thinks HTML/CSS is easy to write UIs with, try Tcl/Tk or Rebol.
> If only someone could find a way to make a good tool without fucking up licensing.
The rest of your comment is quite intelligent, but I find these lines to be quite the opposite.
PyQt is available under both the GPL & a commercial license (https://wiki.python.org/moin/PyQt/PyQtLicensing). What you & the article author seem to want is for other people to write software that you can use and modify for free while you charge your own users to use and modify the software you write.
That's, in a word, hypocrisy. If you want to distribute a commercial PyQt app, then buy a license; otherwise release under the GPL (or a compatible license).
Any idea what effort it would take to integrate MatPlotLib graphs?
# time yum
real 0m2.147s
user 0m1.276s
sys 0m0.772s
# time apt-get
0.00s user
0.00s system 91% cpu
0.004 total
The author wants more Pythonic GUI apps because s/he thinks it produces more readable code. It has been argued that such code can be slower ( http://lukauskas.co.uk/articles/2014/02/13/why-your-python-r... ) and maybe it will lead to trading too much developer pleasure for user pleasure.
In many cases - developer time or cost is the constraint. Therefore it might be the difference between something existing and not existing.
It's a similar argument with 'native vs other' on mobile. Currently native apps are obviously better in terms of speed and overall quality. However - much non-native software simply wouldn't exist if there wasn't a rapid, low-barrier to entry development option.
And the world would be much better if that happened.
Seriously, the primary driver for the "developer-time offset" is the race-to-the-bottom competition between companies on who releases the app first, driven by the assumption that in this market the winner takes all. Maybe it is the case (though my impression is that people tend to gravitate to better software over time), but then there are markets without such a huge competitive pressure. Like package managers for Linux-based systems. Seriously, there is no reason for not doing them right (except of course the Unix philosophy being that not doing things right is the Right Thing).
So to summarise - no-one would choose Python for building GUI apps if it wasn't for the obsession modern companies have with being first-to-market?
If I've been unfair or misunderstood then can you please explain a bit more clearly how we got from a discussion about using Python for GUI applications to a statement that it's somehow about commercial pressures to release an app. It certainly doesn't match my own reasons for learning and using Python or those of anyone I've met.
I don't have anything against Python per se. Sure, it isn't the fastest language out there (even considering the high-level features it provides), but rarely the problem with application performance lies squarely with Python. It's more often about not putting time to "make it good" and "make it fast" after "making it work". Especially with - from what I hear, quite good - FFI capabilities of Python, in the worst case one could always push the most intensive computations down to C.
With regard to mobile apps - I was thinking more about non-commercial or hobbyist apps - the interesting, quirky or niche.
It's not the same in GUIs where the startup time doesn't usually dominate, but it's easier to keep the main loop spinning at 60 Hz to avoid dropping frames with a language implementation that is faster and not encumbered with a GIL.
https://talkpython.fm/episodes/show/58/create-better-python-...
# time dnf
real 0m0.236s
user 0m0.152s
sys 0m0.070s
Substitute Python with PHP and it feels like 2004 again. I think we all agreed a long time ago that decoupling presentation layer from business logic was a good thing, no?
1. Just write Python and get interactive graphs
2. Write Python and small snippets of embedded js when (1) is too limiting
3. Write Python to generate the datasets, and proper javascript via bokeh.js if you need to dig in deep.
And as the project matures - the number of reasons to jump from 1 to 2 to 3 will become less. I'd like to see a similar approach applied to general UI development. It's a great example of "make the easy things easy, and the hard things possible".
However that's a deal I'd consider taking if it means I could write more Python more of the time.
I think you will see applications that are quite generic (look and feel) and very chatty, but quick to develop.
This is incredibly dismissive and hardly a well functioning argument. I don't like to edit html templates, therefor web frameworks shouldn't exist.
I'm somehow trying to solve this problem by using jinja2 macros to the point of abuse and by having relatively large amount of python code that handles generating complex HTML (navigation, tables, forms, widgets...).
for forms use https://github.com/gregmuellegger/django-floppyforms
For navigation just use something like http://purecss.io/menus/
Instead of the webapp-as-desktop-app does there exist a language/IDE/tool that has a friendlier license for building native desktop apps?
This sounds a lot like PyJS: http://pyjs.org/
Nowadays, I wouldn't consider pyjs to build anything relevant..
I see some pretty glaring reasons why Python has not taken off in writing GUIs, especially on mobile.
1. The Python runtime is not very easy to embed on iOS and Android, and the sheer number of bindings needed to make it worth doing is immense.
2. Python's runtime is completely and utterly incapable of threading. Threading being almost essential to any decent user interface, this whole idea falls flat.
3. If the other two problems weren't enough, Python's single-threaded performance is really not great either. On resource-constrained systems (think phones) this hits doubly hard.
With regards to performance, I found that one can produce very fast routines through use of specialized libraries for specific tasks, such as numpy etc. There are also great visualization tools, such as pyqtgraph which are blazing fast, at least, in my view, compared to any web interface. I have been skeptical about the html/js interface so far, because I am concerned with how fast large amounts of data can be surfaced from Python data models to HTML plots.
That said, I share the Python UI pain :/ As of now, I am stuck with QT and cx_freeze for desktop app development and the whole thing feels very medieval. The QT library in itself is great but at the same time it does not feel very "python". cx_freeze requires constant tinkering and makes debugging very hard at times.
What do HN users use for building GUIs for Python? :)
This is just plain wrong and the fact that many GUI programs are written in Python (dropbox, NetworkManager, Zim desktop wiki, etc) should be evidence of that. In fact, most people don't even realize these are written in Python. Yes, Python has the GIL. No, that does not mean it can't do multithreading. It merely means it can't do parallel processing on multiple cores with just threading. But that is by no means a requirement for multithreading, especially regarding GUIs.
This simply isn't true. Python has the GIL, but that doesn't stop it from making use of threads for IO or CPU bound tasks that release the GIL (using extension modules). There are lots of libraries for multi-threaded IO in Python (e.g., gevent, Twisted, Tornado, asyncio), and, not surprisingly, they are very widely used for web programming.
The only platform where Python could flourish without effort was Maemo, and for the very brief time that project lived, it did exactly that.
While you're AFAIK correct about running Python on mobile devices, and I think anyone will admit that Python's performance has never been great, one can have a great UI without threads: use coroutines and channels instead.
Fortunately, Python does have coroutines, and a channel library can be built in the fashion of Lua's channel library (https://github.com/majek/lua-channels). I don't know if anyone has done it yet, I'll grant, but a cursory look suggests that it's possible.
The basic idea is that one would spawn a coroutine to handle each UI element, and the coroutines would send messages to one another on channels. I've no idea how fast it would be (at a guess: terrible), but it should work.