The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source-code editors or integrated development environments (IDEs) and servers that provide "language intelligence tools": programming language-specific features like code completion, syntax highlighting and marking of warnings and errors, as well as refactoring routines. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE. In the early 2020s, LSP quickly became a "norm" for language intelligence tools providers. == History == LSP was originally developed for Microsoft Visual Studio Code and is now an open standard. On June 27, 2016, Microsoft announced a collaboration with Red Hat and Codenvy to standardize the protocol's specification. Its specification is hosted and developed on GitHub. == Background == Modern IDEs provide programmers with sophisticated features like code completion, refactoring, navigating to a symbol's definition, syntax highlighting, and error and warning markers. For example, in a text-based programming language, a programmer might want to rename a method read. The programmer could either manually edit the respective source code files and change the appropriate occurrences of the old method name into the new name, or instead use an IDE's refactoring capabilities to make all the necessary changes automatically. To be able to support this style of refactoring, an IDE needs a sophisticated understanding of the programming language that the program's source is written in. A programming tool without such an understanding—for example, one that performs a naive search-and-replace instead—could introduce errors. When renaming a read method, for example, the tool should not replace the partial match in a variable that might be called readyState, nor should it replace the portion of a code comment containing the word "already". Neither should renaming a local variable read, for example, end up altering identically-named variables in other scopes. Conventional compilers or interpreters for a specific programming language are typically unable to provide these language services, because they are written with the goal of either transforming the source code into object code or immediately executing the code. Additionally, language services must be able to handle source code that is not well-formed, e.g. because the programmer is in the middle of editing and has not yet finished typing a statement, procedure, or other construct. Additionally, small changes to a source code file which are done during typing usually change the semantics of the program. In order to provide instant feedback to the user, the editing tool must be able to very quickly evaluate the syntactical and semantical consequences of a specific modification. Compilers and interpreters therefore provide a poor candidate for producing the information needed for an editing tool to consume. Prior to the design and implementation of the Language Server Protocol for the development of Visual Studio Code, most language services were generally tied to a given IDE or other editor. In the absence of the Language Server Protocol, language services are typically implemented by using a tool-specific extension API. Providing the same language service to another editing tool requires effort to adapt the existing code so that the service may target the second editor's extension interfaces. The Language Server Protocol allows for decoupling language services from the editor so that the services may be contained within a general-purpose language server. Any editor can inherit sophisticated support for many different languages by making use of existing language servers. Similarly, a programmer involved with the development of a new programming language can make services for that language available to existing editing tools. Making use of language servers via the Language Server Protocol thus also reduces the burden on vendors of editing tools, because vendors do not need to develop language services of their own for the languages the vendor intends to support, as long as the language servers have already been implemented. The Language Server Protocol also enables the distribution and development of servers contributed by an interested third party, such as end users, without additional involvement by either the vendor of the compiler for the programming language in use or the vendor of the editor to which the language support is being added. LSP is not restricted to programming languages. It can be used for any kind of text-based language, like specifications or domain-specific languages (DSL). == Technical overview == When a user edits one or more source code files using a language server protocol-enabled tool, the tool acts as a client that consumes the language services provided by a language server. The tool may be a text editor or IDE and the language services could be refactoring, code completion, etc. The client informs the server about what the user is doing, e.g., opening a file or inserting a character at a specific text position. The client can also request the server to perform a language service, e.g. to format a specified range in the text document. The server answers a client's request with an appropriate response. For example, the formatting request is answered either by a response that transfers the formatted text to the client or by an error response containing details about the error. The Language Server Protocol defines the messages to be exchanged between client and language server. They are JSON-RPC preceded by headers similar to HTTP. Messages may originate from the server or client. The protocol does not make any provisions about how requests, responses and notifications are transferred between client and server. For example, client and server could be components within the same process exchanging JSON strings via method calls. They could also be different processes on the same or on different machines communicating via network sockets. == Registry == There are lists of LSP-compatible implementations, maintained by the community-driven Langserver.org or Microsoft.
Easy8
Easy8 is a project management platform. It is an extension to Redmine. == History == Easy8 Group, the company behind Easy8, was established in 2006 by Filip Morávek who serves as the company's CEO and is also a founder of the Mindfulness Foundation. In 2007, the company released an open-source project management software based on Redmine that included modules for project financing. The Easy8 Group has also developed an identical product distributed in Czechia and Hungary. In 2021 Easy8 11 was released with mobile application, Rails 6, Ruby 3.0, Sidekiq B2B CRM features. In 2022 Easy8 was available in 70 countries. In 2023 Easy8 13 was released in collaboration with Scrum certified expert. In March 2026, Easy Redmine and Easy Project rebranded to Easy8. == Overview == Easy8 covers Waterfall and Agile project management individually or simultaneously. It is available in public and private cloud hosting or on-premises server. It's based on open-source technologies such as Redmine. It covers the complete process from planning through implementation to helpdesk support. Easy8 also implements techniques such as risk and resource management, mind maps and Gantt charts. The application includes a CRM module focused on the B2B segment with partner access control and partner network management. Easy8 13 also has integration MediaWiki, the software that runs Wikipedia and GitLab, an AI-powered DevSecOps Platform. Easy8 is used by the Kazakh state administration, Bosch, Zentiva, Innogy, Ministry of Foreign Affairs of the Czech Republic, Axa, RTL Radio Berlin, Continental and Ogilvy among others. It features separately installable extensions. In 2017, it was reviewed by iX Special in comparison to GitKraken (previously known as Axosoft) and Agilo for Trac. PCmag while analyzing Redmine highlights that Easy8 enhances the core features of Redmine with a more polished interface and offers proprietary plug-ins for additional functionalities, such as tools for resource management, financial management, and support for agile methodologies. == Easy AI == Easy AI is an artificial intelligence extension integrated into the Easy8 project management suite, offering both cloud-based and on-premises deployment options. Easy AI uses the Llama 3.1 AI model and supports organizational data controls. The system includes assistants for personal, project, and service workflows, supporting tasks such as text summarization, project planning, and helpdesk ticket management. == License == The Easy8 website claims that "Easy8 is an Open Source software", but its source is neither freely downloadable nor is it licensed under an open-source license according to The Open Source Definition, since the Easy8 Group Commercial License does not allow free redistribution (among other restrictions).
TuVox
TuVox is a company that produces VXML-based telephone speech-recognition applications to replace DTMF touch-tone systems for their clients. == History == TuVox was founded in 2001 by Steven S. Pollock and Ashok Khosla, formerly of Apple Computer Corporation and Claris Corporation. Since then, TuVox has grown to over 150 employees and has US offices in Cupertino, California and Boca Raton, Florida as well as international offices in London, Vancouver and Sydney. In 2005, TuVox acquired the customers and hosting facilities of Net-By-Tel. In 2007, the company raised $20m for its speech recognition, and phone menu software. On July 22, 2010, West Interactive — a subsidiary of West Corporation — announced its acquisition of TuVox. == Customers == TuVox clients include: 1-800-Flowers.com, AMC Entertainment, American Airlines, British Airways, M&T Bank, Canon Inc., Gateway, Inc., Motorola, Progress Energy Inc., Telecom New Zealand, Time, Inc., BECU, Virgin America and USAA.
Artificial intelligence in customer experience
Artificial intelligence in customer experience is the use and development of artificial intelligence (AI) to aid and improve customer experience (sometimes abbreviated to CX AI). Chatbots are often seen as the first step in the development of AI within the industry, but more tailored offerings are slowly becoming available. The use of artificial intelligence in the space has since become more diverse than simply chatbots, with AI underpinning entire CX cloud platforms now used at major corporations. Contact center as a service (CCaaS) has become a core solution of the CX (customer experience) industry, with the CCaaS market size expected to reach $17.19 Billion by 2030 in the United States alone. == History == As with many AI applications, CX AI early implementation case studies have demonstrated that AI can increase the quality of customer interactions and therefore the overall experience that organizations can provide. This in turn has suggested a higher return on investment and/or revenue as a result. The beginning of the revolution of customer experience and the use of machine learning was with chatbots. The use of this type of AI can be traced back to Alan Turing in 1950, when the Church–Turing thesis suggested that computers could use "formal reasoning" to reach conclusions. In 2017, Meta produced one of the first breakthroughs for everyday use of AI for customer experience when it allowed Facebook users to create their own messaging bots for free on its Facebook messenger platform. The main focus of this was to both automate and improve customer experience and interaction. In 2023, CCaaS vendors began announcing the integration of ChatGPT’s generative AI into their CX solutions. Generative AI adds a layer of semantics into AI outputs. This was a major breakthrough for conversational AI. Using natural language processing and conversational AI, chatbots could enhance the level of service they could provide, speaking to customers in an easy-to-understand and conversational tone. == Applications == Currently the main location for the application of CX AI in the sector is in contact centers. Historically, contact centers were simply known as call centers, but in recent years differentiation developed between the two terms. Call centers provide phone support, while contact centers also provide support via digital channels in addition to analogue phone systems. Contact centers are therefore seen as a complete customer service solution, where as call centers simply cover one aspect of customer interactions. As a part of improving CX, AI is also improving the employee experience. AI is able to automate tasks to free up time for contact center agents to focus on higher priority tasks. For example, AI can be used for auto summarization. This means that instead of human agents having to summarize customer interactions now AI can do it, saving organizations time and money.
Course of Action Display and Evaluation Tool
Course of Action Display and Evaluation Tool (CADET) was a research program, and the eponymous prototype software system, that applied knowledge-based techniques of Artificial Intelligence to the problem of battle planning. CADET was also known as Course of Action Display and Elaboration Tool. It was considered an early example of such systems and was funded by the United States Army and by the Defense Advanced Research Projects Agency (DARPA). CADET influenced a later DARPA program called RAID which in turn produced a technology adopted by the United States Army and the United States Marine Corps. == History == The development of Course of Action Display and Evaluation Tool (CADET) began in 1996, at the Carnegie Group, Inc., Pittsburgh PA, funded under the Small Business Innovation Research (SBIR) program. The goal of the first phase SBIR project was to produce “...a live storyboard of [Course of Action] COA development, wargaming, animation, and assessment.” In 1997, the United States Army awarded the Carnegie Group Inc. $750K for SBIR Phase II. The intent was to develop “...a war-gaming modeling and analysis Decision Support System (DSS), … CADET will consist of a combination of Knowledge-Based and decision analytic tools and technologies to provide fast nimble COA war-gaming modeling, simulation, and animation under direct control of the commander and staff. ...Phase II will result in an operations prototype (OP) suitable for use and evaluation in field exercises.” In 2000, CADET was integrated and experimentally evaluated within the framework of the Integrated Course of Action Critiquing and Elaboration System (ICCES) experiment, conducted by the Battle Command Battle Laboratory – Leavenworth (BCBL-L) within the program Concept Experimentation Program (CEP) sponsored by TRADOC. In 2000-2002, DARPA applied CADET in the program titled Command Post of the Future (CPoF) as a tool to generate a course of action. Under the umbrella of the CPoF program, CADET was integrated with the FOX GA system to provide a detailed planner, coupled with COA generation capability. In the same period, Battle Command Battle Lab-Huachuca (BCBL-H) performed an integration CADET with the system called All Source Analysis System-Light (ASAS-L); here CADET was intended to generate plans for intelligence assets, and conduct wargames of different COAs, enemy versus friendly. From 1996 through 2002, work on CADET was performed by the Carnegie Group, Inc., and supported by funding from the US Army CECOM (CADET SBIR Phase I, CADET SBIR Phase II and CADET Enhancements); DARPA (Command Post of the Future); and TRADOC BCBL-H. == Operation == CADET was intended to be used by the staff of the United States Army Brigade, within the Military Decision Making Process (MDMP). In particular, CADET helped produce, automatically or semi-automatically, the products generated within the step of MDMP called Course of Action (COA) Development and the following step of MDMP called COA Analysis and Wargaming. CADET software resided on a laptop computer. Using the computer, the staff officers entered the input to CADET, or alternatively this input arrived at CADET from upstream computer systems. The input consisted of: Order of Battle, i.e., the units constituting the friendly brigade and the enemy units participating in the battle, and their various characteristics; primary activities of the Course of Action, where each activity is typically linked to one or more geographic areas or a route, and sometimes to a major unit executing the activity; digital map of the region where the battle was to take place, including the digital description of significant features such as locations of friendly and enemy units, roads, assembly areas, objectives, and axes of attacks. Taking this input, CADET automatically performed the following tasks (not sequentially): Planning and scheduling the low-level tasks necessary for a given COA Allocating tasks to various units and assets constituting the brigade Assigning suitable locations and routes Estimating the battle losses (attrition) of friendly and enemy forces, and consumption of resources (e.g., fuel and ammunition) Predicting enemy actions or reactions. CADET produced the following outputs: Synchronization matrix, directly editable and printable; synchronization matrix is a kind of Gantt chart that shows assignments of activities to units, to locations/routes and to time periods Map overlays in PPT or JPG formats Animation output XML formally-encoded plan Textual Operation Plan (OPLAN) draft E-mail messages with attachments: XML and text versions of OPLAN == Design == The core algorithm is a planning algorithm where CADET uses a knowledge-based approach of the hierarchical-task-network type. Each task class is associated with a model of more detailed subtasks that should be performed in order to accomplish the higher-level task. Algorithms selected (heuristically) a task and then decomposes it into subtasks. Although similar to hierarchical-task-network planning algorithm, CADET’s algorithm includes elements of adversarial reasoning. After adding a subtask, the algorithm uses rules to determine the enemy’s probable actions and reactions as well as friendly counteractions This approximated the action-reaction-counteraction technique of manual wargaming used by the United States Army. When a task involves movements of a unit, the algorithm performs routing, i.e., finds a route for the movement that minimizes the time required for the movement as well as exposure to the enemy attacks. Each added tasks (subtask) normally requires a unit which would execute the task, and a time period when the task would be executed. Therefore, when a certain number of subtasks is added by the planning process, the algorithm also performs the allocation of the newly added subtasks to units and to time periods (i.e., scheduling). allocation and scheduling of tasks relies on both domain-specific and constraint-guided heuristics. A tasks may also require expenditures of fuel and ammunition. If the tasks involves engagement with the enemy, the performing units will experience lossesof personnel and weapon systems (attrition). CADET’s algorithm includes estimates of consumption of different types of consumables, and also attrition. Depending on the degree of attrition and consumption, CADET adds tasks that are needed to refuel or reconstitute the units. The algorithm continually interleaves incremental steps of planning, routing, scheduling, and attrition and consumption estimates. == Evaluation == Two evaluation experiments are described in literature. The first experiment called ICCES took three days. The subjects were Army officers from combat arms branches, with 11 to 23 years of active service, in the ranks of majors and lieutenant colonels, a total of 8. Each officer was given 4 hours of training learning to operate CADET and related computer tools. Officers were divided into two groups and given a tactical scenario. One group (the control group) used the traditional, manual process; the other used the system called ICCES, the automated core of which was CADET. Each group produced three COA sketches and statements and one COA synchronization matrix. Then, the experiment was repeated with another scenario but the control group became the automated group and vice versa. The users were generally satisfied with the quality of the ICCES-generated products. The group using ICCES made only a few changes to the product that was automatically generated, indicating that they agreed with the majority of the plan that ICCES produced. The second experiment was reminiscent of Turing test. The experiment involved one user, nine judges (active-duty officers, mainly colonels and lieutenant colonels), and five scenarios obtained from several US Army exercises. For each scenario, experimenters obtained synchronization matrices that were produced in earlier exercises, typically by a team of four to five officers in three to four hours, spending approximately 16 person-hours in total. Using these scenarios and COAs, the user had CADET generate automatically detailed plans and express them as synchronization matrices. The user, a retired US Army officer, reviewed and slightly edited the matrices. The entire process took less than two minutes of computations by and approximately 20 minutes of review and post-editing, approximately 0.4 person-hour in total per product. The experimenters gave the resulting matrices the same visual style as those produced by humans. The judges, who did not know whether a planning product was a traditional product of humans, or with computerized aids, were asked to grade the products. The result was that the average grades for manual products and CADET-generated products were statistically indistinguishable, even though CADET-generated products required far less time to produce. == Legacy == CADET served as “...an example of how even relatively basic A
Dyme (company)
Dyme is a Dutch fintech start-up and subscription management app that allows users to cancel and renegotiate their recurring costs. In 2019, Dyme was the first independent Dutch company to receive a PSD2 licence from the Netherlands' central bank (DNB). == History == Dyme was founded in 2018 by Joran Iedema, David Knap, David Schogt and Wouter Florijn. The four had previously founded Cycleswap, a bicycle rental platform launched in 2015 and sold to the American platform Spinlister in 2016. The company gained notability in the Netherlands in 2020 when it appeared on Dutch television in Dragons Den, where Pieter Schoen made a €750,000 bid in an attempt to acquire 51.01% of the company. Dyme's Joran Iedema rejected the deal. == Recognition == Wired described Dyme as one of the "hottest start-ups in Europe" in 2021. As of 2021, the company reportedly had 350,000 registered users in the Netherlands and Great Britain.
AI Snake Oil
AI Snake Oil: What Artificial Intelligence Can Do, What It Can't, and How to Tell the Difference is a 2024 non-fiction book written by scholars Arvind Narayanan and Sayash Kapoor. It is a critique of the tech industry's overly inflated promises and capabilities of artificial intelligence (AI) as well as a debunking of the flawed science fueling AI hype while attempting to outline both the potential positives and negatives that come with different modes of the technology. == Contents == === Publication === The book was published in September 2024 by the Princeton University Press. AI Snake Oil consists of 360 pages and features eight chapters, and sections for acknowledgements, references, and an index. An updated edition with a new preface and epilogue by the authors was published in September 2025. The authors use the term "AI snake oil" derived from the U.S. idiom for a fraudulent remedy, to describe overhyped AI systems. === Chapter one: Introduction === Narayanan and Kapoor argue that many individuals do not yet have the literacy to detect functioning aspects of AI compared to potential snake oil, which they identify as "AI that does not and cannot work as advertised". Some of the major examples utilized by the authors include Allstate's 2013 use of predictive AI, as well as the concern surrounding actors and AI attempting to replicate or use their likeness. Important discussions regarding discrimination are brought up and explored in the first chapter, including the false arrests of six Black individuals due to errors with AI facial recognition tools. The chapter concludes with a comparison to the Industrial Revolution, where Narayanan and Kapoor highlight the extensive human labour that is necessary for artificial intelligence technologies to function. === Chapter two: How Predictive AI Goes Wrong === Chapter two focuses on predictive artificial intelligence, and criticizes the overestimation of the capabilities of the technology. === Chapter three: Why Can't AI Predict the Future? === Chapter three works to inform the reader about the history of early computational prediction attempts, with examples from companies like Simulatics. === Chapter four: The Long Road to Generative AI === The fourth chapter goes in more in-depth in explorations of generative AI. Generative AI software examples include ChatGPT, Midjourney, and DALL-E. The section begins with a positive example of generative AI. As the chapter progresses, the authors begin to provide examples of harm produced by generative AI, including the suicide of a Belgian man after connecting with Chai, a generative chatbot. Issues of deepfakes and preservation of artistic property are also discussed. The use of generative AI to create non-consensual pornographic deepfake content is discussed in relation to female celebrities. === Chapter five: Is Advanced AI an Existential Threat? === The fifth chapter draws attention the AGI, or Artificial General Intelligence. The authors describe AGI as "AI that can perform most or economically relevant tasks as effectively as any human". They summarize that many contributors to the field of artificial intelligence believe AGI to be an impending threat that demands attention. However, they argue that the perceived threat of AGI would only exist if the technology continually functioned reliably. In order to better illustrate the hype surrounding AGI, Narayanan and Kapoor use the Ladder of Generality, which is described as a visual tool in which "each rung represents a way of computing that is more flexible, and more general, than the previous one". They note that we are not yet aware of the next rungs on the ladder, or if the ladder will eventually result in a dead end. The rungs that have been identified so far are as follows: (0, or floor) special purpose hardware, (1) programmable computers, (2) stored program computers, (3) machine learning, (4) deep learning, (5) pretrained models, and, finally, (6) instruction-tuned models. The potential for future rungs and what those rungs might be are currently undetermined. The chapter also discusses the ELIZA effect, which Lawrence Switzky discusses in his article "ELIZA Effects". Switzky attributes the coined term ELIZA Effect to Sherry Turke, who defined it as "our more general tendency to treat responsive computer programs as more intelligent than they really are". === Chapter six: Why Can't AI Fix Social Media? === The sixth chapter focuses on content moderation, why it is important, and how it has been and could be affected by artificial automation. The first issue raised in regard to AI-driven content moderation is the inability for computers and machines to understand context and nuance, resulting in potential for discriminatory moderation and shadow banning. While they note that there are issues with automating content moderation, Narayanan and Kapoor also highlight the psychological impact on human content moderators and their labour. They indicate the hidden labour behind moderation, which is often outsourced to less developed countries, where labourers sort through potentially traumatizing content for pay. However, the discussion focuses more heavily on why automated moderation can be problematic, including discriminatory algorithms and lack of nuance. To balance their argument, issues of discrimination and bias are also discussed in relation the human content moderators. To automate moderation, there are two types of AI used, which are fingerprint matching and machine learning. === Chapter seven: Why Do Myths about AI Persist? === The seventh chapter outlines possible factors that contribute to hype surrounding AI. Narayanan and Kapoor explain how companies often promote their new AI models without properly disclosing how the model works, and what it is learning from. They attribute hype to several different groups, including journalists, researchers, and companies. They explain the impact of companies and the misplaced hype that they spread can be attributed to greed and a desire to grow corporate funds. For journalists, one of the stated sources of hype, they argue that news media has a tendency to prioritize financial incentives over validity and quality of writing. As well, Narayanan and Kapoor point out the emergence of company statement regurgitation in news media, leading to clickbait. Hype from researchers is potentially linked to lack of reproducibility in studies as well as leakage, which occurs when AI models are tested on their training data. === Chapter eight: Where do we go from here? === The final chapter, chapter eight, turns its attention to the future. The authors express their ideas and predictions for how the technology will evolve and be utilized in the upcoming years. == Authors == Author Narayanan is a computer science professor at Princeton University. Kapoor is a doctoral candidate at the same university, and both scholars are located at the Center for Information Technology at Princeton. In 2023, Narayanan and Kapoor appeared on the TIME100 Artificial Intelligence list, which features influential figures in the field. == Reception == Nature, a science and technology peer-reviewed journal, released an article highlighting the top "10 essential reads from the past year", listing Arvind Narayanan and Sayash Kapoor's AI Snake Oil. The article states the that text is "one of the best on this controversial subject". Elizabeth Quill, in her review of the text in Science News, writes that the authors "squarely achieve their stated goal: to empower people to distinguish AI that works well from AI snake oil". Joshua Rothman of The New Yorker writes that "compared with many technologists, Narayanan, Kapoor, and Vallor [Shannon Vallor, University of Edinburgh], are deeply skeptical about today's A.I. technology and what it can achieve. Perhaps they shouldn't be". Rothman argues, following an interview with prominent computer scientist Geoffrey Hinton of University of Toronto, that the potential for AI to replicate complexity is already here and continues to be heavily funded, enhancing the prospective capabilities of the technology. However, he does praise the author's ability to address questions regarding the existential human experience. Alexya Martinez discusses the text in a book review for Journalism and Mass Communication Quarterly, critiquing AI Snake Oil for its extensive focus on the West. Martinez writes that Narayanan and Kapoor "do not fully explore how AI impacts other countries", and suggests more focus on countries outside of the United States to enhance their argument.