• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

C# or C++

In terms of an interface or thin client, an internet browser will never compete with a native application of the OS in terms of bells and whistles. wpf and .net 3.5's 3D graphics and native access to DirectX is a good sell and has no competitor right now if you ask me. In conclusion Microsoft still has a strong and prodomenant grip on the desktop user which is the majority itself. 2D front end applications are not the future.
 
Thin client apps not the future? Hmmmm tell that to companies like Salesforce. Tell that to Microsoft, which is pushing the daylights out of Silverlight.

Most programming is done within companies; it isn't shrinkwrap. Web applications have the ability to push out updates and keep everyone on the same version instantaneously, and for a lot of companies this fact immediately trumps having the bells and whistles of a shrinkwrap application. Besides, browser clients are catching up awful fast on the interface front.
 
"Web applications have the ability to push out updates and keep everyone on the same version instantaneously, and for a lot of companies this fact immediately trumps having the bells and whistles of a shrinkwrap application."

You could have a java swing based thick client with all the bells and whistles. Employ webstart and pushing updates auto-magically becomes quite simple.

I have worked on a handful of high volume trading applications and have seen C#/Swing/SWT on the front end; C++ based price/analytics providers and Java as the "controller"!

I think each of the aforementioned languages has a role to play and really don't foresee any one vanquishing all others!
 
Thin client apps not the future?
As my picture shows, I'm old. Thin clients come, they go. Fat clients come & go as well.
Distributed apps wax and wane, the number of tiers in the architecture grows and shrinks.

The "Network Computer", remember that ?
So crap Scott Adams devoted a good chunk of a Dilbert book about how thin clients were obviously the work of weasels.

My main computer is a fat client, really fat, so fat that the server software tripped a Bloomberg alarm that disabled their shit s/w because it thought I was running a server farm to steal their data.
That's worth knowing because both first and second line support will tell you that there's no reason BB terminal won't work on Windows Server 2003.
That's bad, of course, normal people don't have three versions of Excel, 2 of Visual Studio, VMWare, or rig the graphics cards to do fast floating point :)
It's entirely unsupportable, and if I cost my time properly, it would need replacing about every 6 days. But I'd have it no other way.

At any point the current trend is the result of 3 1/2 main factors.
1. Communication speed vs processor speed.
Sometimes things are best done in a fat client because shipping the data to the server is hard.
Sometimes the data is too big to ship to the client so we have thin clients, fat servers.

2. Style of development. If you want stuff that runs 24/7, you have thin clients, but you're going to have to agree with everyone else what it does. Tactical development is harder with centralised systems, that's why we have Excel doing stuff that it is absurdly unsuited for.

3. Politics
When I first wrote code there was no such thing as a personal computer, everything was centralised. In 1986 I saw a change request form. It was to change a spreadsheet. Not as you might think to install a new version, no, to change some cells. Centralisation had meant that everything was locked down. A lot of development is done by quant/front office teams because now that we are in May, any request for a change is unlikely to come about this year.
But central systems can be more cost effective and secure.

The half factor is the perception by developers of what is cool and will look good on their CVs. I wrote an editorial on Java in the mid 1990s for PC Magazine that talked of the "career advantages" of Java. This whilst I was editing the C++ review...

That was true for the techie audience I addressed, and is true for non-quants even

Tell that to Microsoft, which is pushing the daylights out of Silverlight.
Actually I was talking to a senior Microsoftie a few days ago about this. Silverlight is indeed being pushed hard, partly because it needs pushing. The suck is not great.

This sort of stuff is again en example of the ebb and flow as the ratios of the vectors change.
Games are becoming thin client, as is music as firms like Apple, Amazon, and Microsoft, and EA games try to protect intellectual property. The "pushing updates" sounds good until you find Adobe or Microsoft have turned off the server that permissions you to use it.

If you think your central IT would not do such a thing, look at the interview with me above, I've been a CIO and quant developer in the trenches, and it can and will happen.
 
I came neither to praise fat clients nor bury them. I just wanted to point out that it is usually IT management considerations, not technical ones, that indicate whether you use a fat or thin client.

That being said, I work for an ASP so perhaps I'm biased. Also, this subject is a bit academic on a quant site; I doubt anybody working for front desk even thinks of thin client apps.

Dominic, thanks for the tidbit on Silverlight. Sort of what we suspected at our company - Microsoft trying to horn in on a growth area for Adobe - but we're evaluating it anyway. The reason I even brought up silverlight was because it gives web applications a way to simulate the fancy 3D bells and whistles that are associated with fat clients.
 
I have a couple of questions regarding C++ for Dominic. I took a course in C while I was in college (among top 5 in US). After I graduated from college, I learnt C++ on my own in my free time by reading books on C++ and working out the assignment problems for the indroductory C++ course offered by my college (all the lecture note and assignments for this class was publicly available). Firstly, do employers prefer new hires to have a knowledge of introductory level C++ at the minimum or do you think they prefer a fairly advanced knowledge of C++?. Secondly, do you think I need to take a class to prove that i know C++?. Thank you.
 
I have a couple of questions regarding C++ for Dominic. I took a course in C while I was in college (among top 5 in US). After I graduated from college, I learnt C++ on my own in my free time by reading books on C++ and working out the assignment problems for the indroductory C++ course offered by my college (all the lecture note and assignments for this class was publicly available). Firstly, do employers prefer new hires to have a knowledge of introductory level C++ at the minimum or do you think they prefer a fairly advanced knowledge of C++?. Secondly, do you think I need to take a class to prove that i know C++?. Thank you.

As long as you can answer questions about C++ in the interview and you can prove that you know C++, you will be ok.

The fact that you took a C class in a university that you deem top 5 doesn't mean anything. John Carmack dropped out of college and he is considered one of the best programmers in C++ in the world. If you don't know who John Carmack is, check Wikipedia. If you have ever played a computer game, you probably has seen his work.
 
It seems you have a good knowledge of C++, but I wonder if you have yet built the equlivalent ability to drive it ?
I think you're most of the way to where you need to be to get past interviews, except for having worked on larger, more buggy lumps of other people's code.
 
Gentlemen,


Please see attached link;

Slashdot | Microsoft Prefers Flash To Silverlight

My argument is no matter how good the "thin client" gets. AJAX 10.0 or whatever, it will not beat what a native application can do on an Desktop OS where Microsoft Windows is dominate and they will fight for it to be so. Java SWING interfaces are hobbile compared to a .net interface.

Kind Regards,



AOGLOBALENT
 
I don't think people here care about what somebody posts on Slashdot. I remember I used to read that side in the 90s. Also, what is "hobbile"? I couldn't figure out what you meant by that.

On the other hand, I don't care about the interface as long as it gives me the answer I'm looking for. The discussion about thin clients, fat clients, middle of the road interfaces seems more suited for a Software development forum, not a Quant forum.
 
Back
Top