spreadsheets-parallel-acm.bib

@inproceedings{Stadelmann:1993:SBC:168642.168664,
  author =	 {Stadelmann, Marc},
  title =	 {A Spreadsheet Based on Constraints},
  booktitle =	 {Proceedings of the 6th Annual ACM Symposium on User
                  Interface Software and Technology},
  series =	 {UIST '93},
  year =	 1993,
  isbn =	 {0-89791-628-X},
  location =	 {Atlanta, Georgia, USA},
  pages =	 {217--224},
  numpages =	 8,
  url =		 {http://doi.acm.org/10.1145/168642.168664},
  doi =		 {10.1145/168642.168664},
  acmid =	 168664,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  keywords =	 {APL, constraint satisfaction, constraints, matrices,
                  spreadsheets, user-interface, vectors},
  abstract = 	 {An abstract is not available.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=168664&ftid=33824&dwn=1&CFID=746021857&CFTOKEN=16202337},
  review = 	 {fbie: accepted <2016-01-18 15:12:48>},
}

@inproceedings{deMesquita:2006:DSQ:1218112.1218525,
  author =	 {de Mesquita, Marco Aur{\'e}lio and Hernandez, Alvaro
                  Euzebio},
  title =	 {Discrete-event Simulation of Queues with
                  Spreadsheets: A Teaching Case},
  booktitle =	 {Proceedings of the 38th Conference on Winter
                  Simulation},
  series =	 {WSC '06},
  year =	 2006,
  isbn =	 {1-4244-0501-7},
  location =	 {Monterey, California},
  pages =	 {2277--2283},
  numpages =	 7,
  url =		 {http://dl.acm.org/citation.cfm?id=1218112.1218525},
  acmid =	 1218525,
  publisher =	 {Winter Simulation Conference},
  abstract = 	 {This paper describes the use of spreadsheets combined with simple VBA code as a tool for teaching queuing theory and discrete-event simulation. Four different cases are considered: single server, parallel servers, tandem queuing, and closed queuing system. The data obtained in the simulation run are conveniently stored in spreadsheets for subsequent statistical analysis. This approach was successfully deployed in a second one-semester course on management science for industrial engineers undergraduate students.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=1218525&ftid=399454&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:12:53>},
}

@inproceedings{Pichitlamken:2008:HPS:1516744.1516869,
  author =	 {Pichitlamken, Juta and Kajkamhaeng, Supasit and
                  Uthayopas, Putchong},
  title =	 {High Performance Spreadsheet Simulation on a Desktop
                  Grid},
  booktitle =	 {Proceedings of the 40th Conference on Winter
                  Simulation},
  series =	 {WSC '08},
  year =	 2008,
  isbn =	 {978-1-4244-2708-6},
  location =	 {Miami, Florida},
  pages =	 {663--670},
  numpages =	 8,
  url =		 {http://dl.acm.org/citation.cfm?id=1516744.1516869},
  acmid =	 1516869,
  publisher =	 {Winter Simulation Conference},
  abstract = 	 {We present a proof-of-concept prototype for high performance spreadsheet simulation called S3. Our goal is to provide a user-friendly, yet computationally powerful simulation environment for end users. Our approach is to add power of parallel computing on Windows-based desktop grid into popular Excel models. We show that, by using standard Web Services and Service-Oriented Architecture (SOA), one can build a fast and efficient system on a desktop grid for simulation. The complexity of parallelism can be hidden from users through a well-defined computation template. This work also demonstrates that a massive computing power can be harvested by linking off-the-shelf office PCs into a desktop grid for simulation. The experimental results show that the prototype system is highly scalable. In the best case, the execution time can be reduced 13.6 times using 16 desktop PCs; the simulation time is dramatically reduced from 200 minutes to 14 minutes.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=1516869&ftid=605034&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:12:57>},
}

@article{Juhasz:1999:USS:571535.571568,
  author =	 {Juhasz, Zoltan},
  title =	 {Using Spreadsheets As a Simple and Effective
                  Teaching Tool for Predicting and Visualizing
                  Parallel Program Performance},
  journal =	 {SIGCSE Bull.},
  issue_date =	 {June 1999},
  volume =	 31,
  number =	 2,
  month =	 jun,
  year =	 1999,
  issn =	 {0097-8418},
  pages =	 {51--54},
  numpages =	 4,
  url =		 {http://doi.acm.org/10.1145/571535.571568},
  doi =		 {10.1145/571535.571568},
  acmid =	 571568,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {This paper describes how we can use a spreadsheet program as an inexpensive and readily available tool to help students understand the execution behavior of parallel programs. Using the proposed method a performance prediction model can be created in a matter of minutes and the performance of the parallel system can be visualized and animated by using standard three-dimensional surface plots and user interface control objects.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=571568&ftid=82277&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:02>},
}

@article{Lai:1988:OLL:58566.59298,
  author =	 {Lai, Kum-Yew and Malone, Thomas W. and Yu,
                  Keh-Chiang},
  title =	 {Object Lens: A \&Ldquo;Spreadsheet\&Rdquo; for
                  Cooperative Work},
  journal =	 {ACM Trans. Inf. Syst.},
  issue_date =	 {Oct. 1988},
  volume =	 6,
  number =	 4,
  month =	 oct,
  year =	 1988,
  issn =	 {1046-8188},
  pages =	 {332--353},
  numpages =	 22,
  url =		 {http://doi.acm.org/10.1145/58566.59298},
  doi =		 {10.1145/58566.59298},
  acmid =	 59298,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {Object Lens allows unsophisticated computer users to create their own cooperative work applications using a set of simple, but powerful, building blocks. By defining and modifying templates for various semistructured objects, users can represent information about people, tasks, products, messages, and many other kinds of information in a form that can be processed intelligently by both people and their computers. By collecting these objects in customizable folders, users can create their own displays which summarize selected information from the objects in table or tree formats. Finally, by creating semiautonomous agents, users can specify rules for automatically processing this information in different ways at different times.
The combination of these primitives provides a single consistent interface that integrates facilities for object-oriented databases, hypertext, electronic messaging, and rule-based intelligent agents. To illustrate the power of this combined approach, we describe several simple examples of applications (such as task tracking, intelligent message routing, and database retrieval) that we have developed in this framework.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=59298&ftid=20427&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:08>},
}

@inproceedings{Horey:2010:TSP:2163970.2163971,
  author =	 {Horey, James and Nelson, Eric and Maccabe, Arthur
                  B.},
  title =	 {Tables: A Spreadsheet-inspired Programming Model for
                  Sensor Networks},
  booktitle =	 {Proceedings of the 6th IEEE International Conference
                  on Distributed Computing in Sensor Systems},
  series =	 {DCOSS'10},
  year =	 2010,
  isbn =	 {3-642-13650-8, 978-3-642-13650-4},
  location =	 {Santa Barbara, CA},
  pages =	 {1--14},
  numpages =	 14,
  url =		 {http://dx.doi.org/10.1007/978-3-642-13651-1_1},
  doi =		 {10.1007/978-3-642-13651-1_1},
  acmid =	 2163971,
  publisher =	 {Springer-Verlag},
  address =	 {Berlin, Heidelberg},
  review = 	 {fbie: rejected <2016-01-18 15:13:10>},
}

@inproceedings{Fujima:2004:CCC:1029632.1029664,
  author =	 {Fujima, Jun and Lunzer, Aran and Hornb{\ae}k, Kasper
                  and Tanaka, Yuzuru},
  title =	 {Clip, Connect, Clone: Combining Application Elements
                  to Build Custom Interfaces for Information Access},
  booktitle =	 {Proceedings of the 17th Annual ACM Symposium on User
                  Interface Software and Technology},
  series =	 {UIST '04},
  year =	 2004,
  isbn =	 {1-58113-957-8},
  location =	 {Santa Fe, NM, USA},
  pages =	 {175--184},
  numpages =	 10,
  url =		 {http://doi.acm.org/10.1145/1029632.1029664},
  doi =		 {10.1145/1029632.1029664},
  acmid =	 1029664,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  keywords =	 {customized information access, end-user programming,
                  parallel exploration},
  abstract = 	 {Many applications provide a form-like interface for requesting information: the user fills in some fields, submits the form, and the application presents corresponding results. Such a procedure becomes burdensome if (1) the user must submit many different requests, for example in pursuing a trial-and-error search, (2) results from one application are to be used as inputs for another, requiring the user to transfer them by hand, or (3) the user wants to compare results, but only the results from one request can be seen at a time. We describe how users can reduce this burden by creating custom interfaces using three mechanisms: clipping of input and result elements from existing applications to form cells on a spreadsheet; connecting these cells using formulas, thus enabling result transfer between applications; and cloning cells so that multiple requests can be handled side by side. We demonstrate a prototype of these mechanisms, initially specialised for handling Web applications, and show how it lets users build new interfaces to suit their individual needs.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=1029664&ftid=285532&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:17>},
}

@inproceedings{Sarukkai:1992:PPV:143369.143404,
  author =	 {Sarukkai, Sekhar R. and Gannon, Dennis},
  title =	 {Parallel Program Visualization Using SIEVE.1},
  booktitle =	 {Proceedings of the 6th International Conference on
                  Supercomputing},
  series =	 {ICS '92},
  year =	 1992,
  isbn =	 {0-89791-485-6},
  location =	 {Washington, D. C., USA},
  pages =	 {157--166},
  numpages =	 10,
  url =		 {http://doi.acm.org/10.1145/143369.143404},
  doi =		 {10.1145/143369.143404},
  acmid =	 143404,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {In this paper we introduce a new model for the design of performance analysis and visualization tools. The system integrates static code analysis, relational database designs and a spreadsheet model of interactive programming. This system provides a general methodology for visualizing parallel program executions by providing correlation to the source program, a convenient method for rapidly developing new visualizations of the program and a framework for performance studies.
The basic semantics of this model are described and example applications of visualizing the execution of two different parallel programs are considered.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=143404&ftid=17688&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:23>},
}

@inproceedings{Khan:2014:UJW:2661088.2661090,
  author =	 {Khan, Faiz and Foley-Bourgon, Vincent and Kathrotia,
                  Sujay and Lavoie, Erick and Hendren, Laurie},
  title =	 {Using JavaScript and WebCL for Numerical
                  Computations: A Comparative Study of Native and Web
                  Technologies},
  booktitle =	 {Proceedings of the 10th ACM Symposium on Dynamic
                  Languages},
  series =	 {DLS '14},
  year =	 2014,
  isbn =	 {978-1-4503-3211-8},
  location =	 {Portland, Oregon, USA},
  pages =	 {91--102},
  numpages =	 12,
  url =		 {http://doi.acm.org/10.1145/2661088.2661090},
  doi =		 {10.1145/2661088.2661090},
  acmid =	 2661090,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  keywords =	 {C, OpenCL, WebCL, benchmark, computational dwarfs,
                  javascript, numerical computation, parallelism, web
                  browser},
  abstract = 	 {From its modest beginnings as a tool to validate forms, JavaScript is now an industrial-strength language used to power online applications such as spreadsheets, IDEs, image editors and even 3D games. Since all modern web browsers support JavaScript, it provides a medium that is both easy to distribute for developers and easy to access for users. This paper provides empirical data to answer the question: Is JavaScript fast enough for numerical computations? By measuring and comparing the runtime performance of benchmarks representative of a wide variety of scientific applications, we show that sequential JavaScript is within a factor of 2 of native code. Parallel code using WebCL shows speed improvements of up to 2.28 over JavaScript for the majority of the benchmarks.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=2661090&ftid=1505290&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:28>},
}

@article{Khan:2014:UJW:2775052.2661090,
  author =	 {Khan, Faiz and Foley-Bourgon, Vincent and Kathrotia,
                  Sujay and Lavoie, Erick and Hendren, Laurie},
  title =	 {Using JavaScript and WebCL for Numerical
                  Computations: A Comparative Study of Native and Web
                  Technologies},
  journal =	 {SIGPLAN Not.},
  issue_date =	 {February 2015},
  volume =	 50,
  number =	 2,
  month =	 oct,
  year =	 2014,
  issn =	 {0362-1340},
  pages =	 {91--102},
  numpages =	 12,
  url =		 {http://doi.acm.org/10.1145/2775052.2661090},
  doi =		 {10.1145/2775052.2661090},
  acmid =	 2661090,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  keywords =	 {C, OpenCL, WebCL, benchmark, computational dwarfs,
                  javascript, numerical computation, parallelism, web
                  browser},
  abstract = 	 {From its modest beginnings as a tool to validate forms, JavaScript is now an industrial-strength language used to power online applications such as spreadsheets, IDEs, image editors and even 3D games. Since all modern web browsers support JavaScript, it provides a medium that is both easy to distribute for developers and easy to access for users. This paper provides empirical data to answer the question: Is JavaScript fast enough for numerical computations? By measuring and comparing the runtime performance of benchmarks representative of a wide variety of scientific applications, we show that sequential JavaScript is within a factor of 2 of native code. Parallel code using WebCL shows speed improvements of up to 2.28 over JavaScript for the majority of the benchmarks.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=2661090&ftid=1505290&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:32>},
}

@article{Spradling:2007:SCB:1241601.1241625,
  author =	 {Spradling, Cloyce D.},
  title =	 {SPEC CPU2006 Benchmark Tools},
  journal =	 {SIGARCH Comput. Archit. News},
  issue_date =	 {March 2007},
  volume =	 35,
  number =	 1,
  month =	 mar,
  year =	 2007,
  issn =	 {0163-5964},
  pages =	 {130--134},
  numpages =	 5,
  url =		 {http://doi.acm.org/10.1145/1241601.1241625},
  doi =		 {10.1145/1241601.1241625},
  acmid =	 1241625,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {The benchmarks that make up the SPEC CPU2006 benchmark suite are set-up, run, timed, and scored by the CPU tools harness. The tools have evolved over time from a collection of edit-it-yourself makefiles, scripts, and an Excel spreadsheet to the current Perl-based suite. The basic purpose of the tools is to make life easier for the benchmarker; they make it easier to tweak compilation settings, easier to keep track of those settings, and most importantly, they make it easier to follow the run and reporting rules.},
  review = 	 {fbie: rejected <2016-01-18 15:13:37>},
}

@article{Neff:1987:DBC:38714.38767,
  author =	 {Neff, R. K.},
  title =	 {Data Bases, Compound Objects, and Networked
                  Workstations: Beyond Distributed Computing
                  (Abstract)},
  journal =	 {SIGMOD Rec.},
  issue_date =	 {Dec. 1987},
  volume =	 16,
  number =	 3,
  month =	 dec,
  year =	 1987,
  issn =	 {0163-5808},
  pages =	 {1--1},
  numpages =	 1,
  url =		 {http://doi.acm.org/10.1145/38714.38767},
  doi =		 {10.1145/38714.38767},
  acmid =	 38767,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {Requirements for future data base systems are developed from the perspective of the user of a networked workstation who naturally deals with compound objects. Objects considered include full text, diagrams, maps, sound recordings, images from film and video and of art objects, spreadsheets, etc. Searching requirements and strategies over multi-objects are also considered. The context of such data base systems is the library, in its electronic or digital version. Comments are presented with respect to the digital learning environment of the future. Current related projects at Berkeley are described.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=38767&ftid=26215&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:41>},
}

@inproceedings{Neff:1987:DBC:38713.38767,
  author =	 {Neff, R. K.},
  title =	 {Data Bases, Compound Objects, and Networked
                  Workstations: Beyond Distributed Computing
                  (Abstract)},
  booktitle =	 {Proceedings of the 1987 ACM SIGMOD International
                  Conference on Management of Data},
  series =	 {SIGMOD '87},
  year =	 1987,
  isbn =	 {0-89791-236-5},
  location =	 {San Francisco, California, USA},
  pages =	 {1--1},
  numpages =	 1,
  url =		 {http://doi.acm.org/10.1145/38713.38767},
  doi =		 {10.1145/38713.38767},
  acmid =	 38767,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {Requirements for future data base systems are developed from the perspective of the user of a networked workstation who naturally deals with compound objects. Objects considered include full text, diagrams, maps, sound recordings, images from film and video and of art objects, spreadsheets, etc. Searching requirements and strategies over multi-objects are also considered. The context of such data base systems is the library, in its electronic or digital version. Comments are presented with respect to the digital learning environment of the future. Current related projects at Berkeley are described.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=38767&ftid=26215&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:44>},
}

@inproceedings{Hacigumus:2002:ESO:564691.564717,
  author =	 {Hacig\"{u}m\"{u}\c{s}, Hakan and Iyer, Bala and Li,
                  Chen and Mehrotra, Sharad},
  title =	 {Executing SQL over Encrypted Data in the
                  Database-service-provider Model},
  booktitle =	 {Proceedings of the 2002 ACM SIGMOD International
                  Conference on Management of Data},
  series =	 {SIGMOD '02},
  year =	 2002,
  isbn =	 {1-58113-497-5},
  location =	 {Madison, Wisconsin},
  pages =	 {216--227},
  numpages =	 12,
  url =		 {http://doi.acm.org/10.1145/564691.564717},
  doi =		 {10.1145/564691.564717},
  acmid =	 564717,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {Rapid advances in networking and Internet technologies have fueled the emergence of the "software as a service" model for enterprise computing. Successful examples of commercially viable software services include rent-a-spreadsheet, electronic mail services, general storage services, disaster protection services. "Database as a Service" model provides users power to create, store, modify, and retrieve data from anywhere in the world, as long as they have access to the Internet. It introduces several challenges, an important issue being data privacy. It is in this context that we specifically address the issue of data privacy.There are two main privacy issues. First, the owner of the data needs to be assured that the data stored on the service-provider site is protected against data thefts from outsiders. Second, data needs to be protected even from the service providers, if the providers themselves cannot be trusted. In this paper, we focus on the second challenge. Specifically, we explore techniques to execute SQL queries over encrypted data. Our strategy is to process as much of the query as possible at the service providers' site, without having to decrypt the data. Decryption and the remainder of the query processing are performed at the client site. The paper explores an algebraic framework to split the query to minimize the computation at the client site. Results of experiments validating our approach are also presented.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=564717&ftid=86277&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:47>},
}

@inproceedings{Fujima:2004:CCC:1013367.1013517,
  author =	 {Fujima, Jun and Lunzer, Aran and Hornb{\ae}k, Kasper
                  and Tanaka, Yuzuru},
  title =	 {C3W: Clipping, Connecting and Cloning for the Web},
  booktitle =	 {Proceedings of the 13th International World Wide Web
                  Conference on Alternate Track Papers \&Amp; Posters},
  series =	 {WWW Alt. '04},
  year =	 2004,
  isbn =	 {1-58113-912-8},
  location =	 {New York, NY, USA},
  pages =	 {444--445},
  numpages =	 2,
  url =		 {http://doi.acm.org/10.1145/1013367.1013517},
  doi =		 {10.1145/1013367.1013517},
  acmid =	 1013517,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  keywords =	 {Web application linkage, Web navigation,
                  intelligentPad, interfaces, subjunctive},
  abstract = 	 {Many of today's Web applications support just simple trial-and error retrievals: supply one set of parameters, obtain one set of results. For a user who wants to examine a number of alternative retrievals, this form of interaction is inconvenient and frustrating. It can be hard work to keep finding and adjusting the parameter specification widgets buried in a Web page, and to remember or record each result set. Moreover, when using diverse Web applicationsin combination - transferring result data from one into the parameters for another - the lack of an easy way to automate that transfer merely increases the frustration. Our solution is to integrate techniques for each of three key activities: clipping elements from Web pages to wrap an application; connecting wrapped applications using spreadsheet-like formulas; and cloning the interfaceelements so that several sets of parameters and results may behandled in parallel. We describe a prototype that implements this solution, showing how it enables rapid and flexible exploration ofthe resources accessible through user-chosen combinations of Web applications. Our aim in this work is to contribute to research on making optimal use of the wealth of information on the Web, by providing interaction techniques that address very practical needs.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=1013517&ftid=278320&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:50>},
}

@inproceedings{Weaver:1985:LM:17701.255659,
  author =	 {Weaver, Kevin R.},
  title =	 {Lotus 1-2-3 for Mainframes (Bringing a Product to
                  Market)},
  booktitle =	 {Proceedings of the International Conference on APL:
                  APL and the Future},
  series =	 {APL '85},
  year =	 1985,
  isbn =	 {0-897-91157-1},
  location =	 {Seattle, Washington, USA},
  pages =	 {207--214},
  numpages =	 8,
  url =		 {http://doi.acm.org/10.1145/17701.255659},
  doi =		 {10.1145/17701.255659},
  acmid =	 255659,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {The number of widely-used, business oriented APL applications is few. It's difficult to pinpoint why — other than to reflect on the complexities of conceiving a marketable product and executing the development, release, sale and promotion, distribution, and ongoing support for a product. Although many companies provide APL services, and many custom applications have been developed for specific needs, the ability to bring a mainframe APL product to market and have it succeed seems cornered by IBM (e.g., ADRS, FPS, GRAPHPAK, APL DI). Parallax Systems is one of the few companies to be successful in this arena. The product is called ExecuCalctm, and has been licensed to approximately 200 sites since January 1983.
What are the elements that contribute to the success of this product in such a short period of time? Can these be applied to other APL product ideas to insure the developer is at least on the right road to producing a winner?
First, there was market awareness. The buying market (corporate data processing managers and senior decision makers) should have a mental picture of the concept being explored. ExecuCalc is an electronic spreadsheet product. In the early 1980's, VisiCalc was almost a household word. The concept was clear, accepted, and in practice in the micro computer market. Missionary work (often a key process in promoting APL and APL-based applications) for spreadsheets was already done, and the masses were going to the altar.
Second was market need. VisiCalc satisfied a need. Since this audience accepted the spreadsheet concept long ago, the market need does not have to be detailed. At the same time, VisiCalc lacked both obvious features (e.g., variable column width) and features which resulted from widespread use creating a demand (e.g., file combine for consolidation). ExecuCalc initially contained all of the VisiCalc features, including identical commands and their syntax as well as file formats (“.VC” and “.DIF”), plus a few of the obvious needs (determined by limited market research and personal experience, harnessed by the desire to release the product in a timely fashion). ExecuCalc paralleled the need for a VisiCalc, and added a new dimension: it ran on a mainframe using 3270 terminals. The needs satisfied included: (a) spreadsheet, (b) a widely accepted approach, (c) use of existing hardware (mainframe and 3270s), (d) a product requiring little training and support for information center users, yet (e) enabled users to be immediately productive, and (f) enabled users to process corporate data resident on their mainframe rather than down-load and proliferate segments of the corporate databases.
Third, boundaries were established on the features in each release, especially release 1. By concentrating on a well-defined end of development, Parallax was able to bring ExecuCalc to the market in three man-months. The boundaries were set by VisiCalc's features and the few “obvious” add-ons. Subsequent releases over the next year were timed and delivered as maintenance releases. The subsequent releases always were bounded by a finite set of new features.
Fourth, development was focused and uninterrupted. As a two-person company, Parallax had no alternative other than to focus on a timely completion of the product. We had financial incentives (the desire for income and the need to minimize expenses) as well as the concern that a competitive product would be released and substantially reduce our potential. There is an undisputed edge in being first in the market. As a result, one person spent long hours at the terminal keyboard (implementing, testing, and polishing the product) and one person spent long hours at the typewriter keyboard and telephone (developing press releases, promotional letters, prospect literature, etc.). The argument might be made that this is easy or easier (as well as a necessity) for a small, start-up firm; but a larger firm should keep in mind that fewer interruptions during product development and market planning result in a net gain in productivity.
Fifth, the product was priced to sell. As a product increases in cost and complexity, so does the evaluation time and corporate authority level to sign for the purchase. ExecuCalc was (and still is) priced at $5000 per CPU license. Considerations in arriving at this price included: (a) most middle level managers and up (information center manager, DP manager, etc.) could sign-off on the purchase; (b) the product was approximately the price of one micro running VisiCalc or Lotus, yet offered access to everyone with a 3270; and (c) the price was substantially lower than most mainframe products being purchased by data processing, consequently reducing the decision process to buy.
Sixth, there was a plan for the future. Once Lotus 1-2-3 overpowered VisiCalc. ExecuCalc was enhanced to include most of the popular features of Lotus. Again, we implemented these features in the same (or as close as possible) syntax as that used by Lotus. Also, a high-resolution, color business graphics product, ExecuPlottm, was released. ExecuPlot was a look-alike for VisiPlot — meeting all of the criteria noted above. Parallax also provided customer training in ExecuCalc, ExecuPlot, VisiCalc, and Lotus 1-2-3, so that a full service could be offered to a company as the user base grew and requirements for ongoing support and service rapidly increased.
Seventh, we realized sales, marketing and promotion can make or break a product. Although a traditional sales approach and marketing strategy are essential, especially for a newly formed company — and in fact we spent heavily on large frequent advertising in Computerworld — there are many variations on the standard theme which greatly helped the success of Parallax with ExecuCalc. Our sales brochure was printed on a ledger sheet (i.e., a spreadsheet) to draw attention to the nature of the product. When we exhibited the product in a trade show, we used promotional gimmicks generally affordable by larger companies (e.g., free T-shirts with our name attached to a newly-popular phrase: The Best Has Always Been Good Enough — Parallax). We also gave a T-shirt to each of our customers who responded to a product questionnaire. We pursued every opportunity with the press to gain recognition for the company and/or the product. This meant writing editors and following up with telephone or personal contact, using every contact we knew in the trades, never turning down an opportunity to be mentioned no matter how insignificant the mention or the publication seemed. We also joined ADAPSO to work with others in support of our industry and to make contacts with other executives in the industry. We always gave the appearance of being a large company with a highly successful product.
Since product margins would greatly decline if we were required to make sales calls to sell every copy, we shipped the product to prospective customers for a thirty-day evaluation. In the cases where a demonstration was critical to make the sale, we would demonstrate the product (a two-hour demo) to the prospect at their site only if they would provide us with a two-hour period during which we could demo the product to a group of other companies in the local area. We also offered the product under a monthly lease plan ($500/month) with lease credits toward the perpetual license fee.
The above material could relate to almost any new product launch, not necessarily an APL product. What were the advantages and disadvantages of using APL?
APL was the chosen language in which to write ExecuCalc and ExecuPlot because it was the language in which we had the most expertise. At the same time it afforded us several advantages:
First, we were able to bring the first version of the product to market in a relatively brief period of time. One of our main competitors with a similar product written in assembler took 18 man-months to bring the first release to market.
Second, we were able to develop enhancements in a timely fashion, keeping the same order of magnitude of time difference as noted above for the initial release of the product.
Third, we were able to respond to and fix problems easily. In some cases we could apply a fix over the telephone with a customer on-line with the product. If the product were in assembler we'd have to apply the fix to a master copy and distribute it en mass (although we ultimately did this after fixing any collection of bugs found in the product).
Fourth, with a minor amount of guidance (and proper authorization) from us, a client may enhance the product with formulas specifically related to the company's needs or industry specialization (e.g., actuarial formulas, banking calculations, etc.). This is not possible with other mainframes products, nor is it with Lotus, VisiCalc, or other spreadsheet micro products. Naturally, the company needs an APL terminal and an APL programmer. Beyond that, the process is very easy.
Fifth, IBM “promotes” APL and APL products in the information center. As a result, we fit in nicely with this environment.
Sixth, we were able to use existing software in APL needed to accomplish some of the tasks required of the product. For example, we used AP124X (the full screen manager) or AP126 (part of GDDM) for ExecuCalc; we used GDDM and GRAPHPAK for ExecuPlot.
APL was also a disadvantage.
First, our market place was limited to those running VS APL or those willing to install VS APL to run our product.
Second, the market place continues to have a negative attitude about APL being a resource drain and a product which is difficult to deal with from the standpoint of (a) receiving help from IBM about the product, (b) learning the language, and (c) providing support to both the user community and technical support for the system.
Third, APL is not available from IBM in a form which is helpful to companies marketing APL-based products. Most companies we market to would prefer to license software (and VS APL) in terms of a perpetual license fee, paid once. VS APL is leased by IBM on a monthly basis, without a paid-up plan.
Furthermore, a software developer is not able to provide VS APL source code with the application product on the distribution tape. This means that a firm contracting for a product such as ExecuCalc must also contract with IBM for APL, wait for APL to be delivered, figure out how to install it, install it, then order our product for evaluation and licensing. This is inconvenient and discouraging to all concerned, to say nothing about the additional time needed and expense.
It is difficult to draw a conclusion from this experience which would conclusively determine if we were to write another application software product, would we do it in APL. There are many factors to consider as noted above. This time it worked for Parallax, resulting in one of the largest selling APL-based mainframe software products on the market.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=255659&ftid=11878&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:54>},
}

@article{Weaver:1985:LM:255315.255659,
  author =	 {Weaver, Kevin R.},
  title =	 {Lotus 1-2-3 for Mainframes (Bringing a Product to
                  Market)},
  journal =	 {SIGAPL APL Quote Quad},
  issue_date =	 {May 12, 1985},
  volume =	 15,
  number =	 4,
  month =	 may,
  year =	 1985,
  issn =	 {0163-6006},
  pages =	 {207--214},
  numpages =	 8,
  url =		 {http://doi.acm.org/10.1145/255315.255659},
  doi =		 {10.1145/255315.255659},
  acmid =	 255659,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {The number of widely-used, business oriented APL applications is few. It's difficult to pinpoint why — other than to reflect on the complexities of conceiving a marketable product and executing the development, release, sale and promotion, distribution, and ongoing support for a product. Although many companies provide APL services, and many custom applications have been developed for specific needs, the ability to bring a mainframe APL product to market and have it succeed seems cornered by IBM (e.g., ADRS, FPS, GRAPHPAK, APL DI). Parallax Systems is one of the few companies to be successful in this arena. The product is called ExecuCalctm, and has been licensed to approximately 200 sites since January 1983.
What are the elements that contribute to the success of this product in such a short period of time? Can these be applied to other APL product ideas to insure the developer is at least on the right road to producing a winner?
First, there was market awareness. The buying market (corporate data processing managers and senior decision makers) should have a mental picture of the concept being explored. ExecuCalc is an electronic spreadsheet product. In the early 1980's, VisiCalc was almost a household word. The concept was clear, accepted, and in practice in the micro computer market. Missionary work (often a key process in promoting APL and APL-based applications) for spreadsheets was already done, and the masses were going to the altar.
Second was market need. VisiCalc satisfied a need. Since this audience accepted the spreadsheet concept long ago, the market need does not have to be detailed. At the same time, VisiCalc lacked both obvious features (e.g., variable column width) and features which resulted from widespread use creating a demand (e.g., file combine for consolidation). ExecuCalc initially contained all of the VisiCalc features, including identical commands and their syntax as well as file formats (“.VC” and “.DIF”), plus a few of the obvious needs (determined by limited market research and personal experience, harnessed by the desire to release the product in a timely fashion). ExecuCalc paralleled the need for a VisiCalc, and added a new dimension: it ran on a mainframe using 3270 terminals. The needs satisfied included: (a) spreadsheet, (b) a widely accepted approach, (c) use of existing hardware (mainframe and 3270s), (d) a product requiring little training and support for information center users, yet (e) enabled users to be immediately productive, and (f) enabled users to process corporate data resident on their mainframe rather than down-load and proliferate segments of the corporate databases.
Third, boundaries were established on the features in each release, especially release 1. By concentrating on a well-defined end of development, Parallax was able to bring ExecuCalc to the market in three man-months. The boundaries were set by VisiCalc's features and the few “obvious” add-ons. Subsequent releases over the next year were timed and delivered as maintenance releases. The subsequent releases always were bounded by a finite set of new features.
Fourth, development was focused and uninterrupted. As a two-person company, Parallax had no alternative other than to focus on a timely completion of the product. We had financial incentives (the desire for income and the need to minimize expenses) as well as the concern that a competitive product would be released and substantially reduce our potential. There is an undisputed edge in being first in the market. As a result, one person spent long hours at the terminal keyboard (implementing, testing, and polishing the product) and one person spent long hours at the typewriter keyboard and telephone (developing press releases, promotional letters, prospect literature, etc.). The argument might be made that this is easy or easier (as well as a necessity) for a small, start-up firm; but a larger firm should keep in mind that fewer interruptions during product development and market planning result in a net gain in productivity.
Fifth, the product was priced to sell. As a product increases in cost and complexity, so does the evaluation time and corporate authority level to sign for the purchase. ExecuCalc was (and still is) priced at $5000 per CPU license. Considerations in arriving at this price included: (a) most middle level managers and up (information center manager, DP manager, etc.) could sign-off on the purchase; (b) the product was approximately the price of one micro running VisiCalc or Lotus, yet offered access to everyone with a 3270; and (c) the price was substantially lower than most mainframe products being purchased by data processing, consequently reducing the decision process to buy.
Sixth, there was a plan for the future. Once Lotus 1-2-3 overpowered VisiCalc. ExecuCalc was enhanced to include most of the popular features of Lotus. Again, we implemented these features in the same (or as close as possible) syntax as that used by Lotus. Also, a high-resolution, color business graphics product, ExecuPlottm, was released. ExecuPlot was a look-alike for VisiPlot — meeting all of the criteria noted above. Parallax also provided customer training in ExecuCalc, ExecuPlot, VisiCalc, and Lotus 1-2-3, so that a full service could be offered to a company as the user base grew and requirements for ongoing support and service rapidly increased.
Seventh, we realized sales, marketing and promotion can make or break a product. Although a traditional sales approach and marketing strategy are essential, especially for a newly formed company — and in fact we spent heavily on large frequent advertising in Computerworld — there are many variations on the standard theme which greatly helped the success of Parallax with ExecuCalc. Our sales brochure was printed on a ledger sheet (i.e., a spreadsheet) to draw attention to the nature of the product. When we exhibited the product in a trade show, we used promotional gimmicks generally affordable by larger companies (e.g., free T-shirts with our name attached to a newly-popular phrase: The Best Has Always Been Good Enough — Parallax). We also gave a T-shirt to each of our customers who responded to a product questionnaire. We pursued every opportunity with the press to gain recognition for the company and/or the product. This meant writing editors and following up with telephone or personal contact, using every contact we knew in the trades, never turning down an opportunity to be mentioned no matter how insignificant the mention or the publication seemed. We also joined ADAPSO to work with others in support of our industry and to make contacts with other executives in the industry. We always gave the appearance of being a large company with a highly successful product.
Since product margins would greatly decline if we were required to make sales calls to sell every copy, we shipped the product to prospective customers for a thirty-day evaluation. In the cases where a demonstration was critical to make the sale, we would demonstrate the product (a two-hour demo) to the prospect at their site only if they would provide us with a two-hour period during which we could demo the product to a group of other companies in the local area. We also offered the product under a monthly lease plan ($500/month) with lease credits toward the perpetual license fee.
The above material could relate to almost any new product launch, not necessarily an APL product. What were the advantages and disadvantages of using APL?
APL was the chosen language in which to write ExecuCalc and ExecuPlot because it was the language in which we had the most expertise. At the same time it afforded us several advantages:
First, we were able to bring the first version of the product to market in a relatively brief period of time. One of our main competitors with a similar product written in assembler took 18 man-months to bring the first release to market.
Second, we were able to develop enhancements in a timely fashion, keeping the same order of magnitude of time difference as noted above for the initial release of the product.
Third, we were able to respond to and fix problems easily. In some cases we could apply a fix over the telephone with a customer on-line with the product. If the product were in assembler we'd have to apply the fix to a master copy and distribute it en mass (although we ultimately did this after fixing any collection of bugs found in the product).
Fourth, with a minor amount of guidance (and proper authorization) from us, a client may enhance the product with formulas specifically related to the company's needs or industry specialization (e.g., actuarial formulas, banking calculations, etc.). This is not possible with other mainframes products, nor is it with Lotus, VisiCalc, or other spreadsheet micro products. Naturally, the company needs an APL terminal and an APL programmer. Beyond that, the process is very easy.
Fifth, IBM “promotes” APL and APL products in the information center. As a result, we fit in nicely with this environment.
Sixth, we were able to use existing software in APL needed to accomplish some of the tasks required of the product. For example, we used AP124X (the full screen manager) or AP126 (part of GDDM) for ExecuCalc; we used GDDM and GRAPHPAK for ExecuPlot.
APL was also a disadvantage.
First, our market place was limited to those running VS APL or those willing to install VS APL to run our product.
Second, the market place continues to have a negative attitude about APL being a resource drain and a product which is difficult to deal with from the standpoint of (a) receiving help from IBM about the product, (b) learning the language, and (c) providing support to both the user community and technical support for the system.
Third, APL is not available from IBM in a form which is helpful to companies marketing APL-based products. Most companies we market to would prefer to license software (and VS APL) in terms of a perpetual license fee, paid once. VS APL is leased by IBM on a monthly basis, without a paid-up plan.
Furthermore, a software developer is not able to provide VS APL source code with the application product on the distribution tape. This means that a firm contracting for a product such as ExecuCalc must also contract with IBM for APL, wait for APL to be delivered, figure out how to install it, install it, then order our product for evaluation and licensing. This is inconvenient and discouraging to all concerned, to say nothing about the additional time needed and expense.
It is difficult to draw a conclusion from this experience which would conclusively determine if we were to write another application software product, would we do it in APL. There are many factors to consider as noted above. This time it worked for Parallax, resulting in one of the largest selling APL-based mainframe software products on the market.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=255659&ftid=11878&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:13:58>},
}

@article{L'Ecuyer:1990:RNS:84537.84555,
  author =	 {L'Ecuyer, Pierre},
  title =	 {Random Numbers for Simulation},
  journal =	 {Commun. ACM},
  issue_date =	 {Oct. 1990},
  volume =	 33,
  number =	 10,
  month =	 oct,
  year =	 1990,
  issn =	 {0001-0782},
  pages =	 {85--97},
  numpages =	 13,
  url =		 {http://doi.acm.org/10.1145/84537.84555},
  doi =		 {10.1145/84537.84555},
  acmid =	 84555,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {In the mind of the average computer user, the problem of generating uniform variates by computer has been solved long ago. After all, every computer :system offers one or more function(s) to do so. Many software products, like compilers, spreadsheets, statistical or numerical packages, etc. also offer their own. These functions supposedly return numbers that could be used, for all practical purposes, as if they were the values taken by independent random variables, with a uniform distribution between 0 and 1. Many people use them with faith and feel happy with the results. So, why bother?
Other (less naive) people do not feel happy with the results and with good reasons. Despite renewed crusades, blatantly bad generators still abound, especially on microcomputers [55, 69, 85, 90, 100]. Other generators widely used on medium-sized computers are perhaps not so spectacularly bad, but still fail some theoretical and/or empirical statistical tests, and/or generate easily detectable regular patterns [56, 65].
Fortunately, many applications appear quite robust to these defects. But with the rapid increase in desktop computing power, increasingly sophisticated simulation studies are being performed that require more and more “random” numbers and whose results are more sensitive to the quality of the underlying generator [28, 40, 65, 90]. Sometimes, using a not-so-good generator can give totally misleading results. Perhaps this happens rarely, but can be disastrous in some cases. For that reason, researchers are still actively investigating ways of building generators. The main goal is to design more robust generators without having to pay too much in terms of portability, flexibility, and efficiency. In the following sections, we give a quick overview of the ongoing research. We focus mainly on efficient and recently proposed techniques for generating uniform pseudorandom numbers. Stochastic simulations typically transform such numbers to generate variates according to more complex distributions [13, 25]. Here, “uniform pseudorandom” means that the numbers behave from the outside as if they were the values of i.i.d. random variables, uniformly distributed over some finite set of symbols. This set of symbols is often a set of integers of the form {0, . . . , m - 1} and the symbols are usually transformed by some function into values between 0 and 1, to approximate the U(0, 1) distribution. Other tutorial-like references on uniform variate generation include [13, 23, 52, 54, 65, 84, 89].},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=84555&ftid=11574&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:14:08>},
}

@proceedings{Mattern:2013:2493432,
  title =	 {UbiComp '13: Proceedings of the 2013 ACM
                  International Joint Conference on Pervasive and
                  Ubiquitous Computing},
  year =	 2013,
  isbn =	 {978-1-4503-1770-2},
  location =	 {Zurich, Switzerland},
  note =	 608139,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  review = 	 {fbie: rejected <2016-01-18 15:14:09>},
}

@article{Svobodova:1984:FSN:3872.3873,
  author =	 {Svobodova, Liba},
  title =	 {File Servers for Network-based Distributed Systems},
  journal =	 {ACM Comput. Surv.},
  issue_date =	 {Dec. 1984},
  volume =	 16,
  number =	 4,
  month =	 dec,
  year =	 1984,
  issn =	 {0360-0300},
  pages =	 {353--398},
  numpages =	 46,
  url =		 {http://doi.acm.org/10.1145/3872.3873},
  doi =		 {10.1145/3872.3873},
  acmid =	 3873,
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  abstract = 	 {An abstract is not available.},
  fullTextUrl =  {http://dl.acm.org/ft_gateway.cfm?id=3873&ftid=267096&dwn=1&CFID=746029413&CFTOKEN=19402309},
  review = 	 {fbie: rejected <2016-01-18 15:14:13>},
}

@book{Reiser:1991:OSU:102909,
  author =	 {Reiser, Martin},
  title =	 {The Oberon System: User Guide and Programmer's
                  Manual},
  year =	 1991,
  isbn =	 {0-201-54422-9},
  source =	 {ACM member price \$33.95, order number 706902},
  publisher =	 {ACM},
  address =	 {New York, NY, USA},
  review = 	 {fbie: rejected <2016-01-18 15:14:15>},
}