Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Troll Technology (QT) Releases Scripting Language 64

Posted by timothy from the words-that-do dept.
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!"
This discussion has been archived. No new comments can be posted.

Troll Technology (QT) Releases Scripting Language More

Troll Technology (QT) Releases Scripting Language

Comments Filter:

  • When hell freezes over, pigs fly, et cetera. (Score:4, Funny)

    by cyberkreiger ( 463962 ) on Thursday December 19, 2002 @01:09PM (#4924145) Homepage

    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!
    • 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.

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

    Joe
    http://josephgrossberg.blogspot.com [blogspot.com]

    • Re:just what we need (Score:5, Insightful)

      by eddy the lip ( 20794 ) on Thursday December 19, 2002 @01:26PM (#4924304)

      It's based on ECMAscript [trolltech.com], 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.

    • Hum, did you read the post ? It says it's a beta so you don't have to expect the documentation on their site.

      You obviously didn't download it either, the docs are there. Stop whining and download it if you're really interested.
      • I'll download it, and *then* see what comes with the download. Um ... sure.

        I'm not whining. I'm just saying that if you are releasing a new language, you need to attract developers. If you want to attract developers, you need to make the things they need (e.g. documentation), readily available.
        • they only need documentation if they're using the language, they can't use the language w/out the download, the download contains the documentation.
          • 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 (Score:4, Insightful)

    by Strange Ranger ( 454494 ) on Thursday December 19, 2002 @01:18PM (#4924226)
    'Lug, you aren't going to roll something out to your Trading Desk with "no support and no warranty"?

    Are you?

    • Re:Hopefully (Score:3, Insightful)

      by b_pretender ( 105284 )
      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 (Score:4, Funny)

        by JabberWokky ( 19442 ) <slashdot.com@timewarp.org> on Thursday December 19, 2002 @02:26PM (#4924851) Homepage Journal
        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 (Score:4, Informative)

        by Strange Ranger ( 454494 ) on Thursday December 19, 2002 @03:33PM (#4925252)
        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 (Score:2, Interesting)

          by OOPChugALug ( 57084 )
          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)

        • Okay, I'm now in my fourth trading support environment, as a consultant, and three of them used perl. One also used python.


          The only one that didn't have perl or python insisted on everything in C++. They didn't have *any* C++ programmers, so that the C++ code was effectively unsupported!


          In reality, the biggest problem is that Traders are well versed in Excel, and I have met many of them that don't understand what other applications a PC could possibly want. They can be spotted writing letters to their clients in Cell A1.


          These traders are wrong, since in reality, behind them is a large mass of (semi) automated order processing, settlement and confirmation systems, most of which are mainframe/minicomputer based, or n-tier client server. You *can't* do that with Excel.


          Margins are low in investment banking now, and firms are being pushed to cut costs, especially in IT. Traders are no longer able to swing their big swinging dicks and get what they want. They will get what they are given, and that will start to be the cheapest option -- the spreadsheet widget is a possible flyer.


          Admittedly, the quants do design their pricing models in spreadsheets, but this is a prototype, since to trade whatever it is has been designed, the same model must be implemented in the big iron trading systems. The rest of the universe uses excel for looking at data.

  • ANOTHER scripting language? (Score:3, Interesting)

    by metalhed77 ( 250273 ) <andrewvc AT gmail DOT com> on Thursday December 19, 2002 @01:44PM (#4924469) Homepage
    why not just make libs available to do what this language does for perl, python, etc.

    • Well, there kind of already are - there are python bindings (PyQT [riverbankcomputing.co.uk]) for, oh, everything really, and doubtless perl and ruby bindings too. You need an interpreter for whichever of these languages you want to run, and you need the relevant packages, plus ideally some documentation and you're ready to go.

      Having said that, I think ECMA-script is a good base for scripting functionality - I've thought for a while that it's just too good to spend its whole life servicing pop-ups and roll-overs, and it's good to see that SVG, for instance, will eventually be scriptable via ECMA-script and the DOM. I've used JScript, MS's ECMA-script implementation, with the Windows Scripting Control before now to script the behaviour of COM components, and found it greatly preferable to VBScript - much more dynamic, much better error handling (try...catch...finally, with objects throwable as exceptions), much better array-handling and so on. I haven't tried using it for a larger-scale project, and would probably resort to Python if I wanted to build a full-blown application, but for quick and dirty scripting it's a real gem.

  • Troll Technology (Score:5, Funny)

    by Hubert_Shrump ( 256081 ) <cobranet@[ ]il.com ['gma' in gap]> on Thursday December 19, 2002 @03:33PM (#4925254) Journal
    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"

  • This just reaffirms my growing theory that software development is moving away from a science and becoming more of an art, as it becomes easier and the skills less brain-dependant.
  • 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.

    • 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.
    • Did you notice that QSA is ECMAScript (Javascript)?

Slashdot Top Deals

The program isn't debugged until the last user is dead.

Close