They mentioned JavaScript, not java. But I agree with ecs (except: don't allow java!) and strongly disagree with z3r0. Keep byte-code and interpreted languages off of iOS platforms. Java and other non-compiled-to-object-code languages are CPU-hogs and battery-killers. You may like how it looks when you're coding it, but your iPhone or iPad would choke and nearly die. This is the main reason why android devices will never have the battery-life or stability that iOS devices enjoy.
Almost every web page you visit has some JavaScript in it, which is what an interpreted language. The likes of Python or JavaScript are perfectly fine for utility apps and would have little impact on the battery. It is up to the programmer to choose the best language for his app, if you don't like the battery life of anyone app then don't buy it.
Frankly your position is assinine, it is extremely easy to code up an App in Objective C that wastes the battery too. Just because one language is easier to program in doesn't imply that it isn't worthwhile. One needs to judge how the app is used and by whom to determine the suitable suite of tools to use.
You are a REAL software programmer that had to learn how to write everything by hand and in your opinion that is THE only way to write anything. Anything created any other way is utter crap. How dare Appke turn their backs on the right of doing things by encouraging people to not learn how write code by hand like you had to.
I bet you had to walk 5 kilometers to school every day in the snow, with no shoes. And uphill both ways.
Disregarding the fact that over the years I've seen attempt after attempt fail at achieving anything more than glorified storyboarding, or the insight I got from doing software development on a daily basis, that 90% of the work involved with creating good software requires application of abstract logic that requires a language of expression that is orthogonal to visually arranging and connecting some prefab components, yes, you could say that I'm taking the time to express my thoughts about his topic here, for no other reason than showing off how awesome I am, getting paid a pretty sweet salary just to sit behind a computer doing stuff charlituna on AppleInsider would be able to do if he just had better tools.
Quote:
You are bashing a tool as bad based on some people that haven't used it well. Yes that makes you a snob.
Next you will bash stoves because Some people can't cook well
Maybe you should take a step back and read what you are actually writing here, because logic like that is not actually supporting your argument. To take your analogy: I'm still waiting for a stove that will make me a head chef, so I don't have to invest time learning about ingredients, ways of preparation, which flavors go well together, and all those other pesky details that real chefs have to learn first.
But don't feel bad, logic is pretty hard, lots of people have problems with it. If only they had better tools...
I am gathering based on the comments none of you have heard of multimedia fusion. Its used to create games and apps without code(you can code a plugin if you want).
Its very successfull and some popular flash and ios games have been created with it.
Look it up its made by clickteam.
Why not just buy click team and tailor multimedia fusion for ios devices?
We will see the day when people are able to engage computers at a much higher level than offered today. This project really doesn't seem to be there but one could hold out hope that it will eventually get there. Remember there was a time when the likes of Siri would have been thought impossible.
In any event I suspect this whole bit of news is way overblown as to me this sounds like a beefed up DashCode instead of a app development break through. Frankly I don't see DashCode as a bad thing either, it is a tool that has its place in this world just as C++ and SQL have their place. Your absolute dismissal of this app is perplexing to say the least. I suppose that the people using Keynote to prototype users interfaces is too far out for you also.
The thing here is that open minds should evaluate a tool based on what it can do for them, simplify for them or otherwise get to an end product quicker. Maybe this isn't the optimal solution but frankly if it helps even to slightly reduce development effort it would we well worthwhile to have. Just as something like Keynote can replace sketch pads ans sticky notes so can an app like this find a role.
Quote:
Originally Posted by d-range
Ok allow me to rephrase then: I think it's a bad idea Apple is wasting resources on this, not because I think they are unable to execute the idea better than everyone before them, but because I think the idea is fundamentally flawed in the first place. If all you need is a glorified storyboarding tool, you don't have to wait for Apple, we've had that for years. I remember ObjectVision from the Windows 3.1 era, it basically tried the exact same idea 20 years ago. Many others followed, but the idea still went nowhere. Google App Inventor is basically the same thing as ObjectVision, just a lot fancier.
The probem is that you cannot create complex things involving abstract logic, without investing the time to learn the tools that allow you to actually express those things. Anything that tries to relieve the 'programmer' from dealing what is basically the essence of programming -abstract logic- will inevitably end up as either too restricted to achieve anything useful, or too complex to fulfill its purpose. Somewhere in the middle of this road sits Flash: easy enough for the most basic prototyping for non-programmers, but far too complex if you want to mke anything half-way decent with it. The amount of crap made by people without a programming background, who got a little carried away by the deceptive easiness of the tool and started to explore the complex world of serious ActionScript development should serve well as an example of the problems with 'development tools for the masses'.
I'm not debating the exciting prospect of a tool that makes it so easy to create real applications, I'm just saying the idea is fundamentally flawed and self-contradictory. I can understand you would love to be able to create simple applications without having to program, just like I would love to be able to shoot and edit professional videos without having to learn anything about how to set up a scene, how to use a professional camera, or how to write an engaging story.
Just don't get your hopes up, that's all I'm saying. Unless you are aiming for ridiculously trivial stuff (which you could already do today), or generic 13-a-dozen crap, you will have to invest in learning how to write computer programs the hard way. There is no substitute.
Almost every web page you visit has some JavaScript in it, which is what an interpreted language. The likes of Python or JavaScript are perfectly fine for utility apps and would have little impact on the battery. It is up to the programmer to choose the best language for his app, if you don't like the battery life of anyone app then don't buy it.
Frankly your position is assinine, it is extremely easy to code up an App in Objective C that wastes the battery too. Just because one language is easier to program in doesn't imply that it isn't worthwhile. One needs to judge how the app is used and by whom to determine the suitable suite of tools to use.
Nope, not assinine [sic] in the least. We're talking batteries here. What makes you think that java or Python programmers would restrict themselves to "utility apps"? And yes, javascript is expensive, but the interpreter is maintained/optimized by Apple, so it runs well.
No one said these languages are not worthwhile, but their usage should be restricted to running on single-user machines that do not run on batteries. Sorry, but for most programmers the "best language for his app" is the one that's easiest for him, not necessarily the one that uses the battery most efficiently.
Disregarding the fact that over the years I've seen attempt after attempt fail at achieving anything more than glorified storyboarding, or the insight I got from doing software development on a daily basis, that 90% of the work involved with creating good software requires application of abstract logic that requires a language of expression that is orthogonal to visually arranging and connecting some prefab components, yes, you could say that I'm taking the time to express my thoughts about his topic here, for no other reason than showing off how awesome I am, getting paid a pretty sweet salary just to sit behind a computer doing stuff charlituna on AppleInsider would be able to do if he just had better tools.
That 90% number is just plain garbage. There are many business apps that don't require complex logic or massive efforts at abstract logic. That many can't handle even simple programming is a fact. I have personal experience here picking up projects from engineers that couldn't program to save their jobs and self destructed with VisualBasic. Sadly this on an app that required little in the way of abstract thought.
No looking at iOS and the hipuge waste of time that goes into supporting basic UI elements I actually believe Apple could go a very long way to improving the position of the developer. We might actually get to the point where 90% of the effort goes to actual business logic. As it is now one spends far more time with UI development, antiquated approaches to user interface element handling and boiler plate code to drive the UI. Non of this pertains it self to business logic or abstract concepts.
Quote:
Maybe you should take a step back and read what you are actually writing here, because logic like that is not actually supporting your argument. To take your analogy: I'm still waiting for a stove that will make me a head chef, so I don't have to invest time learning about ingredients, ways of preparation, which flavors go well together, and all those other pesky details that real chefs have to learn first.
You see I don't totally disagree with you because I've seen the results of people trying to program that don't have a clue. On the flip side I've seen cooks with nothing but a bit of charcoal and cast iron cook a fantastic meal. Likewise I've seen rather intelligent people produce some really nice software with just a little bit of knowledge and rudimentary tools.
Quote:
But don't feel bad, logic is pretty hard, lots of people have problems with it. If only they had better tools...
Well let's be honest that statement won't get you anywhere. The whole industry has revolved around building better tools, tools used by professionals mind you. A good tool can go a long way to helping you understand your code professional or not.
Nope, not assinine [sic] in the least. We're talking batteries here. What makes you think that java or Python programmers would restrict themselves to "utility apps"? And yes, javascript is expensive, but the interpreter is maintained/optimized by Apple, so it runs well.
OK, the only reason JavaScript makes the grade is because it is maintained by Apple? I'm having a hard time believing you really mean that, but let's say for arguement Apple offered up Ruby as an option, would that make it any better since Apple is supporting the code?
As to what the programmers restrict themselves to that is up to the development team building the app. Users are free to reject any app they might think is a problem.
Quote:
No one said these languages are not worthwhile, but their usage should be restricted to running on single-user machines that do not run on batteries.
Single user machines, oh come on do you have even the slightest clue where these languages are used. Python, Ruby and the like are often languages of choice on server handing very high volumes of traffic. I have no idea where you got the idea that they are only suitable for single user machines.
As to batteries, again you have failed to show how they are anymore of an energy issues that Objective C. Anybody can write bad code in JavaScript, all one has to do is look at some of the competitive forums out there that can bring my iPad to a crawl. Appleinsider doesn't have this issue which most likely indicates better JavaScript programming. This idea that energy usage is a function of the language belies the fact that the programmer himself can have a huge impact on batter life through his coding technique. Sure C compiled down to highly optimized object code has the potential to use less energy, but like I said it isn't even a significant issue relative to the other issues.
Quote:
Sorry, but for most programmers the "best language for his app" is the one that's easiest for him, not necessarily the one that uses the battery most efficiently.
That is my whole point. Battery usage is as much a function of the programmer as it is the language. Even when delivering the same basic app with the same language, a web forum for example in JavaScript, the performance and battery impact can vary widely. This should be rather obvious to users of the various forums about the web.
I'd estimate that I use the IMDb app at least a couple of times a week. It is another app I consider more useful than the web site.
Maybe it is, I simply haven't installed it. The thing is I am typically on a webpage when I want to look up an actor or title so I want to stay in Safari and just switch to a new page or use that same page to locate the info.
Last time I saw anthing like this it was a tool called Matrix Layout back in the 90s, and it was utter junk. If anyone can make this work Apple can, but as a programmer I've yet to be convinced that these types of tools can do much more than create photo albums and very simple, generic apps.
Exactly. You can't write business logic with icons.
Actually, not true. I also use prototyping/visualization applications Axure and iRise. In Axure, one can create lo-fi or hi-fi interactive prototypes. It looks and behaves almost like the actual thing. It's only been around for several years and adding great functionality with every release.
iRise is the more robust of the two. It actually does create business logic, IN USABLE CODE, for the back-end (Java or .NET) with any mainstream DB. This is done by creating visual elements and assigning properties, relationships, and interactive behaviors to them. It's actually pretty amazing.
Both of them allow you to generate a specifications doc for designers and developers.
This is just the beginning. As we move closer to creating ontologies for everything we do, use, say, want, etc., we are getting that much closer to creating software that can "understand" what we want to to. This is AI in the making.
No worry for devs. They'll just shift from doing mundane tasks to building applications that...well, build apps, for every vertical, market, category, etc.
In my lifetime, I WILL be able to "tell" software such as this, to make an application that does...
There are similar apps but from what I can gather there is no app that allows you to create one app for multiple platforms.
Where I see this as being truly amazing is if it allows you to create one app that runs on Macs and all iOS devices no matter what they are. Development time will be killed.
Sometimes you just want to create a quick and dirty app as an interface for something. For example I'm currently building an online helpdesk system using PHP and MySQL. However, I would also like to develop a proper app for iOS devices to be able to make updates quickly and easily to the database wherever they are. Having to learn two programming languages to do this makes it kind of difficult to do.
A system like this will make it so much easier to do.
Your absolute dismissal of this app is perplexing to say the least. I suppose that the people using Keynote to prototype users interfaces is too far out for you also.
If keynote was marketed as making it easier to streamline your logistics, sell more widgets, or helping you find a cure for cancer, just because you can make nice presentations about these topics, yes, I would dismiss it as I dismiss any tool that promises to bring software development to the masses, without requiring you to actually learn how to program stuff. Just like keynote does not help you to produce better content, a programming language or Application Inventor or whatever does not help you to solve the abstract problems involved in software development.
Quote:
The thing here is that open minds should evaluate a tool based on what it can do for them, simplify for them or otherwise get to an end product quicker. Maybe this isn't the optimal solution but frankly if it helps even to slightly reduce development effort it would we well worthwhile to have. Just as something like Keynote can replace sketch pads ans sticky notes so can an app like this find a role.
I agree with the basic premise, but let's not pretend stuff like mentioned in this article is anything new. It's old stuff and it has been for at least a decade, I've seen it all before. If you look at the evolution of conventional programming languages you'll see that the latest and greatest ones already reduced the amount of boilerplate code you have to write to a minimum, the SDK's and frameworks already solve almost any generic problem you'll encounter, the language constructs offered by the various modern languages already converged to a set that is more or less agreed on is useful, etc. Almost all advancements in programming languages you see today are about parallelism and how to make it easier to harness it without all the pitfalls, a topic the complexities of which are almost impossible to explain to someone without a pretty advanced background in programming and how computers work. Yet, with all the tools we have, writing good software is fundamentally still almost exactly as hard as 30 years ago. Less cumbersome, faster, and safer, but not much easier, at least not for anything besides GUI design. Trying to sugarcoat that fact by making your development environment more accessible by using more visual elements and activities has been tried before. It's too restrictive for almost anything non-trivial.
Quote:
That 90% number is just plain garbage. There are many business apps that don't require complex logic or massive efforts at abstract logic.
I may have overstated that a little but I still stand by my statement. Obviously not every piece of software consists of 90% business logic, but you still require application of abstract logic in some form or another for about any task related to writing it. Even if you are just hooking up a touch event to a button, having it increment some kind of counter, and triggering another event that plays a sound if the counter hits some value, you are applying abstract logic in it's simplest form. Increase the complexity only one level, say by adding a timer that starts when you first hit the button, runs for 10 seconds, and then only process clicks while the counter is running and the number of seconds elapsed rounded to the nearest second is even, is already taking things too far for most people. I'd love to see an example of an easy, visual way of implementing even something as trivial as this, that doesn't require you to learn about conditonals, arithmetic operators and control flow.
Quote:
No looking at iOS and the hipuge waste of time that goes into supporting basic UI elements I actually believe Apple could go a very long way to improving the position of the developer. We might actually get to the point where 90% of the effort goes to actual business logic. As it is now one spends far more time with UI development, antiquated approaches to user interface element handling and boiler plate code to drive the UI. Non of this pertains it self to business logic or abstract concepts.
The UI itself or the code implementing it does not pertain to business logic or abstract concepts, but the stuff you control and display using that UI and how it interacts behind the scenes does, and you have to think about it to do more than just GUI storyboarding. That said, I think iOS, Cocoa, CoreData and XCode already do a pretty good job at relieving you from writing boilerplate code for these kind of things. You can basically create a GUI, a data model, a way to connect the two, and all navigation between different parts of your application, without writing a single line of code. Again, nothing new here. Start using all these tools, and in no time you will find out you need background about abstract concepts such as data model entities and relations, or queries, how persistency works, about data types and how you display and manipate them, what the difference between a float and an integer is, and why you need both, why you want to normalize your data model, and so on. All abstract concepts that you cannot hide behind some kind of visual tool that decides everything for you based on some widgets you threw on a form.
Quote:
Well let's be honest that statement won't get you anywhere. The whole industry has revolved around building better tools, tools used by professionals mind you. A good tool can go a long way to helping you understand your code professional or not.
I'm glad you mentioned this, because I fully agree, and it's exactly this that has gotten me pretty far already. Over the years I think I've used at least 30 different programming languages, IDE's, compilers, platforms and frameworks. I'm not religious about the tools I use, not at the very least. When something better comes a along, I'm the first to evaluate it, if not because my current tools bother me, it would be out of curiosity or just for fun. I even bought my first iPad primarily because I wanted to learn objective-c, cocoa and iOS. So I'm not dismissing any tool that promises to allow you to write non-trivial programs without having to program out of conservatism, but just based on experience and observation. I simply don't believe in it.
I think there are a lot of programing snobs who have the same attitudes that iMovie sucks because you need to go to film school to create anything worthwhile.
If nothing else, this could be a really great introductory tool for kids.
However, like Hypercard, it could be *much* more than that. I have a bunch of ideas for worthwhile apps that have very generic components, relying much more on the development of the media content to be associated with the app. I just don't have the time.
I see a lot of people up on their high horse here... and perhaps they're justified given the context: there have been countless failures towards this end. Still, I think there is a lot to be gained here if done right. Obviously, Apple has the resources and the talent to bring home the bacon.
The whole idea behind Object Oriented Programming is reusable modular architecture. I don't have to create button classes because they're already there, and that's a good thing. Similarly, I shouldn't have to painstakingly recreate common view layouts or the linguistic lubricant that allows each of these objects to interact so regularly from one app to the next, and that would be a good thing too.
The major reason this hasn't worked before is because it's been implemented as a standalone solution to programming (or blogging, where we have seen more success with this model), and the programmer loses some measure of control. This could be a real slam dunk if Apple properly implements this on top of the XCode platform as an additional, optional tool.
This is just the next obvious step in the evolution of programming.
They mentioned JavaScript, not java. But I agree with ecs (except: don't allow java!) and strongly disagree with z3r0. Keep byte-code and interpreted languages off of iOS platforms. Java and other non-compiled-to-object-code languages are CPU-hogs and battery-killers. You may like how it looks when you're coding it, but your iPhone or iPad would choke and nearly die. This is the main reason why android devices will never have the battery-life or stability that iOS devices enjoy.
It would get compiled to native code... It wouldn't run in VM like Java.
how can anyone claim all attempts at this failed? Hypercard was quite successful. Myst was created with hypercard and released in 1993. It went on to sell 6 million copies to make it the best selling computer game until the Sims passed in 2002.
Mishandling Hypercard is one of the bigger mistakes apple ever made. Here are some of the wide variety of apps Hypercard was used for
Quote:
HyperCard has been used for all sorts of hypertext and artistic purposes. Before the advent of PowerPoint, HyperCard was often used as a general-purpose presentation program. Examples of HyperCard applications include simple databases, "choose your own adventure"—type games, and educational teaching aids.
Due to its rapid application design facilities, HyperCard was also sometimes used for prototyping of applications and sometimes even for version 1.0 implementations. Inside Apple, the QuickTime team was one of HyperCard's biggest customers.
A number of commercial software products were created in HyperCard, most notably the original version of the interactive game narrative Myst, the Voyager Company's Expanded Books, and multimedia CD-ROMs of Beethoven's Ninth Symphony CD-ROM, the Beatles' A Hard Day's Night, and the Voyager MacBeth.
The prototype and demo of the popular game You Don't Know Jack was written in HyperCard.
Renault, the French auto manufacturer, used it to control their inventory system.
In Quebec, Canada, Hypercard was used to control a robot arm used to insert and retrieve video disks at the National Film Board CinéRobothèque.
HyperCard was also used to prototype a fully functional prototype of SIDOCI (one of the very first experiments in the world to develop an integrated electronic patient record system) and was heavily used by Montréal Consulting firm DMR to demonstrate how "a typical day in the life of a patient about to get surgery" would look like in a paperless age.
Activision, which was until that time primarily a game company, saw HyperCard as an entry point into the business market. Changing their name to Mediagenic, they published several major HyperCard based applications, most notably Danny Goodman's Focal Point, a personal information manager, and Reports For HyperCard, a program by Nine To Five Software that allowed users to treat HyperCard as a full-fledged database system with robust information viewing and printing features.
Creating commercial software isn't the only viable use for programming tools. If a programming system is easy enough that a small business owner can create custom apps to better run his business without having to hire programmers, it's quite useful. Who cares if you lose 5% more battery getting something useful done that you might have to lose if you hired progressional programmers to write custom objective-c code that that same small business owner has no chance of understudying or modifying.
Having an accessible entry into programming for children is also quite useful. That's what these portable tablet computers were supposed to feature when first envisioned by Alan Kay. I'm a professional programmer with 30 years of experience developing primarily for Apple products. The tools I use are too complex to teach my 10 year old daughter. Yet 30 years ago 10 year olds were programming Xerox Parc computers with no problems. A modern day Hypercard like product would be perfect for her. Something where you don't have to program all of the details, but can easily script objects where needed.
I build our website with javascript/php/mysql - I constantly wonder why that can't be as easy to program as hypercard. The results really aren't all that different. The tools for accessible programming are lightyears behind where they were 20 years ago.
Last time I saw anthing like this it was a tool called Matrix Layout back in the 90s, and it was utter junk. If anyone can make this work Apple can, but as a programmer I've yet to be convinced that these types of tools can do much more than create photo albums and very simple, generic apps.
Exactly. You can't write business logic with icons.
I don't know whether you were including HyoerCard in this opinion, but I offer this. I was the sysadmin for 2700 Macs using Microsoft Mail, and our implementation used an Out of Office notification system that was built completely in HyperCard, both client and server side. Not only did it work pretty well for what it had to do, but it could be customised even further since it was an editable stack. I always thought Hypercard was a nifty programming environment, one that was as simple or as complex as your experience allowed.
Right. So if I understand correctly you are basically saying the abominations people who know nothing about web technology create, serve as a good example why creating iOS applications should be as simple as dicking around in FrontPage pretending you know how to build a good website?
With statements like this you'll be sure to trigger the web developer snobs and the web designer snobs as well, just like the professional programmer snobs posting in this topic. They're all the same, thinking they took an education and years of experience to do stuff anyone could do with just a few better tools. I mean, we've only been trying to make software development easy for a measly 40 years or something
Now if you excuse me, I'm off to continue working on my DIY neurosurgery kit, it's about time anyone can do brain surgery. No reason it shouldn't be as easy as clicking together a website. No reason at all.
10 years ago if you wanted a website you went to a web designer and paid them thousands of pounds to build it. Now you can buy software that lets you build a simple website in no time for very little cost. That's great for small businesses, local interest groups, individuals, etc who can now afford their own website. To me that's progress. If you want a more professional website you can still employ a professional web developer or learn to do it yourself.
I don't see why we can't have the same situation with iOS app's. I'm not suggesting my simple community project app would compete with professional app's or make my fortune, but it would open up iOS app's to a whole new audience in the same way that simple website building software did.
As for the sanctity of iOS developers well all I can say is that the iTunes store is full of badly written, buggy app's that have been developed by those same developers. Maybe some of the amateurs will make a better job of it.
Users are free to reject any app they might think is a problem.
Yes, but Apple can favour tools. If Apple proposes "X" as the default programming language, you'll see a lot of apps using such language.
Just the mention of Javascript as the suggested path by Apple produces me cold sweat.
It's fine to propose a tool for creating apps without code. But, if such tool lets you add code, then code in ObjectiveC, which is the technology behind Cocoa. It will be better for iPhones batteries, and also more coherent with the Apple technologies.
Comments
They mentioned JavaScript, not java. But I agree with ecs (except: don't allow java!) and strongly disagree with z3r0. Keep byte-code and interpreted languages off of iOS platforms. Java and other non-compiled-to-object-code languages are CPU-hogs and battery-killers. You may like how it looks when you're coding it, but your iPhone or iPad would choke and nearly die. This is the main reason why android devices will never have the battery-life or stability that iOS devices enjoy.
Almost every web page you visit has some JavaScript in it, which is what an interpreted language. The likes of Python or JavaScript are perfectly fine for utility apps and would have little impact on the battery. It is up to the programmer to choose the best language for his app, if you don't like the battery life of anyone app then don't buy it.
Frankly your position is assinine, it is extremely easy to code up an App in Objective C that wastes the battery too. Just because one language is easier to program in doesn't imply that it isn't worthwhile. One needs to judge how the app is used and by whom to determine the suitable suite of tools to use.
Why don't you say what you really mean
You are a REAL software programmer that had to learn how to write everything by hand and in your opinion that is THE only way to write anything. Anything created any other way is utter crap. How dare Appke turn their backs on the right of doing things by encouraging people to not learn how write code by hand like you had to.
I bet you had to walk 5 kilometers to school every day in the snow, with no shoes. And uphill both ways.
Disregarding the fact that over the years I've seen attempt after attempt fail at achieving anything more than glorified storyboarding, or the insight I got from doing software development on a daily basis, that 90% of the work involved with creating good software requires application of abstract logic that requires a language of expression that is orthogonal to visually arranging and connecting some prefab components, yes, you could say that I'm taking the time to express my thoughts about his topic here, for no other reason than showing off how awesome I am, getting paid a pretty sweet salary just to sit behind a computer doing stuff charlituna on AppleInsider would be able to do if he just had better tools.
You are bashing a tool as bad based on some people that haven't used it well. Yes that makes you a snob.
Next you will bash stoves because Some people can't cook well
Maybe you should take a step back and read what you are actually writing here, because logic like that is not actually supporting your argument. To take your analogy: I'm still waiting for a stove that will make me a head chef, so I don't have to invest time learning about ingredients, ways of preparation, which flavors go well together, and all those other pesky details that real chefs have to learn first.
But don't feel bad, logic is pretty hard, lots of people have problems with it. If only they had better tools...
I am gathering based on the comments none of you have heard of multimedia fusion. Its used to create games and apps without code(you can code a plugin if you want).
Its very successfull and some popular flash and ios games have been created with it.
Look it up its made by clickteam.
Why not just buy click team and tailor multimedia fusion for ios devices?
Clickteam sells an iOS runtime for MMF apps already: http://www.clickteam.com/website/usa...velopment.html
EDIT: Oops... somehow overlooked your "flash and iOS games" comment...
In any event I suspect this whole bit of news is way overblown as to me this sounds like a beefed up DashCode instead of a app development break through. Frankly I don't see DashCode as a bad thing either, it is a tool that has its place in this world just as C++ and SQL have their place. Your absolute dismissal of this app is perplexing to say the least. I suppose that the people using Keynote to prototype users interfaces is too far out for you also.
The thing here is that open minds should evaluate a tool based on what it can do for them, simplify for them or otherwise get to an end product quicker. Maybe this isn't the optimal solution but frankly if it helps even to slightly reduce development effort it would we well worthwhile to have. Just as something like Keynote can replace sketch pads ans sticky notes so can an app like this find a role.
Ok allow me to rephrase then: I think it's a bad idea Apple is wasting resources on this, not because I think they are unable to execute the idea better than everyone before them, but because I think the idea is fundamentally flawed in the first place. If all you need is a glorified storyboarding tool, you don't have to wait for Apple, we've had that for years. I remember ObjectVision from the Windows 3.1 era, it basically tried the exact same idea 20 years ago. Many others followed, but the idea still went nowhere. Google App Inventor is basically the same thing as ObjectVision, just a lot fancier.
The probem is that you cannot create complex things involving abstract logic, without investing the time to learn the tools that allow you to actually express those things. Anything that tries to relieve the 'programmer' from dealing what is basically the essence of programming -abstract logic- will inevitably end up as either too restricted to achieve anything useful, or too complex to fulfill its purpose. Somewhere in the middle of this road sits Flash: easy enough for the most basic prototyping for non-programmers, but far too complex if you want to mke anything half-way decent with it. The amount of crap made by people without a programming background, who got a little carried away by the deceptive easiness of the tool and started to explore the complex world of serious ActionScript development should serve well as an example of the problems with 'development tools for the masses'.
I'm not debating the exciting prospect of a tool that makes it so easy to create real applications, I'm just saying the idea is fundamentally flawed and self-contradictory. I can understand you would love to be able to create simple applications without having to program, just like I would love to be able to shoot and edit professional videos without having to learn anything about how to set up a scene, how to use a professional camera, or how to write an engaging story.
Just don't get your hopes up, that's all I'm saying. Unless you are aiming for ridiculously trivial stuff (which you could already do today), or generic 13-a-dozen crap, you will have to invest in learning how to write computer programs the hard way. There is no substitute.
Almost every web page you visit has some JavaScript in it, which is what an interpreted language. The likes of Python or JavaScript are perfectly fine for utility apps and would have little impact on the battery. It is up to the programmer to choose the best language for his app, if you don't like the battery life of anyone app then don't buy it.
Frankly your position is assinine, it is extremely easy to code up an App in Objective C that wastes the battery too. Just because one language is easier to program in doesn't imply that it isn't worthwhile. One needs to judge how the app is used and by whom to determine the suitable suite of tools to use.
Nope, not assinine [sic] in the least. We're talking batteries here. What makes you think that java or Python programmers would restrict themselves to "utility apps"? And yes, javascript is expensive, but the interpreter is maintained/optimized by Apple, so it runs well.
No one said these languages are not worthwhile, but their usage should be restricted to running on single-user machines that do not run on batteries. Sorry, but for most programmers the "best language for his app" is the one that's easiest for him, not necessarily the one that uses the battery most efficiently.
Disregarding the fact that over the years I've seen attempt after attempt fail at achieving anything more than glorified storyboarding, or the insight I got from doing software development on a daily basis, that 90% of the work involved with creating good software requires application of abstract logic that requires a language of expression that is orthogonal to visually arranging and connecting some prefab components, yes, you could say that I'm taking the time to express my thoughts about his topic here, for no other reason than showing off how awesome I am, getting paid a pretty sweet salary just to sit behind a computer doing stuff charlituna on AppleInsider would be able to do if he just had better tools.
That 90% number is just plain garbage. There are many business apps that don't require complex logic or massive efforts at abstract logic. That many can't handle even simple programming is a fact. I have personal experience here picking up projects from engineers that couldn't program to save their jobs and self destructed with VisualBasic. Sadly this on an app that required little in the way of abstract thought.
No looking at iOS and the hipuge waste of time that goes into supporting basic UI elements I actually believe Apple could go a very long way to improving the position of the developer. We might actually get to the point where 90% of the effort goes to actual business logic. As it is now one spends far more time with UI development, antiquated approaches to user interface element handling and boiler plate code to drive the UI. Non of this pertains it self to business logic or abstract concepts.
Maybe you should take a step back and read what you are actually writing here, because logic like that is not actually supporting your argument. To take your analogy: I'm still waiting for a stove that will make me a head chef, so I don't have to invest time learning about ingredients, ways of preparation, which flavors go well together, and all those other pesky details that real chefs have to learn first.
You see I don't totally disagree with you because I've seen the results of people trying to program that don't have a clue. On the flip side I've seen cooks with nothing but a bit of charcoal and cast iron cook a fantastic meal. Likewise I've seen rather intelligent people produce some really nice software with just a little bit of knowledge and rudimentary tools.
But don't feel bad, logic is pretty hard, lots of people have problems with it. If only they had better tools...
Well let's be honest that statement won't get you anywhere. The whole industry has revolved around building better tools, tools used by professionals mind you. A good tool can go a long way to helping you understand your code professional or not.
Nope, not assinine [sic] in the least. We're talking batteries here. What makes you think that java or Python programmers would restrict themselves to "utility apps"? And yes, javascript is expensive, but the interpreter is maintained/optimized by Apple, so it runs well.
OK, the only reason JavaScript makes the grade is because it is maintained by Apple? I'm having a hard time believing you really mean that, but let's say for arguement Apple offered up Ruby as an option, would that make it any better since Apple is supporting the code?
As to what the programmers restrict themselves to that is up to the development team building the app. Users are free to reject any app they might think is a problem.
No one said these languages are not worthwhile, but their usage should be restricted to running on single-user machines that do not run on batteries.
Single user machines, oh come on do you have even the slightest clue where these languages are used. Python, Ruby and the like are often languages of choice on server handing very high volumes of traffic. I have no idea where you got the idea that they are only suitable for single user machines.
As to batteries, again you have failed to show how they are anymore of an energy issues that Objective C. Anybody can write bad code in JavaScript, all one has to do is look at some of the competitive forums out there that can bring my iPad to a crawl. Appleinsider doesn't have this issue which most likely indicates better JavaScript programming. This idea that energy usage is a function of the language belies the fact that the programmer himself can have a huge impact on batter life through his coding technique. Sure C compiled down to highly optimized object code has the potential to use less energy, but like I said it isn't even a significant issue relative to the other issues.
Sorry, but for most programmers the "best language for his app" is the one that's easiest for him, not necessarily the one that uses the battery most efficiently.
That is my whole point. Battery usage is as much a function of the programmer as it is the language. Even when delivering the same basic app with the same language, a web forum for example in JavaScript, the performance and battery impact can vary widely. This should be rather obvious to users of the various forums about the web.
I'd estimate that I use the IMDb app at least a couple of times a week. It is another app I consider more useful than the web site.
Maybe it is, I simply haven't installed it. The thing is I am typically on a webpage when I want to look up an actor or title so I want to stay in Safari and just switch to a new page or use that same page to locate the info.
Last time I saw anthing like this it was a tool called Matrix Layout back in the 90s, and it was utter junk. If anyone can make this work Apple can, but as a programmer I've yet to be convinced that these types of tools can do much more than create photo albums and very simple, generic apps.
Exactly. You can't write business logic with icons.
Actually, not true. I also use prototyping/visualization applications Axure and iRise. In Axure, one can create lo-fi or hi-fi interactive prototypes. It looks and behaves almost like the actual thing. It's only been around for several years and adding great functionality with every release.
iRise is the more robust of the two. It actually does create business logic, IN USABLE CODE, for the back-end (Java or .NET) with any mainstream DB. This is done by creating visual elements and assigning properties, relationships, and interactive behaviors to them. It's actually pretty amazing.
Both of them allow you to generate a specifications doc for designers and developers.
This is just the beginning. As we move closer to creating ontologies for everything we do, use, say, want, etc., we are getting that much closer to creating software that can "understand" what we want to to. This is AI in the making.
No worry for devs. They'll just shift from doing mundane tasks to building applications that...well, build apps, for every vertical, market, category, etc.
In my lifetime, I WILL be able to "tell" software such as this, to make an application that does...
Think about it
There are similar apps but from what I can gather there is no app that allows you to create one app for multiple platforms.
Where I see this as being truly amazing is if it allows you to create one app that runs on Macs and all iOS devices no matter what they are. Development time will be killed.
Sometimes you just want to create a quick and dirty app as an interface for something. For example I'm currently building an online helpdesk system using PHP and MySQL. However, I would also like to develop a proper app for iOS devices to be able to make updates quickly and easily to the database wherever they are. Having to learn two programming languages to do this makes it kind of difficult to do.
A system like this will make it so much easier to do.
Your absolute dismissal of this app is perplexing to say the least. I suppose that the people using Keynote to prototype users interfaces is too far out for you also.
If keynote was marketed as making it easier to streamline your logistics, sell more widgets, or helping you find a cure for cancer, just because you can make nice presentations about these topics, yes, I would dismiss it as I dismiss any tool that promises to bring software development to the masses, without requiring you to actually learn how to program stuff. Just like keynote does not help you to produce better content, a programming language or Application Inventor or whatever does not help you to solve the abstract problems involved in software development.
The thing here is that open minds should evaluate a tool based on what it can do for them, simplify for them or otherwise get to an end product quicker. Maybe this isn't the optimal solution but frankly if it helps even to slightly reduce development effort it would we well worthwhile to have. Just as something like Keynote can replace sketch pads ans sticky notes so can an app like this find a role.
I agree with the basic premise, but let's not pretend stuff like mentioned in this article is anything new. It's old stuff and it has been for at least a decade, I've seen it all before. If you look at the evolution of conventional programming languages you'll see that the latest and greatest ones already reduced the amount of boilerplate code you have to write to a minimum, the SDK's and frameworks already solve almost any generic problem you'll encounter, the language constructs offered by the various modern languages already converged to a set that is more or less agreed on is useful, etc. Almost all advancements in programming languages you see today are about parallelism and how to make it easier to harness it without all the pitfalls, a topic the complexities of which are almost impossible to explain to someone without a pretty advanced background in programming and how computers work. Yet, with all the tools we have, writing good software is fundamentally still almost exactly as hard as 30 years ago. Less cumbersome, faster, and safer, but not much easier, at least not for anything besides GUI design. Trying to sugarcoat that fact by making your development environment more accessible by using more visual elements and activities has been tried before. It's too restrictive for almost anything non-trivial.
That 90% number is just plain garbage. There are many business apps that don't require complex logic or massive efforts at abstract logic.
I may have overstated that a little but I still stand by my statement. Obviously not every piece of software consists of 90% business logic, but you still require application of abstract logic in some form or another for about any task related to writing it. Even if you are just hooking up a touch event to a button, having it increment some kind of counter, and triggering another event that plays a sound if the counter hits some value, you are applying abstract logic in it's simplest form. Increase the complexity only one level, say by adding a timer that starts when you first hit the button, runs for 10 seconds, and then only process clicks while the counter is running and the number of seconds elapsed rounded to the nearest second is even, is already taking things too far for most people. I'd love to see an example of an easy, visual way of implementing even something as trivial as this, that doesn't require you to learn about conditonals, arithmetic operators and control flow.
No looking at iOS and the hipuge waste of time that goes into supporting basic UI elements I actually believe Apple could go a very long way to improving the position of the developer. We might actually get to the point where 90% of the effort goes to actual business logic. As it is now one spends far more time with UI development, antiquated approaches to user interface element handling and boiler plate code to drive the UI. Non of this pertains it self to business logic or abstract concepts.
The UI itself or the code implementing it does not pertain to business logic or abstract concepts, but the stuff you control and display using that UI and how it interacts behind the scenes does, and you have to think about it to do more than just GUI storyboarding. That said, I think iOS, Cocoa, CoreData and XCode already do a pretty good job at relieving you from writing boilerplate code for these kind of things. You can basically create a GUI, a data model, a way to connect the two, and all navigation between different parts of your application, without writing a single line of code. Again, nothing new here. Start using all these tools, and in no time you will find out you need background about abstract concepts such as data model entities and relations, or queries, how persistency works, about data types and how you display and manipate them, what the difference between a float and an integer is, and why you need both, why you want to normalize your data model, and so on. All abstract concepts that you cannot hide behind some kind of visual tool that decides everything for you based on some widgets you threw on a form.
Well let's be honest that statement won't get you anywhere. The whole industry has revolved around building better tools, tools used by professionals mind you. A good tool can go a long way to helping you understand your code professional or not.
I'm glad you mentioned this, because I fully agree, and it's exactly this that has gotten me pretty far already. Over the years I think I've used at least 30 different programming languages, IDE's, compilers, platforms and frameworks. I'm not religious about the tools I use, not at the very least. When something better comes a along, I'm the first to evaluate it, if not because my current tools bother me, it would be out of curiosity or just for fun. I even bought my first iPad primarily because I wanted to learn objective-c, cocoa and iOS. So I'm not dismissing any tool that promises to allow you to write non-trivial programs without having to program out of conservatism, but just based on experience and observation. I simply don't believe in it.
https://developer.apple.com/iad/iadproducer/
I think there are a lot of programing snobs who have the same attitudes that iMovie sucks because you need to go to film school to create anything worthwhile.
If nothing else, this could be a really great introductory tool for kids.
However, like Hypercard, it could be *much* more than that. I have a bunch of ideas for worthwhile apps that have very generic components, relying much more on the development of the media content to be associated with the app. I just don't have the time.
The whole idea behind Object Oriented Programming is reusable modular architecture. I don't have to create button classes because they're already there, and that's a good thing. Similarly, I shouldn't have to painstakingly recreate common view layouts or the linguistic lubricant that allows each of these objects to interact so regularly from one app to the next, and that would be a good thing too.
The major reason this hasn't worked before is because it's been implemented as a standalone solution to programming (or blogging, where we have seen more success with this model), and the programmer loses some measure of control. This could be a real slam dunk if Apple properly implements this on top of the XCode platform as an additional, optional tool.
This is just the next obvious step in the evolution of programming.
They mentioned JavaScript, not java. But I agree with ecs (except: don't allow java!) and strongly disagree with z3r0. Keep byte-code and interpreted languages off of iOS platforms. Java and other non-compiled-to-object-code languages are CPU-hogs and battery-killers. You may like how it looks when you're coding it, but your iPhone or iPad would choke and nearly die. This is the main reason why android devices will never have the battery-life or stability that iOS devices enjoy.
It would get compiled to native code... It wouldn't run in VM like Java.
Mishandling Hypercard is one of the bigger mistakes apple ever made. Here are some of the wide variety of apps Hypercard was used for
HyperCard has been used for all sorts of hypertext and artistic purposes. Before the advent of PowerPoint, HyperCard was often used as a general-purpose presentation program. Examples of HyperCard applications include simple databases, "choose your own adventure"—type games, and educational teaching aids.
Due to its rapid application design facilities, HyperCard was also sometimes used for prototyping of applications and sometimes even for version 1.0 implementations. Inside Apple, the QuickTime team was one of HyperCard's biggest customers.
A number of commercial software products were created in HyperCard, most notably the original version of the interactive game narrative Myst, the Voyager Company's Expanded Books, and multimedia CD-ROMs of Beethoven's Ninth Symphony CD-ROM, the Beatles' A Hard Day's Night, and the Voyager MacBeth.
The prototype and demo of the popular game You Don't Know Jack was written in HyperCard.
Renault, the French auto manufacturer, used it to control their inventory system.
In Quebec, Canada, Hypercard was used to control a robot arm used to insert and retrieve video disks at the National Film Board CinéRobothèque.
HyperCard was also used to prototype a fully functional prototype of SIDOCI (one of the very first experiments in the world to develop an integrated electronic patient record system) and was heavily used by Montréal Consulting firm DMR to demonstrate how "a typical day in the life of a patient about to get surgery" would look like in a paperless age.
Activision, which was until that time primarily a game company, saw HyperCard as an entry point into the business market. Changing their name to Mediagenic, they published several major HyperCard based applications, most notably Danny Goodman's Focal Point, a personal information manager, and Reports For HyperCard, a program by Nine To Five Software that allowed users to treat HyperCard as a full-fledged database system with robust information viewing and printing features.
Creating commercial software isn't the only viable use for programming tools. If a programming system is easy enough that a small business owner can create custom apps to better run his business without having to hire programmers, it's quite useful. Who cares if you lose 5% more battery getting something useful done that you might have to lose if you hired progressional programmers to write custom objective-c code that that same small business owner has no chance of understudying or modifying.
Having an accessible entry into programming for children is also quite useful. That's what these portable tablet computers were supposed to feature when first envisioned by Alan Kay. I'm a professional programmer with 30 years of experience developing primarily for Apple products. The tools I use are too complex to teach my 10 year old daughter. Yet 30 years ago 10 year olds were programming Xerox Parc computers with no problems. A modern day Hypercard like product would be perfect for her. Something where you don't have to program all of the details, but can easily script objects where needed.
I build our website with javascript/php/mysql - I constantly wonder why that can't be as easy to program as hypercard. The results really aren't all that different. The tools for accessible programming are lightyears behind where they were 20 years ago.
Last time I saw anthing like this it was a tool called Matrix Layout back in the 90s, and it was utter junk. If anyone can make this work Apple can, but as a programmer I've yet to be convinced that these types of tools can do much more than create photo albums and very simple, generic apps.
Exactly. You can't write business logic with icons.
I don't know whether you were including HyoerCard in this opinion, but I offer this. I was the sysadmin for 2700 Macs using Microsoft Mail, and our implementation used an Out of Office notification system that was built completely in HyperCard, both client and server side. Not only did it work pretty well for what it had to do, but it could be customised even further since it was an editable stack. I always thought Hypercard was a nifty programming environment, one that was as simple or as complex as your experience allowed.
Right. So if I understand correctly you are basically saying the abominations people who know nothing about web technology create, serve as a good example why creating iOS applications should be as simple as dicking around in FrontPage pretending you know how to build a good website?
With statements like this you'll be sure to trigger the web developer snobs and the web designer snobs as well, just like the professional programmer snobs posting in this topic. They're all the same, thinking they took an education and years of experience to do stuff anyone could do with just a few better tools. I mean, we've only been trying to make software development easy for a measly 40 years or something
Now if you excuse me, I'm off to continue working on my DIY neurosurgery kit, it's about time anyone can do brain surgery. No reason it shouldn't be as easy as clicking together a website. No reason at all.
10 years ago if you wanted a website you went to a web designer and paid them thousands of pounds to build it. Now you can buy software that lets you build a simple website in no time for very little cost. That's great for small businesses, local interest groups, individuals, etc who can now afford their own website. To me that's progress. If you want a more professional website you can still employ a professional web developer or learn to do it yourself.
I don't see why we can't have the same situation with iOS app's. I'm not suggesting my simple community project app would compete with professional app's or make my fortune, but it would open up iOS app's to a whole new audience in the same way that simple website building software did.
As for the sanctity of iOS developers well all I can say is that the iTunes store is full of badly written, buggy app's that have been developed by those same developers. Maybe some of the amateurs will make a better job of it.
Users are free to reject any app they might think is a problem.
Yes, but Apple can favour tools. If Apple proposes "X" as the default programming language, you'll see a lot of apps using such language.
Just the mention of Javascript as the suggested path by Apple produces me cold sweat.
It's fine to propose a tool for creating apps without code. But, if such tool lets you add code, then code in ObjectiveC, which is the technology behind Cocoa. It will be better for iPhones batteries, and also more coherent with the Apple technologies.
Disclaimer: I work for them