HN user

hazelnut-tree

628 karma
Posts89
Comments52
View on HN
dl.acm.org 2y ago

Do developers know how to use Git commands? A large-scale study (2022)

hazelnut-tree
3pts2
www.youtube.com 2y ago

Why programming languages matter [video]

hazelnut-tree
74pts124
www.researchgate.net 2y ago

A theory of instruction for introductory programming skills (2019) [pdf]

hazelnut-tree
2pts0
habr.com 2y ago

Lua: Interview with Roberto Ierusalimschy (2019)

hazelnut-tree
1pts0
www.youtube.com 2y ago

Niklaus Wirth on the importance of abstraction to language design (2018) [video]

hazelnut-tree
3pts1
www.youtube.com 2y ago

I tried to an object-oriented program (C#) in a non-OOP language (Go) [video]

hazelnut-tree
2pts1
dl.acm.org 2y ago

Issues in programming language design: an overview (1975) [pdf]

hazelnut-tree
3pts0
www.semanticscholar.org 2y ago

Practical guidelines for the readability of IT-architecture diagrams (2002)[pdf]

hazelnut-tree
2pts0
computeradsfromthepast.substack.com 2y ago

Interviews with Donald Knuth and Niklaus Wirth from 1985

hazelnut-tree
3pts0
clp.bbcrewind.co.uk 2y ago

Programming Language choices: Pascal, LOGO, Forth, Prolog, C (1986) [video]

hazelnut-tree
80pts34
dl.acm.org 2y ago

GRASE: Graphical syntax-directed editor for structured programming (1984) [PDF]

hazelnut-tree
5pts0
dl.acm.org 2y ago

Flowcharting by stepwise refinement (1978) [pdf]

hazelnut-tree
5pts1
livebook.manning.com 2y ago

Complexity of object-oriented programming (book chapter one, 2022)

hazelnut-tree
2pts0
www.youtube.com 2y ago

Smalltalk: Object Orientation is not about objects, it's about messaging [video]

hazelnut-tree
3pts0
www.youtube.com 2y ago

Matthew Carter and typefaces: Bell Centennial, Verdana, Georgia (2014) [video]

hazelnut-tree
2pts0
users.monash.edu 2y ago

Seven deadly sins of introductory programming language design (1996) [pdf]

hazelnut-tree
6pts1
quorumlanguage.com 2y ago

A quick primer on human-factors evidence in programming language design

hazelnut-tree
4pts1
www.youtube.com 2y ago

Modular programming: Most think they do it but hardly anyone does [video]

hazelnut-tree
2pts3
flint.cs.yale.edu 3y ago

C. Hoare: Hints on programming language design (1973) [pdf]

hazelnut-tree
30pts6
dl.acm.org 3y ago

Contextualized programming language documentation (2022) [pdf]

hazelnut-tree
1pts1
dl.acm.org 3y ago

Ada and C: differences as the language for system programming (1993) [pdf]

hazelnut-tree
39pts16
clearleft.com 3y ago

Starting design work in a spreadsheet

hazelnut-tree
123pts34
www.youtube.com 3y ago

Four principles of object oriented programming [video]

hazelnut-tree
2pts2
pixelambacht.nl 3y ago

Optical size, the hidden superpower of variable fonts (2021)

hazelnut-tree
2pts0
kixlab.github.io 3y ago

Beyond instructions: a taxonomy of information types in how-to videos [pdf]

hazelnut-tree
1pts0
cacm.acm.org 3y ago

Why is it difficult for developers to learn another programming language? (2020)

hazelnut-tree
2pts0
www.frontiersin.org 3y ago

Comparing comprehension of a long text read in print book and on Kindle (2019)

hazelnut-tree
1pts0
www.youtube.com 3y ago

Drawing and business communication: explain anything to anybody (2022) [video]

hazelnut-tree
3pts0
www.cl.cam.ac.uk 3y ago

Concepts in Programming Languages (University of Cambridge lecture slides) [pdf]

hazelnut-tree
1pts0
luismendo.medium.com 3y ago

The iPad is the new sketchbook (2020)

hazelnut-tree
3pts0

From paper:

Introduction

- Git comes with a disputed and discussed issue about whether it is easy to learn.

- Some developers say Git is difficult to learn; Git commands are often used, but not fully understood.

- Three of the top-five questions on SO are about Git commands. The top question, “How do I undo the most recent local commits in Git,” has more than 22k votes and 9m views. This suggests there is some confusion about the use of Git commands.

Popularity of Git-related questions

There are 80,000 Git command-related questions on Stack Overflow from 2008 to 2020. The percentage of Git command-related questions and questioners has remained relatively stable. Meanwhile, Git command-related questions on Stack Overflow have higher average numbers of views, favorites, and scores.

Do Git questions come from novices or experienced developers?

After 2017, about 40% of the questioners of Git command-related questions had been registered for more than four years at the time of asking the questions, compared to that over 50% of all questioners on Stack Overflow had been registered for less than 2 years.

This suggests that even developers with years of development experience can have trouble using Git commands.

What Git commands are more popular among the questions asked by developers?

Git commands (e.g., git revert and git reflog) about recovery are among the most popular commands asked, followed by supporting Git commands (e.g., git clean and git help), and commands for branching and conflict resolution (e.g., git mergetool and git branch). Git commands are often used in combination to fulfill tasks.

Command difficulty

In terms of the percentage of questions with no accepted answers, some of the seldom used Git commands (e.g., git pack-redundant and git http-push) are ranked high.

Commands that are asked in quite a number of questions with low percentages of accepted answers (e.g., git credential and git submodule) tend to be those can be used in complex scenarios.

How do developers learn to use Git commands? (Responses from qualitative survey)

Most respondents (from both the academia and the industry) considered their expertise level of using Git commands to be only advanced beginner or competent. A vast majority (81.7%) of all the learning approaches used by our respondents were self-learning (i.e., from the internet and the documentation). Many respondents stressed the importance of understanding Git basic concepts and principles first.

Video description:

How can you create a class hierarchy in a language that doesn’t have classes? The Go (Golang) language doesn’t have classes and doesn’t do inheritance so when I tried to write an adventure game in Go, it looked as though I wouldn’t be able to get very far.

I’ve previously written adventure game sin object oriented languages such as Java and C#. In those languages I can create class hierarchies in which one class (say a Room) inherits the features of another class (say Thing) and adds on any new features. Go doesn’t let me do that……or does it?

In this video, I show how I created a ‘class hierarchy’ in Go even though it doesn’t have classes and so, in principle, it shouldn’t be possible to create a class hierarchy.

Abstract:

"This paper describes a flowchart technique, which supports the method of program development by stepwise refinement. Flowcharts made by this technique have a tree structure, which simplifies program test and coding the chart into a programming language. For design of the overall control structure the basic forms concatenation, selection, repetition and restricted GOTO statements are available."

Video description:

"What is modularity? Dividing code into separate files? No! Hiding data? Well, up to a point...protecting implementation details? Well, that’s a bit nearer the mark. But what does that really mean? How do you protect the implementation details of a module or an object? And why does it matter?"

"In this lesson, I look at some of the ideas and the history of modular programming. From Smalltalk to Modula-2, and onwards to C#, Ruby, Java and Object Pascal, I’ll try to explain what modularity is and why your code will be more reliable if you make use of it."

A summary at the end of the video:

"There is no one clear definition of modularity. Modules mean different things in different languages and different things to different programmers."

"But when I talk about modularity I mean a style of programming in which the internal details of an object both its data and its code are sealed off from the code outside that object. And to communicate with an object you have to use precisely defined ways into and out of that object. In some languages those ways into and out may be declared as interfaces. To an object-oriented language like Smalltalk the interfaces to an object are provided by methods that respond to messages."

Preface to the paper:

"This paper must clearly be read in the context of its date of composition (1973). The relative weight of comment on debugging and reasoning about programs clearly changed as a result of his own later research. Also, a richer notion of types would be appropriate today. But the sound advice in this paper transcends any minor aspects in which it might be considered to be out of date."

Discussed in the paper:

- Simplicity

- Security

- Fast translation

- Efficient object code

- Readability

- Comment conventions

- Syntax

- Arithmetic expressions

- Program structures

- Variables

- Block structure

- Procedures and parameters

- Types

- Language-feature design

From the paper:

We describe a system, 'ExplainThis', that automatically generates contextualized language documentation, structured based on our study of language documentation but specialized to the particular code at the cursor.

This system is integrated into the structure editor of Hazel (https://hazel.org/), a live functional environment.

----

Potential use cases of 'ExplainThis' include code reading and comprehension (e.g. a user trying to understand existing functions in a library or examples in instructor-created tutorials); writing new code (e.g. a user trying to modify starter code to complete an assignment); or debugging (e.g. a user trying to understand unexpected behavior of a function).

Polymorphism and inheritance: simple or complex ideas? Or is meaning depending on the lanuage? I really like the following video: OOP principles (and why so much jargon).

The four principles of object oriented programming (what they are and why they are wrong!) https://www.youtube.com/watch?v=YpYLXq4htKY

Abstraction, Polymorphism, Inheritance and Encapsulation… Yikes! What the heck does all that mean and why should anyone care?

Programming is full of jargon. Object Oriented Programming takes jargon to a whole new level. But even so, that list of the “four fundamentals of object oriented programming” is missing something important. In this video, I explain what the four principles are. And I then explain why they are making a big deal out of something that is essentially quite simple."

Later in the video:

I'd say polymorphism is probably a hundred dollar word for a 50 cent idea. These days computer science teachers and writers have extended the meaning of polymorphism to such an extent that it's often hard to figure out what the heck they're trying to describe.

Video description:

"Abstraction, Polymorphism, Inheritance and Encapsulation… Yikes! What the heck does all that mean and why should anyone care?

Programming is full of jargon. Object Oriented Programming takes jargon to a whole new level. But even so, that list of the “four fundamentals of object oriented programming” is missing something important. In this video, I explain what the four principles are. And I then explain why they are making a big deal out of something that is essentially quite simple."

Later in the video:

"I'd say polymorphism is probably a hundred dollar word for a 50 Cent idea. These days computer science teachers and writers have extended the meaning of polymorphism to such an extent that it's often hard to figure out what the heck they're trying to describe"

Although I have not read DEC's (Digital Equipment Corporation) documentation, but I've come across a 1990 book that mentions DEC's approach to documentation:

Digital Equipment Corporation noted in their 1983 internal documentation guidelines that user documentation should be written first — not last as is traditionally done — because the user documentation is an excellent way to debug the design of a system or a program. “If a writer finds it difficult to document a system, the problem is probably the system not the writer. Holes in design, obscure constructions, and apparent contradictions become starkly visible in the documentation.”

(From book: Writing better computer user documentation, 1990)

There is something very appealing about learning a small(ish) language. However, a small language does not always mean simple. And it means code can be difficult to unravel.

Niklaus Wirth, the creator of Pascal, Modula-2 and Oberon, believe strongly that teaching programming is most effective when students can grasp the entirety of a small language.

From a 2018 interview with Wirth on the topic:

"In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in."

"That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge."

Summary:

Four main kinds of videos on the edX platform (2014):

- Recorded classroom lecture

- Instructor's talking head

- Khan-style digital tablet drawing (popularized by Khan Academy)

- PowerPoint slideshow

Main findings and corresponding recommendations:

1. Shorter videos are much more engaging. Engagement drops sharply after 6 minutes

2. Videos that intersperse an instructor’s talking head with PowerPoint slides are more engaging than showing only slides

3. Videos produced with a more personal feel could be more engaging than high-fidelity studio recordings

4. Khan-style tablet drawing tutorials are more engaging than PowerPoint slides or code screencasts

5. Even high-quality prerecorded classroom lectures are not as engaging when chopped up into short segments for a MOOC

6. Videos where instructors speak fairly fast and with high enthusiasm are more engaging

7. Students engage differently with lecture and tutorial videos

Video summary (from a Rust-focussed YouTube channel)

"We're going to compare Rust to seven other languages that you probably haven't tried. Each and every one of these seven languages gave me a different surprise that I didn't see coming."

- Rust

- Nim

- Julia

- Elixir

- Zig

- Haskell

- Lua

- Crystal

Challenge: "The program we're going to implement reads a line of space to limited numbers from standard input, and process some of those numbers. It's a simple program but one that quickly surfaces the idiosyncrasies of a programming language"

Impressions from the presenter:

- Most concise language: Haskell

- Coolest language features: Elixir's pipe operator

- Most underrated languages: Nim and Crystal

Disclaimer: "It's important to note that this isn't really a fair comparison. Each of these languages caters to a specific need. And in a sense we're comparing them in a way that some might consider surface level. But you do need to look at the surface at some point."

The Quorum programming language was originally designed for blind children. The language scope has expanded to appeal to all children.

https://quorumlanguage.com/

Although the language is not widely known, the language creator posted to Hacker News in 2018:

Hi all, this is Andreas Stefik (I invented Quorum)....First, people saying Quorum was originally designed for blind children are correct. Originally, we were toying with the idea of adjusting syntax to make it easier to read out loud through a screen reader. That stemmed from observing young blind programmers use a variety of programming languages on one of my first National Science Foundation projects. Phrases like, “for int I equals semicolon, I less then semicolon I plus plus” or other phrases can be extraordinarily difficult to listen to, especially if you are child.

This is one reason why Quorum is used so heavily at schools for the blind or visually impaired in the U.S. and elsewhere. We haven’t been just for the blind in a long-time, but I still care about that community quite a bit and we work hard to make things accessible. There’s a ton more to discuss in that area, but I want to move on to “evidence."

Full comment: https://news.ycombinator.com/item?id=17849357

Presentation description:

"Ten years ago, only Linux kernel committers and other early adopters used Git. Almost everyone else used Subversion. Ten years later, Git is the most popular product. Which makes me wonder: what will we use another ten years from now? And what features would YOU want from your version control software in 2032? No history rewrites? Faster? No merge conflicts ever?"

Here's an high-level overview. There's more detail in the video.

Why is Git so popular?

- Git in 2010 = 25% usage

- Git in 2021 = 75% usage

Fossil:

- Distributed version control, bug tracking, wiki, forum

- Contributions from a team of 4 vs Git with 5000+ contributions

- Written in C and SQL - supports SQLite version control

- Website: https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki

Pijul:

- Distributed version control, sound theory of patches

- Focus on changes, instead of differences between snapshots (i.e. Git commits)

- Written in Rust, bootstrapped in 2017

- Website: https://pijul.org/

I still think the biggest user interface (UI) change from Microsoft was the change from Windows 3.1 to Windows 95. There were so many features and improvements e.g. the re-designed Open/Save dialog (not much changed since then). Later versions of Windows have never made the same leap between new versions of Windows. Sure, there are refined or tweaked features (or regressed!), but each new version of Windows felt like an incremental update from the previous version.

I think the next leap in UI and visual design from Microsoft was...Windows Phone 8 (2012). It was a refreshing and different approach to mobile design. The visual language 'Metro' worked well on mobile touch screens. But Microsoft took the bad decision to transplant 'Metro' (flat design) to the desktop. The result is a clumsy, jumble of inconsistent screens. It simply doesn't work.

A partial summary of the paper:

- How can documentation be "user-friendly" to many different types of users: from very sophisticated programmers to brand new computer users?

- How useful are things like: reference cards, illustrations, extensive examples, sample sessions?

These are some of the questions in this short paper about (printed) documentation from Microsoft.

A focus group of thirty-four participants with varying computer experience were recruited to provide feedback on documentation on word processing, spreadsheets, database management systems, and programming language products.

Tutorials

- Everyone (including the programmers) want tutorials that show how to use the product or programming language.

- End-users also want tutorials for completing specific or common tasks.

Illustrations

- Programmers are mostly indifferent to pictures (I wonder if this is true today among programmers?). For end-users, illustrations are essential - especially program screenshots.

Reference

- Everyone agrees they want a "phone book" i.e. a book that tells everything about the product, including "tricks" and shortcuts.

- The programmers emphasise that any examples, especially sections of sample code, must include annotations to be useful.

Cookbook

- The cookbook includes models for solving many types of problems and for performing many types of tasks. (Interesting to note: in 1984 the term "cookbook" was a new, unfamiliar term in the context of documentation, but today is a familiar documentation pattern.)

- The "cookbook" potentially bridges the gap between tutorial and reference manual.

In conclusion, ideal documention looks like:

1. Tutorial

2. Cookbook

3. Reference

---

There is a lot detail in the paper. This an excellent, readable paper. And it hasn't aged much despite being written in 1983.

Finally, the title of the paper "Those Silly Bastards" is a quote from a programmer who participated in the research. From the paper:

I want to finish by explaining the title of this paper - "Those Silly Bastards." During the focus group on programming languages, one of the programmers said:

They obviously are trying to give you something, but those silly bastards don't know what they are trying to do. Just give us a complete, accurate manual that tells us everything we need to know.

There's a pep talk for you.

This story is unclear and possibly misleading from the posted image. There are three versions of Adobe PDF software:

- Adobe Reader desktop app (free and lets you rotate PDF pages)

- Adobe Pro desktop app (full PDF editing and requires subscription)

- Adobe PDF online (requires a free account and lets you rotate PDF pages: https://www.adobe.com/acrobat/online.html)

You can still rotate PDF pages using the Reader desktop app. However, as other posters have recommended, there are many alternative PDF apps. Avoid Adobe if you can.

I agree. In fact, many open source (and closed source) codebases are understood by only a handful of developers with deep understanding of the design and code (e.g. the original developer or a developer with many contributions). The rest of us (including me) have a superficial understanding of the code at best. There's even a word that developers use to describe popular open source frameworks: 'magic'. A euphemistic way to say: 'I have no-idea how the code fit together, but this code library or framework is popular and it all works'.

There are not many languages (in active use) with a small surface area. Go is small, Lua is another. However, a small language does not always mean simple - you may still encounter code that is difficult to unravel.

New programming languages tend to range from medium-to-large in size.

Here are number of keywords in some languages. Note: this is a bit of a blunt measure of a language's size so you may not consider it a measure of small surface area:

- Lua (21 keywords)

- Go (25 keywords)

- Julia (30+ keywords)

- Python (30+ keywords)

- Javascript (30+ keywords)

- Ruby (40+ keywords)

- Crystal (50+ keywords)

- Rust (50+ keywords)

- Nim (60+ keywords)

- C# (70+ keywords)

- PHP (70+ keywords)

Languages still in development

- Odin (30+ keywords)

- V lang (40+ keywords)

- Zig (40+ keywords)

Topics from the talk:

- Design goal: make it easy to write code that works with version 1 and 2

- No pointless syntax games

- Stricter compiler, better defaults

- Based on the code base of version 1: evolution, not revolution

- Nim 2 release: 2022

Some new features:

- object fields with default values

- more precision in how values are initialised

- overload enums

- ORC: the default for memory management in Nim 2

- and more...

The iPad and Apple Pencil are hugely popular for artists and designers. The leading iPad app for digital painting is Procreate. (Adobe are late to the game with their own painting app called Fresco. However, Adobe has failed to dent the popularity of Procreate.)

There is also a wide variety of design apps for the iPad (e.g. Clip Paint Studio, Affinity Designer, Affinity Photo).

The Apple Pencil offers superb pressure sensitivity - why the iPad is so popular for artists, illustrators and designers.

An extract from the video:

The value of the information technology itself is unproven in the last 20 years. The number of office workers has almost trebled. However, research has failed to find any significant increases in office productivity. Perhaps because it's almost impossible to measure.

There's still a lot of paper about - an estimated thousand billion sheets a year in America alone. And so many office activities remain largely unaffected by technology because they depend on people talking to colleagues: telephoning, reading, and writing things, going to meetings, even thinking.

Though not so obvious as it used to be, the traditional office hierarchy still exists. The conflict between the need to control what the staff do, and the need to motivate them by allowing them freedom still remains.

Perhaps all this high technology is really no closer to creating the perfect office and the scientific management techniques of the 1920s. I suspect the efficiency of an office is really more dependent on the personalities of the people who work there, and how well they all get on with each other.

The related paper:

Inky: a sloppy command line for the web with rich visual feedback

Abstract: We present Inky, a command line for shortcut access to common web tasks. Inky aims to capture the efficiency benefits of typed commands while mitigating their usability problems. Inky commands have little or no new syntax to learn, and the system displays rich visual feedback while the user is typing, including missing parameters and contextual information automatically clipped from the target web site. Inky is an example of a new kind of hybrid between a command line and a GUI interface. We describe the design and implementation of two prototypes of this idea, and report the results of a field study.

https://dspace.mit.edu/handle/1721.1/51696

These websites are readable without JavaScript (note: some videos may fail to load):

- BBC News (for UK readers): https://www.bbc.co.uk/news

- BBC Weather: https://www.bbc.co.uk/weather (includes international cities)

- Sky News (UK): https://news.sky.com/

- GOV.UK (UK government services and information): https://www.gov.uk/

- Related to GOV.UK: Building a resilient frontend using progressive enhancement (2019) - https://www.gov.uk/service-manual/technology/using-progressi...

- England Coronavirus (COVID-19) dashboard: https://coronavirus.data.gov.uk/

- NHS (National Health Service): https://www.nhs.uk/

- Nitter (open source alternative Twitter front-end with no JavaScript): https://nitter.net/

- Reddit (old mobile version that still works): https://i.reddit.com/

- Smashing Magazine: https://www.smashingmagazine.com/

- Related to Smashing Magazine: I used the Web for a day with JavaScript turned off (2018) - https://www.smashingmagazine.com/2018/05/using-the-web-with-...

I also dislike Adobe and many of their products. But my impression is the majority of Adobe apps continue to dominate their market sectors.

I use the Affinity apps (Designer, Photo and Publisher) but even Affinity have made little dent on equivalent Adobe apps. However, Affinity have carved out a slice of the market with apps that are successful, profitable, and no subscription.

Adobe's UI design app 'Adobe XD' is one of the few Adobe apps to trail behind their competitors: Sketch and Figma.

Figma is also much more than just a UI design tool. You can create virtual whiteboards, brainstorm sessions and virtual classrooms - far ahead in collaboration features compared to Adobe XD and Sketch. Figma is even encroaching on the territory of apps like 'Miro' (a popular online collaborative whiteboard tool).

Adobe also has single Adobe ID sign-on for their products. I assume Adobe ID will integrate into Figma as some time in future. Will they force Figma users to switch to Adobe IDs?

Adobe's plan for Figma shows if you can't beat a rival, you buy the competition.

(An aside: 'Procreate' on the iPad is a digital painting app where, once again, Adobe is chasing the competition with their own digital painting app called 'Fresco'. Adobe's app has failed to dent Procreate's massive popularity.)

Some extracts from the video (the full video has much more detail):

---

Rust

"It borrows great proven concepts from other languages like, for example, algebraic data types. It makes sure that the language constructs don't lead to slow or inefficient code. Rust calls it zero cost abstractions."

"There's also no compromise regarding memory safety. This must not be delegated to the programmer - it must be inherent in the language. Rust tries to tackle the problem of mutable state with heavy restrictions where the state can be modified through the borrow checker. The resulting programs are easier to reason about, albeit harder to write. Architecture must not be an afterthought. However, there are also some downsides in Rust: some functionality which is easy to achieve in other languages might be rather hard."

---

Nim

"One can write highly efficient code in such a simple way. The code is easy to read and really a pleasure to look at. It's compiled to C but can also be compiled to JavaScript."

"Nim's memory management is deterministic and customizable and it even follows some move semantics which are inspired by C++ and Rust and it's therefore also suited for embedded and hard real-time systems you can even choose which garbage collector runs."

"Nim also has a powerful macro system and you can actually directly manipulate the abstract syntax tree and therefore you can create your own domain specific languages."

---

Vale

"It's a brand new language currently still in its alpha version."

"Vale is fast. It uses LLVM as a compiler back-end, it's statically typed and it uses so-called 'generational references'. It's a technique for memory safety. Soon it will have a region borrow checker to make it even faster (and because it uses generational references). It's also safe and it also has fearless foreign function interface, and of course Vale strives to be easy and memory safe."

"Generational references: they are a memory management technique which allows for easy deterministic and very fast memory access so generational references are built on the concept of single ownership (that you might already know from Rust)."

---

The future

"We're kind-of stuck with the mainstream languages. The future looks bright - so many interesting concepts, so many new and better ways of doing things. Makes me curious and I can't wait to see the future impact of such languages."

Examples of the quizzes have been added to The Rust Book.

Experiment: Improving the Rust Book: https://rust-book.cs.brown.edu/

A small but interesting detail: the quizzes open as a full-screen in the Rust book. The explanation:

Why is this quiz fullscreen?

We want to know how much you are learning that can be recalled without assistance. Please complete the quiz without re-reading the text.