Or maybe, to be frank, perhaps not a lisp question at all. So delete this if you are busy.
However...from the two meetings of the Toronto lisp group I have attended, I gather that several of you do web development, or related stuff. So some of you are probably knowledgeable in areas that are a mystery to me.
I made it CASCON today and enjoyed the session on "Practical Ontology Infrastructure". Of course, this topic has plenty of connections to things that may interest the lisp community. But that topic is not the source of my questions, or rather my bafflement.
Over the past ten years I have often been utterly flummoxed and not a little annoyed when I try to grasp what is going on in the "business world" of computing. At CASCON this week many of the sessions were about SOA (Service Oriented Architecture). The notion of SOA came to my attention some time ago, but although I looked it up on wikipedia and even read some commercial blurbs on it, I still have no damned idea what they are talking about. I enjoy learning things that seem like "computer science." But I cannot for the life of me penetrate this combined computing and business stuff.
From my limited, jaded, and admittedly dated perspective, it seems we are subjected to a never-ending succession of questionable panaceas, cooked up - maybe - by marketing people. The ones that are about computing over the internet seem particularly offensively squishy to me.
Would anybody be willing to fill me in, perhaps not on the mailing list if it is too off-topic? LIke, as I struggle to learn lisp and such, should I really pay attention to "software as a service", "service oriented architecture", and so on ad infinitum?
Or should I just grow old and die of gum disease and varicose veins. F**k.
- Dave -
My understanding is that the people who know what the business has to do are not the developers and can't talk to the developers or refuse to talk to the developers. Instead developers keep trying to make tools for these business analysts to formalize the processes they understand.
Unfortunately BAs aren't programmers so any attempt at formalization always comes off as some hard to use tool for BAs or an oversimplication for developers.
Many of SOA people hope they can just compose services with a high level script and get on with business but too often they run into lame little cases where they need some scripting in the middle anyways or the service doesn't do as much as they need.
At least with SOA you have people defining interfaces which are more stable than those defined in Java.
I wouldn't worry about SOA, think of it as the commandline, except as services and servers instead of commandline programs.
Healthy doses of skepticism are to your advantage ;)
abram
David Penton wrote:
Or maybe, to be frank, perhaps not a lisp question at all. So delete this if you are busy.
However...from the two meetings of the Toronto lisp group I have attended, I gather that several of you do web development, or related stuff. So some of you are probably knowledgeable in areas that are a mystery to me.
I made it CASCON today and enjoyed the session on "Practical Ontology Infrastructure". Of course, this topic has plenty of connections to things that may interest the lisp community. But that topic is not the source of my questions, or rather my bafflement.
Over the past ten years I have often been utterly flummoxed and not a little annoyed when I try to grasp what is going on in the "business world" of computing. At CASCON this week many of the sessions were about SOA (Service Oriented Architecture). The notion of SOA came to my attention some time ago, but although I looked it up on wikipedia and even read some commercial blurbs on it, I still have no damned idea what they are talking about. I enjoy learning things that seem like "computer science." But I cannot for the life of me penetrate this combined computing and business stuff.
From my limited, jaded, and admittedly dated perspective, it seems we are subjected to a never-ending succession of questionable panaceas, cooked up - maybe - by marketing people. The ones that are about computing over the internet seem particularly offensively squishy to me.
Would anybody be willing to fill me in, perhaps not on the mailing list if it is too off-topic? LIke, as I struggle to learn lisp and such, should I really pay attention to "software as a service", "service oriented architecture", and so on ad infinitum?
Or should I just grow old and die of gum disease and varicose veins. F**k.
- Dave -
toronto-lisp mailing list toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
Thanks for those answers, Justin and Abram. I shall try to stop fretting about terms such as SOA.
I have a long personal history of being on the boundary between the business world and the computer science world. Probably I have done neither very well, but in any case it has led me be a bit schizoid (figuratively speaking) about such things.
Thanks again.
On 2009-11-04, at 10:05 PM, David Penton wrote:
Or maybe, to be frank, perhaps not a lisp question at all. So delete this if you are busy.
<etc...>
Maybe it's because I've been heavy into Dijkstra lately, but "business computing" is fundamentally flawed and fashion-driven and really isn't worth understanding. As Dijkstra said, businesses purposefully try to complicate things and keep their work secret in order to profit.
If you strip away the bullshit, it's easy to understand and useful. However, that would make it *too* easy to understand and accessible and lots of IBM salespeople would be out of jobs! Bullshit keeps the economy afloat I'm afraid :-P
You should grow a beard and turn into Dijkstra or Knuth or Stallman instead :-D -Rudolf
At least business computing is about meaning. They don't care that there is a computer there, they simply want process followed and these objects or symbols manipulated.
It is actually very abstract in many cases and it is often grounded in being actually useful to the customer who employs it.
That said, you should stay skeptical ;)
abram
Rudolf Olah wrote:
Maybe it's because I've been heavy into Dijkstra lately, but "business computing" is fundamentally flawed and fashion-driven and really isn't worth understanding. As Dijkstra said, businesses purposefully try to complicate things and keep their work secret in order to profit.
If you strip away the bullshit, it's easy to understand and useful. However, that would make it *too* easy to understand and accessible and lots of IBM salespeople would be out of jobs! Bullshit keeps the economy afloat I'm afraid :-P
You should grow a beard and turn into Dijkstra or Knuth or Stallman instead :-D -Rudolf
toronto-lisp mailing list toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
Here's a long rant. I loved writing this. It was cathartic, and I just couldn't stop myself. I hope it doesn't annoy anyone toooo much.
I guess my own background has resulted in some antipathy to the business computing culture. Before going to law school, and then again recently, I did application development for organizations whose main line of work was not software development. I did so for perhaps twenty client organizations the petroleum industry and then later in law- related fields
There are aspects of the culture in such settings that are hard to take. For as long as I worked in that environment, the source of the nastiness was usually the central IT department, which went by various names such as "Data Processing", "Computer Department", etc. These folks had certain convictions that were, to them, beyond challenge. There was/is some validity to their view, but they took it too far. A rough catalog of a few of their notions might include:
(1) Existing tools (meaning s/w and h/w already available in our organization) are adequate for all computing-related purposes. Such tools should always be centralized, never distributed. Innovations make it too hard to administer our data centre. (2) There are no hard programming problems. Everything boils down do getting requirements from users correctly. (3) The current flavour of the month s/w development methodology will solve all your problems related to (2) above. (4) Computer-science guys are a problem. Soon automated methods will make those geeks obsolete.
To blather on a bit more I'll give an example of the absurdities these views created in one project I worked on..
In the late 1980s I worked on an engineering problem that boiled down to (a) a gas pipeline network design problem with an interactive aspect, and (b) solving a large sparse system of nonlinear de's to test optimality of the network design.
The IT department had a huge IBM mainframe. They ran ADABAS and NATURAL (business, meaning commerce tools; look up Software AG in the web). They flatly refused to accept my recommendation that we use (the then emerging) graphic workstations to do the interactive network design. They insisted that we could use their dumb IBM 3270 terminals hooked up to the mainframe. (These clunkers will be as unfamiliar to younger guys as vacuum tube computers. They were about that obsolete even at the time.) They also insisted that all data modelling, storage and retrieval use inverted-list database technology (ADABAS). And not just for persistence, but for run-time modelling of what were inherently graph structures. They insisted on that because db technology was what they had and understood. They could not conceive of the existence of problems that "business software" could not solve.
The IT/Business guys also insisted that we derive solutions directly from the output of the mandated s/w methodology. This methodology was perhaps suitable for setting up, say, an accounting system in which the domain experts could tell developers more or less how to write the software using "business rules."
The problem was, the domain experts in this case were engineers who did not know what the solution to the problem was. They fully expected those of us on the project team to research, find, adapt or invent algorithms and techniques to solve the problem. Their expression of "business rules" was no more than a statement of hoped-for outcomes.
This led to a year-long series of meetings run by one senior consultant (who bought into the methodology thing) in which she repeatedly interviewed groups of engineers. She repeatedly asked them "what software do you want us to write?" (These were "JAD" or joint application development sessions according to the methodology.) The engineers would sketch out the expected results, but when she went back to her office she had no idea what to do next.
After 18 months I quit because I could not take it any longer. The project never produced a damned thing, as far as I know.
Here is the paradigm in that culture:
BUSINESS RULES ==> {a miraculous non-human-mediated transformation occurs} ==> A GREAT SYSTEM
Right.
So, I despise that culture. Now that I'm on a roll, I'll say that I hate the word "business" in a lot of ways.
More than anything I HATE the assumption that any and all important activities in the world are a form of "business." Government, so neo- liberals say, should be run like a business. The real world is about "business." Universities are now businesses, run by administrators who pimp their institutions out to the "business community." Children's soccer teams, amateur string orchestras, photography clubs, churches, community centres, EVERYTHING should be run "like a business."
Well, fuck that, I say. Down with market capitalism! Death to Microsoft! Long live the revolution! To the barricades, comrades! Aaaarrrgh....
Whew. Now I'll eat some junk food.
- Dave -
On 2009-11-08, at 11:56 AM, Abram Hindle wrote:
At least business computing is about meaning. They don't care that there is a computer there, they simply want process followed and these objects or symbols manipulated.
It is actually very abstract in many cases and it is often grounded in being actually useful to the customer who employs it.
That said, you should stay skeptical ;)
abram
Rudolf Olah wrote:
Maybe it's because I've been heavy into Dijkstra lately, but "business computing" is fundamentally flawed and fashion-driven and really isn't worth understanding. As Dijkstra said, businesses purposefully try to complicate things and keep their work secret in order to profit.
If you strip away the bullshit, it's easy to understand and useful. However, that would make it *too* easy to understand and accessible and lots of IBM salespeople would be out of jobs! Bullshit keeps the economy afloat I'm afraid :-P
You should grow a beard and turn into Dijkstra or Knuth or Stallman instead :-D -Rudolf
toronto-lisp mailing list toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
toronto-lisp mailing list toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
Hilarious. I definitely see parallels to this where I work.
BC
From: David Penton [mailto:djp@arqux.com] Sent: Sunday, November 08, 2009 9:46 PM To: toronto lisp Subject: Re: [toronto-lisp] A Not Strictly Lisp Question
Here's a long rant. I loved writing this. It was cathartic, and I just couldn't stop myself. I hope it doesn't annoy anyone toooo much.
I guess my own background has resulted in some antipathy to the business computing culture. Before going to law school, and then again recently, I did application development for organizations whose main line of work was not software development. I did so for perhaps twenty client organizations the petroleum industry and then later in law-related fields
There are aspects of the culture in such settings that are hard to take. For as long as I worked in that environment, the source of the nastiness was usually the central IT department, which went by various names such as "Data Processing", "Computer Department", etc. These folks had certain convictions that were, to them, beyond challenge. There was/is some validity to their view, but they took it too far. A rough catalog of a few of their notions might include:
(1) Existing tools (meaning s/w and h/w already available in our organization) are adequate for all computing-related purposes. Such tools should always be centralized, never distributed. Innovations make it too hard to administer our data centre. (2) There are no hard programming problems. Everything boils down do getting requirements from users correctly. (3) The current flavour of the month s/w development methodology will solve all your problems related to (2) above. (4) Computer-science guys are a problem. Soon automated methods will make those geeks obsolete.
To blather on a bit more I'll give an example of the absurdities these views created in one project I worked on..
In the late 1980s I worked on an engineering problem that boiled down to (a) a gas pipeline network design problem with an interactive aspect, and (b) solving a large sparse system of nonlinear de's to test optimality of the network design.
The IT department had a huge IBM mainframe. They ran ADABAS and NATURAL (business, meaning commerce tools; look up Software AG in the web). They flatly refused to accept my recommendation that we use (the then emerging) graphic workstations to do the interactive network design. They insisted that we could use their dumb IBM 3270 terminals hooked up to the mainframe. (These clunkers will be as unfamiliar to younger guys as vacuum tube computers. They were about that obsolete even at the time.) They also insisted that all data modelling, storage and retrieval use inverted-list database technology (ADABAS). And not just for persistence, but for run-time modelling of what were inherently graph structures. They insisted on that because db technology was what they had and understood. They could not conceive of the existence of problems that "business software" could not solve.
The IT/Business guys also insisted that we derive solutions directly from the output of the mandated s/w methodology. This methodology was perhaps suitable for setting up, say, an accounting system in which the domain experts could tell developers more or less how to write the software using "business rules."
The problem was, the domain experts in this case were engineers who did not know what the solution to the problem was. They fully expected those of us on the project team to research, find, adapt or invent algorithms and techniques to solve the problem. Their expression of "business rules" was no more than a statement of hoped-for outcomes.
This led to a year-long series of meetings run by one senior consultant (who bought into the methodology thing) in which she repeatedly interviewed groups of engineers. She repeatedly asked them "what software do you want us to write?" (These were "JAD" or joint application development sessions according to the methodology.) The engineers would sketch out the expected results, but when she went back to her office she had no idea what to do next.
After 18 months I quit because I could not take it any longer. The project never produced a damned thing, as far as I know.
Here is the paradigm in that culture:
BUSINESS RULES ==> {a miraculous non-human-mediated transformation occurs} ==> A GREAT SYSTEM
Right.
So, I despise that culture. Now that I'm on a roll, I'll say that I hate the word "business" in a lot of ways.
More than anything I HATE the assumption that any and all important activities in the world are a form of "business." Government, so neo-liberals say, should be run like a business. The real world is about "business." Universities are now businesses, run by administrators who pimp their institutions out to the "business community." Children's soccer teams, amateur string orchestras, photography clubs, churches, community centres, EVERYTHING should be run "like a business."
Well, fuck that, I say. Down with market capitalism! Death to Microsoft! Long live the revolution! To the barricades, comrades! Aaaarrrgh....
Whew. Now I'll eat some junk food.
- Dave -
On 2009-11-08, at 11:56 AM, Abram Hindle wrote:
At least business computing is about meaning. They don't care that there is a computer there, they simply want process followed and these objects or symbols manipulated.
It is actually very abstract in many cases and it is often grounded in being actually useful to the customer who employs it.
That said, you should stay skeptical ;)
abram
Rudolf Olah wrote:
Maybe it's because I've been heavy into Dijkstra lately, but "business computing" is fundamentally flawed and fashion-driven and really isn't worth understanding. As Dijkstra said, businesses purposefully try to complicate things and keep their work secret in order to profit.
If you strip away the bullshit, it's easy to understand and useful. However, that would make it *too* easy to understand and accessible and lots of IBM salespeople would be out of jobs! Bullshit keeps the economy afloat I'm afraid :-P
You should grow a beard and turn into Dijkstra or Knuth or Stallman instead :-D -Rudolf
_______________________________________________ toronto-lisp mailing list toronto-lisp@common-lisp.netmailto:toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
_______________________________________________ toronto-lisp mailing list toronto-lisp@common-lisp.netmailto:toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
-
Abram Hindle -
Brian Connoy -
David Penton -
Rudolf Olah