Studio 6.1 method lines increased to 256K

Marten Verhoeven m.verhoeven at
Fri Aug 8 07:16:57 EDT 2014

Hi Geir,

I have no idea what those other technologies where. I even didn't know about Athena. I started with Omnis when Studio 2 was already available and converted our Omnis 7 app to Studio. That application is basically rewritten, but in stages, so it was useful you could still use the old DML etc. in Studio.

I don't necessarily think Omnis should have been written as a server in mind. For the time it had no use and probably was a bridge to far. I'm not a fan of 'creating a new beast'. I like iteration instead. Slowly, step by step improving all aspects and then years later you have rearchitected about everything. Otherwise you get a big bang with all problems at the same time and nobody who will want to convert. 
Even Apple with Swift isn't building a completely 'New beast'. They built it on top of existing stuff: LLVM/clang, interfaced with cocoa (so they still have all the frameworks everybody know) and runs on the same runtime (it's even binary compatible). Swift is arguably 'just' a new syntax which enables them to do more in the existing stuff and at the same time it is more powerful for developers. They removed legacy burden which held them back so they can iterate further. A next step will probably be adding Swift specific API's. Because of this iteration developers can gradually move over to Swift and they can gradually improve the core foundations (like I gradually moved over from classic to OO in studio and from DML to SQL etc).

TL hasn't done a lot of iteration on the Omnis core, so they have some catching up to do. But Iteration is still the way to go imho. Studio is starting to get outdated, but I definitely don't think it's ready for retirement. It will never be (and has never been) a big market player, but it can keep being a successful nice market player if they keep iterating. The key differentiator in my opinion is the speed, ease and flexibility in development. It does this partly by limiting what you can do with it, but that makes it can be a niche market environment and this also makes it can differentiate itself from the big players (as the big players need to do be able to 'do everything'). You can't create fancy dynamically adapting user interfaces which also work well for visually impaired people and run on a laptop, phone and watch, but you can create (boring but) decently working, relatively powerful business applications with really limited resources.



-----Oorspronkelijk bericht-----
Van: omnisdev-en-bounces at [mailto:omnisdev-en-bounces at] Namens Geir Fjærli
Verzonden: vrijdag 8 augustus 2014 12:13
Aan: OmnisDev List - English
Onderwerp: Re: Studio 6.1 method lines increased to 256K

Those who remember will have noticed that there was indeed such a beast planned: Back when Studio was still code named Prometheus, the Powerpoint slides had three other technologies on them, including a SQL database engine code named Athena. I guess most of us are glad they didn't waste their limited resources on that idea.

Extra points to those who can still name and explain the other two technologies.

Oh and I used to agree with you Marten. The obvious problem with Studio was that at its core it was still Omnis, with all its implications. And not only the core: One of my main suggestions back then were that they simply turn off all the «classic» elements by default for new applications. I realized they were needed( were they?) for the sake of converted applications, but no need to lure new users into basing their apps on the CRB and other dated structures.

Which opens for another question: How many out there actually ended up with converted Omnis 7 applications after all? My suspicion is that eventually many rewrote their apps and scrapped the old code, not to mention all those who tried going Studio and failed, and who are still on Omnis 7, or long gone.

I agree that Studio - in hindsight - should have been written with an effective server in mind. But I am not sure many asked for that in 1996. Which leaves the third question: Is Studio itself now outdated and ready for retirement? (With ample support time for exists apps.) Should TL create a new beast, and if so, what should it be? 

Geir :)

8. aug. 2014 kl. 11:26 skrev Marten Verhoeven <m.verhoeven at>:

> so the move to SQL was required (or they would need to build their own database engine).

Manage your list subscriptions at

More information about the omnisdev-en mailing list