Iverson style array programming has a reputation for high density, high performance, and concise programs on a wide range of domains. However, programmers unfamiliar with array programming may struggle to see how to apply array programming to their particular domain, or how to achieve high performance when the domain is not an obviously array-oriented problem. The key is understanding the appropriate ways to think about data, data structures, domain mappings/encodings, and architecture. This talk discusses some of the key structures, techniques, and patterns for thinking about and encoding a problem domain into APL arrays to enable both productive solutions and high performance on that data. There are many "bread and butter" techniques that APLers pick up implicitly that serve as critical techniques for any serious array programmer, and knowing these will help unlock your array programming. 

After learning the basics of APL, the question is often, "What do I do next?" The intermediate process of learning how to write good APL can feel especially challenging to those who are not used to operating in a dataflow, array-oriented style. One valuable resource is the large number of APL Idioms available for use. These are often referenced as a kind of "standard library" of APL functionality, especially for more experienced APL programmers. Studying the idioms is often a source of new insights for APL programmers, but for the uninitiated, it can be unclear what exactly you should learn when looking at an Idiom. Many users mistakenly see Idioms as just a short implementation of what would be a library call in another language, and thus equate Idioms and Libraries as serving the same purpose. In this talk, we will discuss and explore three combinatorial idioms in detail, not only explaining how they work, the thought process behind them, and the lessons that you can learn from them, but also the meta-level question of how to go about extracting these lessons for yourself when reading idioms on your own. 

Beginning functional and APL programmers often express confusion about how to structure large software projects or larger pieces of code. Both APL and FP have a tendency to highlight their low-level features and de-emphasize system architecture patterns. This can leave programmers with a strong sense of how to write a set of small functions, but with less confidence or skill in designing, recognizing, and implementing more cohesive implicit system architectures that hold these lower level functions together. System architectures serve as a method for constraining the overall design of a system to give direction and focus to lower level implementation requirements. Especially in APL, where system architecture is often best implemented implicitly, it behooves the programmer to understand the ramifications of architecture and to implement them in their own systems. This talk unpacks a number of these "architecture level" questions within the framework of the APL programming language by exploring the same topic through 3 different architectural approaches, each of which has a very distinct flavor, presentation, and impact on the resulting source code. Particular attention is paid to the question of domain-specific languages, their design, and how they can interact with APL as tools for architectural exploration and guidance in APL source trees. 

During the conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group

This is an intensive workshop for those who are interested in learning how to think, read, and write APL. It will help give you the tools, mental framework, and structure for doing things "the APL way." In this workshop, you will have the chance to spend intensive time thinking like an APL programmer. What makes it different? How does the code look at the end? What thought process do you go through to get there? Get a chance to play around with a wide array of problems and solving them "the APL way."

Taijiquan Classics say, "Four ounces deflects a thousand pounds."

APLers might say instead, "Fifty characters solve a thousand problems."

Programs are getting fat. They're becoming slow. They're taking up more computing resources. They're getting harder to maintain and more complex from the ground up. Layer upon layer of sophistication is causing us to lose our ability to predict what software will do. Where's that bug? Why is everything going so slowly? Am I even using the right data structures? Where's that important point in the documentation again?

What's happened to us? In this meta-dive into the nature of our approach to programming, we will explore some of the dangers of our current approaches to programming and the how/why of our current programming obesity problem. We will look at real case studies and see just how bad the situation can be.

But we will also explore how we can battle these sources of obesity. In this passionate plea for code that we can gain control over again, we will look at examples of how we can return to a state of high-performance on all levels, from code size to code scalability. We will look at the principles that can help us to reach leaner, more efficient, more usable, less buggy code. We will hopefully find some light at the end of the tunnel, and how we can change our outlook on programming to push ourselves towards code that benefits not only ourselves, but also those that will come after us.

APL is getting a lot of attention lately due to its potential for very high performance portability and suitability for both rapid prototyping of complex solutions as well as deployment of complex algorithms to high-speed, modern parallel hardware. It has the potential to vastly improve the speed, scalability, and size of your code bases. But APL has a reputation as an intimidating language to learn.

In this back to the basics tutorial, we will explore the core of APL, and focus on those areas that usually trip up the beginner in learning APL. We will also walk you through how to approach an APL expression, how to reason about them, and how to read them efficiently. We will teach you the skills that the expert APLer has internalized, and how you can work through these skills externally and explicitly in a way that will help you to eventually internalize these critical skills in a way that makes you efficient at using APL on real world problems.

This is an intensive workshop for those who are interested in learning how to think, read, and write APL. It will help give you the tools, mental framework, and structure for doing things "the APL way." In this workshop, you will have the chance to spend intensive time thinking like an APL programmer. What makes it different? How does the code look at the end? What thought process do you go through to get there? Get a chance to play around with a wide array of problems and solving them "the APL way."

Taijiquan Classics say, "Four ounces deflects a thousand pounds."

APLers might say instead, "Fifty characters solve a thousand problems."

APL is the original functional programming language, the grand-daddy, the Godfather, and the old workhorse. But don't let Grandpa's age fool you. APL programmers have been leveraging the use of functional programming with arrays long before it was cool to be chasing pointers in an ADT using statically typed pattern matching, and they've refined their own style and approach to getting the most from a "functional paradigm."

In this workshop, you will have the chance to spend some time thinking like a functional array programmer. What makes it different? How does the code look at the end? What thought process do you go through to get there? Get a chance to play around with some classic problems and try solving them "the APL way."

Taijiquan Classics say, "Four ounces deflects a thousand pounds."

APLers might say instead, "Fifty characters solve a thousand problems."

APL is known for its concise problem-solving expressiveness, and it is used very successfully in places where high-quality and rapid iteration are requirements, not luxuries. Static Type Systems have had tremendous success throughout the computing industry, even receiving positive HCI usability studies that demonstrate their effectiveness on a number of metrics with mainstream and functionally-oriented programming languages. This success leads many programmers to take the value of type systems as a given, especially as mission-criticality and the age of a project increase. Therefore, it comes as a surprise to many, when learning about APL, that it has spent so long as an untyped, interpreted language in domains and use cases where traditional wisdom would suggest the need for a typed, compiled language.

But APL is not like other languages, and its unique features and historical uses warrant a careful revisiting of the question of type systems. In this talk we will explore whether or not APL needs a type system, whether it would benefit from having one, what that might look like, and how the interaction between APL and type theory might inform the design and use of type systems in general.

APL is a notorious language with a reputation for being "write only" and difficult to learn. Yet, many people consider APL to be their single most productive, advantageous tool that they hope never to give up. In particular, it is generally observed that many computer scientists have a poor opinion of the usability of APL, while many data scientists and domain experts find the language to be exceptionally usable.

This session focuses on the experienced programmer's struggle to gain real facility with APL beyond the basic, trivial understanding of its semantics and syntax (which can be taught in a few hours). We will observe this struggle through a "human-centered" experience analysis identifying a set of Pattern/Anti-pattern tensions that are at the heart of the intermediate APL learning "wall." By examining the experience of thinking and working with APL code versus regular code, we can identify principles of APL coding practice that directly oppose the widely taught and embraced best practices of the broader programming community. We'll see not only what these principles are, but also why they survive in APL and how they contribute to the positive development cycle of an experienced APL programmer, instead of the negative impact such practices usually have when writing in other languages.

Understanding these practices will provide a focus point for the discussion of programming experience design and the use of concise array language, as well as provide a structure for becoming better able to write, read, and think in APL expert.

How would your make your programs easier to write, inherently parallel, and have high performance across GPUs and CPUs? How about a development methodology that makes agile programming look sluggish and unreliable? How about shrinking the size and complexity of your code base by an order of magnitude, while increasing performance by an order of magnitude? This intensive workshop is designed to demystify the strange and special world of array programming like you may never have seen it before. Iverson-style array programming terrifies some and amazes others, but no one can argue with the results in areas such as finance, energy, education, or medical research. New research has made array programming scalable across a wide array of parallel hardware architectures. Often renowned for remarkably short, concise code that does a tremendous amount, the area of production level, array programming is an often misunderstood area. This workshop will bring you through a whirlwind of array programming concepts by example and case study, opening up the curtains on the original interactive functional programming language in its modern incarnation. You will learn how you can make use of this sometimes mystical world, with an emphasis on the concepts and how to integrate these concepts into a practical, targeted development methodology and ecosystem for maximizing productivity and leveraging the benefits of notational thinking to their full effect. The goal is to let you keep the magic and fun of programming alive while you use that magic for your benefit in the real world.