I sometimes feel they should also make a bigger gab between the 2 products... Advanced is really Advanced and the more general product is a simpler version. This way they can market the products differently. One is geared to real develoeprs ... the other is geared towards novices and users.
I couldn't agree more with both of your comments.
@Vince: Fantastic point. Almost everything I'd ask of from a future FMPA falls into the category of making it a true development tool. I'd hope that in the future, FMPA would take on more characteristics geared towards developers' needs.
@Jeremy: Totally agree on all points. My assumption (hope) is that FMI has chosen a phased roll out, intentionally providing only SELECT functionality for FM12, and (hopefully) rolling out the remaining elements of the SQL DML in FM13. But it can't be stated too strongly how important having INSERT, UPDATE, and DELETE would be.
I'd also add here that the ability to have FM SQL return true tabular structures (instead of just strings) would be a giant step forward. If we could, for example, link portals to ExecuteSQL() output, or create virtual tables based on SQL Joins, this would open up a great deal of power to our solutions.
As a bit more of a FileMaker purist myself, I "think" I am in agreement with you for the most part. I started with FileMaker back at v2.1.
While FileMaker is not quite as "Secretive" as Apple, I doubt you will see FM Product Managers chime in here to explain the direction of FileMaker Pro. What you will get is opinions from developers and users. So here's mine...
I am not sure that I would necessarily attach the word "Pro" to things like SQL, OBDC, XML, CWP, etc... These elements are peripheral to FileMaker. There are lots of people who understand them well, but could not make a usable FileMaker solution. There are others who have used these things in concert with FileMaker to do great things for themselves and/or their clients. Additionally there are many developers who build powerful solutions without any of these elements at all.
One of the problems that FileMaker faces is that they need to make FileMaker inviting to new users, yet make it powerful enough to support long term usability. While I firmly believe that todays "Novice" is tomorrows "Pro" developer... In reality "good" Database Development is not an "Entry Level" operation. I think most experienced developers would agree that novice users will generally build their early solutions the "wrong" way. One can try to guide a novice user, but short of holding their hand all the way, they will have to learn from their own mistakes, just like we did... (and still do.)
I think FileMaker does cater a fair amount to beginners, and a bit too much to the "Peripheral Elements"... Personally I would like to see more put into the core features "within" FileMaker. Here are some things I think FileMaker has added over the years that really made "FileMaker Pro" more powerful "in my opinion"...
1. v3 Added Relational functionality (HUGE)
2. v7 Multi-Key relational (HUGE)
3. v7 Multiple Tables in a file.
4. v8.5 Variable and Script Parameters
5. v9 Conditional Formatting
6. v10 Script Triggers
While there have been many other features added, these are the ones "in my opinion" that are major. I would like to see more focus on advancements like these. If FileMaker Pro was only 3-5 years old I would consider this a great revision cycle. However, FileMaker Pro is close to 25 years old.
While I am not advocating FileMaker move away from things like OBDC, SQL, etc. I do however feel if FileMaker had put half the effort into improving FileMaker's core features, as they do integrating with peripheral elements, by now the "other" companies/protocols would have been trying to figure how they fit with FileMaker.
I agree more with you than with what you seem to think I think. I used ExecuteSQL as an example of a "pro" feature because it is the most discussed "pro" feature in the most recent release. I don't mean to define the pro-ness of a feature by the adopting of a technology used outside of FileMaker, but by the depth of responsibility that comes with the extra power. Script triggers are probably a better example of what I mean by "pro" features. Using script triggers effectively and robustly requires an escalation in a developer's understanding of how FileMaker works and the sophistication of a developer's programming technique. They were a feature strongly requested by professional developers — especially developers with experience with event-based programming in other contexts. Script triggers were solidly done "the FileMaker way," rather than trying to adapt another technology too faithfully so that it doesn't make sense in the context of FileMaker. (I agree with aspiring to FileMaker purism. One of the biggest advantages of FileMaker is that you don't have to know any non-FileMaker technologies to use it, or even be professionally good at it.) Script triggers are also an abstract feature that's easy to sell to developers who can imagine the potential, but hard to sell to folks who aren't experienced developers until after pro developers build working examples of how to use the feature. Unlike quick find Go to Layout, ExecuteSQL and script triggers are much easier to get wrong than to get right.
I agree that FileMaker caters to beginners, and I wouldn't have it any other way. I like to say that FileMaker's "easy on-ramp" is one of it's most important features. With the exception of the new ExecuteSQL function, and the rising role of CSS for layouts, FileMaker seems to steer clear of adopting external technologies for itself — as I agree it should be. (I cringe a little every time I see a developer passing multiple parameters formatted as JSON or psuedo-XML; that seems like a step backwards to me, away from the cohesiveness of the platform.) Developers with experience in other technologies may ask for FileMaker to implement their favorite features of those other technologies, and I'm happy to see those developers indulged; but I would like those features to be implemented in a way that FileMaker doesn't surrend it's product design to "peripheral elements" and lose the soul of its easy on-ramp and self-contained platform — less ExecuteSQL and more script triggers. Alas, the pandora's box of ExecuteSQL may already be open...