Learning Functional Programming in Go.Pdf

Total Page:16

File Type:pdf, Size:1020Kb

Learning Functional Programming in Go.Pdf Learning Functional Programming in Go Lex Sheehan BIRMINGHAM - MUMBAI Learning Functional Programming in Go Copyright © 2017 Packt Publishing First published: November 2017 Production reference: 1221117 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 7-1-772-13-4 www.packtpub.com Contents Preface 1 Chapter 1: Pure Functional Programming in Go 11 Motivation for using FP 12 Getting the source code 13 The directory structure of the source files 13 How to run our first Go application 14 Imperative versus declarative programming 15 Pure functions 1 Fibonacci sequence - a simple recursion and two performance improvements 1 Memoization 21 The difference between an anonymous function and a closure 24 FP using Go's concurrency constructs 26 Testing FP using test-driven development 2 A note about paths 30 How to run our tests 31 A journey from imperative programming to pure FP and enlightenment 36 Benchmark test for the imperative SumLoop function 37 Benchmark test for the SumRecursive function 37 A time of reckoning 3 A quick example of a function literal 3 Summary 40 Chapter 2: Manipulating Collections 41 Iterating through a collection 42 Piping Bash commands 44 Functors 45 Functions that modify functions 46 A coding example of functions that modify functions 46 A visual example of functions that modify functions 47 Composition in Mindcraft 4 Tacit programming 4 Tacit programming with Unix pipes 4 Programming CMOS with Unix pipes 4 Tacit programming with FP 50 Non-TCO recursive example 50 TCO recursive example 51 The importance of recursion 52 Various intermediate and terminal functions 53 Reduce example 54 Intermediate functions 54 Common intermediate functions 55 Map Example 55 Terminal functions 56 Common terminal functions 56 Join example 56 GroupBy example 57 Reduce example 57 Predicates 57 Reflection 60 Combinator pattern 61 Map and filter 61 Contains 67 Iterating over a collection of cars 6 The empty interface 6 The Contains() method 6 If Go had generics 70 Map function 71 Testing our empty interface-based Map function 71 Itertools 72 Go channels used by the New function 74 Testing itertool's Map function 74 Testing iterators for element equality 75 Functional packages 76 Another time of reflection 76 Go is awesome 76 Go is awesome, but 76 The cure 77 Gleam - distributed MapReduce for Golang 77 LuaJIT's FFI library 7 Unix pipe tools 7 Processing Gleam collections 7 Summary 0 Chapter 3: Using High-Order Functions 1 Characteristics of FP 1 Function composition 2 Monads allow us to chain continuations 3 Generics 4 First-class functions 5 Closure 6 Dynamically scoped 7 Pure function Immuable Data Persistent data structures for Go Use of expressions 101 Sample HOF application 101 The chapter4 application code 102 Build and runtime instructions 103 More application code 104 The Filter function 105 Reality check 106 FilterFunc 107 Filter function 107 RESTful resources 10 Chaining functions 10 More cars 110 Reality check 110 The Map function 111 Improved performance from the Map function 112 The Reduce function 113 More high-order functions 114 Generators 115 RESTful server 116 The GenerateCars function 116 Currying Goroutine 11 A closer look at currying 11 Extending our currying example 120 Using a WaitGroup variable to manage concurrency 121 Finishing up the GenerateCars function 121 Handling concurrency 122 The final HOF example 123 Summary 124 Chapter 4: SOLID Design in Go 125 Why many Gophers loath Java 125 More reasons for loathing Java 127 Digging deeper into error handling 12 A conversation - Java developer, idiomatic Go developer, FP developer 12 Software design methodology 132 Good design 133 Bad design 134 Good versus bad design over time 134 SOLID design principles 135 Single responsibility principle 136 Function composition 13 Open/closed principle 13 Open / close principle in functional programming 141 FantasyLand JavaScript specification 142 Setoid algebra 142 Ord algebra 143 The expression problem 143 Liskov substitution principle 144 This OOP method stinks 144 Our FP function smells like roses 145 In FP, contracts don't lie 146 Duck typing 150 What can go wrong with inheritance? 150 Interface segregation principle 152 Dependency inversion principle 152 The big reveal 153 MapReduce 154 MapReduce example 155 What else can Monads do? 157 Viva La Duck 15 Pass by value or reference? 161 Type embedding with Go interfaces 163 Interface embedding to add minor features 164 A Go error handling idiom 164 It's time to run our program 165 Summary 16 Chapter 5: Adding Functionality with Decoration 16 Interface composition 170 Go's complimentary Reader and Writer interfaces 170 Example usages of the Reader and Writer interfaces 171 Design with Duck Typing 171 More reasons to design using interfaces 172 Using the Reader and Writer interfaces 174 Decorator pattern 176 Type hierarchy UML 177 How Procedural design compares to functional Inversion of Control (IoC) 17 Procedural design example 17 Functional IoC example 17 A decorator implementation 10 The main.go file 10 The decorator/simple_log.go file 12 Example InitLog calls 13 Back to our main package 14 Understanding our statistics using the easy-metrics GUI 17 Quick look at the Dot Init update 1 Easy-metrics - 1 of 3 1 The decorator/decorator.go file 10 A framework to inject dependencies 11 Wrapping a client request with decorators (in main) 11 Authorization decorator 12 Logging decorator 12 LoadBalancing decorator 13 Strategy pattern 13 Inversion of control and dependency injection 15 Our first failure 16 Easy metrics - 2 of 3 16 Groking our trace log file 17 The rest of the graph 1 Easy metrics - 3 of 3 1 Examining the trace log 200 The decorator/requestor.go file 200 The job variable declared in main() 201 Back to the requestor.go file 201 Using channels to manage the life cycle 202 All requests done 204 Launching our makeRequest goroutine 204 Our DI framework in action 205 Summary 206 Chapter 6: Applying FP at the Architectural Level 207 Application architectures 20 What is software architecture? 20 Client-server architecture 20 Cloud architecture 210 Why does architecture matter? 211 The role of systems engineering 212 Real systems 212 IT system specialty groups 212 Systems engineering is lean 213 Requirements, scope and terms 213 Defining terms 213 Software requirements 214 System 214 System architecture 214 System elements 214 System Boundaries 214 Managing Complexity 214 The best tool for the job 215 Divide and conquer 215 Designing for state management 216 Add a microservice 216 FP influenced architectures 21 Domain Driven Design 21 Dependency rule 220 Cyclic dependency 221 Working code 221 Code with cyclic dependency error 222 The Golang difference 223 Solution for cyclic dependencies 224 Domain Driven Design 224 Interface-driven development 225 Hollywood principle 226 Observer pattern 226 Dependency injection 22 A cloud bucket application 230 Directory structure 230 main.go 231 func HandlePanic 232 Dependency injection 233 func main() 234 Layers in the architecture 234 Domain layer 235 Use cases layer 240 Compatible interfaces 242 Interfaces layer 244 Why global variables are bad 252 Format the response 253 Testing our interfaces 25 Infrastructure layer 262 Context object 264 Benefits of DDD 266 Adaptability 266 Sustainability 267 Testability 267 Comprehensibility 267 A solid architectural foundation 267 FP and Micyoservices 267 Message passing 26 All parties must participate 26 Communication across boundaries 26 Polyglot Persistence 26 Lambda architecture 270 Speed 270 Batch 270 Servicing 271 Next generation big data architecture 271 CQRS 271 Benefits of CQRS 272 Infrastructure architecture 273 Share nothing architecture 274 Integrating services 274 Agreed upon protocol 274 Circuit breakers 274 Functional reactive architecture 275 Go is ideal for building microservices 276 Size matters 277 Benefits of gRPC 27 Who is using Go? 27 Summary 27 Chapter 7: Functional Parameters 20 Refactoring long parameter lists 21 What's wrong with a function signature with more than seven parameters? 21 Refactoring - the book 22 Edsger W. Dijkstra says OOP is a bad idea 23 What else did Edsger W. Dijkstra say? 24 The underlying OOP problem 26 OOP inconsistency 27 Functional programming and cloud computing 27 A closer look at f(x) 2 A closer look at refactoring 2 Passing every parameter a function requires to do its job is not a good idea 2 Methods can query other objects' methods internally for data required to make decisions 20 Methods should depend on their host class for needed data 20 Pass a whole object with required attributes to reduce the number of required parameters 20 Replace parameter with method technique to reduce the number of required parameters 21 Before applying Replace Parameter with Method technique 21 After applying Replace Parameter with Method technique 21 Use a parameter object when we have unrelated data elements to pass 21 Long parameter lists will change over time and are inherently difficult to understand 23 The solution 24 Three ways to pass multiple parameters 25 Simply passing multiple parameters 25 Passing a configuration object/struct that contains multiple attributes 25 Partial application 26 Functional parameters 27 Contexts 301 Context limitations 304 Report example 305 Writing good code is not unlike a good game of soccer 305 Functional parameters - Rowe 307 Report example 307 A more practical Context use case 307 src/server/server.go 30 The src/server/server_options.go file 315 Summary 31 Chapter : Increasing
Recommended publications
  • What I Wish I Knew When Learning Haskell
    What I Wish I Knew When Learning Haskell Stephen Diehl 2 Version This is the fifth major draft of this document since 2009. All versions of this text are freely available onmywebsite: 1. HTML Version ­ http://dev.stephendiehl.com/hask/index.html 2. PDF Version ­ http://dev.stephendiehl.com/hask/tutorial.pdf 3. EPUB Version ­ http://dev.stephendiehl.com/hask/tutorial.epub 4. Kindle Version ­ http://dev.stephendiehl.com/hask/tutorial.mobi Pull requests are always accepted for fixes and additional content. The only way this document will stayupto date and accurate through the kindness of readers like you and community patches and pull requests on Github. https://github.com/sdiehl/wiwinwlh Publish Date: March 3, 2020 Git Commit: 77482103ff953a8f189a050c4271919846a56612 Author This text is authored by Stephen Diehl. 1. Web: www.stephendiehl.com 2. Twitter: https://twitter.com/smdiehl 3. Github: https://github.com/sdiehl Special thanks to Erik Aker for copyediting assistance. Copyright © 2009­2020 Stephen Diehl This code included in the text is dedicated to the public domain. You can copy, modify, distribute and perform thecode, even for commercial purposes, all without asking permission. You may distribute this text in its full form freely, but may not reauthor or sublicense this work. Any reproductions of major portions of the text must include attribution. The software is provided ”as is”, without warranty of any kind, express or implied, including But not limitedtothe warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authorsor copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, Arising from, out of or in connection with the software or the use or other dealings in the software.
    [Show full text]
  • NOVEMBER 18 • WEDNESDAY Build Stuff'15 Lithuania
    Build Stuff'15 Lithuania NOVEMBER 18 • WEDNESDAY A Advanced B Beginner I Intermediate N Non­Technical 08:30 – 09:00 Registration 1. Alfa Speakers: Registration 09:00 – 09:15 Welcome talk 1. Alfa Speakers: Welcome talk 09:00 – 18:00 Open Space 6. Lobby Speakers: Open Space Sponsors: 4Finance, Devbridge, Storebrand, Visma Lietuva, WIX Lietuva 09:15 – 10:15 B Uncle Bob / Robert Martin @unclebobmartin ­ The Last Programming Language 1. Alfa Speakers: Uncle Bob / Robert Martin For the last 50 years we’ve been exploring language after language. Now many of the “new” languages are actually quite old. The latest fad is “functional programming” which got it’s roots back in the 50s. Have we come full circle? Have we explored all the different kinds of languages? Is it time for us to finally decide on a single language for all software development? In this talk Uncle Bob walks through some of the history of programming languages, and then prognosticates on the future of languages. 10:15 – 10:35 Coffee/tea break 1. Alfa Speakers: Coffee/tea break 10:35 – 11:30 I Dmytro Mindra @dmytromindra ­ Refactoring Legacy Code 5. Theta Speakers: Dmytro Mindra Every programmer has to face legacy code day after day. It might be ugly, it might look scary, it can make a grown man cry. Some will throw it away and try rewriting everything from scratch. Most of them will fail. Refactoring legacy code is a much better idea. It is not so scary when you take it in very small bites, introduce small changes, add unit tests.
    [Show full text]
  • The Best of Both Worlds?
    The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge Thesis submitted for the degree of Master in Informatics: Programming and Networks 60 credits Department of Informatics Faculty of mathematics and natural sciences UNIVERSITY OF OSLO Autumn 2019 The Best of Both Worlds? Reimplementing an Object-Oriented System with Functional Programming on the .NET Platform and Comparing the Two Paradigms Erik Bugge © 2019 Erik Bugge The Best of Both Worlds? http://www.duo.uio.no/ Printed: Reprosentralen, University of Oslo Abstract Programming paradigms are categories that classify languages based on their features. Each paradigm category contains rules about how the program is built. Comparing programming paradigms and languages is important, because it lets developers make more informed decisions when it comes to choosing the right technology for a system. Making meaningful comparisons between paradigms and languages is challenging, because the subjects of comparison are often so dissimilar that the process is not always straightforward, or does not always yield particularly valuable results. Therefore, multiple avenues of comparison must be explored in order to get meaningful information about the pros and cons of these technologies. This thesis looks at the difference between the object-oriented and functional programming paradigms on a higher level, before delving in detail into a development process that consisted of reimplementing parts of an object- oriented system into functional code. Using results from major comparative studies, exploring high-level differences between the two paradigms’ tools for modular programming and general program decompositions, and looking at the development process described in detail in this thesis in light of the aforementioned findings, a comparison on multiple levels was done.
    [Show full text]
  • On the Cognitive Prerequisites of Learning Computer Programming
    On the Cognitive Prerequisites of Learning Computer Programming Roy D. Pea D. Midian Kurland Technical Report No. 18 ON THE COGNITIVE PREREQUISITES OF LEARNING COMPUTER PROGRAMMING* Roy D. Pea and D. Midian Kurland Introduction Training in computer literacy of some form, much of which will consist of training in computer programming, is likely to involve $3 billion of the $14 billion to be spent on personal computers by 1986 (Harmon, 1983). Who will do the training? "hardware and software manu- facturers, management consultants, -retailers, independent computer instruction centers, corporations' in-house training programs, public and private schools and universities, and a variety of consultants1' (ibid.,- p. 27). To date, very little is known about what one needs to know in order to learn to program, and the ways in which edu- cators might provide optimal learning conditions. The ultimate suc- cess of these vast training programs in programming--especially toward the goal of providing a basic computer programming compe- tency for all individuals--will depend to a great degree on an ade- quate understanding of the developmental psychology of programming skills, a field currently in its infancy. In the absence of such a theory, training will continue, guided--or to express it more aptly, misguided--by the tacit Volk theories1' of programming development that until now have served as the underpinnings of programming instruction. Our paper begins to explore the complex agenda of issues, promise, and problems that building a developmental science of programming entails. Microcomputer Use in Schools The National Center for Education Statistics has recently released figures revealing that the use of micros in schools tripled from Fall 1980 to Spring 1983.
    [Show full text]
  • Handout 16: J Dictionary
    J Dictionary Roger K.W. Hui Kenneth E. Iverson Copyright © 1991-2002 Jsoftware Inc. All Rights Reserved. Last updated: 2002-09-10 www.jsoftware.com . Table of Contents 1 Introduction 2 Mnemonics 3 Ambivalence 4 Verbs and Adverbs 5 Punctuation 6 Forks 7 Programs 8 Bond Conjunction 9 Atop Conjunction 10 Vocabulary 11 Housekeeping 12 Power and Inverse 13 Reading and Writing 14 Format 15 Partitions 16 Defined Adverbs 17 Word Formation 18 Names and Displays 19 Explicit Definition 20 Tacit Equivalents 21 Rank 22 Gerund and Agenda 23 Recursion 24 Iteration 25 Trains 26 Permutations 27 Linear Functions 28 Obverse and Under 29 Identity Functions and Neutrals 30 Secondaries 31 Sample Topics 32 Spelling 33 Alphabet and Numbers 34 Grammar 35 Function Tables 36 Bordering a Table 37 Tables (Letter Frequency) 38 Tables 39 Classification 40 Disjoint Classification (Graphs) 41 Classification I 42 Classification II 43 Sorting 44 Compositions I 45 Compositions II 46 Junctions 47 Partitions I 48 Partitions II 49 Geometry 50 Symbolic Functions 51 Directed Graphs 52 Closure 53 Distance 54 Polynomials 55 Polynomials (Continued) 56 Polynomials in Terms of Roots 57 Polynomial Roots I 58 Polynomial Roots II 59 Polynomials: Stopes 60 Dictionary 61 I. Alphabet and Words 62 II. Grammar 63 A. Nouns 64 B. Verbs 65 C. Adverbs and Conjunctions 66 D. Comparatives 67 E. Parsing and Execution 68 F. Trains 69 G. Extended and Rational Arithmeti 70 H. Frets and Scripts 71 I. Locatives 72 J. Errors and Suspensions 73 III. Definitions 74 Vocabulary 75 = Self-Classify - Equal 76 =. Is (Local) 77 < Box - Less Than 78 <.
    [Show full text]
  • Applicative Programming with Effects
    Under consideration for publication in J. Functional Programming 1 FUNCTIONALPEARL Applicative programming with effects CONOR MCBRIDE University of Nottingham ROSS PATERSON City University, London Abstract In this paper, we introduce Applicative functors—an abstract characterisation of an ap- plicative style of effectful programming, weaker than Monads and hence more widespread. Indeed, it is the ubiquity of this programming pattern that drew us to the abstraction. We retrace our steps in this paper, introducing the applicative pattern by diverse exam- ples, then abstracting it to define the Applicative type class and introducing a bracket notation which interprets the normal application syntax in the idiom of an Applicative functor. Further, we develop the properties of applicative functors and the generic opera- tions they support. We close by identifying the categorical structure of applicative functors and examining their relationship both with Monads and with Arrows. 1 Introduction This is the story of a pattern that popped up time and again in our daily work, programming in Haskell (Peyton Jones, 2003), until the temptation to abstract it became irresistable. Let us illustrate with some examples. Sequencing commands One often wants to execute a sequence of commands and collect the sequence of their responses, and indeed there is such a function in the Haskell Prelude (here specialised to IO): sequence :: [IO a ] → IO [a ] sequence [ ] = return [] sequence (c : cs) = do x ← c xs ← sequence cs return (x : xs) In the (c : cs) case, we collect the values of some effectful computations, which we then use as the arguments to a pure function (:). We could avoid the need for names to wire these values through to their point of usage if we had a kind of ‘effectful application’.
    [Show full text]
  • Learn You a Haskell for Great Good! © 2011 by Miran Lipovača 3 SYNTAX in FUNCTIONS 35 Pattern Matching
    C ONTENTSINDETAIL INTRODUCTION xv So, What’s Haskell? .............................................................. xv What You Need to Dive In ........................................................ xvii Acknowledgments ................................................................ xviii 1 STARTING OUT 1 Calling Functions ................................................................. 3 Baby’s First Functions ............................................................. 5 An Intro to Lists ................................................................... 7 Concatenation ........................................................... 8 Accessing List Elements ................................................... 9 Lists Inside Lists .......................................................... 9 Comparing Lists ......................................................... 9 More List Operations ..................................................... 10 Texas Ranges .................................................................... 13 I’m a List Comprehension.......................................................... 15 Tuples ........................................................................... 18 Using Tuples............................................................. 19 Using Pairs .............................................................. 20 Finding the Right Triangle ................................................. 21 2 BELIEVE THE TYPE 23 Explicit Type Declaration .......................................................... 24
    [Show full text]
  • There Is No Fork: an Abstraction for Efficient, Concurrent, and Concise Data Access
    There is no Fork: an Abstraction for Efficient, Concurrent, and Concise Data Access Simon Marlow Louis Brandy Jonathan Coens Jon Purdy Facebook Facebook Facebook Facebook [email protected] [email protected] [email protected] [email protected] Abstract concise business logic, uncluttered by performance-related details. We describe a new programming idiom for concurrency, based on In particular the programmer should not need to be concerned Applicative Functors, where concurrency is implicit in the Applica- with accessing external data efficiently. However, one particular tive <*> operator. The result is that concurrent programs can be problem often arises that creates a tension between conciseness and written in a natural applicative style, and they retain a high degree efficiency in this setting: accessing multiple remote data sources of clarity and modularity while executing with maximal concur- efficiently requires concurrency, and that normally requires the rency. This idiom is particularly useful for programming against programmer to intervene and program the concurrency explicitly. external data sources, where the application code is written without When the business logic is only concerned with reading data the use of explicit concurrency constructs, while the implementa- from external sources and not writing, the programmer doesn’t tion is able to batch together multiple requests for data from the care about the order in which data accesses happen, since there same source, and fetch data from multiple sources concurrently. are no side-effects that could make the result different when the Our abstraction uses a cache to ensure that multiple requests for order changes. So in this case the programmer would be entirely the same data return the same result, which frees the programmer happy with not having to specify either ordering or concurrency, from having to arrange to fetch data only once, which in turn leads and letting the system perform data access in the most efficient way to greater modularity.
    [Show full text]
  • An Introduction to Applicative Functors
    An Introduction to Applicative Functors Bocheng Zhou What Is an Applicative Functor? ● An Applicative functor is a Monoid in the category of endofunctors, what's the problem? ● WAT?! Functions in Haskell ● Functions in Haskell are first-order citizens ● Functions in Haskell are curried by default ○ f :: a -> b -> c is the curried form of g :: (a, b) -> c ○ f = curry g, g = uncurry f ● One type declaration, multiple interpretations ○ f :: a->b->c ○ f :: a->(b->c) ○ f :: (a->b)->c ○ Use parentheses when necessary: ■ >>= :: Monad m => m a -> (a -> m b) -> m b Functors ● A functor is a type of mapping between categories, which is applied in category theory. ● What the heck is category theory? Category Theory 101 ● A category is, in essence, a simple collection. It has three components: ○ A collection of objects ○ A collection of morphisms ○ A notion of composition of these morphisms ● Objects: X, Y, Z ● Morphisms: f :: X->Y, g :: Y->Z ● Composition: g . f :: X->Z Category Theory 101 ● Category laws: Functors Revisited ● Recall that a functor is a type of mapping between categories. ● Given categories C and D, a functor F :: C -> D ○ Maps any object A in C to F(A) in D ○ Maps morphisms f :: A -> B in C to F(f) :: F(A) -> F(B) in D Functors in Haskell class Functor f where fmap :: (a -> b) -> f a -> f b ● Recall that a functor maps morphisms f :: A -> B in C to F(f) :: F(A) -> F(B) in D ● morphisms ~ functions ● C ~ category of primitive data types like Integer, Char, etc.
    [Show full text]
  • It's All About Morphisms
    It’s All About Morphisms Uberto Barbini @ramtop https://medium.com/@ramtop About me OOP programmer Agile TDD Functional PRogramming Finance Kotlin Industry Blog: https://medium.com/@ ramtop Twitter: @ramtop #morphisms#VoxxedVienna @ramtop Map of this presentation Monoid Category Monad Functor Natural Transformation Yoneda Applicative Morphisms all the way down... #morphisms#VoxxedVienna @ramtop I don’t care about Monads, why should I? Neither do I what I care about is y el is to define system behaviour ec Pr #morphisms#VoxxedVienna @ramtop This presentation will be a success if most of you will not fall asleep #morphisms#VoxxedVienna @ramtop This presentation will be a success if You will consider that Functional Programming is about transformations and preserving properties. Not (only) lambdas and flatmap #morphisms#VoxxedVienna @ramtop What is this Category thingy? Invented in 1940s “with the goal of understanding the processes that preserve mathematical structure.” “Category Theory is about relation between things” “General abstract nonsense” #morphisms#VoxxedVienna @ramtop Once upon a time there was a Category of Stuffed Toys and a Category of Tigers... #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 1) A collection of Objects #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 2) A collection of Arrows #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 3) Each Arrow works on 2 Objects #morphisms#VoxxedVienna @ramtop A Category is defined in 5 steps: 4) Arrows can be combined #morphisms#VoxxedVienna
    [Show full text]
  • Visual Programming Language for Tacit Subset of J Programming Language
    Visual Programming Language for Tacit Subset of J Programming Language Nouman Tariq Dissertation 2013 Erasmus Mundus MSc in Dependable Software Systems Department of Computer Science National University of Ireland, Maynooth Co. Kildare, Ireland A dissertation submitted in partial fulfilment of the requirements for the Erasmus Mundus MSc Dependable Software Systems Head of Department : Dr Adam Winstanley Supervisor : Professor Ronan Reilly June 30, 2013 Declaration I hereby certify that this material, which I now submit for assessment on the program of study leading to the award of Master of Science in Dependable Software Systems, is entirely my own work and has not been taken from the work of others save and to the extent that such work has been cited and acknowledged within the text of my work. Signed:___________________________ Date:___________________________ Abstract Visual programming is the idea of using graphical icons to create programs. I take a look at available solutions and challenges facing visual languages. Keeping these challenges in mind, I measure the suitability of Blockly and highlight the advantages of using Blockly for creating a visual programming environment for the J programming language. Blockly is an open source general purpose visual programming language designed by Google which provides a wide range of features and is meant to be customized to the user’s needs. I also discuss features of the J programming language that make it suitable for use in visual programming language. The result is a visual programming environment for the tacit subset of the J programming language. Table of Contents Introduction ............................................................................................................................................ 7 Problem Statement ............................................................................................................................. 7 Motivation..........................................................................................................................................
    [Show full text]
  • Keir, Paul G (2012) Design and Implementation of an Array Language for Computational Science on a Heterogeneous Multicore Architecture
    Keir, Paul G (2012) Design and implementation of an array language for computational science on a heterogeneous multicore architecture. PhD thesis. http://theses.gla.ac.uk/3645/ Copyright and moral rights for this thesis are retained by the author A copy can be downloaded for personal non-commercial research or study, without prior permission or charge This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the Author The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the Author When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given Glasgow Theses Service http://theses.gla.ac.uk/ [email protected] Design and Implementation of an Array Language for Computational Science on a Heterogeneous Multicore Architecture Paul Keir Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computing Science College of Science and Engineering University of Glasgow July 8, 2012 c Paul Keir, 2012 Abstract The packing of multiple processor cores onto a single chip has become a mainstream solution to fundamental physical issues relating to the microscopic scales employed in the manufac- ture of semiconductor components. Multicore architectures provide lower clock speeds per core, while aggregate floating-point capability continues to increase. Heterogeneous multicore chips, such as the Cell Broadband Engine (CBE) and modern graphics chips, also address the related issue of an increasing mismatch between high pro- cessor speeds, and huge latency to main memory.
    [Show full text]