Thursday, December 09, 2010

Reset: Tools And Frameworks

In Reset: The New Normal I explored the reasons that business apps have to run on multiple types of devices and on multiple OS’s within 3 years.  That in turn led me to a sea change in how I view my development tools.  I alluded to that change in direction in that blog entry.  In this entry I flesh out major details.  Well, not just the details, which can be pretty boring.  The rationale for choices that lead to the details are pretty interesting (read: it’s possible to argue each choice at least 2 ways).  And because the choices reflect a choice I thought I would never make, the act of declaring the choices is a bit scary.

Farewell, .Net, I Hardly Knew Ye

Well, I knew you a bit, and there are certainly tools you have that I will miss being able to use.  But you are controlled by a brilliant guy who thinks static is good, and dynamic is bad.  That developers must be controlled.  And that’s from his asides during presentations, the unscripted comments.  And then there’s the impedance mismatch between data and objects, papered over (clumsily) with LINQ and various ORM’s, that will persist.  For apps that do the data manipulation that I know from our experience to be necessary in full-featured business apps, this mismatch would be a tremendous liability that would not go away.  I found ways to work around it, but these are pretty convoluted, and most importantly would not help us get to “everywhere,” which is where we need to be.

And that’s the killer issue, and why we’re leaving you behind.  Yes, Miguel and the Mono team are doing great work in making .Net run everywhere.  But running everywhere bumps up against memory, security, and bandwidth considerations.  Our programs are not lightweight demos, but heavy hitters fit for power users doing complex work.  Practically speaking, that means running on Javascript on the client (thanks to the spectacular progress in Javascript engines): nothing goes to the client but the application.

Hail Python, My Good Buddy

Working with complex domains requires complex code.  And that in turn means that the feedback loop of code-observe-code  gets taxed.  Simple things that you’ve done 20 times don’t tax the feedback loop, but expert apps, designed for Tier 1 and Tier 2 businesses (largest and next-to-largest, on a scale of 1 to 4), by definition are complex.  If they were simple, or even sort-of-simple, anyone could and would do them.

Nobody gets complex creation, in any field, right the first time.  Even The Masters covered up their painting mistakes.  The difference with software is that it can always be changed.  But to change it the feedback loop has to be engaged.  And there is nothing more beneficial in enhancing feedback loop efficiency than working in a dynamic language that allows observing and changing values during runtime.  And that’s where Python (and other dynamic languages) fit.

Python is a very clean, straight-forward, dynamic and object-oriented language, with a huge base of users (#6 on the Tiobe index and rising, and in fact rising faster than C#, which is #5 by .2% over Python –- at the present rate, Python will overtake C# early in the coming year).  It is one of the “official” languages at Google (the Google App Engine has Python and Java SDK’s), Yahoo, Nasa, etc.  It has easy-to-use libraries for every purpose imaginable.  It runs everywhere.  While there are other like languages (e.g., Ruby, also with a huge user base, but is at #11 on the Tiobe index, and actually falling in relative place), none are as clean and straightforward, and as complete, as Python.  Most importantly, Python has available established (V 1.0 or later) frameworks for getting applications everywhere, as mentioned above.

A VFP programmer used to programming in objects can learn enough Python to be productive in a weekend. 

Going Everywhere With Python

The key to making apps run everywhere is Javascript.  Sounds crazy to those of us who worked with Javascript in the old days.  Back in 2001, I think, I created a little web site that stored, searched, and displayed KB artcles without page refreshes, using an invisibly small frame to execute Javascript that did all the work of querying an html-based web service.  It was snappy enough, but I couldn’t imagine trying to do more than that.  How things change.

The big change has been Google: their goal has been, and is, to supplant what we think of as the Operating System with what is essentially a Browser.  The Google Netbook, running the Chrome (as in Browser) OS, on a reference hardware implementation, was released 3 days ago (2010/12/7).  It has no hard drive.  It is, they hope, the Microsoft Windows killer.  It will have ( “will” because 3rd-party implementations of the hardware spec will arrive  in the Q1-Q2 timeframe next year) Citrix and Terminal Services clients.  At first, those clients will be needed to access Windows apps.  But over time, the middleman always gets eliminated, elipsed.  Over time, apps will be written to write to the Google App Engine, or equivalent, because there is no reason not to, and good reasons (TCO for The Enterprise) to do so.

And what will run on the browser or Chrome OS without having to move other libraries over to the client, with all the security, memory and bandwidth considerations that entails?  Of course (I gave the answer away), it’s JavaScript.  Which is good news for Python users.

Python and JavaScript

I mentioned in the first Reset blog entry the existence of frameworks where you program in Python and it gets converted to JavaScript.  Which means having the power of OOP, and the run-everywhere-ness of JavaScript.  pyjamas, the most flexible of the two frameworks mentioned (the other is Titanium, a worthy contender, especially for creating apps to sell/give away in the iTunes store), translates (thanks to a translation engine written in Python) from Python to JavaScript.  You can even write classes in Python, a concept that does not exist in JavaScript, and they will be translated to JavaScript.

In addition, and actually the driving motivation for pyjamas, is the Google Web Toolkit, which includes a set of widgets that can run anywhere, but which unfortunately is programmable only in Java.  pyjamas has rewritten those widgets in Python, which then gets converted to JavaScript for runtime.  Adding widgets in, e.g., HTML5, is a reasonably easy exercise.  Creating composite widgets and adding those is a reasonably easy exercise.

There’s More, Of Course

There’s a lot more to the Python story, of course, but this blog entry has been about why not .Net, and why Python.  I’ll dig into more details in the next blog entry or two in this series.

34 comments:

Vfp likes me said...

This is the direction people see. I've looked at pyjamas, installed it. Unfortunately it is not well documented (just not to be rude). You only can deal with some examples.

Vfp likes me said...

Google sdk has also a visual designer. Does Pyjamas have something like that because i couldn't see ?

Hank Fay said...

The PyJsGlade project (http://sourceforge.net/projects/pyjsglade/) is providing the designer. I know the new documenter well.

Also: the Pyjamas Book provides links to examples (distributed with the app) that show various features. E.g., the TimeSheet and EmployeeAdmin examples use the Python port of PureMVC, which looks like a good way of hooking of events efficiently.

Pertti said...

Great posts, Hank. The writing appears to be on the wall regarding the explosion of devices and operating environments (rather than operating systems.) I'm convinced this thinking and realization is behind the recent Silverlight developments (or anti-developments as the case might be.) Not even Microsoft can afford to rewrite/readjust their development software to the various devices and form factors that are coming out now (iOS, Chrome, HP/PalmOS, new Symbian versions, etc.) So if we want to stay in this business we have to look for the new Lingua Franca/Esperanto -equivalent for computers and devices.

Hopefully there will emerge a language that gets better traction than, say, Esperanto did. I have personally been looking around for such thing, vacillating between Python, Java, Ruby and JavaScript. With Pyjamas, we may actually really have a system that is more universal than anything else out there. The fact that it translates Python into JavaScript sounds almost too good to be true, since JavaScript is the smallest common denominator for writing browser based applications -- any device worth its weight will pretty much have to be able to run JavaScript today and in the future. Trying to manage, maintain and support large applications in pure JavaScript is extremely difficult because of the hodge-podge spit and bailing wire -approach of the language. Being able to put a solid, well thought out and thoughtfully designed object -based control layer on top of JavaScript truly seems like the way to go.

The only thing missing here, it seems to me, is a robust IDE that would ease the pain of designing UI by hand. I’m wary of leaning heavily on open source –based IDE’s because there never seems to be the kind of ease of use and general polish in them that I need. I don’t want to end up with a creaky spit and bailing wire IDE where I have to remember workarounds and dead ends while I develop my software, and that’s why I’ve stuck with .NET for quite a while. You just can’t beat its IDE. Which is not to say that you couldn’t emulate it for another environment, but that would take serious, concentrated, controlled and, dare I say, hierarchy –based team effort. This to me at least means that it would have to be created by a commercial for-profit company rather than a group of hobbyists/enthusiasts. Consequently, I am constantly monitoring this space for something like that to pop up for Pyjamas, and when it does I will join the pyjama party without further ado.

CrazyFox said...

Well,

it seems I have not been the only one to have played with pyjamas a bit, for reasons very similar to the post. For me the point was sligthly before the silverlight gaffe, when Scott voiced the rift between Silverlight and HTML5. Pyjamas is tolerable (but without special design for small screens somewhat unusable) even on 240*320 Symbian.

Dabo's Springboard technology is also interesting, but the toolchain needed for that is IMHO to great: a CPython with Wxwigdet is *NOT* standard on smartphones / tablets. BUT springboard shows at least, that the web side in dabo is already working for server hosted dabo apps sporting a rather thin pure GUI client. The benefits of zero app deployment/upgrade server only for biz changes are already there.

Ed commented a while back, that he'd prefer to generate clean JS before using pyjamas bulk stuff - I think he underestimates the complexity, even if they acomplished a lot with dabo wrapping wx. I might have overinterpreted or he may have mollified a bit by now... But if a bunch of interested python half newbie hackers with vfp background were to add some rewriting and especially debugging, supporting pyjamas as an alternative GUI for dabo might be a viable set for most of us giving dabo apps hosted on a web server smartphone front ends. Dabo is at least a 3-tier database fwk coming from vfp roots *AND* has the ability to query bizobject data via SQL directly without cripples like LINQ added (although in a backward way: stuff data transparantly back into Sqlite, query...) Great as it re-uses well tested routines, but keeping biz data in SQLite cursors instead of Dbapi cursors might make the POOP in me happier. Still, YAGNI says leave it alone for now.

That said, Servoy seems to have one of the best implementations of JS front ends also usable as desktop app - but their licensing cost is not in my customer range. Also I am weary, as they open sourced *NOT* the backend incruing licensing cost - if Larry buys Servoy, bets are off IMHO.

CrazyFox said...

@Pertti:
If pyjamas or something similar does not work out the next thing IMHO is a Node.JS based fwk keeping at least the language used in server and client the same. A lot of Huge interest of smart people over at the node.js group, but clearly nothing to built apps on NOW. But they already have some connectors to PostGreSQL and probably Sqlite, and they are a dynamic language making large strides with google support for V8.

CrazyFox said...

For those not familiar with dabo:
a database framework in python for standard desktop apps or PC/Mac/Linux accessing a server sporting only a very thin GUI on the client side. Written by Ed Leafe with a lot of vfp/codebook expirience as a fwk author and Paul McNett, (in)famous for getting vfp to run on linux. Fully open source, with a few others besides Ed & Paul actively adding to it, but still a small dev base (which is good in some situations, bad in others)

Hank Fay said...

@Crazy_Fox: the PyJsGlade probject, as mentioned in another comment, provides the designer. They could use more help (although the two admins are both dynamite). The best part is that it's written in Python, so creating a builder system...

For event-handling (the part of Dabo that's of interest, as I can generate the data parts dynamically at dev time and statically, if desired, for distribution) I see PureMVC as a great alternative, that could have a place on both the client and server sides. And yes, I think dbapi cursors is probably the way to go, but more experimentation required.

@Pertti: the editor part of Python/Pyjamas is easy -- there are lots of very good Python editors, the newest (and one I like the best) being PyCharm, from JetTrains. The visual IDE as mentioned appears to be a coming along: Bos Kees and Luke Leighton (the latter being the maintainer for Pyjamas) as both involved. I'm going to do documentation; if anyone else wants to be involved...

CrazyFox said...

Hank: Currently I don't want to throw "classic" installable app out with the baby, so I'm inclined to look at dabo as db and biz tier of things to come - having a w/lintel server will probably the rule for most server deployments. The code for those tiers in dabo is quite readable and probably well tested enough for my bouts of paranoia. For those not sure of a secure net-connection (think behind former iron curtain or big brotherized like china) having an option for installable serverless app on config down to WinPads or netbooks is a definite plus. Currently I am part time in parts of former east germany, and there a mobile connection is not always established. Part might also be some mental feeling at home more with a classical app instead of a django based one - and those web frameworks are often wrapped around ORM as well ;-)

Hank Fay said...

@CrazyFox: well, I'm thinking Web.py and JSONRpc, actually. I have many things to say about ORM's, however this is not an "adults only" blog. <s> The Pyjamas Desktop takes care of the need for an installable app: it's running Python, as you've likely read. Running on Windows is unlikely to be an issue (although lack of a decent connection certainly makes the Cloud an issue), and I agree, Windows servers are the rule for nearly all the businesses I've dealt with in the past few years. The big change, though, is the Enterprise's willingness, in fact eagerness, to avoid having servers at all by going to the Cloud. Not for the most central apps, yet, but definitely for niche apps.

Pertti said...

@crazyfox:
I am familiar with Dabo, and while it is certainly an interesting and promising project, the problem I have with it is that it is basically a garage project by two smart guys. Which is not to say that it won’t possibly become something much more significant (think: HP, which also started in a garage.) As it is now, however, I can’t with good conscience build mission critical applications on top of it.
And therein lies the problem I have with almost all current Python efforts – they are either volunteer –based or too convoluted UI –wise. I’ve looked high and low, and I may have missed something, but I have not found a tool (especially visual IDE) that makes me want to jump in with both feet. Unfortunately I don’t have the luxury of time to participate in open source projects, and that’s why I am more than willing to pay for a good implementation. I need to know that my top development tools are well built, documented, supported and updated. When I have a problem with software, I can’t wait for days for what might or might not be a proper answer to my question on a user forum.
The idea of non-JavaScript development system for JavaScript is great, though, and I sure hope Pyjamas or some other framework with the same approach rises to a level where visual development IDE is easy to install and configure, highly usable, full-featured, well supported/documented and stable enough for heavy day-in-day-out use.

Chris said...

Great stuff Hank and commenters. Any thoughts on a dev architecture like Visual WebGUI? Visual Studio familiarity + javascript client which is used only to render the GUI and pass events?

Kind of a lock-in that isn't really locked... In the messing about that I have done to date, the only real requirement on the client side is javascript.

Tempting, because the familiarity and testing we've done points towards good initial productivity. Looking for pitfalls to this approach.

Regards

Hank Fay said...

@Pertti: well, VFP was supported and now what... PyJSGlade has to work and be extensible (but being Python will be extensible) for what I will be doing. The visual designer is a big deal. Ultimately, the viability of open source comes down to corporate support for the projects important to one's livelihood. Choosing between ensuring that happens and being subject to decisions made by middle managers at MS over whom I have not only no control but also for whom I have no means of meaningful input, is getting easier all the time.

@Chris: I like Visual WebGui for what it does. But I have to ask myself: do I really want to work past all the object-data impedance mismatches in .Net, and then throw away the actual display mechanism? What am I gaining? I know what I'm losing: simple programming. E.g., compare setting up a JSONRpc session under WebPy with setting up the exact same thing under WCF. There is no comparison. So what do I gain in .Net? It's got a rich ecosystem, but not what I want. Google hit the sweet spot with GWT, and Microsoft at this point has no answer. I wish they did, since they are nice tools and we get them for free (my daytime employer is a Gold Certified Partner). Finally, there's the cloud. I can publish apps written in the tools mentioned here to the Google App Engine for Business (which will have mySQL available as a low-latency relational DB). I can do the same with Azure, but the DB size is limited, at least at this point. And the Azure pricing is not competitive. In general, Windows server cloud pricing is not competitive with Linux server cloud pricing (on Amazon's EC2, I think it's 4 to 5 times as much per minute). I guess that's the Microsoft tax, but I don't know that for sure. In the end: I'm going to be displaying HTML5, so why do I need to have a ton of software, that I an going to need to work around, in order to do that? I think that's the ghost that spooked Muglia when he said (unfortunately for him) that Silverlight was just for WinMo7. He was wrong (Silverlight is still under development -- hey, they are hiring), but he did grok the challenge MS is facing. And WinMo7 may be the one platform on which SL has an advantage over other UI technologies -- unless PhoneGap creates a wrapper for WinMo7 <s>.

Hank Fay said...

@Pertti: well, VFP was supported and now what... PyJSGlade has to work and be extensible (but being Python will be extensible) for what I will be doing. The visual designer is a big deal. Ultimately, the viability of open source comes down to corporate support for the projects important to one's livelihood. Choosing between ensuring that happens and being subject to decisions made by middle managers at MS over whom I have not only no control but also for whom I have no means of meaningful input, is getting easier all the time.

@Chris: I like Visual WebGui for what it does. But I have to ask myself: do I really want to work past all the object-data impedance mismatches in .Net, and then throw away the actual display mechanism? What am I gaining? I know what I'm losing: simple programming. E.g., compare setting up a JSONRpc session under WebPy with setting up the exact same thing under WCF. There is no comparison. So what do I gain in .Net? It's got a rich ecosystem, but not what I want. Google hit the sweet spot with GWT, and Microsoft at this point has no answer. I wish they did, since they are nice tools and we get them for free (my daytime employer is a Gold Certified Partner). Finally, there's the cloud. I can publish apps written in the tools mentioned here to the Google App Engine for Business (which will have mySQL available as a low-latency relational DB). I can do the same with Azure, but the DB size is limited, at least at this point. And the Azure pricing is not competitive. In general, Windows server cloud pricing is not competitive with Linux server cloud pricing (on Amazon's EC2, I think it's 4 to 5 times as much per minute). I guess that's the Microsoft tax, but I don't know that for sure. In the end: I'm going to be displaying HTML5, so why do I need to have a ton of software, that I an going to need to work around, in order to do that? I think that's the ghost that spooked Muglia when he said (unfortunately for him) that Silverlight was just for WinMo7. He was wrong (Silverlight is still under development -- hey, they are hiring), but he did grok the challenge MS is facing. And WinMo7 may be the one platform on which SL has an advantage over other UI technologies -- unless PhoneGap creates a wrapper for WinMo7 <s>.

Pertti said...

Hank --

True, VFP was supported but is no more, supported, that is. But it still is a viable development platform because it was fastidiously developed by a for-profit company with proper documentation and source control.
I realize that the success of open source systems depends mostly on volunteers, and if you want to see something succeed, you better put some effort into it. That's fine if you have time to devote to a movement like that, but if you don't, you will just have to rely on commercial solutions and be willing to pay for them.
Regardless, Python looks pretty exciting now that it is gaining speed and altitude. Now we just need better instrumentation and intuitive, responsive controls to successfully fly the thing.

CrazyFox said...

@Perrti:
The small size of dabo devs and user base is also worrying me. But the vfp frameworks were built from similar sizes: think the Feltons VFE, Arturo starting VFX which is currently developed by 3-5 people working part time on it, Drew starting his framework and so on.
For me frameworks only saved me some dev time, but I always had to rewrite some part more to my liking – may be part egomania, but sometimes was just necessary to get a project accepted. Offering to pay for OS enhancements might help (no data here) speed up things. But I also know some of the defects I sent back to MS were never fixed. Look up the „resolved“ list of issues in vfp which were „resolved“ by „won’t fix“ ;-)

@Chris: Visual Webgui would take a role similar to the vfp engine for such apps: solid with a few warts, but project is governed by the any limitations existing there. I would want at least the source for it, to be able to implement a super-duper widget if such is asked for...

@Hank: the MS tax on Amazon is 20-30% AFAIR compared to Amazon linux offering. Working off pyjamas desktop gives me an install on PC – but I assume that this approach is less snappy than hooking a GUI like wx or similar level. Haven’t looked enough how well-designed and –tested middle tiers for such an approach would be – might be unneccessary to reuse the dabo routines, but I stayed in the mindset of „basic stuff in via JS“ and optionally more eye candy / speed for installed app. Perhaps the „more“ part is not cost efficient / asked for enough to worry about.

Pertti said...

@CrazyFox -- I, too, bought a commercial framework (ProMatrix) and modified it somewhat to fit my own needs. I could have saved some money and taken the free "open source" CodeBook -approach, but doing that I would've quickly spent much more money (in my time) than I spent on the framework which was already solid, well thought out and pretty bullet-proof.
I'm not suggesting paying for specific OS improvements, I'm just saying that I'd rather pay for a good framework and upgrades to it over time than participate in an open source project towards the same goal. Not because OS development isn't an interesting or a worthy enterprise, but simply because I have to earn a living by doing what I do best. And just like most other craftspersons I'd rather buy my tools from a tool manufacturer than join a tool manufacturing alliance in order to develop my own tools.

Hank Fay said...

@CrazyFox and @Pertti:

I'm on both sides of this question. @Pertti's comment about a first-class visual designer is incredibly important. If I have to play with CSS and manipulate the DOM, I can kiss productivity good-bye.

But the ability to modify the framework to my use is also critical. What VPM offered was a class system that let us subclass everything. Which we did.

I may have found half the answer for both questions: take a look at Cappucino and Atlas (both are from the same company; Cappucino (http://cappuccino.org/) is open source, Atlas (http://280atlas.com/), the IDE, is/will be for sale. I can see these on the client side, and Web.py-PureMVC-PSPData on the server side, connected with JSONRpc. The only downside is learning Objective-J for client-side processing -- but it looks very easy to learn from a VFP perspective, and would seemingly be needed only for subclassing the existing classes, which is to say, would only have to be done as needed. So client side programming would be done in Atlas (right now you have to run OSX Snow Leopard in a VM session, running on a VM-compatible Intel processor, to run the beta); while server side would be edited in Python edited in, e.g., PyCharm. This may be the best of both worlds.

Pertti said...

Hank --

Interesting links to Atlas and Cappuccino. After checking out a few demos I am a bit concerned about how much time is spent on showing how a screen object anchors and stretches, and how little time (none, actually) is spent on talking about data connectivity, binding and other LOB app -related necessities.

Hank Fay said...

@Pertti: reading through Cappucino a bit, it appeared to me that JSONRpc is an oft-used option. I could be mistaken. I signed up for the Atlas beta (but have to upgrade my desktop to run Snow Leopard before I can actually run it), so I'll be finding out.

Hank Fay said...

@Pertti: by-and-large Atlas simply incorporates the features of Cappuccino, which I understand to be taken from Cocoa. Given my perspective (domain experts creating the interface using metadata), being able to visually connect to events etc. is a great feature. BTW: Motorola owns the company that owns Cappuccino and Atlas (they bought, last August, to be able to attack the Android market by fostering app development). I'm looking forward to seeing how it could work with a real-world app.

Pertti said...

Motorola, eh? I'm not sure if that's a good thing or a bad thing. Shouldn't they concentrate on developing a compelling follow-up to their one-hit-wonder, the Motorola Flip Phone?

CrazyFox said...

@Hank:
I had seen Cappuccino in my foray about non Silverlight alternatives, but after the sale it seems to have slowed down a lot. Haven't looked in depth though.

@Pertti:
While I also like well designed and running things, I sometimes question the quest for the ideal GUI /Fwk. My best successes were "scripting" vfp for big iron data to difficult to mine there or glueing together different apps. I not only rewrote self-grown, but a part of a commercial fwk - but whenever I put too much trust into something it will break. Perhaps the Pathon idea of getting well designed blocks and glue them has more merit than we imagine. And as I am known for my aversion for Docs, the pseudo-code quality of python makes reading and fixing easier than in java or C#, nothing to say about the hair I lost on C/C++ libraries.

regards

thomas

CrazyFox said...

@Hank:
I had seen Cappuccino in my foray about non Silverlight alternatives, but after the sale it seems to have slowed down a lot. Haven't looked in depth though.

@Pertti:
While I also like well designed and running things, I sometimes question the quest for the ideal GUI /Fwk. My best successes were "scripting" vfp for big iron data to difficult to mine there or glueing together different apps. I not only rewrote self-grown, but a part of a commercial fwk - but whenever I put too much trust into something it will break. Perhaps the Pathon idea of getting well designed blocks and glue them has more merit than we imagine. And as I am known for my aversion for Docs, the pseudo-code quality of python makes reading and fixing easier than in java or C#, nothing to say about the hair I lost on C/C++ libraries.

regards

thomas

Michael Hawksworth said...

Hi Frank,

I've been looking at using Python but have been toying with QT. While you do have to do a manual conversion from C++ to python the 'creator' seems easy enough at the moment (still early days).

One downside so far seems to be a cross platform installer (particularly since I'm using Python 3)

Hank Fay said...

I assume you've seen PyQT4? http://wiki.python.org/moin/PyQt4

Hank Fay said...

@all: Here's how I am seeing the ProSysPlus stack now. This was created using a Cappuccino-based application, 280slides.com, written by the 280north.com folks who own Cappuccino, and are producing Atlas. http://280slides.com/Viewer/?user=62905&name=PSPStack&fullscreen

@CrazyFox: I am seeing commits to Cappuccino on a regular basis, including one last week. The team has admitted they have been busy (likely in getting the platform to where Motorola wants it for Android), which is why I looked at the commits, to make sure I wasn't buying into a product whose development is glacial in its velocity.

Hank Fay said...

Cappuccinno is in fact being strongly developed. This from Francisco (one of the 3 founders of 280North) on the Dev maillist (Google Group): https://groups.google.com/d/msg/objectivej-dev/112MrWrZpdg/3yN_WT5pSTkJ

Vfp likes me said...

I just wonder why google didn't used python for it's GWT, python beeing one of it's used languages on the engine. I've recently bought a book on GWT and it looks pritty mature and has a lot of documentation.

Hank Fay said...

@VFP Likes Me: from what I've seen on the instantions.com website (they are the creators of the GWT designer, which Google bought), the folks who designed the GWT designer don't do python, not a one of them, only java. Thus they have no plans to have it work with Python. The Google App Engine itself has a Python SDK; and in fact, advances show up there first.

johnf said...

I'm very happy and sad to see that you left .Net in the past. I'm sad because you spent lot's of time getting involved and programming. Happy because you have seen the light!

My only issue with pyjamas is how in the hell can you debug it! I haven't used it yet but I do not see where it is easy to debug. At least not as easy as straight python.

For those who seem to think buying tools from a large company (M$) is better than using a product such as Dabo I ask only one question - where is VFP 10, or IronPython today?

I wrote the interface to Postgres for Dabo and I can say without question that it will be here today and tomorrow with more certainty than I can say silverlight will be here in the future!

Hank Fay said...

@JohnF: pyjamas apps can run as pure python apps on the desktop, where all the standard Python debugging tools, unit tests, etc. come into play. If you want to watch the JavaScript, add the -d option to the compiler (translator), and watch the JavaScript console of your choice (the pyjamas FAQ gives suggestions for the basic browser choices).

All that said, I do wish pyjamas had a visual designer of the class of Atlas (280Atlas.com). I expect a lot of that to change: Apple will be releasing a visual designer at their WWDC, it appears, for general web development that uses widgets and generates JavaScript. They have released the iAds version of it this or last week.

In the meantime, I've found a developer who has been creating his own pyjamas widgets: I'm going to see if he'll write a tutorial on creating new widgets, to ease the way for the rest of us.

Hank Fay said...

@JohnF: pyjamas apps can run as pure python apps on the desktop, where all the standard Python debugging tools, unit tests, etc. come into play. If you want to watch the JavaScript, add the -d option to the compiler (translator), and watch the JavaScript console of your choice (the pyjamas FAQ gives suggestions for the basic browser choices).

All that said, I do wish pyjamas had a visual designer of the class of Atlas (280Atlas.com). I expect a lot of that to change: Apple will be releasing a visual designer at their WWDC, it appears, for general web development that uses widgets and generates JavaScript. They have released the iAds version of it this or last week.

In the meantime, I've found a developer who has been creating his own pyjamas widgets: I'm going to see if he'll write a tutorial on creating new widgets, to ease the way for the rest of us.

Hank Fay said...

For more discussion of Dabo as a foundation for a pyjamas toolset: https://groups.google.com/forum/?fromgroups#!topic/psp-python-toolset/ZPLiFu5vEqg