Write up on Tech geek history: Logo Programming Language”Turtle”

logo-1

Literature Review:

A logic Program is typically, a collection of Clauses that consist of preconditions for running the clause and a should be taken. Matching exercises in a Cognitive Compression way to develop a child’s brain to think Logically and Mathematically even about Reading Compression.

Designed for Fuzzy Logic in A.I in advanced way to train Human Interactions and Brain Cognitive and Generally how Programming works

#35. In context which of the following would NOT improve sentence 14

Whatever their experience, I believe that more and more women are playings, sports today, than ever before did play sports, and I think that is has many positive consequences for LARGER SOCIETY

  1. Delete “ I believe that:
  2. Delete “than ever before did play sports.”
  3. Delete: I think that “
  4. Insert the word” trend: after “this.:
  5. Replace “many” with : alot of .”

Imagine if utilized Daydreamin Comics with a computational abstraction: in OCR( optical character recognition) a child’s imagination of reading a comic book or literature give a survey of comments to what the context of the story was about, not knowing it , training for great reading compression. example

COMMENT BOX AND ABOVE IS THE FOLLOWING:

  1. Delete “ I believe that:
  2. Delete “than ever before did play sports.”
  3. Delete: I think that “
  4. Insert the word” trend: after “this.:
  5. Replace “many” with : alot of .”

Computational Abstractions

Introduction

Pupils should be taught to: design, use and evaluate computational abstractions that model the state and behavior of real-world problems and physical systems.

In computer science, abstraction is the process by which data and programs are defined with a representation similar in form to its meaning (semantics), while hiding away the implementation details. Abstraction tries to reduce and factor out details so that the programmer can focus on a few concepts at a time. A system can have several abstraction layers whereby different meanings and amounts of detail are exposed to the programmer refines the definition of computational thinking to six concepts: a thought process, abstraction, decomposition, algorithmic design, evaluation, and generalization. All of these concepts are employed in problem solving processes. Again, the emphasis in this list of concepts is on thought processes, not the production of artefacts or evidence.

The Computing Progression Pathways (Dorling and Walker, 2014) is an example of a non-statutory assessment framework. It was produced by a small team of authors and reviewers, all teachers, based on their classroom experiences. It is an interpretation of the breadth and depth of the content in the 2014 national curriculum for computing program of study. It includes the dependencies and interdependencies between concepts and principles. This may help non-specialist teachers and inexperienced teachers to understand what should be taught in the classroom. It is publicly available at this link: 

Evidence of assessing computational thinking Given that computational thinking concepts have been defined (Selby and Woollard, 2013) and an assessment framework for the computing program of study has been proposed (Dorling and Walker, 2014), a mapping can be developed to illustrate how computational thinking can be assessed over the full breadth and depth of the computing programme of study.

2.3. Problem solving techniques.

2.3.1. Introduction Now, it’s easy to write down these stages but harder to see how they apply in practical problem solving for programming.

Significance of the Study:

Logo is a programming language that was developed in the late 1960s by a team of researchers at Bolt, Beranek and Newman (BBN) led by Wally Feurzeig, Seymour Papert, and Cynthia Solomon.

The language was designed to be a simple and intuitive tool for teaching children the principles of computer programming. The development of Logo was closely tied to the field of artificial intelligence (AI) and the broader movement to make computers more accessible to the general public.

Feurzeig, Papert, and Solomon were all influenced by the work of the pioneering AI researcher Marvin Minsky, who believed that children could learn to think logically and computationally if they were given the right tools.

At the time, most programming languages were designed for use by professional programmers, and were considered too difficult for children to learn. Logo was different in that it was designed to be simple and intuitive, with a focus on using graphics and turtle-based commands to create simple programs and animations.

The first version of Logo was implemented on a DEC PDP-1 computer, using a turtle as a visual representation of the cursor. The turtle could be moved around the screen by giving it commands in Logo, allowing children to create simple drawings and animations.

This innovative approach to teaching programming quickly gained popularity, and by the early 1970s, Logo was being used in schools around the world.

In the 1980s, it was adapted for use on home computers, including the Apple II and the Commodore 64, and became widely accessible.

One of the key features of Logo is its use of English-like commands, which made it easy for children to learn and use. This was a major departure from other programming languages of the time, which were often difficult for non-experts to understand.

Over the years, Logo has evolved and been implemented on a variety of different platforms, including personal computers and mobile devices.

One of the most famous uses of Logo was the development of the first widely-used educational robotics platform, the LEGO Mindstorms system. Using the Logo programming language, students were able to create simple programs that could control LEGO robots and make them move, turn, and interact with their environment.

In the decades since its inception, the Logo programming language has evolved and grown in complexity, but it remains a popular choice for educators looking to introduce children to the world of computer programming.

The Logo Programming Language, a dialect of Lisp, was designed as a tool for learning. Its features — modularity, extensibility, interactivity, and flexibility — follow from this goal.

For most people, learning Logo is not an end in itself, and programming is always about something. Logo programming activities are in mathematics, language, music, robotics, telecommunications, and science. It is used to develop simulations, and to create multimedia presentations and games. Logo is designed to have a “low threshold and no ceiling”: It is accessible to novices, including young children, and also supports complex explorations and sophisticated projects by experienced users.

The most popular Logo environments have involved the Turtle, originally a robotic creature that sat on the floor and could be directed to move around by typing commands at the computer. Soon the Turtle migrated to the computer graphics screen where it is used to draw shapes, designs, and pictures.

Some turtle species can change shape to be birds, cars, planes, or whatever the designer chooses to make them. In Logo environments with many such turtles, or “sprites” as they are sometimes called, elaborate animations and games are created.

Out Into the World

Widespread use of Logo began with the advent of personal computers during the late 1970s. The MIT Logo Group developed versions of Logo for two machines: The Apple ][ and the Texas Instruments TI 99/4. The Logo language itself was similar in both versions, but the video game hardware of the TI 99/4 lent itself to action-oriented projects, while the Apple version was best suited to turtle graphics, and language projects.

In 1978 a pilot project sponsored by MIT and Texas Instruments was begun at the Lamplighter School in Dallas, Texas with 50 computers and a student population of 450. In 1980 the Computers in Schools Project was initiated by the New York Academy of Sciences and Community School Districts 2, 3, and 9 in New York City, and supported by Texas Instruments and MIT. Twelve TI 99/4 computers were placed in six New York City Public Schools. These were later joined by a few Apple ][s.

Both projects offered teachers extensive training and support through intensive two-week Summer Institutes and follow-up workshops during the school year.

These projects have had lasting results. Theresa Overall, who was a leader in both the Dallas and New York workshops, continued to teach Logo at Lamplighter and to offer summer workshops. Michael Tempel, then of the New York Academy of Sciences is now President of the Logo Foundation, a nonprofit organization that provides Logo professional development and support services to schools and districts throughout the world, including New York City Community School District 3. Two of the teachers who represented that district in the original project, Peter Rentof and Steve Siegelbaum, went on to form the Computer School, one of the District’s alternative middle schools where Logo is still in use today.

The prototype Logo implementations used in those pioneering projects evolved into commercial products. TILOGO was released by Texas Instruments. Terrapin Software, a company that was set up in 1977 to distribute robot floor Turtles, licensed the Apple ][ version of MIT Logo and has marketed it and upgraded it to this day.

A new company, Logo Computer Systems, Inc. (LCSI) was formed in 1980. Many of the researchers, teachers, programmers, and writers who were involved in this venture have played major roles in the subsequent development of Logo. Seymour Papert is LCSI’s chairman. Brian Silverman was Director of Research and guided the development of all of LCSI’s products. Cynthia Solomon, who was on the team that created the original Logo in 1967, headed up LCSI’s first development office in Boston and later directed the Atari Cambridge Research Center. Michael Tempel provided educational support services from LCSI’s New York City office for ten years until he started the Logo Foundation in 1991.

LCSI developed Apple Logo, followed by versions for a host of other computers. With commercial availability, Logo use spread quickly.

Another important event occurred in 1980 – the publication of Seymour Papert’s Mindstorms . Teachers throughout the world became excited by the intellectual and creative potential of Logo. Their enthusiasm fueled the Logo boom of the early 1980s.

New versions of Logo were implemented in more than a dozen spoken languages on a variety of machines, many with video game style graphics and sound capabilities. Logo for MSX computers was popular in Europe, South America, and Japan. Atari Logo and Commodore Logo were popular in North America.

Logo received considerable support from mainstream computer manufacturers. Apple Computer marketed LCSI’s Apple Logo and, at one point, bundled it with the computers given away to each school in California. IBM marketed LCSI’s IBM Logo and Logo Learner.

Atari not only distributed Atari Logo, but set up the ambitious Atari Cambridge Research Center under the direction of Cynthia Solomon.

By the mid 1980’s the computers with video game capabilities had dropped off the market and taken their versions of Logo with them. MSDOS machines increasingly dominated the world of educational computing, except in the United States where Apple was the school favorite. Logo developers concentrated on these machines. Although new implementations added features and took advantage of the increased speed and memory of newer computers, the most popular versions of Logo in use in 1985 were similar to those of 1980.

Around this time there was also some interest in using Logo as a “serious” programming language, especially for the new Macintosh computer. MacLogo from LCSI added new functionality to the Logo environment. Coral Software, developed an object-oriented version of Logo called Object Logo. It included a compiler which allowed programs to run at higher speed, and stand-alone applications could be created. But Logo did not become popular among applications programmers.

Innovation

In 1985 Logo Computer Systems, Inc. introduced LogoWriter, which was novel in several ways. First, it included word processing capability – hence the name. Second, the user interface was simplified and made more intuitive. LogoWriter also included, as the earlier “sprite” Logos had, multiple turtles that could take on different shapes, although in this area the Apple and IBM computers on which LogoWriter ran were no match for the earlier game machines. LogoWriter was implemented in many spoken languages and became popular throughout the world.

Another innovation of the mid-eighties was LEGO LogoMitchel Resnick and Steve Ocko, working at the MIT Media Lab, developed a system which interfaced Logo with motors, lights and sensors that were incorporated into machines built out of LEGO bricks and other elements. Robotics systems with Logo were not new, but the popular and well-supported LEGO TC Logo was a commercial success which reached thousands of teachers and their students.

It was around this time that a unique series of Logo conferences took place at MIT. Beginning with LOGO ’84 and continuing for two more years with LOGO ’85 and LOGO ’86, these meetings brought a worldwide community together at Logo’s unofficial home.

In 1988 the Programa Informática Educativa was initiated in Costa Rica by the Omar Dengo Foundation, the Ministry of Public Education, and IBM Latin America. This project put Logo in the hands of most of Costa Rica’s elementary school students and their teachers. A similar project was initiated in Costa Rica’s secondary schools.

The Costa Rican projects have provided extensive teacher education and support with a strong emphasis on Logo’s contructionist educational approach. They have been taken as models for similar endeavors in a dozen other Latin American countries. Through the 1990s Latin American Logo enthusiasts came together every two years in a different country for the Congreso Logo.

In Japan, Logo saw growing acceptance in the country’s schools where the original LogoWriter, then the enhanced LogoWriter2, and then LogoWriter Win were the most popular versions.

In England, Logo was a mandated part of the national curriculum. This guaranteed that Logo was widely, if not necessarily well used. England is also the birthplace of the extinct Valiant Turtle and the Roamer.

There are Logo hot spots throughout Europe where there is a biennial EuroLogo conference. Now renamed, this conference was most recently held in Vienna, Austria as Constructionism 2014. European Logo software developments have included WinLogo in Spain and Comenius Logo from Slovakia.

New Developments during the 1990s

A new version of Logo called MicroWorlds was released in 1993 by LCSI. It embodied major changes both in the Logo environment and the Logo language. It included many extra-Logo features – drawing tools, a shape editor, a melody maker, the ability to import graphics and sounds – that work along with Logo to support the creation of multimedia projects, games, and simulations. Microworlds has been upgraded several times and is available today as MicroWorlds EX.

MicroWorlds Logo includes a number of changes, the most significant being multi-tasking, or parallel processing. Several processes can be launched independently. This is invaluable when creating animations with more than one actor – the car can drive off a cliff while the dog wags its tail while the fat lady sings. This sort of thing is possible in a non-parallel Logo environment but it is far easier and more natural in MicroWorlds.

Control Lab and Control System were LEGO Logo products whose multi-tasking software was built on the same core as MicroWorlds.

Another LEGO Logo innovation was the Programmable Brick , a research project at MIT spearheaded by Fred Martin. Unlike earlier LEGO Logo products where the robot received instructions through wires connected to a computer, the Programmable Brick had a computer inside. A program written on a desktop or laptop computer could be downloaded to the Brick, which could then be detached from the host computer and run its program autonomously.

LEGO commercialized the programmable brick as the RCX and later the NXT, and now the EV3 in products called LEGO Mindstorms. Smaller versions of the Programmable Brick, called crickets, where also developed commercially as the Handy Cricket and PICO Cricket .

As part of the Programmable Brick project at the MIT Media Lab a new version of Logo called Logo Blocks was created.  Instead of writing lines of code in text, programs were built by snapping together jigsaw-like puzzle pieces.

A radically different Logo called StarLogo was introduced in 1994. It is a massively parallel version that was developed by Mitchel Resnick at MIT. Thousands of turtles can carry on independent processes and interact with each other and with patches of background. The system is specifically designed to facilitate the exploration of decentralized systems, emergent phenomena, and self organizing behavior. Resnick’s Turtles, Termites, and Traffic Jams is the source book on StarLogo and the ideas underlying its conception.

A similar program called NetLogo was developed by Uri Wilensky, who now heads the Center for Connected Learning at Northwestern University.

The 21st Century

In 2004 a new Logo programming environment called Scratch emerged from the Lifelong Kindergarten Group at the MIT Media Lab.  It uses the blocks programming paradigm that was originally implemented as Logo Blocks.  Scratch is well suited to designing and building interactive stories, animations, games, music, and art. It can gather information from the outside world via a sensor board connected to the computer. The Scratch Web site provides the focal point for a community of millions of users who have shared more than nine million projects.

Following from the popularity of Scratch, blocks programming has become widespread and is used in a number of other Logo applications including Turtle ArtScratch for ArduinoSnap!, and StarLogo TNG .

Meanwhile, traditional versions of Logo continue to be used.Brian Harvey, author of the three-volume classic Computer Science Logo Style wrote UCBLogo, a public domain version for Macintosh, MSDOS, and Unix.George Mills used the core of UCBLogo as the basis for his MSWLogo which runs under Windows with many enhancements that are possible in that operating system. FMSLogo is a more recent version of Logo based on MSWLogo.

After more than four decades of growth, Logo has undergone dramatic changes in step with the rapid pace of development in computer technology. The family of Logo environments is more divers than ever before.

Pavel Boytchev, who created Elica, has compiled the  Logo Tree, which lists all the versions of Logo, past and current, that he has information about. There are more than 300 of them.

Logo is a growing family of programming languages and a learning environments, and a worldwide community of people drawn together by a shared commitment to a constructivist educational philosophy.

To find out more about Logo you can continue to wander around this website and check out the links to other sites. 

Today, it is still widely used in schools and other educational settings as a tool for teaching computational thinking and problem-solving skills.

There are many different versions of Logo available, including versions that run on personal computers and mobile devices. Overall, the Logo programming language has played a significant role in the history of personal computing, and continues to be an important tool for teaching the next generation of computer programmers.

Despite its age, Logo remains an important part of the history of programming and continues to inspire new generations of programmers and computer scientists. It stands as a testament to the power of simple, intuitive tools for teaching complex concepts and encouraging children to think critically and creatively.

The Logo Programming Language, a dialect of Lisp, was designed as a tool for learning. Its features — modularity, extensibility, interactivity, and flexibility — follow from this goal.

For most people, learning Logo is not an end in itself, and programming is always about something. Logo programming activities are in mathematics, language, music, robotics, telecommunications, and science. It is used to develop simulations, and to create multimedia presentations and games. Logo is designed to have a “low threshold and no ceiling”: It is accessible to novices, including young children, and also supports complex explorations and sophisticated projects by experienced users.

The most popular Logo environments have involved the Turtle, originally a robotic creature that sat on the floor and could be directed to move around by typing commands at the computer. Soon the Turtle migrated to the computer graphics screen where it is used to draw shapes, designs, and pictures.

Some turtle species can change shape to be birds, cars, planes, or whatever the designer chooses to make them. In Logo environments with many such turtles, or “sprites” as they are sometimes called, elaborate animations and games are created.

Content of Problem:

Computational Abstractions

1.0

Pupils should be taught to:

design, use and evaluate computational abstractions that model the state and behaviour of real-world problems and physical systems.

In computer science, abstraction is the process by which data and programs are defined with a representation similar in form to its meaning (semantics), while hiding away the implementation details. Abstraction tries to reduce and factor out details so that the programmer can focus on a few concepts at a time. A system can have several abstraction layers whereby different meanings and amounts of detail are exposed to the programmer

refines the definition of computational thinking to six concepts: a thought process, abstraction, decomposition, algorithmic design, evaluation, and generalisation. All of these concepts are employed in problemsolving processes. Again, the emphasis in this list of concepts is on thought processes, not the production of artefacts or evidence

Computing Progression Pathways and describes how it can be used to acknowledge progression and reward performance in mastering both the computing programme of study content and computational thinking skills.

There is some debate about whether it is important that the arbitrary values of progression be standardized across schools. Naace (Harrison, 2014), in their guidance, indicate “…a school approach to assessment will need to be tailored to match their approach to the curriculum” (p. 1).

Alternatively, the National Association of Head Teachers (NAHT) propose when translating the national curriculum into assessment criteria “… there is little room for meaningful variety, we suggest this job be shared between schools” (2014, p. 10).

Whether it is designed by a single school or a collection of interested parties, an assessment framework is required by classroom practitioners.

The Computing Progression Pathways (Dorling and Walker, 2014) is an example of a non-statutory assessment framework. It was produced by a small team of authors and reviewers, all teachers, based on their classroom experiences.

 It is an interpretation of the breadth and depth of the content in the 2014 national curriculum for computing programme of study.

 It includes the dependencies and interdependencies between concepts and principles. This may help non-specialist teachers and inexperienced teachers to understand what should be taught in the classroom. It is publicly available at this link: 

The framework is grid-based.

Five of the six strands, represented as columns, are aligned with the range and content categories from the Computing at School curriculum (Computing at School, 2012) and the requirements of applicants to initial teacher training courses (DfE, 2012).

 These include algorithms, programming and development, data and data representation, hardware and processing, communication and networks.

The sixth strand incorporates the more traditional concept of information technology. This breadth affords an opportunity to view the subject of computing as a whole, rather than the separate subjects of Computer Science, Digital Literacy, and Information Technology.

 Each row represents a level of pupil progression. Annotation of the framework suggests that key stages 1-2 cover the first four levels (pink, yellow, orange, and blue), that key stages 3-4 cover the next four levels (purple, red, and black), and that GCSE covers the final level (white).

As an example, the purple cell under the “Hardware and Processing” strand states that a pupil “Recognises and understands the function of the main internal parts of basic computer architecture” (Dorling and Walker, 2014).

The colour-coded rows may aid teachers in assessing whether pupils are exhibiting competences at different levels and in recognizing achievement and attainment. In addition, adherence to the colour-coded statements can provide standardization across schools as identified by the NAHT (2014).

Institutions planning to use this assessment framework with existing assessment or reporting systems may: • assign values or levels to the coloured rows, • agree the benchmark value, level, or entry point for a particular key stage, assign the benchmark value or level to the appropriate progression statements.

The Computing Progression Pathways also affords opportunities to celebrate achievement in computing. There is a growing interest in badges as an informal recognition of skill, knowledge, understanding, or attitude.

They are made and awarded by commercial organisations, educational suppliers, websites, schools, teachers, and pupils (Hamilton and Henderson, 2013; Mozilla, 2014; Radiowaves Schools, 2014).

Recognizing and rewarding pupil achievement in each strand can be accomplished via coloured digital badges. Each strand can be assigned a separate digital badge. There may be two-tone badges for pupils working between coloured progression levels. Currently, there are no digital badge designs for the strands.

 Teachers and pupils who will be using the digital badge system are better placed to design and create them. The process of designing and creating the digital badges might promote learner ownership and student-centeredness (Reigeluth, 2013).

The computational thinking concepts of abstraction, decomposition, algorithmic design, evaluation, and generalisation have been abbreviated to the first two letters. Care has been taken by 3 iterations of expert evaluation of the statements to avoid making assumptions about how the teaching might afford opportunities for computational thinking rather than strictly interpreting what is explicitly stated in the Computing Curriculum Pathways.

 For example, an exercise in a classroom might afford opportunities to identify suitability for purpose and efficiency of input and output devices.

Table 1: Computational thinking and progression pathways in computing (Based on Dorling and Walker, 2014) Using this strategy of identifying computational thinking concepts associated with the pathways’ statements enables computational thinking to be assessed using the same framework as the programme of study. From a practitioner’s perspective, there is no additional assessment or progression tracking required to fulfil the broad aim of the computing programme of study to incorporate computational thinking.

Conclusion The computing programme of study (DfE, 2013b) includes the broad aim of incorporating computational thinking into the classroom.

The subject content is detailed in the document, but the connection to computational thinking and its meaning is not. Removal of the statutory assessment frameworks, which did not assess computational thinking, leaves a void in assessing pupils’ attainment.

Both of these shortcomings have been addressed in this paper. An understanding of 9 computational thinking, based on the work of Selby and Woollard (2013), has been established. An assessment framework, the Computing Progression Pathways, has been used to illustrate the dependencies and interdependencies between the concepts and principles of the programme of study (Dorling and Walker, 2014). This work has demonstrated how the Computing Progression Pathways can be used to evidence the assessment of computational thinking directly. By using the assessment framework to evidence progression, with its underlying support for computational thinking concepts, it is possible for the classroom practitioner to assess computational thinking without introducing additional complexity to the assessment process. However, this does raise questions around the provision for teachers of a framework for the pedagogy of computational thinking that aligns to this assessment approach

2.3. Problem solving techniques 2.3.1. Introduction Now, it’s easy to write down these stages but harder to see how they apply in practical problem solving for programming. It’s really not clear where to begin. Programming isn’t hard when you know how to solve the problem. It then becomes a matter of battling with the vagaries of language‐specific syntax, semantics and tools. For people new to programming, this language specific detail can become overwhelming, leading to a plethora of tiny, low level concerns at the expense of understanding how to solve an original problem. And there is curiously little material on problem solving and programming.  

For example, Wienberg’s (1971) classic study of the psychology of programming assumes that programming is an activity based on a specification that is elaborated from analysis, but says nothing about analysis itself. This echoes the then prevalent waterfall model of software development with distinct stages which are never revisited.

 One of the few books that ostensibly focuses on problem solving and programming, Dromey’s How to solve it by computer (Dromey, 1982), draws explicitly on Polya’s 1950 foundational study How to solve it (Polya, 1990) and on later work by Wickelgren (1974). Polya (pp5 & 6) characterises problem solving as a four stage process of: understanding the problem; linking unknowns to data to make a plan; carrying out the plan; looking back and reviewing the solution. He offers a long list of problem solving heuristics, many of which correspond to different aspects of CT (e.g. analogy, auxiliary problem, decomposing and recombining, do you know a related problem, specialisation) but doubts any systematic way of deploying them: ‘Rule of discovery. The first rule of discovery is to have brains and good luck.

 The second rule of discovery is to sit tight and wait till you get a bright idea. … To find unfailing rules applicable to all sorts of problems is an old philosophical dream; but this dream will never be more than a dream.’ (p172)

Nonetheless, Wickelgren attempts to provide a methodical approach to solving what he terms formal problems that is those couched in some formal notation, typically logical or mathematical. Wickelgren sees a problem as being specified as a starting state, a set of allowable operations over states, and a goal state. Thus, a solution is found by a sequence of state to state transitions leading from the start state to the goal state. Much of the book focuses on techniques for pruning the space of transitions, in particular reasoning backwards from the goal, but there is little on problem formulation. Dromey (1982) is a proponent of top down design and stepwise refinement, linking decomposition to algorithm, which we will consider briefly below. He also uses logical statements to capture properties of program stages, typically loop invariants.

While he acknowledges the central role of the choice of data structures in programming, he largely focuses on algorithm design, suggesting that structures are somehow chosen from a menu of JPD: 5:1:55   

 Journal of Pedagogic Development Volume 5, Issue 1 options. Despite acknowledging Polya’s and Winkelgren’s influences, Dromey has little to say about problem formulation. Still, we already have tried and tested techniques for teaching programming so why can’t we retrofit CT to what we do already? Let us now consider a range of these in slightly more detail, in inconsistently chronological order. Please note that much of the following is partial, anecdotal and superficial.

Effective Tool of Logical Programming in Curriculums for Highschool, and Middle Schools:

1.1  Learning Outcomes

In our LP course, we decided not to put emphasis into Prolog knowledge per-se (although

basic elements of the language should be taught), but to focus on all the above aspects. We

believe the students appreciate more the skills acquired through this course, which can be

used to change the mind-set of the programming task as a whole. By the end of the course

should be able to:

•  understand the basic principles of logic programming theory and symbolic reasoning,

•  demonstrate  good knowledge of the basic Prolog language by constructing small

programs,

•  make sense of more complicated Prolog programs, predict and describe what they do,

•  modify existing code to perform a similar task,

•  identify the advantages of declarative programming and evaluate its shortcomings in

comparison with imperative languages,

•  comprehend the basic principles of programming languages, like procedural abstraction,

program design and development, parameter passing, recursion, variable binding etc., 

•  adapt declarative programming techniques to other programming paradigms.

These learning outcomes are assessed through coursework and final examinations. 

1.2 Discrete Mathematics Preparation

Discrete Mathematics

Discrete mathematics is foundational material for computer science: Many areas of computer science require the ability to work with concepts from discrete mathematics, specifically material from such areas as set theory, logic, graph theory, combinatorics, and probability theory.

1.3 Common Lisp

The material in discrete mathematics is pervasive in the areas of data structures and algorithms but appears elsewhere in computer science as well. For example, an ability to create and understand a proof is important in virtually every area of computer science, including (to name just a few) formal specification, verification, databases, and cryptography.  Graph theory concepts are used in networks, operating systems, and compilers. Set theory concepts are used in software engineering and in databases.  Probability theory is used in artificial intelligence, machine learning, networking, and a number of computing applications.

Consequently, a Common Lisp program tends to provide a much clearer mapping between your ideas about how the program works and the code you actually write. Your ideas aren’t obscured by boilerplate code and endlessly repeated idioms. This makes your code easier to maintain because you don’t have to wade through reams of code every time you need to make a change. Even systemic changes to a program’s behavior can often be achieved with relatively small changes to the actual code. This also means you’ll develop code more quickly; there’s less code to write, and you don’t waste time thrashing around trying to find a clean way to express yourself within the limitations of the language.2

Common Lisp is also an excellent language for exploratory programming–if you don’t know exactly how your program is going to work when you first sit down to write it, Common Lisp provides several features to help you develop your code incrementally and interactively.

For starters, the interactive read-eval-print loop, which I’ll introduce in the next chapter, lets you continually interact with your program as you develop it. Write a new function. Test it. Change it. Try a different approach. You never have to stop for a lengthy compilation cycle.3

Other features that support a flowing, interactive programming style are Lisp’s dynamic typing and the Common Lisp condition system. Because of the former, you spend less time convincing the compiler you should be allowed to run your code and more time actually running it and working on it,4 and the latter lets you develop even your error handling code interactively.

Another consequence of being “a programmable programming language” is that Common Lisp, in addition to incorporating small changes that make particular programs easier to write, can easily adopt big new ideas about how programming languages should work. For instance, the original implementation of the Common Lisp Object System (CLOS), Common Lisp’s powerful object system, was as a library written in portable Common Lisp. This allowed Lisp programmers to gain actual experience with the facilities it provided before it was officially incorporated into the language.

Consequently, a Common Lisp program tends to provide a much clearer mapping between your ideas about how the program works and the code you actually write. Your ideas aren’t obscured by boilerplate code and endlessly repeated idioms. This makes your code easier to maintain because you don’t have to wade through reams of code every time you need to make a change. Even systemic changes to a program’s behavior can often be achieved with relatively small changes to the actual code. This also means you’ll develop code more quickly; there’s less code to write, and you don’t waste time thrashing around trying to find a clean way to express yourself within the limitations of the language.2

Common Lisp is also an excellent language for exploratory programming–if you don’t know exactly how your program is going to work when you first sit down to write it, Common Lisp provides several features to help you develop your code incrementally and interactively.

For starters, the interactive read-eval-print loop, which I’ll introduce in the next chapter, lets you continually interact with your program as you develop it. Write a new function. Test it. Change it. Try a different approach. You never have to stop for a lengthy compilation cycle.3

Other features that support a flowing, interactive programming style are Lisp’s dynamic typing and the Common Lisp condition system. Because of the former, you spend less time convincing the compiler you should be allowed to run your code and more time actually running it and working on it,4 and the latter lets you develop even your error handling code interactively.

Another consequence of being “a programmable programming language” is that Common Lisp, in addition to incorporating small changes that make particular programs easier to write, can easily adopt big new ideas about how programming languages should work. For instance, the original implementation of the Common Lisp Object System (CLOS), Common Lisp’s powerful object system, was as a library written in portable Common Lisp. This allowed Lisp programmers to gain actual experience with the facilities it provided before it was officially incorporated into the language.

A Language for Learning Mathematics Feurzeig’s Logo group began with education and worked back to the form of their language. Early Logo was very simple. Like Basic, it came with built-in editing and file manipulation commands. If these are ignored, the 1971 version consisted of just 26 ‘operations,’ five of which accessed the calendar and clock, and 15 ‘commands.’ Most operations were concerned with program logic or list manipulation. An essential part of the design was to produce a language of such simplicity that it forced users to write their own library of commonly used routines, such as multiplication and division.

From such a library, complex programs could be built. “Ideally, by the end of the course, each student would have created his own extended version of Logo” (Brown & Rubinstein, 1974, p.10). There is no mention of the degree of difficulty inherent in learning to program generally, and certainly not in learning Logo, in Feurzeig’s papers.

The entire emphasis in The Final Report (Feurzeig et al., 1969) is on the difficulty of learning Mathematics and how Logo was developed to make that easier. The programming language followed as a result of a specific educational need.

The designers of Logo intended it not only as a vehicle to express Mathematical ideas and make Mathematical concepts concrete, they saw it also as a meta-language in which to express Mathematical thought (Feurzeig et al., 1969, p.5). Here is the origin of Papert’s often expressed need to teach ‘thinking about thinking’ (Papert, 1971a, p.2) and the decision to write a computer language whose primitives and predicates inherently contained and expressed the mechanisms of logic and Mathematics. “Do we give children the instruction ‘think!’ without even telling them how to think?” (Papert, 1971a, p.4). The mathematical purpose expressed by Feurzeig is actually at odds with Papert who is at pains to stress the general problem solving capability of the language (Papert, 1971a; Papert & Solomon, 1971).

 Lisp’s origins in Artificial Intelligence were supposed to support this (Evans, 1992, p.14; Abelson et al., 1976, p.16), but no author we have read ever explained how it was to happen. The ‘Lo’ in Logo suggested ‘Logic,’ and the earliest versions of the Logo system were written in Lisp, a list processing language.

Many from the primary level, ages 7 to 9, are examples of programs to reverse the letters in a word, print a set of consecutive numbers or simply print strings.

 The first lessons did not involve writing code at all. This did not happen until Lesson Seven (p. 67). In the secondary curriculum, many essential elementary functions such as divide and multiply were written by the teachers and given to the students to try to understand (p. 215), the inference being that students could not be expected to write these routines themselves. Johnson (2000, p.201) found “The position that the programming environments themselves, e.g., Logo microworlds, would become the school mathematics curriculum has clearly failed to gain the support of the educational system.” The Educational Programming Language Logo: Its Nature and Its Use in Australia 397 None of this suggests a language easily taken up by beginners and used for their own purposes. Part of the reason has to be the use, initially, of recursion for all loops, definite or indefinite. Recursion is, as Papert has said repeatedly, a powerful problem solving tool (Papert, 1980; Papert, 1971a; Papert & Solomon, 1971; Papert, 2002) and indeed it is. But then, so is calculus! Papert’s work with Jean Piaget resulted in a passionate belief in the idea of ‘learn ing by doing,’ something he later extended to what might be termed ‘learning by making things.’ Papert in particular has always insisted that Logo is designed to encourage experimentation, with students writing and testing their own creations. Given this emphasis, it is difficult to understand the reliance on recursion at the expense of a general iterative statement. We can find nothing in the early literature that asserts that students can be expected to discover a recursive solution to a problem on their own.

All we can find are examples provided to students to explain, understand, and adapt. In his seminal book, Mindstorms, published in 1980, Papert states that “recursion stands out as the one idea that is particularly able to evoke an excited response.” That might be so, but he devotes less than two pages to it, mentioning it once more in the Appendix in the context of ‘circular logic’ (p109). Brown and Rubinstein suggest that with suitable prior experience, students can write their own recursive routine to tra

verse a tree, but these writers give no clue to their success rate. They did find that “if a student couldn’t figure out how to write a function, we could not slowly lead him down the path to discovery” (Brown & Rubinstein, 1974, p.43). Once acquainted with WHILE—DO in Basic or Pascal, or even the primitive Dartmouth-Basic GOTO, students have no trouble in writing their own indefinite loops (Murnane, 1991; Murnane, 1992). (See also McDougall, 1985.)

Enter the Turtle Even allowing for difficulty in conceptualizing recursion, Logo is not English, and in its early versions Logo struggled to make progress. The cure for many of these problems was provided by Seymour Papert.

 Logo is often associated specifically with Papert, and particularly with his Turtle Graphics. He joined the project in January 1969 as a consultant (Feurzeig et al., 1969, p.1) and his invention of the Turtle and its commands transformed the language. A Turtle is a small robot which, when connected to a computer, can move and turn on the floor. At a stroke this eliminated the gap between entering a program and observing its outcome, since the Turtle could execute a command as soon as it was entered. It also solved the problem of students understanding what the command did. While they might need to be taught the meaning of “TEST IS COUNT /SENTENCE/ 1 (Feurzeig et al., 1971, p.45) they could easily appreciate what FORWARD 100 meant because it accorded with their own body actions and their natural language.

History of Logo 79:5 (4) a collection of projects (5) a meta-language: a consistent way of talking about the language, the projects, etc. (6) a rich learning culture (7) a collection of “bridge activities” such as juggling and puzzle-solving All of these components are interdependent and the special virtues of the environment follow from their synergy. For example, one would expect very limited educational benefits to arise from merely teaching programming, even Logo programming, in a completely abstracted context, or from using turtles as toys without the insight one derives from the underlying computer culture. The design of the environment as a whole was strongly influenced by several ideas that are central to Logo work with young children: precedurization, anthropomorphization (Papert later talked about body syntonics), and debugging. Atimeline of notable Logo events is in

3.2 Aspects of Logo Taken Unchanged From Lisp Many aspects of Logo’s design weren’t the result of deliberate choices, but rather were taken for granted as part of Logo’s Lisp makes it possible for users to build language extensions, “little languages” with only a subset of Lisp’s capabilities, or language experiments in which some aspect of Lisp semantics is changed.

The Logo version of eval is called run. It takes only one input, an instruction list or expression list. In the latter case, run outputs the value of the expression. ? run [print “hello print “goodbye] hello goodbye ? print run [sum 2 3] 5 In the first example, the input to run is an instruction list containing two print instructions, which are carried out in order. In the second example, the input is an expression (only one is allowed), and run outputs the result, 5, which is then used as the input to print. Run takes only one input because environments are not first class in Logo.

 Since the goal is to turn children into mathematicians, not to turn them into computer scientists, teaching about environments isn’t one of the goals.

Most versions of Logo do not allow list mutation, so the sharing of structure in traditional linked lists is not problematic. The earliest versions of Logo had no data aggregation beyond text strings. But once the need for a general data aggregate was seen, Lisp-style lists were the obvious choice, because Logo inherits Lisp’s emphasis on recursion as the main control structure.

The only primitive iteration facility in Logo is the repeat command, which carries out a given set of instructions a fixed number of times. For anything more subtle, such as the equivalent of a for loop or a repeat-while loop, Logo uses recursion. With young children, Logo teachers sometimes start with a very simple infinite recursion, so the first version of a procedure to draw a circle would be to circle forward 5 right 1 circle end The turtle would keep tracing over the same circle until the child manually stops the program. (A disadvantage of this approach, especially for older learners, is that it encourages the idea that a recursive call means “go back to the beginning,” which can be hard to eradicate when a need for embedded recursion comes up.) With such heavy reliance on recursion as the idiom for

Although this is a minor syntactic change in the overall picture of Logo, the first thing that Lisp users notice is that the language is not fully parenthesized. Lay people have often singled out parentheses as their reason not to program in Lisp. Logo avoids this controversial notation.

 In Lisp, the notation for a procedure call is (procedure arg arg …). The parentheses around the call tell Lisp how many arguments are being supplied; even more important, since parentheses also delimit lists in Lisp, a Lisp program is already a data structure, so very little additional parsing is needed to implement Lisp in Lisp. In Logo, most procedures, primitive as well as user-defined, have fixed arity (that is, a fixed number of arguments). Parentheses are therefore not needed, as long as the interpreter knows the arity of all procedures. For example, the parsing of (print f g 1 2 3 4) depends on the arity of f and g. At one extreme, if they both take no arguments, then all the numbers are arguments to print. If each of f and g take two arguments, then the statement is equivalent to (print (f (g 1 2) 3) 4) The fact that the interpreter must know all procedure arities to parse a program means that Logo, very unusually, is not a context-free language, so the usual automated parser generators aren’t helpful. Logo documentation the arguments to a procedure are called “inputs.”

A procedure is a box with input hoppers on top and an output chute on the bottom. If this model is used in teaching Logo, the name output for the primitive that provides an output from its calling procedure is natural. Many Logo users have talked about this command as if it were a special aspect of the syntax, but it is syntactically just an ordinary procedure. Some later versions used report instead of output because many students confused output with print. The word “input,” by the way, is used in the Logo literature to mean both formal parameter and actual argument. When it’s necessary to make the distinction, one says “input name” or “input value,” respectively. But most often the meaning is clear from the context, and a goal of Logo design is to encourage children to focus on the mathematics—the meaning of the procedure they’re writing—rather than on the computer science. There have been Logo dialects that allow an expression by itself as implicitly providing a return value from the procedure in which it appears, but they are out of the mainstream. In most dialects, expressions are not allowed even in the top level interpreter loop:

Logo microworld is turtle geometry, a kind of differential geometry in which explorations can range from simple polygons for young children to non-Euclidean geometry and relativity for college students [Abelson and diSessa 1980]. But the first Logo microworld, strongly influencing its design, was English words and sentences (The name “Logo,” suggested by Wallace Feurzieg, comes from λόγoς, the Greek word for “word.”) Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 79. Publication date: June 2020. History of Logo 79:21 This choice came from Papert’s insight that elementary mathematics, the subject in which most previous experiments in programming for children focused, is something many children find difficult and painful. By contrast, every child can speak and understand English (or the child’s native language, whatever it is) and most enjoy playing with words, e.g., in nonsense poetry or word games such as Boggle. At first, words and sentences were represented as text strings in Logo, and indicated syntactically by the paired quotation marks that are still used for text strings in most programming languages. A text string was considered a sentence if it contained a space character, or a word otherwise. The selector first, for example, would output the first letter of a word, or the first word of a sentence; butfirst outputs all but the first letter, or all but the first word. This design was already revolutionary in abstracting away the task of searching for spaces in a string. But its obvious weakness is that it is impossible to represent a sentence of length one, so a procedure that butfirsts its way recursively through a sentence suddenly finds itself dealing with letters instead of with words. So the internal representation of sentences was changed to lists. As a result, first and butfirst for a sentence are just the Lisp car and cdr. (However, Logo also provides selectors last and butlast, which take O(n) time when applied to a singly linked Lisp-style list. This is a small illustration of the general principle that in a language for children efficiency isn’t important; children almost always operate on small data sets. What matters is the naturalness of the user interface, and there’s no reason to privilege the prefix of a word or sentence over its suffix. Think, as an example, about the algorithm to compute the plural of a word.) At the same time the notation was changed to “foo for a word (a compromise, using the open quote-only notation for a Lisp symbol but keeping the double-quote character familiar to children) and [foo bar] for a sentence (the square brackets both quote and delimit the sentence). Another advantage of double-quote instead of the Lisp single-quote to begin a symbol is that it doesn’t raise syntactic hurdles when dealing with words such as “I’m or “John’s. Logo later added the ability to nest square brackets, allowing lists of lists and thereby making Logo suitable for a study of data structures by older children. Some programmers object to Logo’s treatment of words and sentences because the same procedure, first for example, accepts both strings and lists as input. They would prefer two separate procedures, perhaps named first letter and first word, or perhaps word. First and sentence. First if the complainer likes object oriented programming. Our answer is that such complaints mean that the complainer is ignoring the data abstraction and thinking below the abstraction, at the underlying data types used in the implementation of Logo. Yes, strings and lists are quite different data types, and each should have its own selectors. But the abstract types “word” and “sentence” have a lot in common, and are part of the same linguistic microworld. It’s completely natural that they should share selectors; that sharing also has the pedagogic virtue of teaching a single recursive pattern in which the first piece of some aggregate is separated from the rest of the aggregate, with the latter used as input to a recursive call. Similarly, the sentence constructor feels very strange to a programmer who thinks in terms of primitive data types. It’s sort of like (apply append arguments), except that the domain of append is lists, while sentence accepts words as well as sentences (that is, strings as well as lists) as inputs. It’s actually equivalent to (define (sentence . args) (apply append (map (lambda (arg) (if (list? arg) arg (list arg))) args))) Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 79. Publication date: June 2020. 79:22 Solomon et al. But above the abstraction barrier, this is a perfectly natural behavior. “Sentence takes any number of words and sentences, and combines them into one big sentence.” 3.3.4 Logo Is a Lisp-2. Lisp systems are divided into two categories: Lisp-1 and Lisp-2. In a Lisp-1, there is only one namespace for all entities with names, including procedures among other kinds of data. In a Lisp-2, procedures have their own namespace, so the same symbol can name both a variable and an unrelated procedure.

Conclusion The computing programme of study (DfE, 2013b) includes the broad aim of incorporating computational thinking into the classroom.

The subject content is detailed in the document, but the connection to computational thinking and its meaning is not. Removal of the statutory assessment frameworks, which did not assess computational thinking, leaves a void in assessing pupils’ attainment.

Both of these shortcomings have been addressed in this paper. An understanding of 9 computational thinking, based on the work of Selby and Woollard (2013), has been established. An assessment framework, the Computing Progression Pathways, has been used to illustrate the dependencies and interdependencies between the concepts and principles of the programme of study (Dorling and Walker, 2014). This work has demonstrated how the Computing Progression Pathways can be used to evidence the assessment of computational thinking directly. By using the assessment framework to evidence progression, with its underlying support for computational thinking concepts, it is possible for the classroom practitioner to assess computational thinking without introducing additional complexity to the assessment process. However, this does raise questions around the provision for teachers of a framework for the pedagogy of computational thinking that aligns to this assessment approach

https://escholarship.org/content/qt1623m1p3/qt1623m1p3_noSplash_bf5f9ec7dd71bd2b44037fa047119301.pdf

Leave a Comment

Your email address will not be published. Required fields are marked *