Monday, January 23, 2006 - Posts
Adam over at Emergent Chaos (the Jazz Edition), has a good piece on recent breaches and the attention both in the media and with law enforcement that this has received.
I have left comments there, but essentially, I agree with Adam. I think that it is difficult to protect a customer's interests in this setting. While it may seem impersonal, my view originates in captitalism and the simple notion that profitability of a corporate entity has not been affected by these types of breaches in a widespread manner. That is not to say that there have not been incidents that have caused corporate failure, but rather that this issue is just one of many that a management team must face when operating a company.
I wrote (in his comments):
4. In the absence of any penalty to shareholder value, the management team and their reputations and ability to run a profitable bank will view other issues above these.
and
I think that the above issues have damaging consequences for any firm as they make it difficult to identify security problems that have long-term and durable impact on profitability. While the beginning effects appear negligible on the bottom line (or top line revenue, for that matter), the ability to identify and address these issues will require that more firms fail through their share prices as opposed to pressures from the security community and regulatory agencies. And NO, I'm not stating that there isn't net impact by the security community, but rather stating that the security community represents a leading indicator of the "opportunity for lost revenue and earnings". Like many leading and lagging indicators, the value of the indicator is only useful if it provides a pertinent horizon for profit.
Adam's response to my comments is forthcoming, but I think his original piece is worth a read. Good coverage of difficult topics over there, as always.
Updated to add: Adam's follow up, "On Disclosure" is here.
Wow, I have to admit that there is so much to learn on so many fronts. Sahil mentions the newest .NET technologies here and wonders both how much time is needed to work to learn these. The comments are useful as well (yeah, I'm in there in a few spots).
But I'm really getting jazzed on a few other works as well. I read Lambda the Ultimate - Programming Languages Weblog, and quite frankly, I have a difficult time keeping up with many of the works here. I have some depth in maths and logics, but there is a great deal of work by very bright people that is listed here.
Two posts, Haskell is not not ML and Haskell vs. Erlang, Reloaded, caught my attention.
Haskell is not not ML
I'm still not not done with this article. My first take-away from this is that there can be a "peaceful" co-existence with an eager language (ML) and a lazy language (Haskell) through an IL (hmmmmm). I really want to jump into a parenting analogy where one parent is strict and the other, not so strict, but, I'll refrain for the moment. I'm linking this article, because it has implications that remove some of the tendencies that can arise in the comparison of these (and other similar) languages. The authors are clear to specify that they are not going to attempt to unify these two approches, i.e. strict and non-strict, in the paper, but rather to discuss the manner in which such a language could be constructed.
Haskell vs. Erlang, Reloaded
This article has a bit of depth to it as well. I cannot give a qualified analysis of this article as of yet (or ever), but what did catch my eye is the link to LexiFi in Section 5. LexiFi is a Financial Engineering product that was written in OCaml, an ancestor of F#. While this article is lopsided in favor of Erlang over Haskell, it is clear to me that there is significant bias in the author's perspective, and therefore I tend to agree with the LtU opinion of this post (and some of the comments), i.e. both Haskell and Erlang have merit and are outstanding functional programming languages with different target domains, a fact that was muddied in the article.
And a little bit of that Quantum Computing
Also, I'm reading The Quantum Pontiff's series on Quantum Computing (starting here; I'll not link all posts). That this series is from a course taught at the University of Washington and that the materials are publicly available and transparent, i.e. available to a non-UW-student like me, reminds me of how much better our society is today than even 20 years ago. There are so many professors, academics, principal researchers and other professionals that provide their materials and insights. My appreciation is extended to Dr. Dave Bacon for his work to produce and distribute this.
The series (as of this writing) has just completed Simon's Algorithm (and Problem) and promises to get to factoring in Quantum Computing. From my readings and from what I am aware of in this field, this series is approachable, and has good coverage of many topics. Check the syllabus for useful resources, and in particular, Nielsen and Chuang's Quantum Computation and Quantum Information (on my list to buy; I can't read everything at once).
Well, life has been a bit easier lately. The Liz is behaving herself. She makes it easy to be a Dad. She had a four day weekend off from school which she spent almost exclusively in her room. She's been sick and would probably would rather be out with friends. But she is focused on what matters. When she is focused, it frees up my time to be focused. Good girl and I love you for it Liz.
On that note, I'm presenting at the Wisconsin INETA meeting. The official presentation announcement was just posted. My presentation is on February 21st, 2006 and is titled publicly as:
An Introduction to F#
The official working title is:
F# - An Introduction under the Application of Quantitative Finance
I didn't want that posted on the INETA web site for fear that no one would show up. Seriously, this will be a fun session. This is my first presentation at Wisconsin INETA, my first public speaking on F# (see my blogroll for useful F# links) and my first public presentation in about six years. I'm not nervous, just excited. I tend to talk very quickly, so the usual comments that I hear from my friends and colleagues is "You are going to have to talk slower." That is not possible. Of course, I'm presenting during the same month as Don Haleyione, the Godfather of Interesting Finds, just in a different city. Those Beantown guys are going to get a dose of Debris and practical dissassembly. Nice.
((marketing hat on; warning, imprecise language in use))
If you are interested in investing in stocks, I'll be covering a few simple techniques to measure characteristics of those stocks. We'll build a few applications that use publicly available data from the major sources like finance.yahoo.com and others. I hope that anyone in attendance will get a flavor of F# and it's capabilities within the .NET framework as well as a perspective for some of the basic ideas used in quantitative finance (finance by the numbers). The target audience is the .NET developer and not the capital markets professional, so the ideas in finance are straightforward and simple to implement.
The part about this that has me excited is the use of F# to do this work. I've been using F# now since last summer (again, thanks to Marty for the pointer). Because F# is based on ML and OCaml, it was not unfamiliar to me, i.e. I had some competence in the language, but needed to improve my skills. That is still true now, but I've at least had the opportunity to build some real world stuff in F#. To me, F# represents the first core competence platform under .NET for scientific and engineering based computing that is (or may be) mathematics intensive.
I invite you to come and spend some time at this meeting. I hope that I can give some basic ideas on F# and it's usage, some basic ideas for the everyday .NET developer in finance and just have a lot of fun. In case you cannot decide whether to attend or not, I will mention that there will be free pizza and soda. How can you pass up an offer like that?
---
As always, contact me here.
Copyright (c), JJB Research. All Rights Reserved.