Why Do We Need the C language in Programming Courses?

Katsuhiko Gondow and Yoshitaka Arahori

Department of Computing Science, Tokyo Institute of Technology, Tokyo, Japan

Keywords:

C Language, Programming Courses, Embedded/System Programming, Operating Systems, Language Pitfalls.

Abstract:

The C language is still one of the important programming languages both in development and in education,

since C has several positive characteristics like good abstraction for low-level programming, and fast execution

speed with less footprint, although C has several drawbacks and pitfalls like buffer overruns. So there are

several research studies to support C programming educations to compensate the C’s drawbacks and pitfalls,

but there is a skeptical view about these research direction: “C is a bad language, so it is better to stop

teaching C, instead of supporting C education”. In this position paper, we argue against this skeptical view,

mainly because C is very important in upper-level courses like embedded/system programming and operating

systems, so worth teaching.

1 INTRODUCTION

The C language is still one of the important program-

ming languages both in development and in educa-

tion, since C has several positive characteristics like

good abstraction for low-level programming, and fast

execution speed with less footprint, although C has

several drawbacks and pitfalls like buffer overruns.

So there are several research studies to sup-

port C programming educations to compensate the

C’s drawbacks and pitfalls (Uchida and Gondow,

2016)(Freund and Roberts, 1996)(Song et al., 1997)

(Osuka et al., 2012)(Kummerfeld and Kay, 2003),

but there is a skeptical view about these research di-

rection: “C is a bad language, so it is better to stop te-

aching C, instead of supporting C education”. In this

position paper, we argue against this skeptical view,

mainly because C is very important in upper-level

courses like embedded/system programming and ope-

rating systems, so worth teaching, although we admit

that the C language may not be suitable for a ﬁrst lan-

guage.

This paper is organized as follows. Section 2 pre-

sents the background of this position paper: the re-

ason why C is still used (Sec. 2.1), previous work

to support C programming education (Sec. 2.2), pre-

vious work to choose ﬁrst programming languages

(Sec. 2.3). Section 3 provides four C code examples

to show good abstraction in low-level programming.

In Section 4, our position “the C language is worth

teaching” is given. Section 5 provides the conclusion.

2 BACKGROUND

2.1 C Language and Its Uses in

Development

C is a general-purpose procedural programming lan-

guage, developed by D. Richie in 1973 (Ritchie,

1993). Over the 40 years, C has been widely used

as a system implementation language, being revised

through the three standards (C90/C99/C11). For ex-

ample, operating systems like Linux, language pro-

cessors like GCC and JVM, embedded systems, de-

vice drivers, Web servers like Apache are written in C.

In the TIOBE index (TIOBE, 2017) (a measure of po-

pularity of programming language), C has been ran-

ked ﬁrst or second from 2002 to 2017. Thus C is not

a legacy, but still an active programming language.

As is well known, C has a serious drawback;

C programmers are very likely to write insecure

code like buffer overruns since the compile/run-time

checking of C is very weak. Despite this drawback,

why so many developers use the C language instead

of a more modern, safer language like Java? The ans-

wer is that C has several advantages as below:

• C provides better abstraction than assembly lan-

guages. For example, in C, it is easy to pro-

gram low-level access to system or memory using

inline-assembler or pointer arithmetic. This is

the reason why operating systems, device dri-

vers, embedded systems are written in C. The

Gondow, K. and Arahori, Y.

Why Do We Need the C language in Programming Courses?.

DOI: 10.5220/0006837205490556

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 549-556

ISBN: 978-989-758-320-9

549

compile/run-time checking of C is weak on pur-

pose to allow this kind of low-level description in

• Most C programs run fast in less memory foot-

print. This is closely related to C’s weak run-time

checking. This is the reason why Web servers like

Apache or language processors like GCC are writ-

ten in C.

Thus the C language is indispensable to write ef-

ﬁcient and portable code, where assembly languages

are required or execution speed and less footprint are

important.

2.2 Previous Work to Support C

Programming Education

There are several previous works to support C pro-

gramming education as follows, to compensate C’s

weak compile-time/runt-time checking. One impor-

tant issue is that there is a skeptical view about this

research direction; “C is a bad language, so it is bet-

ter to stop teaching C, instead of supporting C educa-

tion.”

We argue against this skeptical view in Sec. 4.

• C-Helper (Uchida and Gondow, 2016) is a C sta-

tic checker of our previous work, that aims to

emit more direct error messages understandable

for novices to correct wrong programs, and also

aims to handle latent errors. As our another pre-

vious work (Kojima et al., 2015) indicated, war-

ning messages in commercial-level compilers like

GCC are often difﬁcult and misleading for novice

programmers. Our C-Helper tries to (partially)

solve this problem.

Listing 1: Example of assigning string to char array

variable.

1 char arr[20];

2 arr[20] = "This is illegal";

For example, for Listing 1, GCC-4.7.2 emits the

message “warning: assignment makes integer

from pointer without a cast”, which is very confu-

sing for novices. Instead, our C-Helper provides

a more direct message “String cannot be stored

in an element of char array variable. Consider to

use strcpy”.

• Thetis (Freund and Roberts, 1996) is an integrated

development environment for C with C interpre-

ter, understandable error reporting, run-time error

Actually there was this question in our presentation in

(Uchida and Gondow, 2016).

detection, debugging/visualization tools. A spe-

cial feature of Thetis is strengthened syntactic re-

strictions, where common code fragments often

mistakenly used by novices are regarded as er-

rors by Thetis, even though they are perfectly le-

gal in the C standard. The most common exam-

ple is if(i=0)···, where the assignment operator

= is often misused instead of the relational opera-

tor = = by novices.

• C-Tutor (Song et al., 1997) is a C program ana-

lysis tool, which provides novices with under-

standable messages to correct their wrong pro-

grams. C-Tutor combines static and dynamic ana-

lysis techniques, and extracts novice’s intentions

using sample programs.

• CX-checker (Osuka et al., 2012) is a C coding

style checker. While the current C-Helper only

checks unbalanced indentation as a common co-

ding style, CX-checker copes with various sty-

les, which are highly customizable using XPath,

DOM and wrapper API.

• Kummerfeld’s method (Kummerfeld and Kay,

2003) catalogs some common C/C++ compiler er-

ror messages, typical code examples for them, and

their possible corrections as a Web-based refe-

rence guide. This method might be effective, but

its maintenance cost is very high since the catalog

needs to be updated whenever compiler messages

are changed.

2.3 Previous Work to Choose First

Programming Languages

There are so many discussions about what language

to teach as a ﬁrst programming language (Kaplan,

2010) as below. There are many factors to decide

this: e.g., student’s ability, interest, background, pro-

spective career, the levels of courses, and so on, thus

making this discussion harder. Although this discus-

sion is very common in our community, as far as we

know, not restricted to the ﬁrst language, what pro-

gramming languages should be taught in the entire

computer science courses has not been studied suf-

ﬁciently.

• Early work suggested the C language was well

introduced in introductory programming courses.

For example, (Gilberg and Forouzan, 1996) repor-

ted the number of students in C courses dramati-

cally increased compared to Pascal courses. Also,

(Hosch, 1996) reported the combination of C and

UNIX was well taught. Of course, these may not

apply to today’s situation since new programming

ICSOFT 2018 - 13th International Conference on Software Technologies

550

languages have emerged like Java, Python, C# and

JavaScript.

• Java is one of the most popular ﬁrst language no-

wadays; for example, Java is ranked ﬁrst in (Gas-

par et al., 2007), and ranked second in (Guo,

2014). As positive characteristics, Java is (relati-

vely) small, robust, portable (Hosch, 1996)(King,

1997). Furthermore, Java is attractive to students

since Java is a programming language used to de-

velop Android applications. Of course, Java has

several minor problems; e.g., uncaught exceptions

must be declared explicitly, which is troublesome

for introductory students (Hosch, 1996)(King,

1997).

• C# is another candidate of today’s ﬁrst program-

ming language. As (Bates, 2004) mentioned, C#

is easier to learn the fundamental concepts in the

programming, since C# is a very sophisticated

object-oriented language.

• Python is yet another most popular ﬁrst language

nowadays; for example, Python is ranked ﬁrst in

(Guo, 2014). As positive characteristics, Python

is simple, dynamic, readable and Python has fe-

wer syntactic exceptions. (Sanders and Langford,

2008) pointed out another interesting issue; Py-

thon is a language that attracts both experienced

and inexperienced students. Like Scheme, Python

is easily accessible to inexperienced students. At

the same time, Python is a real-world popular lan-

guage, so Python is positively accepted to expe-

rienced students, too.

• JavaScript is a today’s very popular language, but

JavaScript seems not to be considered as a good

candidate of ﬁrst programming languages. For

example, (Mombrea, 2014) pointed out that Ja-

vaScript is a poor example of Object-Oriented

programming. Another issue is that JavaScript’s

callback hells make it difﬁcult for novices to le-

arn JavaScript programming. The characteris-

tic of “run-to-completion” in JavaScript prohi-

bits programmers from blocking like simply cal-

ling sleep(10) in C. Instead, JavaScript always

forces programmers to use callbacks (e.g., using

setTimeout()).

3 C CODE EXAMPLES TO SHOW

GOOD ABSTRACTION FOR

LOW-LEVEL PROGRAMMING

It is often said that one big advantage of the C

language is good abstraction for low-level program-

sbrk

Figure 1: sbrk allocates memory by moving down the

break position.

Listing 2: Outline of custome memory allocator.

1 struct memory buckets ∗f r e e l i s t ;

2 void ∗my malloc ( s ize t si ze ) {

3 void ∗p , ∗s ;

4 / / f i r s t search f r e e l i s t for an unused

5 / / bucket with ’ s iz e ’ bytes

6 p = s ea r ch f r eel ist ( size );

7 if (p != NULL) return p ;

9 / / then c al l sbrk , and divide the obtained

10 / / memory into ’p ’ and ’ f r e e l i s t ’

11 s = sbrk (BULK MEMORY SIZE) ;

12 divide mem ( s , &p , &f r e e l i s t ) ;

13 return p;

14 }

ming, e.g., in (TechLiebe, 2014)(Noordergraaf et al.,

2015)(Viswa, 2014). But few of them present con-

crete code examples, which makes it difﬁcult to dis-

cuss the reason why the C language is required in em-

bedded/system programming courses, and thus how

the C language is useful for students to understand

how the system works inside the computer. In this

section, we present several concrete code examples to

show that the C language is good abstraction for low-

level programming, but Java is not.

3.1 Custom Memory Allocator

To learn the mechanism of memory management in a

hands-on way, it is a good way to implement a sim-

ple custom memory allocator, garbage collector, buf-

fer overrun detector, and so on. In C, it is fairly easy

to implement a custom memory allocator (e.g., reim-

plementation of malloc in Unix) using sbrk and/or

mmap. As shown in Fig. 1, sbrk is a system call in

Unix to allocate memory by moving down the bottom

of heap (called the break position). malloc is imple-

mented, considering the following requirements:

• To avoid system call’s overhead, the number of

sbrk calls should be reduced. malloc achieves

this by allocating a large memory block with one

sbrk call, and dividing it into several memory

buckets.

Why Do We Need the C language in Programming Courses?

551

Figure 2: Inaccessible memory area detects buffer overrun.

Listing 3: Outline of buffer overrun detector.

1 void *ef_malloc (size_t size) {

2 void *p, *p2;

3 size_t size2 = ROUNDUP_PAGE (size);

4 p = mmap (size2, PROT_WRITE|PROT_READ);

5 p2 = p + size2 - PAGE_SIZE;

6 mprotect (p2, PAGE_SIZE, PROT_NONE);

7 return p + size2 - PAGE_SIZE - size;

8 }

• To achieve high-speed memory management,

malloc manages the memory buckets using the

data structure like hash or balanced tree.

So the outline of a custom memory allocator be-

comes like Listing 2. Thus, students see how two ab-

straction layers (malloc and sbrk) are bridged with

actual running code in C. On the other hand, it is dif-

ﬁcult in Java, since the API corresponds to sbrk is

not provided in Java, and if provided, it is difﬁcult to

replace Java’s new with the custom memory allocator.

By extending this custom memory allocator in C,

it is also fairly easy to implement a garbage collec-

tor, and buffer overrun detector. For example, Fig. 2

shows the idea of Electric Fence, which is one of the

buffer overrun detectors, where two pages are used

at least; the last page is used to protect invalid read/-

write (inaccessible area), and the other pages are used

for the user (used area). In actual implementation,

mmap is used to allocate memory on continuous pa-

ges, and mprotect is used to prohibit read/write on

the last page (Listing 3). If a read/write is attemp-

ted to the inaccessible area as a result of buffer over-

run, it is notiﬁed as a signal delivery like SIGSEGV.

Thus the students understand how the memory mana-

gement works using actual running code in C, while it

is difﬁcult in Java, since mmap and mprotect are not

available in Java.

3.2 System Calls v.s. Function Calls

In system programming, it is essential for the stu-

dents to understand the difference between a library

function call and a system call (Fig. 3). Both of li-

brary functions (e.g., printf) and system calls (e.g.,

int main ()

{ printf (...);}

int printf ()

{ write (...); }

int write ()

{ .... }

call

int

Figure 3: a library function is called with call, while a

system call is called with int in x86-32.

Listing 4: The difference between library function and sy-

stem call can be seen in the compiled assembly code.

1 % cat foo.c

2 int main (void)

3 {

4 printf ("1\n");

5 write (1, "2\n", 2);

6 }

7 % gcc -S foo.c; cat foo.s

8 ...

9 call printf

10 ...

11 int 0x80 // write

write) have the same interface to programmers in the

sense that programmers can call both of them as a

function call in C (e.g., printf(); and write();).

The reason why the difference is essential is because

a library function is executed in the user space, while

a system call is executed in the kernel space. All sy-

stem calls are implemented inside the kernel, since

they requires the CPU privilege, or some arbitration

in the kernel (e.g., to avoid data races in the shared

data among all processes).

The easiest way for the students to see the diffe-

rence is to see the assembly code compiled from C

(Listing 4)

. This method using C is easy and straig-

htforward for students, but not in Java, since we can-

not see the difference in the Java bytecode compiled

from Java.

3.3 Setting a Breakpoint in Debuggers

Suppose a system programming course where stu-

dents implement a simple debugger which natively

runs on their PCs. A key feature of debuggers is a

breakpoint, and a typical way to implement (software)

breakpoints is to overwrite the instruction at the bre-

In the recent Unix(-like) OSes, a system call is wrap-

ped as a library function. In this case, we need to use, for

example, process monitor tools like ltrace and strace in

Linux.

ICSOFT 2018 - 13th International Conference on Software Technologies

552

55 pushl %ebp

89 e5 movl %esp, %ebp

83 ec 08 subl $8, %esp

55 pushl %ebp

cc e5 int3

83 ec 08 subl $8, %esp

Sets a breakpoint by overwriting

the top byte of "movl" instruction

Figure 4: Setting a breakpoint on x86-32.

Listing 5: int3 transfers the control to the debugger.

1 % lldb ./a.out

2 (lldb) run

3 Process 7445 stopped

4 2 int main ()

5 3 {

6 4 printf ("1\n");

7 -> 5 asm ("int3");

8 6 printf ("2\n");

9 7 }

akpoint address with a software interrupt instruction

In x86-32, for example, we can set a breakpoint to

overwrite the top byte of instruction (movl in Fig. 4)

with the software interrupt instruction int3 (0xCC in

hex). The students easily see int3 transfers the con-

trol to the debugger using inline assembly code like

Listing 5.

Most Unix(-like) OSes (e.g., Linux) provide an

process ﬁle system API (procfs) to allow program-

mers to access the debuggee’s memory address space

as ﬁle I/O. So the C code to set a breakpoint beco-

mes like Listing 6, where ﬁrst the byte at the break-

point address (addr) is saved to orig, and then int3

instruction (0xCC) is overwritten. Thus, the students

easily understand how the breakpoint works in C.

On the other hand, it is not easy for students to un-

derstand it in Java, since the notion of software inter-

ruption (int3 in x86-32) is completely hidden under

the Java API. The Java Virtual Machine Tool Interface

(JVM TI) provides a debugger interface including the

following method to set a breakpoint.

jvmtiError SetBreakpoint (jvmtiEnv* env,

jmethodID method, jlocation location);

But the students cannot see the inside of the Java

method SetBreakpoint as Java code, since it is im-

plemented in C using Java Native Interface (JNI).

Listing 6: Setting a breakpoint in C.

1 void

2 set breakpoint ( int fd , void ∗addr , char ∗orig )

3 {

4 char int3 = 0xCC;

5 ll seek (fd , addr , SEEK SET) ;

6 read ( fd , orig , siz eof (∗ orig ) ) ;

7 ll seek (fd , addr , SEEK SET) ;

8 write ( fd , &int3 , sizeo f ( i nt3 ) ) ;

9 }

3.4 Direct Memory Access (DMA) in

OSes

In the above discussion through Sec. 3.1 to Sec. 3.3,

all example code runs in the user space. The same

discussion holds for the code that runs in the kernel

space. For example, Listing 7 is actual C code that

sets up the DMA controller (Intel 8237) to transfer

data between an I/O device (typically HDD) and me-

mory without CPU. The textbooks of operating sys-

tems just explain how to do DMA transfer like the

following simple description.

1. The kernel sets up the I/O device in DMA mode.

2. The kernel instructs the DMA controller to trans-

fer data in DMA mode with the speciﬁed address,

size and the transfer direction (i.e., read or write).

The code example in Listing 7 does this step in

PC/AT compatibles.

3. The DMA controller transfers the data.

4. When the transfer is ﬁnished, the DMA controller

interrupts CPU to signal transfer completion.

But the students cannot understand concretely

how DMA works with the above simple description,

since the API of the DMA controller and the code

using the API are not offered. Using the actual run-

ning code example like Listing 7, the students can un-

derstand DMA more concretely:

• The whole actual running code is not long as

shown in Listing 7, although each byte of address,

for example, needs to be transferred separately.

• Five I/O registers

(DMAC clear byte point ﬂipﬂop,

DMAC base addr reg 2, DMAC page reg 2,

DMAC base count reg 2, DMAC mode reg) are

used in this setup, which are the APIs of the

DMA controller.

• During this setup, the DMA must be disabled.

For lack of space, the detailed mechanism is omitted

here.

Why Do We Need the C language in Programming Courses?

553

Listing 7: Setting up the DMA controller.

1 void

2 outb (uint8_t value, uint16_t port) {

3 asm volatile ("outb %0,%1"::"a"(value),"Nd"(port));

4 }

6 static void

7 setup_DMAC (uint32_t physical_addr, int count, int is_read) {

8 // disable DMA2 (mask set for DMA2)

9 outb (0x06, DMAC_channel_mask_reg); // STCL=1, SEL1:SEL0=2

11 /

set address and counter

12 outb (0xFF, DMAC_clear_byte_point_flipflop);

13 outb (physical_addr & 0xFF, DMAC_base_addr_reg_2);

14 outb (physical_addr >> 8 & 0xFF, DMAC_base_addr_reg_2);

15 outb (physical_addr >> 16 & 0xFF, DMAC_page_reg_2);

16 count--;

17 outb (count & 0xFF, DMAC_base_count_reg_2);

18 outb (count >> 8 & 0xFF, DMAC_base_count_reg_2);

20 /

set mode

21 if (is_read) {

22 outb (0x46, DMAC_mode_reg); // single, inc, noauto, write (I/O device -> memory), DMA2

23 } else {

24 outb (0x4A, DMAC_mode_reg); // single, inc, noauto, read (memory -> I/O device), DMA2

25 }

27 // enable DMA2 (mask clear for DMA2)

28 outb (0x02, DMAC_channel_mask_reg); // STCL=0, SEL1:SEL0=2

29 }

4 OUR POSITION

4.1 The C Language is Worth Teaching

Our main position is that the C language is worth tea-

ching since C is required to teach upper-class cour-

ses like embedded/system programming and opera-

ting systems. The C language does not have to be a

ﬁrst programming language, but it still be needed for

the upper-class courses.

• The C language may not be the best ﬁrst lan-

guage in introductory courses themselves, espe-

cially just for teaching algorithms, or the funda-

mental concepts of programming languages like

conditional branches, loops, variable assignments,

(recursive) procedure calls, and so on. This is

mainly due to C’s weakness of compile-time/runt-

time checking, and the ambiguity of the C stan-

dards (e.g., the evaluation order of the subex-

pressions within an expression is unspeciﬁed in

(C90/C99/C11)).

• Nevertheless, the C language is worth teaching in

programming courses, since C is very required to

teach upper-class courses like embedded/system

programming and operating systems, as shown in

Sec. 3. Furthermore, not only real operating sys-

tems, but also educational operating systems boot-

able in PC/AT compatibles like Xv6 (Cox et al.,

2006) and udos (Gondow and Ohba, 2007) are

written in C (and little assembly code). This is

also supported by the survey analysis in (Gaspar

et al., 2007).

• Native educational compilers (i.e., compilers that

generate native assembly code like x86-32) have

many practical and pedagogical advantages (Gon-

dow, et al., 2010), since;

– Generating native (i.e., real) assembly code

motivates students to learn.

– Students are getting better to read assembly

code emitted by commercial-level compilers

(e.g., GCC).

– There are many high quality documents like

(Intel, 2017) and tools (eg., GCC and GNU Bi-

nutils) for real machines.

– Library functions (eg., printf in the C stan-

dard library) can be directly called from the

source program to be compiled, which widens

the expressiveness of the source program.

The C language or its moderate subset is a good

candidate of the source program to be compiled in

such native educational compilers, since the map-

ping between C and assembly code is quite simple

and straightforward.

• C is worth teaching in other reasons:

– C is needed to learn low-level security issues

ICSOFT 2018 - 13th International Conference on Software Technologies

554

like buffer overruns and the techniques to solve

them.

– C is also needed to read open source code like

Linux, Apache, TCP/IP protocol stacks, to le-

arn a wide variety of programming techniques.

4.2 Every Language Has Its Drawbacks

and Pitfalls

Another position of ours is as follows. As mentio-

ned in Sec. 2.1 and in (Koenig, 1989), C has some

drawbacks and pitfalls, but this cannot be a reason

to stop teaching C, since they are tightly coupled to

C’s advantages, and C is very required in upper-level

courses like embedded/system programming and ope-

rating systems.

Similarly, other languages have their draw-

backs and pitfalls, e.g., Java (Biddle and Tempero,

1998)(Daconta et al., 2003), Python (Miller and

Settle, 2016), JavaScript (Alimadadi, et al., 2016).

5 CONCLUSIONS

The C language is still one of the important program-

ming languages both in development and in educa-

tion, so there are several research studies to support C

programming educations to compensate the C’s draw-

backs and pitfalls. This position paper argued that the

C language is worth teaching even though C has the

drawbacks like buffer overruns and mysterious com-

piler error messages.

Our future work is to create a better C language

while preserving the C’s advantages. The languages

like C++, Java, Objective-C, C#, Go failed to be a

better C in our observation.

REFERENCES

Ritchie, D. (1993). The development of the C language.

2nd ACM SIGPLAN conf. on History of programming

languages (HOPL-II) pp.201-208.

Programming languages–C: ISO/IEC 9899:1990,

9899:1999, 9899:2011 (C90/C99/C11).

TIOBE programming community index. (2017).

http://www.tiobe.com/tiobe-index/, [Online; accessed

31-Jan-2017].

Gaspar, A., Boyer, N. and Ejnioui, A. (2007). Role of the C

language in current computing curricula part 1: survey

analysis. J. Comput. Sci. Coll. 23, 2, 120-127.

Gilberg, R. and Forouzan, B. (1996). Comparison of stu-

dent success in Pascal and C-language curriculums.

Proc. 27th SIGCSE tech. sympo. on Computer science

education (SIGCSE ’96) pp.252-255.

Hosch, F. (1996). Java as a ﬁrst language: an evaluation.

SIGCSE Bull. 28, 3. pp.45-50.

King, K. (1997). The case for Java as a ﬁrst language. Proc.

35th Annual Southeast Regional Conf. (ACM-SE 35).

pp.124-131.

Sanders, I. and Langford, S. (2008). Students’ percepti-

ons of python as a ﬁrst programming language at wits.

SIGCSE Bull. 40, 3. pp.365-365.

Bates, B. (2004). C# as a ﬁrst language: a comparison with

C++. J. Comput. Sci. Coll. 19, 3. pp.89-95.

Kaplan, R. (2010). Choosing a ﬁrst programming language.

Proc. conf. on Information technology education (SI-

GITE ’10). pp.163-164.

Mannila, L. and Raadt, M. (2006). An objective comparison

of languages for teaching introductory programming.

Proc. 6th Baltic Sea conf. on Computing education re-

search: Koli Calling 2006. pp.32-37.

Bosse, Y. and Gerosa, M. (2017). Why is programming so

difﬁcult to learn?: Patterns of Difﬁculties Related to

Programming Learning Mid-Stage. SIGSOFT Softw.

Eng. Notes 41, 6. pp.1-6.

Biddle, R. and Tempero, E. (1998). Java pitfalls for begin-

ners. SIGCSE Bull. 30, 2. pp.48-52.

Miller, C. and Settle, A. (2016). Some Trouble with Trans-

parency: An Analysis of Student Errors with Object-

oriented Python. Proc. ACM Conf. Int. Computing

Education Research (ICER ’16). pp.133-141.

Alimadadi, S. Mesbah, A. and Pattabiraman, K. (2016).

Understanding asynchronous interactions in full-stack

JavaScript. Proc. Int. Conf. on Software Engineering

(ICSE’16). pp.1169-1180.

Freund, S. N. and Roberts, E. S. (1996). Thetis: An ansi c

programming environment designed for introductory

use. In Proceedings of the Twenty-seventh SIGCSE

Technical Symposium on Computer Science Educa-

tion, SIGCSE ’96, pages 300–304, New York, NY,

USA. ACM.

Song, J. S., Hahn, S. H., Tak, K. Y., and Kim, J. H. (1997).

An intelligent tutoring system for introductory c lan-

guage course. Comput. Educ., 28(2):93–102.

Osuka, T., Kobayashi, T., Atsumi, N., Mase, J., Yama-

moto, S., Suzumura, N., and Agusa, K. (2012). CX-

checker: A ﬂexibly customizable coding checker for

C. Journal of Information Processing Society of Ja-

pan, 53(2):590–600.

Kummerfeld, S. K. and Kay, J. (2003). The neglected battle

ﬁelds of syntax errors. In Proceedings of the Fifth Au-

stralasian Conference on Computing Education - Vo-

lume 20, ACE ’03, pages 105–111, Darlinghurst, Au-

stralia, Australia. Australian Computer Society, Inc.

Kojima, Y. Arahori, Y., Gondow, K. (2015). Investigating

the Difﬁculty of Commercial-level Compiler Warning

Messages for Novice Programmers. 7th Int. Conf.

on Computer Supported Education (CSEDU 2015).

pp.483–490.

Uchida, K. and Gondow, K. (2016). C-Helper: C Latent-

error Static/Heuristic Checker for Novice Program-

mers. 8th Int. Conf. on Computer Supported Educa-

tion (CSEDU 2016). pp.321–329.

Why Do We Need the C language in Programming Courses?

555

Gondow, K. Fukuyasu, N. and Arahori, Y. (2010). Mie-

ruCompiler: Integrated Visualization Tool with “Ho-

rizontal Slicing” for Educational Compilers. 41st

ACM Technical Sympo. on Computer Science Educa-

tion (SIGCSE 2010). pp.7–11.

Gondow, K. and Ohba, M. (2007). Design and imple-

mentation of compact educational operating system

udos by practice of middle-level abstraction, hhin

middle layers and traceability. The Transactions of

the Institute of Electronics, Information and Commu-

nication Engineers. J90-D[5], pp.1194-1208. (In Ja-

panese) http://www.sde.cs.titech.ac.jp/∼gondow/udos

[Online; accessed 31-Jan-2017].

Cox, R. Kaashoek, F. and Morris, R. (2006). Xv6,

a simple Unix-like teaching operating system.

https://pdos.csail.mit.edu/6.828/2012/xv6.html, [On-

line; accessed 31-Jan-2017].

Koenig, A. (1989). C Traps and Pitfalls. Addison-

Wesley Professional. ISBN-10: 0201179288. 160 pa-

ges. https://www.amazon.co.jp/dp/0201179288/, [On-

line; accessed 31-Jan-2017].

Daconta, M. Smith, K. Avondolio, D. and Richardson,

W. (2003). More Java Pitfalls: 50 New Time-

Saving Solutions and Workarounds. Wiley. ISBN-

10: 0471237515. 480 pages. https://www.amazon.

co.jp/dp/0471237515/, [Online; accessed 31-Jan-

2017].

Monbrea, M. (2014). Why I don’t suggest JavaScript

as a ﬁrst programming language. ITworld, Jan. 9,

2014. http://www.itworld.com/article/2693386/why-

i-don-t-suggest-javascript-as-a-ﬁrst-programming-

language.html, [Online; accessed 31-Jan-2017].

Guo, P. (2014). Python is now the most popular intro-

ductory teaching language at top U.S. universities.

BLOG@ACM, July 7, 2014. http://cacm.acm.org/

blogs/blog-cacm/176450-python-is-now-the-most-

popular-introductory-teaching-language-at-top-u-s-

universities/fulltext [Online; accessed 31-Jan-2017].

Intel. (2017). Intel 64 and IA-32 Architectures Software

Developer Manuals http://www.intel.com/products/

processor/manuals/, [Online; accessed 31-Jan-2017].

TechLiebe (2014) Why to Learn C? https://techliebe.com/

why-to-learn-c/ [Accessed: 24-Nov-2017]

Noordergraaf, L. Boldyshev, K. and Rideau, F. (2015)

Assembly HOWTO, version 0.7 http://asm.

sourceforge.net/howto/Assembly-HOWTO.html

[Accessed: 24-Nov-2017]

Viswa (2014) Advantages and Disadvantages of C

Language https://tekslate.com/advantages-and-

disadvantages-of-c-language/ [Accessed: 24-Nov-

2017]

ICSOFT 2018 - 13th International Conference on Software Technologies

556