- Computer Science and Telescopes
- Computer Scientists Cant Program!
- What Is It Good For?
- The State of Open Source 3D
- What Is Mac OS X?
- Snow Leopard: The Underhyped APIs
- Foundation: The Objective-C Standard Library
- Cocoa Tips: Exposing System Services
- Cocoa Tips: Don't Reimplement Standard Functionality
- Localizing Cocoa
- How Core Animation Changed Cocoa Drawing
- Using Distributed Objects in Cocoa
- Inside Modern X11 Programming
- Making JavaScript Fast, Part 2
- Security in Your Pocket: OpenBSD on ARM
- Making JavaScript Fast, Part 1
- The Failure of the GPL
- How Not To Optimize
- A Half-Way Step to Apple’s Source Code: An Interview with David Chisnall
- Advanced Flow Control for Objective-C
- Erica Sadun on the iPhone SDK, OS X, and the Computing Landscape
- From NeXTSTEP to Cocoa: Erik Buck on the Development of Cocoa and Objective-C
- Fun with the Objective-C Runtime
- Marcus Zarra and Matt Long on Core Animation
- Steve Kochan on the Evolution of Objective-C
- The Technology NeXT Gave the World
- Where the Web and the Desktop Meet: An Interview with Lee Barney
- Pandora: An Open Console
- The Future of Wireless Networking
- GNU or Linux?
- Debugging C-Family Languages
- How Small Is Your PC? The Rise of Netbooks and Other Small Form-Factor PCs
- David Chisnall's CPU Feature Wishlist
- The Dynamic Languages Renaissance
- Robert Seacord on the CERT C Secure Coding Standard
- Objective-C for C++ Programmers, Part 3
- Objective-C for C++ Programmers, Part 2
- Objective-C for C++ Programmers, Part 1
- Writing Insecure C, Part 3
- Writing Insecure C, Part 2
- Writing Insecure C, Part 1
- iRex iLiad e-Reader: Linux's Answer to the Kindle?
- How It Works: Filesystems
- How the LLVM Compiler Infrastructure Works
- How It Works: Virtual Memory
- What Is C For?
- The Future of eBooks
- Imagining an Open Network
- Understanding How Xen Approaches Device Drivers
- Examining the Legendary HURD Kernel
- Competition Among Open Source Compilers
- Inside Your OS: What is a Process Scheduler, and How Does it Work?
- Bad UI of the Week: Read This (OK/Cancel)
- The End of the Desktop Era
- The What and Why of Open IM
- A Look at the Modern X Server
- The Future of Digital Media
- The Future of Identity
- Bad UI of the Week: Ask Forgiveness, Not Permission
- Copyright Versus Free Software
- Is Computer Science Dying?
- A Brief History of Programming, Part 2
- A Brief History of Programming, Part 1
- The 700MHz Question: Will the Wireless Spectrum Auction Lead to Innovation or More of the Same?
- Bad UI of the Week: The Menu Bar
- The Dark Corners of x86
- Bad UI of the Week: The Cross-Platform User Interface
- Bad UI of the Week: The Mythical "is Like" Operator
- Bad UI of the Week: Don't Make Me Tell You Twice...
- Bad UI of the Week: Kettles and Washing Machines
- The BBC iPlayer Controversy Explained
- Bad UI of the Week: The Mitten Mouse
- Bad User Interface of the Week: File It Under “Bad”
- Bad User Interface of the Week: The DVD
- A Roundup of Free Operating Systems
- DragonFly BSD: UNIX for Clusters?
- CPU Wars, Part 3: Put Your Left ARM In
- CPU Wars, Part 2: POWER to the People
- CPU Wars, Part 1: When the Chips Are Down
- ZFS Uncovered
- Vector Programming with GCC
- Free Software Versus Open Source Software
- What Programming Languages Should You Know?
- Standardizing UNIX
- Prolog: Logic Programming for Rapid Development
- POSIX Parallel Programming, Part 3: Threads
- POSIX Parallel Programming, Part 2: Message Passing
- POSIX Parallel Programming, Part 1
- The Nokia 770 Revisited
- The Open Source Desktop Myth
- Separating Style and Content: LaTeX and Typesetting
- GNUstep: A Free Software alternative to OpenStep
- Behind the Scenes of Objective-C 2.0
- The Future of CPUs: What's After Multi-Core?
- What Makes a Good Programming Language?
- Emulation: Role-Playing for Computers
- NetBSD: Not Just for Toasters
- POSIX Asynchronous I/O
- Breaking Down GPL Version 3
- The Role of Binary Drivers in a Free OS
- Security Is a UI Problem
- Debunking the Myth of High-level Languages
- A Taste of Erlang, a Dynamic, Asynchronous Message-Passing Language
- Alternatives to LAMP
- BSD Packaging Systems
- DRM: Digital Rights or Digital Restrictions?
- Introducing OpenBSD 3.9
- The Need for Virtualization and Xen
- Making Effective Software TCO Calculations
- 10 Things I Hate About U(NIX) Revisited: Readers Speak
- Comparing Open Source Licenses: GPL vs. BSDL
- BSD: The Other Free UNIX Family
- Measuring the Effectiveness of Application Security Policies
- The Cost of Free Software
- Nokia 770 Internet Tablet Week-long Test Drive
- 10 Things I Hate About (U)NIX
- The Lure of Open Source Software: Why Consider It for Your Business?
- Cocoa Tip of the Day, 1/29/10
Don't ignore old versions of OS X.
- Cocoa Tip of the Day, 1/28/10
Exceptions should be exceptional.
- Cocoa Tip of the Day, 1/27/10
Explore the runtime system.
- Cocoa Tip of the Day, 1/26/10
Copy design patterns from Cocoa.
- Cocoa Tip of the Day, 1/25/10
Profile with Instruments.
- Cocoa Tip of the Day, 1/22/10
Expose system services.
- Cocoa Tip of the Day, 1/21/10
Always read the release notes for new OS X versions.
- Cocoa Tip of the Day, 1/20/10
Broadcast events with notifications.
- Cocoa Tip of the Day, 1/19/10
Port your code with GNUstep.
- Cocoa Tip of the Day, 1/18/10
Use CoreAnimation for caching.
- Cocoa Tip of the Day, 1/15/10
Don't recreate standard features.
- Cocoa Tip of the Day, 1/14/10
Don't forget NSCell.
- Cocoa Tip of the Day, 1/13/10
Plan for code reuse.
- Cocoa Tip of the Day, 1/12/10
Remember the C in Objective-C.
- Cocoa Tip of the Day, 1/11/10
Separate interfaces and implementations.
- Cocoa Tip of the Day, 1/8/10
Think about localisation early.
- Cocoa Tip of the Day, 1/7/10
Read the Human Interface Guidelines.
- Cocoa Tip of the Day, 1/6/10
Don't optimise yet.
- Cocoa Tip of the Day, 1/5/10
Put controllers in nib files.
- Cocoa Tip of the Day, 1/4/10
Don't write code.
- Cocoa Tip of the Day, 1/1/10
Use Distributed Objects for local network communication.
Like this article? We recommend
Web Technologies: A Computer Science Perspective
Computer Scientists Can’t Program!
Talking to people in the industry, I’m frequently told that computer scientists can’t program. Part of the problem is people hiring computer scientists and thinking that they’ve just done a three- or four-year programming course. (Another part is students applying to study computer science with the same idea.)
Some computer scientists, and even professors, really can’t program. Professors have PhD students to handle programming for them, but recent graduates can’t make that claim. Programming falls close to the engineering part of computer science, and people who have been through a degree that focuses more on the mathematics or psychology aspects of the subject are likely to be fairly weak in engineering.
A lot of dissatisfaction with computer science comes from the misplaced expectation that a computer science graduate will be a good programmer. Such a graduate should have been exposed to at least half a dozen languages, but won’t necessarily have done anything particularly complicated with those languages. She almost certainly won’t have any kind of deep understanding of the standard library available for a given platform. This kind of comprehension comes only with experience. She may have picked it up from other jobs or open source work, but not from her degree.
Computer science and software engineering are very different disciplines, and a lot of people seem to confuse the two. Software engineering teaches the process of developing software, in terms of both tools and processes. A computer science course briefly touches on these topics, in the same way that a materials physicist may learn something of mechanical engineering. This doesn’t make a computer scientist a software engineer, any more than it makes a physicist the best candidate for building a bridge.
Account Sign In
View your cart