Table and Query Classes good or unnecessary?
On Fri, Mar 16, 2018 at 11:28 AM, Marten Verhoeven <email@example.com>
> Hi Clifford,
> The licensing can be a show-stopper, but doesn’t have to be. It depends on
> your application/business case. If you are building a (partially)
> free-to-use application (for example as an iOS app, which has a free
> version with in-app purchase to add functionality) it will probably a no-go
> with regards to licenses (you at least need to talk to Omnis about it). For
> us, we have a fixed amount of users. Adding a middle tier would require a
> bit more licenses, but not 2x. So the licensing cost is no issue at all for
> our situation.
> I agree with your first remark: single threaded is easier to develop for,
> and that is fine for Omnis in my opinion. I don’t need the multi-threading
> power of clojure for my business application. It is a no-go however to have
> to handle all client requests in a single-threaded environment. You have to
> be able to respond to separate request at the same time, otherwise you are
> lost even with 5 users of your server. So in my opinion, multi-threading or
> multi process is required, even for small uses (and handling one request
> can be done in a single-threaded manor).
> And about python… Oh boy…:-)
> I am a novice, so I will probably be shot, but I will give it a try;-)
> I don’t like that the indentation is part of your application flow. You
> can get different flow of your code even if it looks visually the same (by
> mixing tabs and spaces in the wrong way). That however can be solved in
> practice by using the right tools,
“The right tools”… like any text editor or virtually any IDE. The amateur
mistake of mixing tabs and spaces for indentation, you’ll only make once.
Once you’ve gotten over it, it’s really a no-brainer. If you were on my
team, I’d even create a git hook, say “martenProofTheIndentation”, and let
git handle any potential errors. 🙂
> and that is not why python currently is not my favourite language. Heck, I
> even really _love_ lisp and that notation is really awful. But somehow the
> dynamics and flexibility of that language make me love it.
> I have only used Python a little bit. And it _is_ on my list for a middle
> tier to investigate further. I don’t have the love for it, _yet_. For a
> small part this might be caused by not having a closing part of a code
> block (so no “end if” or something like that).
I love the indentation and the I love the removal of superfluous chatter,
like “endif”. Every language has its peculiarities and once you’ve worked
with it for a while, it just becomes second nature, like human languages.
(Who would ever spell the word “thought” the way it’s spelled if we were
doing a “clean slate” design of English, for example?) Omnis has lots of
these peculiarities. You’ve just become inured to them because you’re so
used to. The $ signs all over the place – that’s ugly. The mish mash of
procedural and object-oriented constructs in Omnis are weird to an
outsider. It’s unnecessarily verbose. “Calculate foo as bar” How is that
any more intuitive or expressive than “foo = bar”? You just get used to it
and deal with it.
> But the biggest part, I think, was my inability to comprehend the standard
> modules. For example, I struggled a lot with calling command-line tools.
> Should I use os.spawnl, or os.popen, or one of the many other? I know I am
> a novice with python, but that made me search a lot and did not seem very
> nice. However, I believe a lot of the modules are cleaned up in Python 3,
> so it might be a lot different now. I just don’t know as I haven’t
> converted my (small) code-base.
There wasn’t a big problem with modules in Python 2x so I think this is
just your inexperience with the language. The various ways of forking and
interacting with the OS have to do with the fact that Python is portable
across many operating systems. All that stuff is well-documented and it
just takes a bit of patience and practice to sort it out.
> As for python to build UI: I know it is used on linux quite a lot, but on
> windows I have never seen anything based on it, and the only GTK
> applications I have seen on windows look just like linux applications on
Which is why I used PyQt. That more closely approximates native widgets,
certainly more accurately than Omnis. Omnis never looks quite native either
and it’s understandable given that it paints its own widgets on a canvas.
> I will not be building a linux frontend anytime soon. The first new
> front-end will be mobile, and I can use c# and swift for that (and as far
> as I know I cannot use python for that).
Why bother with two completely different languages and two completely
different codebases to target iOS and Android? Isn’t Xamarin good enough to
target both? React Native and Flutter are two other frameworks that do a
great job building native iOS and Android apps.
> I have no interest in making a web version of our application at all. That
> has been completely solved by ‘bringing your own device’. Installation and
> updating are not big issues anymore. I would prefer a cross-platform
> language and toolkit (like you can with c#) above a ‘webview in an app’ or
> ‘in a browser app’ anytime. So I definitely don’t want to transpile python
> Clojure is not transpiled!
I didn’t say it was. I said that if you wanted to do client-side
development with Clojure, Clojurescript could be an option. Transpilation
is a problem that has been well sorted out. Source maps make it painless to
debug your code in the original language, well, as painless as debugging
anything can get.
> Clojure is compiled to run on the jave runtime. Clojurescript is something
> different. Heck, clojure is created for multi-threading, and clojurescript
> is intended to run on a single threaded runtime. So, if we would use
> clojure, I would have to write the client side in a different language (I
> don’t think building a java-ui with clojure (or basically building any java
> ui) a good idea).
> I mentioned protocol buffers. I don’t know ZeroMQ, but as far as I can see
> it is something different. Protocol buffers is a tool from google (
> developers.google.com/protocol-buffers/). Basically you define
> the interaction of data between your applications in a configuration file.
> Based on this file code is generated to handle transferring the data. With
> one definition you can create modules in different languages. So, on the
> server you create data, the protocol buffer transforms it to binary data
> (or text when required for humans to read), you transfer the data and read
> it back in the other application. The data transferred is small (as it is
> in binary format, so not like JSON or XML), it can be converted very fast
> to usable data in your application and it is type-safe. I haven’t
> investigated it enough to know if you can also generically define the data,
> which you need when you want to be able to specify the columns of a select
> dynamically. You could do the same thing quite easily when server and
> client are both Omnis (you could transfer the binary data), but the
> advantage of a protocol buffer is that you can transfer data between
> different languages as well. It also takes version of the data definition
> into account (so a client with an older version of the code can still talk
> to the server with a newer version).
I’ve never encountered it. I wonder how popular this is. Looks interesting.
> reason for it. And I don’t see our application as an application completely
> run in a webview. I don’t require it and I think it would take a lot more
> work to build something nice and the risks of it being not nice are much
> higher (I know a lot of crappy web applications, only a few reasonably
> good). I don’t believe in the ‘build once, run everywhere’ utopia;-)
ES 6, is actually very good. The complexity of the build toolchain that I
mentioned a few days ago is my biggest pet peeve but that has more to do
with the relatively slow pace of adoption by browsers and of newer
ECMAScript standards. I can live with that. The fact that we can build
modern applications that are every bit as rich as any desktop application
and deliver that application in this runtime environment called a browser
is a huge win. There is also something to be said for the “one language to
end-to-end because our team is small so it makes little sense to have
people who only work on the backend while others work only on the frontend.
As for transpilation being a bad idea, the facts don’t bear out that
opinion. We transpile TypeScript to ES 5 so that it can run in a browser.
We’re not unique in this regard. Anyone who is writing ES 6 is transpiling.
The modern web would be nothing like it is today without transpiling being
By the way, we have received nothing but great reviews from our customers
who are using the formerly Omnis fat-client window that we deliver as web
forms via the Chromium Embedded Framework XCOMP that we’ve built. They
actually prefer it to the legacy Omnis fat-client windows that the web
forms are replacing. One of our design goals was to minimize the changes to
the user interface while still freshening it up. The UI of the legacy
fat-client application was hideous not just because Omnis widgets have a
sort of Windows 95 look about them, at least in Studio 4.3, but because
there were some strange design choices that were made at the time that the
application was built, like pale green backgrounds on all dropdown lists.
It doesn’t matter why that choice was made. That’s what the users are now
used to. We faithfully reproduced those warts in the web application not
because we’re not capable of changing but because we don’t want any user
complaints about “Hey! You’ve changed everything!” We will evolve this
application over time so that it looks better. It already looks much better
by virtue of Bootstrap 3 styling and Font Awesome icons. We took care to
use iconography that is as close as possible to the Omnis icons except they
don’t look like a SEGA game console graphics.
I think the resistance by developers to deploying their applications within
a browser due to some imagined benefits of having a native look miss the
mark if their customers want applications deployed within a browser. We
fight our customers at our own peril. Whether there is actually any real
benefit of running our application on an iPad or not, our customers were
oohing and aahing over demos being done by our competitors who have web
applications so if we don’t meet the expectations of our customers, our
competitors will. I can see real benefits of running at least parts of our
application on mobile devices. Initially, that will be via WebView and it
will be like a web site running on a mobile device. We’ll eventually build
native apps for iOS and Android. We’ve had that in mind from the outset
which is why we implemented a REST API even though we control both the
frontend and backend.
+1 647-778-8696 <(647)%20778-8696>
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:firstname.lastname@example.org