I tend to think the opposite, natural language will become the way computers are programmed - we aren't there yet but it will come. I agree that most natural language can be imprecise, but you can work around this by echoing back in plain english what we think you said in precise terms "Next friday" becomes "Friday the 9th of November". We replaced a very complex data entry screen with 50+ input fields and checkboxes and turned it to english input. End user mistakes have dropped, help desk calls have dropped. To be fair the english parser is super dumb, and we are only using it for very specific domains, not complete programs, but the power is evident. Small first steps, but I can see we could probably build a simple PWA based purely on english if that was our aim. Heck, we even now have an experimental API that takes classic query parameters OR english /people?q=get 5 most recent seen with blue as favourite color. Vs /people?limit=5&order=recentseen&select=favouritecolor(blue) I hate to say it, but it is putting power into end users who aren't programmers. Most end users can look intuitively at previous sentences and understand how to change it. Sure, it cannot handle all the nuances yet, and users learn to phrase in a certain way. When you step right back, isn't a programming language simply another language like english/french/german? Programmers take natural language requirements and translate to C/Java/etc which compilers then translate again to machine code. Of course programmers [should] also have more logical thought patterns than J.Bloggs which is currently still required.

Which mobile platforms are most ISV friendly? We are trying to decide the first platform to target from Android, iOS and windows 8 (we have actually built samples for them, so already know the technical aspects), but are more than slightly confused by the myriad of deployment options. Our apps are not of interest to the general public, so app store is not a major requirement. Our customers range from very small to large, and many will not be "corporate" grade to qualify for enterprise deployment options. Most of our customers are not worried about which platform they use, as they will buy devices purely to run our solution. Having app store certification is seen mostly as a hindrance that will slow down delivery of time critical updates. (remember, this is not for general public, only to prequalifed users) when our customers want a code change, they really want it now. We do already have HTML-5 style delivery, but want to go the app route for some specific stuff. We have also tried PhoneGap style development, but I'm more interested in what rules control our deployment of apps than the development iteself Is the following accurate, or have I overlooked a critical deciding factor? Android. + Can use Google play, but can also deploy direct from website. + No specific enterprise deployment option + No restrictions on code? + Approval only required for Google play + Very low cost per developer. Develop in java or C++ + Fragmented OS (ie slight differences between vendors/devices) iOS + Can only deploy via App Store for most customers, some can use enterprise tools, but many do not have DUNS number + Apps must be approved before release, will delay delivery by few days at best + Low cost per developer + Restrictions on code - I am uncertain + Uses Objective-C, which is only iOS + Tightly controlled OS Windows 8 + Deploy only via store, sideloading for enterprise "windows" customers, but not generally + Apps must be approved before release, will delay delivery by few days at best + Low cost per developer, develop in C++ + Tightly controlled OS + Restrictions on code (ie cannot dynamically download executable scripts) + Currently highest physical device cost

We are quite similar. We will support whichever browser/version we choose but will get to N% of observed users. This applies for desktop and mobile seperately (although percentages change and measurement is by country). For internal-use corporate customers we name the versions that make up the N% of browsers/devices and if you want something not on the list you pay to get it added. Otherwise we end up spending lots of effort supporting X.Y.Z for 0.008% of user base. Using percentage rather than direct naming means we guarantee to keep adapting to market trends.

The mainlogic is identical on all platforms, it is essentially a pile of APIs and events. I had figured that SCC was the only way, but I thought there might be a better way now-a-days. Rewriting the mainlogic away from C++ to another meta language is possible, but the question is then what is a nice future proof generic meta language? To answer the next reply too - we do have a Web API layer already too (and HTML5 apps) - so I guess those platforms that cannot support C++ just have to use the Web API, unless there is a meta language that solves my problem. Thanx

We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ? This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines. I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.

We use a customised web server that uses a Wurfl database to detect device type and serve highly specific versions, even serving variations in JS to support the variations/bugs in different platforms. Our usage is all private LAN, so we also restrict "support" to only certain devices, not the 10,000+ variations in the wild. High maint, but we have some very specific requirements and need complete control. Differences in browsers are plain painful, geez we have an example of two android phones in test, same versions, that behave different to each other!

www.evolis.com We used the Dualys for while, but most of our customers tend to prefer to use barcodes on the card rather than mag-swipe as its slightly cheaper per card, and they already have barcode scanners. All fairly simple to drive, blank cards ribbons etc reasonably priced.

Are we the only ISV that is wondering why changes in Microsoft select program are being implemented? We buy the "select" package so we can test our apps on lots of configurations. Now it seems we have to "qualify" by sitting MS Certified XXX exams. We are staffed by developers and testers and only really deliver to end customers via partners (who are generally MSxxx). To us, it just seems like a ploy to sell more exams - which is fine, but this is costing us tooo much time, just so we can buy a product. Do Microsoft want us to move to Linux faster? Aren't other development companies feeling the pain - or are we the last Windows Dev shop? :confused: