Troll Technology (QT) Releases Scripting Language

OopChugALug writes "Troll Tech last night released a beta of QSA, which stands for QT Scripting Language for Applications. Download here. As a business apps developer for a major financial institution's trading floor, I know the traders will love this. Hopefully, with QSA, I can get rid of Excel, and give the traders Spreadsheet widgets, with the flexibility of a 'VBA-like' scriptability to boot!"

Comments

When hell freezes over, pigs fly, et cetera.

[cyberkreiger]

Hopefully, with QSA, I can get rid of Excel, and give the traders Spreadsheet widgets, with the flexibility of a 'VBA-like' scriptability to boot!"

Yes, yes, very likely!

Re:When hell freezes over, pigs fly, et cetera.

[e8johan]

QSA shows the great hidden abilites of the Qt toolkit. Hopefully the code will show how easy this is so that a free VBA compatible version will appear rendering all (non-viral) Windows scripts runnable in a free environment. This is one of the major things M$ Office has today, the scriptability. It is not great, not even good according to some (me) but it is there and works.

just what we need

[josephgrossberg]

Not only is it yet another scripting language, there is no documentation on their site!

Joe
http://josephgrossberg.blogspot.com

Re:just what we need

[eddy the lip]

It's based on ECMAscript, so it's not really learning a whole other language. This was smart on TrollTech's part - no one's interested in learning a whole other language just to interface with pretty widgets. This'll make it very accessible to a lot of developers.

Should open up some interesting possibilities for KDE, too.

Re:just what we need

[josephgrossberg]

I think you have the logic backwards, and you're missing my point.

They should make the documentation readily available and easily accessible. That way, it will encourage people to download it.

Before I download something, I want to make sure it's useful and worth my time. I don't just go around downloading programs, and *then* seeing what they are.

For applications, this means a feature list and screenshots. For languages, this means documentation I can (easily find and) browse online.

Hopefully

[Strange Ranger]

'Lug, you aren't going to roll something out to your Trading Desk with "no support and no warranty"?

Are you?

Re:Hopefully

[b_pretender]

Trading support software is developed in-house at *all* of the investment banks (i.e. Supported in house, no warranty).

What's unusual is that this guy (story's original author) thinks that he's going to get the said traders to move away from Excel. Yeah, that will happen when Enron regains its credibility as a market maker. I got news for him. The traders drive the trader-support tools. He should think to stop using excel *after* the traders start asking him to stop using excel.

All traders everywhere use Excel. All Risk depts everwhere use Excel. A majority of quant modeling is done with excel.

Please post any exceptions below, because I'm interested in knowing who doesn't use excel.

A final point is that VBA for Excel is highly polished and the best currently available. It's very easy to code and compile C++ DLLs that directly link into Excel through VBA. A lot of people are doing this, there's a lot of information available, .net promises to make this even easier to do, and there's little reason to switch to something different.

Re:Hopefully

[JabberWokky]

I worked for a revenue stream purchaser (the kind of people who buy lottery streams, etc). The guy who calculated everything had an Excel spreadsheet he used for it all - billions of dollars of streams. He knew about Excels quirks and bugs and he did the major calculations twice using different formula and methods to arrive at the answers. I once asked him what he did when they didn't match - and they often didn't. "Choose the one that benefits us the most" was his reply.

No wonder why they use Excel. :)

--
Evan "Thinks Word 97 is the best WP to date, but not a fan of Excel"

Re:Hopefully

[Strange Ranger]

Trading support software is developed in-house at *all* of the investment banks (i.e. Supported in house, no warranty).

Um..I work with a trading desk every day. Some of it is in-house, much of it isn't. There's a huge list of vendors that supply trading desk applications. Many of them sell software with Excel plugin capability. Bloomberg and Bridge come to mind. And you're right, why in the world would you switch away from Excel.

Regardless of all that, if one of our developers downloaded an obscure scripting language with no support and started rolling out custom applications I'm pretty sure we'd escort him to the door on the spot. Things like compliance, due diligence, split second transaction accountability, Business Recovery, transparency, etc all mean you can't just toss out whatever widgets you like. Can you imagine rolling out trade balancing tools to a trading desk writting in unsupported language 'Foo', and then putting in your 2 week notice?

Re:Hopefully

[OOPChugALug]

I've worked with traders on an interest rate derivatives desk for the past 7 years, basically using Excel, VBA, and C/C++ DLLs coupled to Tibco, Infinity as well as other custom software packages.

I submitted the article, and believe me, it will be a hard task to ween traders off of Excel - if even possible. I plan on rolling out parallel versions of the software I am producing - and we'll see which "version" the traders like better. I believe I will be able to flex and bend to the trader's whims more adeptly with QT/QSA, but we'll see. Excel will not be abandoned by any means, but if it is used to a lesser extent, than this will be making some headway.

Often, we just can't do things in Excel that we would like, with the control and protection we desire. Likewise, we find that traders often find "hard-coded" GUIs, without any scripting language or ability to customize the appearance to be lacking in flexibility as well.

I've written Excel DLL's for a long time, and believe me, I'm no fan of Microsoft's underlying API for exporting VBA variables / types back and forth to C / C++ DLL land.

Do you think APIs such as SafeArrayAccessData(...) or structures such as SAFEARRAYS and VARIANTs are elegant? Ever try passing nested structs that contain arrays of nested structs of unsigned numbers or BSTRings back and forth between C and VBA? I think the Microsoft APIs for doing this and the Microsoft documentation is crap. IMHO, the QT documentation looks clearer.

Additionally, I've been extremely impressed with QT as a GUI toolkit -unlike MFC/Win32 (or the complexity of COM). As far as support, we are planning on buying quite a few developer licenses / support from Troll tech. The price is not an issue and we like the license terms.

As far as "Things like compliance, due diligence, split second transaction accountability,...etc", you would be surprised how much traders mix in their own models/ calculations with programmer-built tools - With Excel, it's a real problem keeping software under control. I can't see how it could be worse with QT. Should be interesting....

Cheers,
Dave Linenberg (OopChugALug)

Re:Hopefully

[grammar nazi]

...but for quant jockeying, where you actually manipulate data, it's far too 2D. Also, people discover excel has only 65535 rows and decide it sucks.

Plus excel runs neither on commercial unix nor IBM motherfuckin' mainframes, so lots of banks won't use it for anything mission critical. Traders tend to be tech-savvy, and here (City) insist on APL on Unix on their desktops -
Most of the quants I know use an APL2 family language like Saxon APL or an asciified derivative thereof like K.

2D is all that you need for traders' on-screen analysis. It is simple, quick, down-and-dirty, and gets the job done. If you are doing anything with even close to 65535 rows, or if you need a 3+ Dimensional data structure then you need to reevaluate your model and your decision to use Excel. There are many tools (Matlab, SAS, C++, Perl) that better suited for large data sets. Pricing Options, Derivitaves and Bonds doesn't require these models.

With regard to banks using Excel. I was refering specifically to supporting traders in investment banks. I'm not sure what is run serverside, but I hope it is mission critical. I know that *all* of the quants and risk analysts that I know use excel. Some of them have Sun compute servers with SAS and Matlab, but Excel is the dominant tool and the tools that they develop for traders *have* to work in excel.

You say that you work at city. Do you mean Citi? (Citigroup). If this is the case, your misspelling makes me doubt that you really work in the finance industry.

Re:Hopefully

[grammar nazi]

I stand corrected. I'm sorry for my american-centric view. I work on "the street" so I should have realized. Actually, I will be looking for work in London/Frankfurt as soon as I finish up my Quant-finance MS.

You're right. Excel may be far less prevalent elsewhere in the world, although I can't imagine what might take its place. I would be interested in knowing.

Re:Hopefully

[b_pretender]

As for two week rollouts - I wish! Try 2 day rollouts. You'd be surprised how little testing goes into these applications.

Exactly! Suppose ibank A is pricing a complicated instrument. If their software took two weeks to quality check and verify, then ibank B would do the software in two days and purchase/sell the instrument before ibank A could ever get to it. What if ibank B makes a mistake in their software that ibank A doesn't make? Well, ibank B will more than cover their losses during the next two weeks when they roll out 7 new packages for pricing 7 new instruments and ibank A is still working on the first instrument.

wxWindows

[DrSkwid]

free, portable, many bindings

wxWindows: wxPython, wxBasic, wxLua

[Nicolay77]

wxWindows has native look and feel over all the supported platforms, not emulated, and has several scripting languages.

Nothing beats wxPython for what you want to do.
There is even wxLua (a very fast light scripting language) and wxBasic for the fanatics of that language.

Re:wxWindows: wxPython, wxBasic, wxLua

[fuzzbrain]

I don't know much about wxWindows but from what I've heard about it, there are two advantages Qt has over WxWindows:

• Qt implements an observer pattern using signals & slots which are very powerful; wxWindows uses callbacks with event handlers like MFC
• Because Qt doesn't wrap around other widget sets, it's faster

There are also python & ruby bindings to qt just like with wxWindows.

Re:Released, really?

[Nicolay77]

QT is not free if you want to do commercial applications. wxWindows is.
And I'm not really convinced that it's better, unless you think only in KDE.

Anyway, wxWindows already has several scripting language bindings. (I forgot wxPerl too)

ANOTHER scripting language?

[metalhed77]

why not just make libs available to do what this language does for perl, python, etc.

Troll Technology

[Hubert_Shrump]

Troll(/.) {
case FP:
? FP[Rnd]
case Soviet:
reverse(HeadLine)
? "in soviet russia, $1 $2es you!"
case Ascii:
for (!filtered)
? Rand_Art
case ReadArticle:
restate(wrongly+inflammatoryDeclaration)
case !ReadArticle:
restate(wrongly+inflammatoryDeclaration)
case Beo:
? "imagine a beowulf cluster of $1"
case AYB:
? "All your $1 are belong to $2"

Re:Troll Technology

[tg_schlacht]

Interesting? Try FUNNY.

Re:Troll Technology

[StandardDeviant]

case (location == SovietRussia):
? "case switches YOU!"

Re:Released, really?

[PurpleFloyd]

The reason QT has its own string class is for cross-platform compatability. Standard strings on different platforms may behave oddly, while a QT-standard string object helps to achive the whole "write once, compile anywhere" goal.

Speaking of reinventing the wheel, how about GTK implementing its own OO environment on top of C? Last time I checked, there was a very good one called "C++".
</FANBOY>

The K Language

[Jayson]

For those of you who don't know about K here are two resources.

My quick intro: http://www.kuro5hin.org/story/2002/11/14/22741/791

A wiki entry written by David Ness: http://www.c2.com/cgi/wiki?KayLanguage

How wonderful

[drinkypoo]

Yet ANOTHER scripting language. I seriously lost count long, long ago how many new scripting languages have been introduced since I started paying attention. Do we really need ANOTHER one? I mean I personally really didn't think we needed php. (The best solution would have been to mimic ASP, whether you supported visual basic or not; Mimicking ASP with perl and jscript would have been good. This would have bought "us" way more portability in web code...

But back to the PHP thing, PHP looks like perl and smells like perl but it ain't perl and if you try to pretend it is it doesn't work out way too much of the time. What does this scripting language look like, and why did we need another one? Why couldn't they have just plugged something good which already existed in to that place? Troll is determined to reinvent every wheel possible where gnome is trying to do things in the best of established ways, as far as I can tell. I don't use either any more (Devotee of XP on the desktop) so I'm not keeping up with every detail but that's my broad impression.

Re:How wonderful

[Caractacus Potts]

Yes, we need more scripting languages. Yes, we need to reinvent wheels whenever possible. It's amazing how clear this is to some people and how incomprehensible it is to others. Portability and establishing standards are among the most practical goals to have, but you still need people plugging away in R&D-type activities to birth new ideas and techniques. If you're on a budget and a schedule, sure, grab the best thing available and go with it. But, if you can glimpse a better way to do something, give that a try too.

Erm...

[rakslice]

Did you notice that QSA is ECMAScript (Javascript)?

Re:Erm...

[drinkypoo]

Nope. I stand corrected in that case.

Egg on face for this reason, not the sibling to your comment :P