Agreed on the value of data structures

Post #10,693 by ben_tilly 9/27/01 6:15:45 PM Reply	Agreed on the value of data structures First of all a nit on the code generation. Compilers generate code. Do you think we should get rid of compilers...? Now to the main point. I absolutely have to agree with you on the value of keeping a complete data structure. Particularly when working with financial analysts. Show an analyst your code and they look helpless. Give them an argument they can add to get a pretty-printed debugging dump of your data structure where the variables have reasonable names, and they are pretty good at figuring out what the dump means and figuring out which calculation you are doing wrong. I have found this to be true even when they aren't programmers and don't understand the programming language. Similarly I have had good luck presenting non-programmers with configuration files that are just pretty-printed data structures. Trivial to process internally. Readily understandable. This is an important point. You cannot depend on finding the domain expertise and the programming expertise in the same person. So any tool that the programming person can use which makes it easier for the domain expert to give direct feedback is good. So if you have tools that you think do this, then use them. Cheers, Ben
Post #10,717 by admin 9/27/01 9:32:32 PM Reply	Yes, that is a nit. Because I think you damn well know what I was talking about. ;-) When you compile a bit of C code, and there is an error, you find out where the error was in the source code. You don't have to trace back from the machine code to the source code to try and figure out where that bit of machine code came from. Yes, the fact that this can be traced back (or not) is the fault of the compiler, but by the time we see native JSP->java byte code compilers, I will consider the problem to be solved. The problem is that the compiler is generating more of the same code, not a level down. I completely agree on the semantic value of the data structure, and since I'm likely going to need to have bond experts debug some of the calculations and so forth, I'd definitely prefer to stick to the templates. Regards, -scott anderson
Post #10,731 by ben_tilly 9/28/01 12:06:09 AM Reply	Well... As you know better than I, assembly programmers complained for ages about the horrible code generated by compilers. It is the same issue. People and machine-generated code don't tend to be friends. And agreed on your point about code being at the same level, personally when I autogenerate code, I make sure that it is as easy to trace back as possible and as robust as I can make it. The level of abstraction arising from autogeneration is enough without confusing issues by having to guess where this came from. Unfortunately not all people do the same... Finally, it is very odd to have you in a similar field to me. And yes. You are probably learning how much terminology there are in bonds. And every kind of bond has even more terminology... Cheers, Ben
Post #10,763 by admin 9/28/01 9:02:07 AM Reply	Bond terminology... Yes, that part is a bit overwhelming at times. They have a running weekly bond seminar here in the conference room, however, which helps. And a sense of humor: the announcement yesterday went something like: "Attention, K-Mart shoppers! For your listening pleasure, Tom will be conducting this week's Bonds 101 at 2PM on the wild and fabulous subject of Callable Certificate of Deposit Issues!" Regards, -scott anderson
Post #10,860 by ben_tilly 9/28/01 9:27:29 PM Reply	Bonds show the problem of XML The great dream of XML is interchangable data formats that are readily understood. But the sheer number of terms, special cases, fields, fields used different ways by different people, etc, etc, etc in the bond markets make the data structure quickly impenetrable. Consider. Money starts as interest on a loan, turns into the loan's coupon, and then morphs into the wac (weighted average coupon) over the bond. And that is just one field. Every field is like that. It only gets worse when the field is, say, a status code and one vendor is unreliable about populating it while another is very reliable but invents new status codes. And you are supposed to show this to people? BTW what is scary is what I have picked up through osmosis. For instance your title makes perfect sense to me. A certificate of deposit is something you can put your money into for a fixed time at a guaranteed interest rate. A call on a financial instrument means that someone else has the right to buy it from you at any time under some negotiated rate. A callable CD is therefore a CD which someone (usually the issuer) can buy back at any time. So I would guess that you were hearing about callable CDs, how to price them (price the bond and then the call, pricing the call requires Black-Scholes), and possibly you talked some about what the call does to the hedging characteristics of the bond. Stuff that you need to know because your software is going to be used to make buy and sell decisions... Cheers, Ben
Post #10,905 by wharris2 9/29/01 10:52:08 AM Reply	Amen. XML as pipe dream Who knows how empty the sky is In the place of a fallen tower. Who knows how quiet it is in the home Where a son has not returned. -- Anna Akhmatova (1889-1966)
Post #10,787 by tseliot 9/28/01 11:50:56 AM Reply	My nit. I completely agree on the semantic value of the data structure, and since I'm likely going to need to have bond experts debug some of the calculations and so forth, I'd definitely prefer to stick to the templates. Can you give an example of what you mean? I can't (or won't ;) conceive of such a system, where critical business logic gets put anywhere near the templates (IOW, the M/V/C is getting a bit muddled for my liking). Shouldn't you be using a Proxy or Iterator (or something) to achieve cleaner separation? That's her, officer! That's the woman that programmed me for evil!
Post #10,788 by admin 9/28/01 11:55:16 AM Reply	Picture if you will... The entire system as it stands is built in Oracle stored procedures using mod_plsql and catenating the output using htp.p(). I need to fix that. As a result, I want to completely disallow any calculations being done in the output system as it is. However, I am going to need to have people verify that what came from the back end is actually being displayed properly on the front end, hence the business experts. Regards, -scott anderson
Post #10,790 by tseliot 9/28/01 12:02:53 PM Reply	Wow you really do sit around and watch this forum all day :P The entire system as it stands is built in Oracle stored procedures using mod_plsql and catenating the output using htp.p(). >>shudder<< But, hey, the great thing about the Dark Ages was coming out of them, right? More power to ya. That's her, officer! That's the woman that programmed me for evil!
Post #10,816 by admin 9/28/01 2:00:22 PM Reply	You know it. Dark ages... more like BC. The scary thing is that there are a number of people who have to be convinced of the usefulness of separation of business from presentation. Regards, -scott anderson
Post #10,819 by Fearless Freep 9/28/01 2:03:24 PM Reply	Scary thing... ..is that there are still a number of people who have to be convinced... Jay O'Connor "Going places unmapped to do things unplanned to people unsuspecting"
Post #10,820 by admin 9/28/01 2:10:03 PM Reply	Yeap. But, it's what they know. Keep in mind that this application started as an Oracle app, written by PL/SQL programmers with HTML handbooks. They did a helluva lot of good stuff with it, but the architecture is going to start (actually, continue in some instances) breaking here soon. Regards, -scott anderson

Welcome to IWETHEY!