Thank you for your wonderfully unconsidered response.
As it happens, the issue of an appropriate server with acceptable interface had been considered prior to my suggestion. Even back in 94 it was not hard to find a network-connected x86 PC. In any case - yes... I would have been able to supply a configured server as well if that was necessary!
A USB key drive would have been 'oh-so-useful' three years before the interface was first included with mass produced equipment (on PC motherboards in 1997) and even longer before drivers were widely available for operating systems. Today this may be more useful, though data stored on such a deveice would not easily be shared. Ambitious modern projects would probably benefit from even more space today.
The case against usefully available space was the financial cost of fully managed disk-space. Cheap hardware addresses this problem at the expense of reduced reliability. If this reduced reliability is acceptable (which it was in the case I described - and I suggest many others too) then it becomes a reasonable proposition.
Your retarded attitude that other users' data is "shit" only goes to show your ignorance.
Your arrogant attitude is further exposed as you suggest this was an "individual one-off" request... as it happens it was a collaborative suggestion proposed by a number of students with similar needs.
I'm pleased to hear that the 'two tier' system I suggested back in '94 is now (a decade on) considered worthy of your consideration. To address your concerns (or are they excuses to procrastinate) I can offer the following observations:
The fact that you have a large number of users simply exaggerates the potential savings.
There are many ways to implement this sort of solution - these days the most obvious would be to buy cheap PC hardware, configure it offline and then simply connect it to your Ethernet. A Terabyte scale Linux PC, say, is likely significantly cheaper than upgrading your main server and there would be no issue of down-time. It would also be interesting to factor in the administrative time savings for quotas expected from the more flexible storage provision.... This would have been considerable back in 1994, and would probably be noteworthy today.
Stupid bureaucratic decisions should be politely challenged. A well-argued cost saving would likely make the case to policy makers that only the default storage would need frequent back up, whereas some other clearly labelled - say "NoBakcup" - storage need not.
"Educating" users should be a relatively simple task and often brings benefits of its own - it certainly would have been in my scenario... the users who required abnormally high quotas all understood what they were doing... so this would have been a non-issue. It sounds to me as if you need to clearly ascertain the requirements of your users then strive to meet them.
While I realise that making decisions is likely outside your support-role, I think it would be important to remember that the core responsibility of IT support is to support the needs of the users. Depending upon circumstances the approach will vary dramatically. A good IT department will continually assess the needs of the users and aim to meet all these requirements in the most cost effective manner. If your users are frequently complaining about inadequate provision for on-line storage then there is a problem which needs to be redressed in the most appropriate way to support primary objectives of your organisation.
I believe that an email service from a company like google has massive potential. I would happily pay a reasonable sum (say 30 per year) to use google to manage my email assuming they meet my requirements. I think google could effectively eliminate spam by sharing signatures of mass-mailings among its huge user base which would more than justify my expense.
In order to be useful to me, google would need to offer IMAP access; support forwarding of email from users' own domains; support secure access both over the web (https) and preferably with IMAP/SSL too. I'd like to see it collect email from obsolete pop3 accounts (especially if spam elimination works) and I'd pay a premium to be able to easily generate SMS alerts when email matching user-defined criteria are received.
Finally - assuming Google can effectively eliminate spam, and can offer me an email service sufficiently flexible to meet my needs, then I, for one, would be pleased to receive a daily (clearly labelled) series of text-based targeted adverts based upon keywords in the email I've received. If I want my email to be private I should be using encryption anyway - I can only see this as a win-win situation... if Google wants my business I'm sure it already knows what to do!
Hmm... I guess I might be thought somewhat maverick here - but because a user is not a programmer this does not correlate with the view that the interface should be restrictive and illogical. Any numerate person will understand the distinction between integers and natural (counting) numbers. What I find far more difficult to explain is why "Example" + 5 + 3.14159 + 5_Sep_2003 = 37877.14159... which, I would suspect, most users of spreadsheets would find a confusing nonsense. By expanding the range of types which spreadsheets support we can seriously improve the ability of applications developers to define restrictive bespoke templates which reduce the risk of inadvertent error. By supplying a rich domain specific type system with a familiar tabular interface, we can reduce end-user confusion and expand the range of problems which can be realistically addressed in a spreadsheet paradigm. Sadly, it seems this hasn't happened yet.
I think it a big red herring to claim that because spreadsheets are frequently used to solve simple problems that design flaws in features not necessary for such trivial applications should be ignored.
Ten years ago I was the student being given grief about insisting I retain my 30-40Mb account. I moaned that for a couple of hundred quid (for this was the UK) I could buy a 1GB disk - which I would happily share with the other students wanting the larger quota... and I was faced with the same unreasonable brick-wall response.
While it is obvious that fully supported, highly reliable, frequently and automatically backed up storage is damned expensive, this misses the point somewhat. Most users with significant storage requirements don't need all of their data to be managed so rigorously. For myself, I wanted about 15Mb of reference material (which wouldn't change - hence would not require frequent backups); 10Mb of 'most recently built data' which given a few hours I could re-generate from source - and 5Mb of 'My-god-guard-this-with-your-life-important--my-on ly-copy data.'
I maintained that to minimise the cost of storage that users should, by-default, use a small quota 'ultra-reliable' space, but also have access to a private scratch space which would behave similarly but would not burden the organisation with backups and would utilise the cheapest hardware - even if that would not be the most reliable. BTW - the suggestion was never implemented and my "expensive" quota was simply increased.
Nincompoops failing to understand the implications of their models aside, I still feel that modern spreadsheets are desperately lacking. I can see several obvious ways in which support for richer data types would make spreadsheets more useful - though I agree that the article shows no evidence to back up their claim that such additional functionality would improve financial forecasts.
Spreadsheets have been and will always continue to be an extraordinarily powerful ad-hoc tool for those wishing to tabulate data with automated calculations. They are worse than useless if, for whatever reason, the user has no savvy approach to the problem at hand, or if the model which requires manipulation has no concrete representation.
After many years with little use for a spreadsheet (previously having used Supercalc and Lotus 123) I was shocked by corporate state of the art. Specifically, I was disturbed by the type system employed to represent cell values and by the way in which formatting settings can so easily obscure the values actually being processed. The way in which Excel handles dates seems particularly horrific... and OO-Spreadsheet just mimics the same mistakes. I was also amazed that modern spreadsheets haven't started to use extensible libraries to represent new data types. It seems a no-brainer for a spreadsheet to make use of pluggable C# or Java classes to allow domain specific types to be manipulated in the context of a spreadsheet environment. Am I missing something - or have we not only failed to advance the art (as suggested by the article) but actually taken several steps backwards?
I admit that I might be guilty of suggesting an oversimplified view of filter-design and control. You shouldn't, however, assume I mean that filter design is trivial or even that it might be less challenging than other software problems... far from it! All I want to suggest is that this is a restricted form of computation far more amenable to a graphical approach... It's clear we agree in principle: the techniques which work well for those working in DSP can't straightforwardly be applied to all fields. For example - would you even bother to try and implement quicksort in simulink? The sieve of Eratosthenes? A binary tree or linked list data structure? These problems usually have straightforward (even trivial) solutions in conventional textual programming languages. It is this kind of flexibility (at the cost of domain specific clarity) which I suspect has been difficult to retain in the graphical arena and will continue to be elusive.
Actually, there's no reason why you can't model processes in something that businesses understand and then get the tool to generate code (in fact, the model should be the code).
Welcome to the search for the holy-grail! Modelling processes is frequently a realistic and valuable activity right now - though (as I'm sure you're aware) this model is seldom executable. The catch 22 of your argument is that when your model is your code then, clearly, your code is also your model. Hence, if your model is your code, you've lost the advantage of presenting at a higher level of abstraction. Language design can learn a lot from modelling, but I think it is a mistake to assume that textual representation of programs will be obsolete in my lifetime.
I don't understand your argument that the growth of the PC (and with it fantastic improvements in price/performance) has anything to do with the failure of 4GL to dominate the software market. As I see it the real problem was the approaches which were taken for these tools either hindered or prevented the expression of a significant proportion of desirable programs. Your comment about "coding for performance" is interesting - I assume you refer to the use of lower-level toolsets - though I claim that programmers haven't moved back towards that model, but rather that they haven't left it behind as quickly as 4GL proponents anticipated. The fantastic improvements in available processing power over the last couple of decades, however, are no substitute for using an appropriate algorithm for the problem at hand... the real trouble with high-level tools is that they frequently haven't delivered on their promise to simplify development of the systems which are required by business.
BTW - if you are frittering away time with non-critical features while missing the fundamentals - it's time to hire a better analyst!:-)
Regarding Simulink et al... Absolutely... graphical approaches can be (and have been) extremely successful when working within a constrained domain. The interesting point about signal processing is the relative simplicity of the data structures involved (i.e. a single stream as both input and output) and the restricted computational model of even complex filters.
IMHO we will see more domain specific languages - yet this idea didn't seem to be the focus of the original article. If all programming in the future will be visual in nature then we must assume that either all useful algorithms will have been captured in some appropriate form for component-wise re-use in a graphical development environment, or that there will be a graphical language more convenient than a textual one to encode algorithms. Where is the evidence that either of these is likely?
I suspect, please don't be offended if I'm wrong here, that you've only been 'up with' programming for a few years? I, like many others, find the concept of generic visual programming comical.
Let me explain... Firstly, I should say that visual techniques have enormous potential and should not be ignored. UML is responsible for a snails-pace revolution in object oriented design and flow charts and schematics (a historic mainstay of computing) are becoming ever more advanced with automated techniques and tools. That said, there is still no way to arrive at a program without writing it. The best one can hope is to find a more appropriate syntax in which to write programs. If you have an effective visual language then there must exist one-to-one mappings from programs in that language to similar programs in any sufficiently rich textual programming language. Furthermore, gurus of theoretical computer science will be quick to tell you that it is possible to re-write any program written in one computationally complete language in another. (In case you wondered - practically useful languages are almost always computationally complete!)
The real challenge of visual languages is to effect a notation which is more convenient to that offered by a conventional textual form. With the exception of a few specific circumstances (e.g. WSYWIG word processing in place of programmatic typesetting; visual form design and video sequencing - for example) every visual language I've seen hyped for 20 odd years has been vapourware. Thinking back to the early 80s there has always been some well meaning salesman or other telling us that generic visual programming is just around the corner... yet I am still to see a single convincing example where, for example, a classic algorithm can be more easily or more clearly accurately specified in a graphical format than in a conventional textual language. I won't say this will never happen - I just retain a strong sense that I'll believe it only if I see it. I seriously doubt they will make programming any less demanding a task.
I've a weakness for reasonably good restaurants... I am always most impressed when the menu has only, say, half a dozen dishes and you know all of them will be fantastic. The food will more likely be fresh and the chef, who you then suspect may have forgotten more about the culinary arts than mere mortals will ever learn, is set to take control for a delightful gastronomic experience.
I've been fascinated with the idea that choice can be undesirable for several years having seen a TV documentary on the subject suggesting that people living in circumstances where choice was limited were far less likely to feel stress. I found this engrossing as I've certainly have mixed feelings when presented with many options - and (to keep on a shopping note) found deciding upon which car, house or watch to buy a seriously draining experience.
I've a theory - and it differs with that of Prof. Barry. I think people find it very uncomfortable to deal with uncertainty. Making choices really is something of a "maximisation problem" - especially if you suspect you would find most of the choices you might make somewhat unsatisfactory (even if that suspicion has no basis.) Modern advertising focuses not on quality, reliability, durability, fitness for purpose or similar "oh-so-1950s quaint" ideas... but rather on style - aiming to appeal to impulses rather than reason. This makes me deeply suspicious of the potential for vendor dishonesty - which makes me all the more anxious to investigate matters thoroughly. For example, I've been looking to buy a watch for ages - I know what I want (Thin, light, clear-simple-face, analogue, perpetual calendar) but I can't find anything suitable. If I were sure that no such watch is made, then I'd just put up with something second rate happy in the knowledge that a little perseverance would not turn up just what I'm looking for. This watch situation is exacerbated by the fact that Web vendors don't offer what I consider vital details (e.g. weight, physical dimensions etc. etc.); Manufacturers offer precious little information and supply different ranges to different countries for no obvious reason; Watches in shop windows aren't clearly marked with features etc, and it all makes me hopping mad! If I were somehow artificially constrained to allow only a handful of choices I could easily fully consider my options and pick my favourite (even if it isn't exactly what I want) or resign to using a sundial forever and feel free to focus my attention on new and more interesting things.
Other posters have postured that wealthy people have only "good" options where poor people typically have only bad ones. As un-PC as it may seem, I think this misses the point entirely. A bad selection of choices isn't one where none are particularly desirable, but rather a selection in which it is difficult to discriminate between the choices a-priori. A wealthy person is more likely to be presented with bad choices as they are more likely a target for scams and will often be making decisions with longer term consequences. This combination increases the likelihood of stress considerably. I think human happiness is less about what you have than how you get there... increasing the number of ultimately trivial choices is not the key to accomplish anything worthwhile nor to happiness.
It is interesting to note that plumbing has become one of the most highly paid skilled trades. I wonder what proportion of plumbers responded "happy" because the rates of pay are exceptionally high at the moment? The whole of IT is a strange, young profession and doesn't suit all temperaments. I also wonder what proportion of unhappy employees would be unhappy no matter what their job happened to be?
If I get into my car leaving my phone in my pocket, will the phone negotiate with the car to allow me to answer/make calls legally, or must I somehow enable the collaboration by pressing buttons on the phone (which would be illegal once I've set off and annoying to do before I set off - especially for short journeys)?
If I need to do something special - then there is no advantage to Bluetooth and I would be better off slotting the phone into a cradle every time I get behind the wheel.
The S55 looks rather good on the web page... two questions...
1) Do I need to place it in the in-car holder to use it wireless, or will the car kit work with it still in my pocket? 2) Assuming it will work from my pocket, do I need to press buttons to turn Bluetooth on and off, or is it reasonable to just leave it to the phone and the car to negotiate between themselves?
I wonder why this isn't offered at any of the retail outlets? Hmmm... maybe I just wonder why the retail phone shops are so pathetic...
My observations have been different... while the 2-3 year old design works well, I would have hoped that a phone company would have extended an excellent design such as the 8310 to provide robust wireless integration to motor vehicles. It seems that developments in mobile phones these days have become more concerned with style than substance. The reply about the 6310i is interesting but still makes me compromise on size - and leaves me wondering about issues relating to "always-on" Bluetooth. Surely it should not be a problem to listen for Bluetooth messages from my car without seriously adversely affecting battery life?
I'm not complaining about this phone per-se, but I am complaining that all mobile phone makers seem to have abandoned the idea that functionality improvements in core features will drive sales - especially considering the substantial demand.
Since the early 1990s I've seen immense value in having a mobile phone - just to remain in contact. 1990s phones were temperamental, fragile, bulky and permanently approaching a flat battery. In the noughties things started to look up - phones designs started to become more robust (no aerial sticking out); came in conveniently small packages and battery life sufficient for a working week on standby.
Britain recently passed drive-phoning laws - which bans using a hand-held phone while "driving" (including when stationary - say in a not-infrequent motorway hold up) and I decided a legal hands-free kit would be needed. Blue-tooth seemed to be the perfect answer to the problem - a simple system wired into my car so that whenever my engine is running, the in-car hands free kit takes control of any phone calls - allowing me to legally use my phone without taking it out of my pocket. Off I trooped to the mall now obscenely cluttered with mobile phone shops. To say I was surprised is an understatement!
Phone size - if I want blue tooth then I must have a larger phone (very undesirable) but that it would have a camera in it (no use at all thanks - maybe even a hindrance as I might not be permitted to take it with me everywhere I go) and a snazzy colour screen (Why!?! I just want to make and receive calls!) and a dramatically reduced battery life to boot. As for wireless connectivity - the vendors advise it is normally turned off, and activated only for the duration I'm using a particular blue tooth service...( What's the point then!?!!! ) and that using blue tooth would dramatically reduce battery life again!
Don't get me wrong I've been very impressed with my current Nokia 8310, but can't help feeling that more modern phones have become feature crazy and now neglect the primary requirement to make mobile telephone conversations convenient and reliable with minimum effort. Nokia - PLEASE - stop concentrating on the gimmicks and get back to making solid reliable phones for business use.
There are "zero problems" due to the environment in which the system was deployed. A Casino is a private club free to bar membership on any arbitrary basis wit a lot to loose if they were to admit a "frequently successful" or dishonest punter. Hell - the innocent may even be thought of as benefiting though a false-positive on this system preventing them from loosing to the house!
It is not sensible to publish this data - even in "anonymous form." Use of hashing will only prevent a party with access to the hash from directly reverse engineering the hashed data to arrive at a list of suspect names - however this completely misses the mark.
If I were a terrorist organisation planning something like 9/11 and I knew many of my lemming-recruits would be identified by airport security as risks, I would process my terrorist volunteers myself and only send those who would not raise any eyebrows. This information (anonymous though it is) would be of great value as it would eliminate another uncertainty from the evil plan.
If I were a private individual with interest in knowing the identities of all suspects then I would be able to mount a dictionary attack using, say, the electoral role or census data - with only a few billion people worldwide, a modest cluster of PCs would be able to exhaustively search for matches in reasonable time.
Finally - if this anonymous data were to be available only to authorities to whom the raw information would otherwise have been available then this approach is still a disadvantage. Without access to the reason for someone matching, it will make it much harder for authorities to make appropriate judgement calls based upon a match. The mere possibility that a match might be due to a hashing collision or data- entry errors prior to hashing could result in the wrong decisions being taken. There is certainly a risk that without information on why someone is a suspected risk that related vital clues may be missed - possibly resulting in an otherwise preventable disaster.
When I read a statement like this, all I can think is that it seems incredible that someone has a free hand to $1m, yet seems to have only a tenuous grasp of English and an apparently hopeless understanding of prudent business and general common sense. Why hasn't someone else fleeced them sooner? I suspect that there has been an unspecified incentive.
Many years ago I was at a science convention (don't ask) and saw a presentation of W-Technologies' virtual-reality full-immersion technology. (UK cutting edge, all the rage mid '80s technology) After the presentation, during questions, a woman asked why all the simulations involved killing people. The CEO fielded that one by saying that he could find no end of young men willing to pay a pound a minute to kill people, but that Knitting simulators were predicted to generate less revenue.
I've always thought typical female disdain for pixel-blasting violence to be a most endearing quality. I, for one, am against this slippery slope towards androgyny.
The Telewest telecommunications company (UK) doesn't need this system - they already have a better approach. You call customer services, explain that you've spent 2 months trying to terminate an account, get told that this has now happened, but that they are not willing to put this in writing. When pressed, they refer you to "Customer Services" which don't have a telephone number because they are not "customer facing." The customer is told that if they want anything other than to pay the same invoices already paid then they must write a letter in order that Telewest can more easily ignore the matter.
I see, my arrogant fellow poster with a limited but colourful vocabulary, that you are making one very big assumption. It seems you believe that you are in some sense more valuable than a manual worker - one assumes by your education... though I see precious little evidence of academic ability in your post. May I be so bold as to suggest that if you can't offer anything desired by others then maybe you aren't as valuable to others as you think you are?
I feel that the current popular trend of outsourcing work to less affluent countries is often misguided, but not because anyone owes western programmers a substantial salary, but rather because success in any project (IT especially so) requires good communication. Communication is only hampered by the inherent barriers of distance, time-zones, cultural differences and language. An IT contract in India is likely best served by an Indian supplier, a US contract by a US supplier etc. This has nothing to do with your inappropriate assumption of superiority.
Slashdot Mirror
I'm pleased to hear that the 'two tier' system I suggested back in '94 is now (a decade on) considered worthy of your consideration. To address your concerns (or are they excuses to procrastinate) I can offer the following observations:
While I realise that making decisions is likely outside your support-role, I think it would be important to remember that the core responsibility of IT support is to support the needs of the users. Depending upon circumstances the approach will vary dramatically. A good IT department will continually assess the needs of the users and aim to meet all these requirements in the most cost effective manner. If your users are frequently complaining about inadequate provision for on-line storage then there is a problem which needs to be redressed in the most appropriate way to support primary objectives of your organisation.
I believe that an email service from a company like google has massive potential. I would happily pay a reasonable sum (say 30 per year) to use google to manage my email assuming they meet my requirements. I think google could effectively eliminate spam by sharing signatures of mass-mailings among its huge user base which would more than justify my expense.
In order to be useful to me, google would need to offer IMAP access; support forwarding of email from users' own domains; support secure access both over the web (https) and preferably with IMAP/SSL too. I'd like to see it collect email from obsolete pop3 accounts (especially if spam elimination works) and I'd pay a premium to be able to easily generate SMS alerts when email matching user-defined criteria are received.
Finally - assuming Google can effectively eliminate spam, and can offer me an email service sufficiently flexible to meet my needs, then I, for one, would be pleased to receive a daily (clearly labelled) series of text-based targeted adverts based upon keywords in the email I've received. If I want my email to be private I should be using encryption anyway - I can only see this as a win-win situation... if Google wants my business I'm sure it already knows what to do!
Hmm... I guess I might be thought somewhat maverick here - but because a user is not a programmer this does not correlate with the view that the interface should be restrictive and illogical. Any numerate person will understand the distinction between integers and natural (counting) numbers. What I find far more difficult to explain is why "Example" + 5 + 3.14159 + 5_Sep_2003 = 37877.14159... which, I would suspect, most users of spreadsheets would find a confusing nonsense. By expanding the range of types which spreadsheets support we can seriously improve the ability of applications developers to define restrictive bespoke templates which reduce the risk of inadvertent error. By supplying a rich domain specific type system with a familiar tabular interface, we can reduce end-user confusion and expand the range of problems which can be realistically addressed in a spreadsheet paradigm. Sadly, it seems this hasn't happened yet.
I think it a big red herring to claim that because spreadsheets are frequently used to solve simple problems that design flaws in features not necessary for such trivial applications should be ignored.
Ten years ago I was the student being given grief about insisting I retain my 30-40Mb account. I moaned that for a couple of hundred quid (for this was the UK) I could buy a 1GB disk - which I would happily share with the other students wanting the larger quota... and I was faced with the same unreasonable brick-wall response.
n ly-copy data.'
While it is obvious that fully supported, highly reliable, frequently and automatically backed up storage is damned expensive, this misses the point somewhat. Most users with significant storage requirements don't need all of their data to be managed so rigorously. For myself, I wanted about 15Mb of reference material (which wouldn't change - hence would not require frequent backups); 10Mb of 'most recently built data' which given a few hours I could re-generate from source - and 5Mb of 'My-god-guard-this-with-your-life-important--my-o
I maintained that to minimise the cost of storage that users should, by-default, use a small quota 'ultra-reliable' space, but also have access to a private scratch space which would behave similarly but would not burden the organisation with backups and would utilise the cheapest hardware - even if that would not be the most reliable. BTW - the suggestion was never implemented and my "expensive" quota was simply increased.
Nincompoops failing to understand the implications of their models aside, I still feel that modern spreadsheets are desperately lacking. I can see several obvious ways in which support for richer data types would make spreadsheets more useful - though I agree that the article shows no evidence to back up their claim that such additional functionality would improve financial forecasts.
P.S. I got the joke - in spite of TLA hell:-)
Spreadsheets have been and will always continue to be an extraordinarily powerful ad-hoc tool for those wishing to tabulate data with automated calculations. They are worse than useless if, for whatever reason, the user has no savvy approach to the problem at hand, or if the model which requires manipulation has no concrete representation.
After many years with little use for a spreadsheet (previously having used Supercalc and Lotus 123) I was shocked by corporate state of the art. Specifically, I was disturbed by the type system employed to represent cell values and by the way in which formatting settings can so easily obscure the values actually being processed. The way in which Excel handles dates seems particularly horrific... and OO-Spreadsheet just mimics the same mistakes. I was also amazed that modern spreadsheets haven't started to use extensible libraries to represent new data types. It seems a no-brainer for a spreadsheet to make use of pluggable C# or Java classes to allow domain specific types to be manipulated in the context of a spreadsheet environment. Am I missing something - or have we not only failed to advance the art (as suggested by the article) but actually taken several steps backwards?
I admit that I might be guilty of suggesting an oversimplified view of filter-design and control. You shouldn't, however, assume I mean that filter design is trivial or even that it might be less challenging than other software problems... far from it! All I want to suggest is that this is a restricted form of computation far more amenable to a graphical approach... It's clear we agree in principle: the techniques which work well for those working in DSP can't straightforwardly be applied to all fields. For example - would you even bother to try and implement quicksort in simulink? The sieve of Eratosthenes? A binary tree or linked list data structure? These problems usually have straightforward (even trivial) solutions in conventional textual programming languages. It is this kind of flexibility (at the cost of domain specific clarity) which I suspect has been difficult to retain in the graphical arena and will continue to be elusive.
Actually, there's no reason why you can't model processes in something that businesses understand and then get the tool to generate code (in fact, the model should be the code).
:-)
Welcome to the search for the holy-grail! Modelling processes is frequently a realistic and valuable activity right now - though (as I'm sure you're aware) this model is seldom executable. The catch 22 of your argument is that when your model is your code then, clearly, your code is also your model. Hence, if your model is your code, you've lost the advantage of presenting at a higher level of abstraction. Language design can learn a lot from modelling, but I think it is a mistake to assume that textual representation of programs will be obsolete in my lifetime.
I don't understand your argument that the growth of the PC (and with it fantastic improvements in price/performance) has anything to do with the failure of 4GL to dominate the software market. As I see it the real problem was the approaches which were taken for these tools either hindered or prevented the expression of a significant proportion of desirable programs. Your comment about "coding for performance" is interesting - I assume you refer to the use of lower-level toolsets - though I claim that programmers haven't moved back towards that model, but rather that they haven't left it behind as quickly as 4GL proponents anticipated. The fantastic improvements in available processing power over the last couple of decades, however, are no substitute for using an appropriate algorithm for the problem at hand... the real trouble with high-level tools is that they frequently haven't delivered on their promise to simplify development of the systems which are required by business.
BTW - if you are frittering away time with non-critical features while missing the fundamentals - it's time to hire a better analyst!
Regarding Simulink et al... Absolutely... graphical approaches can be (and have been) extremely successful when working within a constrained domain. The interesting point about signal processing is the relative simplicity of the data structures involved (i.e. a single stream as both input and output) and the restricted computational model of even complex filters.
IMHO we will see more domain specific languages - yet this idea didn't seem to be the focus of the original article. If all programming in the future will be visual in nature then we must assume that either all useful algorithms will have been captured in some appropriate form for component-wise re-use in a graphical development environment, or that there will be a graphical language more convenient than a textual one to encode algorithms. Where is the evidence that either of these is likely?
I suspect, please don't be offended if I'm wrong here, that you've only been 'up with' programming for a few years? I, like many others, find the concept of generic visual programming comical.
Let me explain... Firstly, I should say that visual techniques have enormous potential and should not be ignored. UML is responsible for a snails-pace revolution in object oriented design and flow charts and schematics (a historic mainstay of computing) are becoming ever more advanced with automated techniques and tools. That said, there is still no way to arrive at a program without writing it. The best one can hope is to find a more appropriate syntax in which to write programs. If you have an effective visual language then there must exist one-to-one mappings from programs in that language to similar programs in any sufficiently rich textual programming language. Furthermore, gurus of theoretical computer science will be quick to tell you that it is possible to re-write any program written in one computationally complete language in another. (In case you wondered - practically useful languages are almost always computationally complete!)
The real challenge of visual languages is to effect a notation which is more convenient to that offered by a conventional textual form. With the exception of a few specific circumstances (e.g. WSYWIG word processing in place of programmatic typesetting; visual form design and video sequencing - for example) every visual language I've seen hyped for 20 odd years has been vapourware. Thinking back to the early 80s there has always been some well meaning salesman or other telling us that generic visual programming is just around the corner... yet I am still to see a single convincing example where, for example, a classic algorithm can be more easily or more clearly accurately specified in a graphical format than in a conventional textual language. I won't say this will never happen - I just retain a strong sense that I'll believe it only if I see it. I seriously doubt they will make programming any less demanding a task.
I've a weakness for reasonably good restaurants... I am always most impressed when the menu has only, say, half a dozen dishes and you know all of them will be fantastic. The food will more likely be fresh and the chef, who you then suspect may have forgotten more about the culinary arts than mere mortals will ever learn, is set to take control for a delightful gastronomic experience.
I've been fascinated with the idea that choice can be undesirable for several years having seen a TV documentary on the subject suggesting that people living in circumstances where choice was limited were far less likely to feel stress. I found this engrossing as I've certainly have mixed feelings when presented with many options - and (to keep on a shopping note) found deciding upon which car, house or watch to buy a seriously draining experience.
I've a theory - and it differs with that of Prof. Barry. I think people find it very uncomfortable to deal with uncertainty. Making choices really is something of a "maximisation problem" - especially if you suspect you would find most of the choices you might make somewhat unsatisfactory (even if that suspicion has no basis.) Modern advertising focuses not on quality, reliability, durability, fitness for purpose or similar "oh-so-1950s quaint" ideas... but rather on style - aiming to appeal to impulses rather than reason. This makes me deeply suspicious of the potential for vendor dishonesty - which makes me all the more anxious to investigate matters thoroughly. For example, I've been looking to buy a watch for ages - I know what I want (Thin, light, clear-simple-face, analogue, perpetual calendar) but I can't find anything suitable. If I were sure that no such watch is made, then I'd just put up with something second rate happy in the knowledge that a little perseverance would not turn up just what I'm looking for. This watch situation is exacerbated by the fact that Web vendors don't offer what I consider vital details (e.g. weight, physical dimensions etc. etc.); Manufacturers offer precious little information and supply different ranges to different countries for no obvious reason; Watches in shop windows aren't clearly marked with features etc, and it all makes me hopping mad! If I were somehow artificially constrained to allow only a handful of choices I could easily fully consider my options and pick my favourite (even if it isn't exactly what I want) or resign to using a sundial forever and feel free to focus my attention on new and more interesting things.
Other posters have postured that wealthy people have only "good" options where poor people typically have only bad ones. As un-PC as it may seem, I think this misses the point entirely. A bad selection of choices isn't one where none are particularly desirable, but rather a selection in which it is difficult to discriminate between the choices a-priori. A wealthy person is more likely to be presented with bad choices as they are more likely a target for scams and will often be making decisions with longer term consequences. This combination increases the likelihood of stress considerably. I think human happiness is less about what you have than how you get there... increasing the number of ultimately trivial choices is not the key to accomplish anything worthwhile nor to happiness.
It is interesting to note that plumbing has become one of the most highly paid skilled trades. I wonder what proportion of plumbers responded "happy" because the rates of pay are exceptionally high at the moment? The whole of IT is a strange, young profession and doesn't suit all temperaments. I also wonder what proportion of unhappy employees would be unhappy no matter what their job happened to be?
Hmmm - but can you tell me:
If I get into my car leaving my phone in my pocket, will the phone negotiate with the car to allow me to answer/make calls legally, or must I somehow enable the collaboration by pressing buttons on the phone (which would be illegal once I've set off and annoying to do before I set off - especially for short journeys)?
If I need to do something special - then there is no advantage to Bluetooth and I would be better off slotting the phone into a cradle every time I get behind the wheel.
The S55 looks rather good on the web page... two questions...
1) Do I need to place it in the in-car holder to use it wireless, or will the car kit work with it still in my pocket?
2) Assuming it will work from my pocket, do I need to press buttons to turn Bluetooth on and off, or is it reasonable to just leave it to the phone and the car to negotiate between themselves?
I wonder why this isn't offered at any of the retail outlets? Hmmm... maybe I just wonder why the retail phone shops are so pathetic...
> ... plenty of other models do.
My observations have been different... while the 2-3 year old design works well, I would have hoped that a phone company would have extended an excellent design such as the 8310 to provide robust wireless integration to motor vehicles. It seems that developments in mobile phones these days have become more concerned with style than substance. The reply about the 6310i is interesting but still makes me compromise on size - and leaves me wondering about issues relating to "always-on" Bluetooth. Surely it should not be a problem to listen for Bluetooth messages from my car without seriously adversely affecting battery life?
I'm not complaining about this phone per-se, but I am complaining that all mobile phone makers seem to have abandoned the idea that functionality improvements in core features will drive sales - especially considering the substantial demand.
Since the early 1990s I've seen immense value in having a mobile phone - just to remain in contact. 1990s phones were temperamental, fragile, bulky and permanently approaching a flat battery. In the noughties things started to look up - phones designs started to become more robust (no aerial sticking out); came in conveniently small packages and battery life sufficient for a working week on standby.
Britain recently passed drive-phoning laws - which bans using a hand-held phone while "driving" (including when stationary - say in a not-infrequent motorway hold up) and I decided a legal hands-free kit would be needed. Blue-tooth seemed to be the perfect answer to the problem - a simple system wired into my car so that whenever my engine is running, the in-car hands free kit takes control of any phone calls - allowing me to legally use my phone without taking it out of my pocket. Off I trooped to the mall now obscenely cluttered with mobile phone shops. To say I was surprised is an understatement!
Phone size - if I want blue tooth then I must have a larger phone (very undesirable) but that it would have a camera in it (no use at all thanks - maybe even a hindrance as I might not be permitted to take it with me everywhere I go) and a snazzy colour screen (Why!?! I just want to make and receive calls!) and a dramatically reduced battery life to boot. As for wireless connectivity - the vendors advise it is normally turned off, and activated only for the duration I'm using a particular blue tooth service...( What's the point then!?!!! ) and that using blue tooth would dramatically reduce battery life again!
Don't get me wrong I've been very impressed with my current Nokia 8310, but can't help feeling that more modern phones have become feature crazy and now neglect the primary requirement to make mobile telephone conversations convenient and reliable with minimum effort. Nokia - PLEASE - stop concentrating on the gimmicks and get back to making solid reliable phones for business use.
There are "zero problems" due to the environment in which the system was deployed. A Casino is a private club free to bar membership on any arbitrary basis wit a lot to loose if they were to admit a "frequently successful" or dishonest punter. Hell - the innocent may even be thought of as benefiting though a false-positive on this system preventing them from loosing to the house!
It is not sensible to publish this data - even in "anonymous form." Use of hashing will only prevent a party with access to the hash from directly reverse engineering the hashed data to arrive at a list of suspect names - however this completely misses the mark.
If I were a terrorist organisation planning something like 9/11 and I knew many of my lemming-recruits would be identified by airport security as risks, I would process my terrorist volunteers myself and only send those who would not raise any eyebrows. This information (anonymous though it is) would be of great value as it would eliminate another uncertainty from the evil plan.
If I were a private individual with interest in knowing the identities of all suspects then I would be able to mount a dictionary attack using, say, the electoral role or census data - with only a few billion people worldwide, a modest cluster of PCs would be able to exhaustively search for matches in reasonable time.
Finally - if this anonymous data were to be available only to authorities to whom the raw information would otherwise have been available then this approach is still a disadvantage. Without access to the reason for someone matching, it will make it much harder for authorities to make appropriate judgement calls based upon a match. The mere possibility that a match might be due to a hashing collision or data- entry errors prior to hashing could result in the wrong decisions being taken. There is certainly a risk that without information on why someone is a suspected risk that related vital clues may be missed - possibly resulting in an otherwise preventable disaster.
When I read a statement like this, all I can think is that it seems incredible that someone has a free hand to $1m, yet seems to have only a tenuous grasp of English and an apparently hopeless understanding of prudent business and general common sense. Why hasn't someone else fleeced them sooner? I suspect that there has been an unspecified incentive.
Many years ago I was at a science convention (don't ask) and saw a presentation of W-Technologies' virtual-reality full-immersion technology. (UK cutting edge, all the rage mid '80s technology) After the presentation, during questions, a woman asked why all the simulations involved killing people. The CEO fielded that one by saying that he could find no end of young men willing to pay a pound a minute to kill people, but that Knitting simulators were predicted to generate less revenue.
I've always thought typical female disdain for pixel-blasting violence to be a most endearing quality. I, for one, am against this slippery slope towards androgyny.
The Telewest telecommunications company (UK) doesn't need this system - they already have a better approach. You call customer services, explain that you've spent 2 months trying to terminate an account, get told that this has now happened, but that they are not willing to put this in writing. When pressed, they refer you to "Customer Services" which don't have a telephone number because they are not "customer facing." The customer is told that if they want anything other than to pay the same invoices already paid then they must write a letter in order that Telewest can more easily ignore the matter.
I see, my arrogant fellow poster with a limited but colourful vocabulary, that you are making one very big assumption. It seems you believe that you are in some sense more valuable than a manual worker - one assumes by your education... though I see precious little evidence of academic ability in your post. May I be so bold as to suggest that if you can't offer anything desired by others then maybe you aren't as valuable to others as you think you are?
I feel that the current popular trend of outsourcing work to less affluent countries is often misguided, but not because anyone owes western programmers a substantial salary, but rather because success in any project (IT especially so) requires good communication. Communication is only hampered by the inherent barriers of distance, time-zones, cultural differences and language. An IT contract in India is likely best served by an Indian supplier, a US contract by a US supplier etc. This has nothing to do with your inappropriate assumption of superiority.