Is it time to rewrite the operating system in Rust? [slides] - <AUTHOR> https://www.slideshare.net/bcantrill/is-it-time-to-rewrite-the-operating-system-in-rust <comment><USER2> I think the question is wrong. People are already writing new operating systems in Rust just because they can. The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them.

These will of course still be around for the foreseeable future (i.e. decades). At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc.

IMHO it is just a matter of time before vendors start providing e.g. drivers written in Rust for their hardware. I could see linux evolve to a point where integrating drivers like that is both possible and common. Once that happens, it will be a hybrid kernel effectively. Rust is not the only thing moving that direction; wasm is also going that direction. People are talking about running that in the kernel. And of course Rust runs on top of that as well. So one outcome would be a lot of Rust code running in a wasm sandbox on top of legacy kernels.

<comment><USER3> > wasm is also going that direction

Genuine question: why would WASM in the kernel make any sense at all?

<comment><USER4> Security. WASM is sandboxed by design.

<comment><USER3> Many things are "sandboxed by design." Few things are true sandboxes.

I'm very skeptical of the idea of throwing out virtual memory and process isolation to depend instead only on software sandboxes.

</comment></comment></comment></comment><comment><USER5> Bit of a mixed bag.

Slide 12:

> Go etc. are garbage collected, making interacting with C either impossible > or excruciatingly slow.

"Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general.

Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster than C", although the programs being compared use different data structures, so it's inconclusive. (It's not clear to me whether the author wanted to make a broad claim like this. The title suggests so, but again, the difference in data structures suggests otherwise.)

Slide 16:

> every operating system retains some assembly for reasons of performance

Is this really the case? I would be interested in examples. My impression was that assembly is needed for hardware interaction for which there are simply no C constructs available (setting timers, interrupts, system registers, and whatnot), and possibly highly space-constrained bootloader stuff, but performance? C compilers are not stupid.

Slide 19:

> in-kernel C tends to be de facto safe

This is a bit of a stretch. I mean, yes, _most_ lines of the Linux kernel have never been the cause of a CVE. But it's hard to tell which lines are the critical ones. Properly encapsulating safe/unsafe regions does seem like an improvement. (My understanding is that Rust's "unsafe" is not properly encapsulated: You might mess something up that will cause a segfault later on, in ostensibly "safe" code. Still, it's a step forward.)

<comment><USER6> > Slide 12:

IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable.

> Slide 14:

Rust can be faster than C in the general case because of the optimizations permitted by, among other things, strict aliasing rules. [1] The Rust language invariants are stronger and therefore the compiler can be more aggressive.

> Slide 16:

IMO you can do all that stuff in C with a combination of volatile pointer I/O and if necessary compiler intrinsics. I've done a lot of AVR programming and never dropped down to assembler because something wasn't available in C. I'd imagine the answer is really neither, just that some people are set in their ways and view ASM as 'faster' even though in reality LLVM would probably generate faster code by better taking into account instruction issue and data dependencies.

> Slide 19:

Unsafe Rust is unsafe because you can't express what you want in safe Rust. To your point, you can absolutely break things. The implicit contract is when writing unsafe sections that you are to maintain the invariants of the safe language at entry and exit of the block.

What makes safe Rust safer than C, though, is all the flagship features. You can detect data races across threads (and interrupts) statically. You can't write to and read from data at the same time. You have fully deterministic dynamic collection of resources. etc.

[1] [https://robert.ocallahan.org/2017/04/rust-optimizations- that...](https://robert.ocallahan.org/2017/04/rust-optimizations-that-c-cant- do_5.html)

<comment><USER7> Any dynamic memory allocation lacks determinism, which is why in high integrity systems it often forbidden to dynamically allocate memory.

As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as optimized C and have all the safety features.

<comment><USER8> > After all, those languages use the same backends - GCC in the case of C & > Ada, LLVM in the case of C & Rust.

The killer flaw of C for performance is the pointer aliasing problem. C only has the very coarse-grained tools of strict aliasing (often disabled in large applications because it breaks code!) and restrict (which relies heavily on manual programmer annotation) to control these aliasing issues. Since Rust has the rule that you can only have one mutable reference to an object at once (and read-read aliasing issues don't matter), it can effectively automatically add in these annotations without relying on programmer annotation.

<comment><USER6> I think it's fair to say that "average" Rust code will be faster than "average" C code due to lack of pointer aliasing issues as the average developer doesn't care about/understand this enough to make the annotations in any codebase I've worked in. Can you make both equally fast? I don't see why not, they're both LLVM.

<comment><USER9> Given enough time, effort and smarts, you can probably make any lang as fast as any other :-)

</comment></comment></comment></comment></comment></comment><comment><USER10> I'd really like to see an open-source QNX-type microkernel in Rust. Everybody is re-implementing early Unix in Rust, but that's not a good model. The great thing about the QNX model is that the tiny kernel barely changes from year to year, because everything is outside it and not very trusted. So it approaches being totally debugged.

L4 is too low-level - you have to run another OS on top of it, usually Linux. QNX offers a POSIX interface.

<comment><USER11> What is the state of documentation on QNX? Is there sufficient documentation that it would be possible to write a QNX-compatible kernel from the documentation (plus access to a QNX machine, which has to be available somehow outside of industry, right?)?

<comment><USER10> Until Blackberry bought it, it was open source. There were free downloads. Now it's proprietary. But there's a lot of info out there from the open source era. The manuals are available.

Here's the original QNX paper.[1]

[1] [https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx- paper92.p...](https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf)

<comment><USER12> I am amazed that I cannot find a copy of the source code from the time it was freely available now.

<comment><USER10> Here's the 2007 press release announcing QNX going open source.[1]

On April 9, 2010, the day the acquisition closed, Research and Motion took the source code offline, with no notice. All user open source projects on QNX were abandoned shortly thereafter.[2]

[1] [http://www.qnx.com/news/pr_2471_1.html](http://www.qnx.com/news/pr_2471_1.html)

[2] [https://community.qnx.com/sf/sfmain/do/listProjects](https://community.qnx.com/sf/sfmain/do/listProjects)

</comment></comment></comment></comment></comment><comment><USER13> It'll be interesting to see how much use Rust gets within Fuchsia atop the Zircon microkernel.

<comment><USER14> The current state is, a few hundred thousands of lines, and Google hiring more Rust engineers quite aggressively.

I'm also excited to see how it turns out :)

<comment><USER15> Any other high profile company/project using Rust ? (beside mozilla of course)

<comment><USER14> Facebook, Dropbox, cloudflare, fastly, tons of startups you've heard of...

</comment></comment></comment></comment><comment><USER16> Presentation by the Joyent CTO btw, who hired a lot of the old Sun Solaris team.

<comment><USER17> Among other things because he is also was part of the old Solaris team?

<comment><USER16> Hilarious example of why English is a terrible language: I meant for the the pronoun to refer to Joyent, not [necessarily] the CTO.

<comment><USER18> No, that's an example of someone not knowing the language very well. You should have written something like, "which is the company that...".

I can't think offhand of any language that's really better here in a sense of being more efficient, except probably Classical Latin which is horribly complicated and of course a dead language.

<comment><USER19> Czech allows you to specify that with a change of one letter depending on who you mean (the CTO - který, the company - která) - this depends on different genders of the two words, but is commonly used.

<comment><USER18> Are they officially calling themselves "Czechia" these days? I saw that on Google Maps recently, I think. It certainly is shorter and simpler than "Czech Republic".

<comment><USER19> It's the oficial short name (the full name is still Czech Republic), local people don't like it much but they're coming around. However I wasn't referring to the country (Czechia/Czech Republic) but to the language (Czech).

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> A bit surprising that he doesn't mention any other C++ based kernels such as [https://github.com/l4ka/pistachio/](https://github.com/l4ka/pistachio/) and most of the fuchsia code base except for the lk micro kernel. In my opinion fuchsia points towards where things are going multi-language implementations (mostly c++) with an interface description language for interfacing components. From a point of view of postmodern c++, rust has little to no advantages left. It has a much more mature ecosystem and set of libraries, is just as fast and can be very safe if used correctly.

<comment><USER21> > From a point of view of postmodern c++, rust has little to no advantages > left.

My entire adult life I've been writing C, I resisted Rust for a while but took the plunge when a C++ project came along that was in dire need of being reworked. I liked it, the language and the compiler and tooling around it helped me tremendously.

I assume you're aware of all the things that Rust statically guarantees for you, and I'll also assume you know the difference between language complexity and language implementation complexity (eg, the compiler or some other tooling):

I've been skimming through the C++ section of cppreference.com, and oh boy, there's heaps and heaps of... stuff... just stuff. The interplay between all that stuff is complex and it's hard to keep everything in mind. Keeping things in mind is important for correctness, or at least for having a reasonable amount of confidence in what you're writing. Information locality is also important for correctness, and C++ lacks both of those. I'll even go further and say that C++ is a write-only language, like a garbage bin of features and exceptions to each of those features. Rust has many many many clear advantages (and some disadvantages) compared to postmodern C++.

<comment><USER20> Maybe just to elaborate: In contrast to rust, C++ is a standard defined language, with >3 mature and competitive implementations, two of which (clang / microsofts compiler) provide excellent tooling and support for refactoring (clang in particular) beyond any other language in existence (maybe except Java). Instead of looking at cppreference.com, maybe consider browsing [https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md) the Cpp Core Guidelines, this outlines a forward looking vision of how good c++ code should look like.

A lot of the static guarantees that rust provides can be modelled in C++ as well, see for example "[https://clang.llvm.org/extra/clang- tidy/checks/cppcoreguidel...](https://clang.llvm.org/extra/clang- tidy/checks/cppcoreguidelines-owning-memory.html"). Eventually someone will write a rust-style borrow checker as a clang analysis pass. Already now it is possible to express a lot of compile time properties cleanly in c++, with features such as constexpr lambdas, static_assert etc. Additional features such as Concepts / meta-classes / modules will improve C++ expressivity even further.

In short, yes C++ has a lot of stuff and everyone knows that it is hard to get a grip on all its features and misfeatures. But there has been a continuous effort to rectify and improve on its short comings. See for example [https://clang.llvm.org/extra/clang- tidy/checks/list.html](https://clang.llvm.org/extra/clang- tidy/checks/list.html) for a list of clang based code transformations that are able to automatically improve your c++ code.

The way I see it, just because of legacy reasons (I can interface with the majority of commercial software developed in the last 30 years (CAD, EDA software, Houdini, Abelton, ...)), tooling reasons (the rust compiler is a slow hot mess, compared to the state of the art c++ compilers) and momentum (there is a large incentive to continuously improve c++, because it is the foundation of a large fraction of commercial software out there) it is unlikely that rust will outcompete c++ in a significant way in the long run.

To close of with an example the lean theorem prover [https://github.com/leanprover/lean](https://github.com/leanprover/lean), implemented in C++ handily beats the 20+ year old Coq prover. One of its key features is multicore support. If you look into its implementation details, the equivalent rust code would have to work around a lot of rust "safety" features, essentially because in many cases it is hard to convince a hardcoded heuristic like a borrow checker that whatever you are doing is safe. The static guarantees that rust gives wouldn't help you at all in correctly implementing some of the very involved algorithms a theorem prover kernel has to implement, while standing in the way of the implementation being straightforward. This leaves aside the obvious tooling (you can use Visual Studio, good profilers and debuggers) and integration (SAT checkers like Z3, LLVM backend) advantages.

<comment><USER22> > the lean theorem prover

Which has its share of segmentation faults (around 50 closed issues) and unknown number of corner cases with silent memory corruption/data races.

</comment></comment></comment></comment><comment><USER23> The slide about the operating systems of the 1980s ignores Lisp machines. Genera was not a "research system" and it had good performance. There was also Xerox Star's OS written in Mesa.

</comment><comment><USER24> I think Zig would be better suited.

See: [https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is- Al...](https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Already- CPP%2C-D%2C-and-Rust%3F)

<comment><USER25> I took a brief look at Zig.

The top slogan for Rust is "fearless concurrency", which ties back into the memory model, mutability and sharing references. This helps you prevent (at compile-time) data races and other interesting bugs.

I didn't see any support for that in Zig at all.

<comment><USER26> Last I checked Zig is more concerned about overflow conditions than Rust(numeric overflow, stack overflow, OOM etc.) and boasts features in that vein - so it competes, but not in the same territory.

If you are writing a kernel it's highly likely that you'll end up in a lot of scenarios where you have to use unsafe Rust, in which case Zig would be the better language for the task. Admittedly, it would be nice to have some of both, and they both have room to get better. But I see Rust as more of a "libraries and applications" centric setup, where it's the right thing for a web browser and the wrong thing for a device driver.

</comment></comment></comment><comment><USER27> These slides are quite high-level, so I've got to ask: what's the expected benefit of using Rust to implement a kernel? I somehow thought that nearly all interesting concurrency there would not fit into the paradigm of exclusive ownership. And if we are preaching for programming in unsafe Rust, then doesn't the message become less compelling?

<comment><USER28> The purported benefit would be to wrap all of the unsafe bits in safe wrappers and then have a less bug prone, more secure OS, I suppose.

This would be, to put it mildly, quite difficult. Even then, unsafe code is sometimes not written correctly which brings the whole thing down.

I, personally, still think it's worth it. I think efforts like Redox OS can teach us a lot about what we're doing and offer a chance to collapse some of the layers of cruft existing OSes have accumulated.

<comment><USER29> Having only a small part of the code with unsafe means you only have to check only a small % of the code for UB/security holes and not the whole code base like in C.

It just limits the places shit can happen and which need to be closely reviewed which alone is a big help.

<comment><USER30> It should be noted that you can have correctness bugs can occur in safe code if a Rust guarantee was violated in an unsafe block. This might seem obvious, but it does mean that when you hit one of these bugs you might start with debugging safe code and thus it's not _as_ clean a separation as some Rust evangelists might imply.

</comment></comment></comment></comment><comment><USER31> Is there a video of this presentation? bcantrill's always a fun / interesting watch.

<comment><USER32> There will be it was recorded. From Qcon SF this week.

</comment></comment><comment><USER33> Another important and related question to ask is what role Lua should play in writing drivers and applications on top of a new kernel. NetBSD started on this direction, but exactly what an operating system looks like when it leverages both systems-level and scripting-level programmability waits to be seen.

[https://www.netbsd.org/~lneto/dls14.pdf](https://www.netbsd.org/~lneto/dls14.pdf)

[https://www.lua.org/wshop13/Cormack.pdf](https://www.lua.org/wshop13/Cormack.pdf)

<comment><USER34> I played with the idea of setting up a runtime for a scripting language such as JS, then I was thinking, what is a OS anyway ? If it can be written in Rust or any other high level language, it can also be written in a scripting language !...?

</comment></comment><comment><USER35> i think there is a case for a rewrite, apart from the memory safety guarantees. two things come to my mind:

1\. elimination of backwards compatibility. this is true for all new operating systems, independently of the language. clean slate and throw away all the baggage that was reasonable 20 years ago, doesn't hold true today anymore but still is baked into the old architecture. this might be less relevant for all- purpose OSes, but might be a viable option for specialized systems (IoT, Network Appliances, ...). you remember what linus says when a kernel patch breaks buggy userland code? we now get a second chance to implement a new system that avoids whole classes for buggy code (while the underlying problem doesn't go away, it may get greatly reduced).

2\. reduction of complexity. this _is_ a rust thing, and the story to back this up is [stylo]([https://blog.rust-lang.org/2017/11/14/Fearless- Concurrency-I...](https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency- In-Firefox-Quantum.html)), the parallel css engine used in firefox. i remember reading that google tried to implement concurrent styling in chrome but failed, because it got too complex in c++. human intellect is pretty much finite and doesn't scale well; we rely on better tools. so, rust might enable us to do things that were considered impossible before.

the emergence of such an OS would be gradual of course, niche at first, then slowly growing until one day it's the new de-facto standard.

lets say, game engines. you rarely write your own game engine, because that's too complex and ties up all the resources you need to actually implement your game. so you buy one and it's in C++, of course. because they all are, and thus your developers are fluent in C++. there are no game engines in rust and few developers who know the language. but over the years, more and more game devs will try rust in their spare time and like it and write game engines in rust for their side or indie projects, where it's still feasible. a few of those will grow and get more features and tooling and at _some point_, suddenly, rust will be a viable alternative. even though rusts strengths aren't really that important in game engines. performance happens on the graphic cards anyway. security is not as big of a deal. parallelism is quite constrained anyway. etc, etc. but if all else is equal, rust might be more productive.

so, is it time to rewrite the OS in rust? sure, why not. it's just that we wont all switch to redox overnight.

</comment><comment><USER36> I'm surprised there are no mentions to Microsoft Research's Singularity, that used only software barriers, and the languages used there (Sing#, Spec#) had ownership concepts ([Claims] attribute).

</comment><comment><USER37> Nim is realtime garbage collected and compiles to optimized C and it can use the C ecosystem of libraries and tooling. It also produces smaller binaries than Rust and is faster for most tasks.

<comment><USER38> Despite what the Nim documentation says, realtime and garbage collection are mutually exclusive (unless you count non-deferred reference counting and give up on collecting cycles.) Setting maximum pause times doesn't change the fact that the garbage will be collected nondeterministically, which is a problem for kernels.

<comment><USER39> Those are 3 orthogonal(ish) things.

Realtime just means that actions triggered by event occur in an explicitly bounded time. It doesn't usually mean that they occur in the same time. So a GC with bounded pause _could_ be used in a realtime system assuming you could guarantee the explicit bounds.

I can't comment on whether or not this is true of Nim and pause time probably isn't sufficient (depends on how it's defined) but they're not mutually exclusive.

And most kernels don't need to be realtime unless they are realtime kernels.

Having said that, of course, the vast majority of GC systems are most definitely not realtime, or anywhere close. But that's just actually true, not theoretically true.

<comment><USER38> > So a GC with bounded pause could be used in a realtime system assuming you > could guarantee the explicit bounds.

You _can 't_ guarantee explicit bounds on when a given resource will be collected with GC. Bounded times can provide upper bounds on GC pass runtime, but they do that by potentially deferring further collection. Those deferrals make it nondeterministic.

> And most kernels don't need to be realtime unless they are realtime kernels.

That's not true. Most (all?) kernels have internal realtime needs, e.g. responding to interrupts.

There is a way to write a kernel with a GC'd language, as Niklaus Wirth has demonstrated, by circumventing the GC where needed. But the critique I was bringing up was simply that there's no such thing as a realtime GC.

</comment></comment></comment></comment><comment><USER40> Rust allows for new architectures. Eg beos style os would be a match made in heaven as rust really shines when it comes to async code.

Also maybe you could have a less complicated memory manager as you can deal with allocations statically.

<comment><USER17> "rust really shines" they need to land async/await

<comment><USER14> We really do. It's in nightly; likely to hit stable early next year. One of its precursors is being stabilized as we speak.

</comment></comment></comment><comment><USER10> _in-kernel C tends to be de facto safe_

Huh?

</comment><comment><USER41> no.

<comment> keir-rex I was expecting to see this type of response. I don't program at low levels but it seems like this would be the responding answer. Kernel programmers would be using something else if that's what they wanted to use. Decades of experience and hard learnt lessons down the drain.

<comment> keir-rex Also, if you can abstract away at a sufficiently low level why not just do it in C where there's already a generation of experience and familiarity?

<comment><USER42> Sure, why not just continue writing C for the rest of time?

</comment></comment></comment></comment><comment><USER43> NO, and I wish HN stopped upvoting this sort of propaganda. There are hundreds of languages around and the slides did not even attempt to compare pros and cons across languages that would be suitable for kernels.

</comment><comment><USER44> > Is it time to rewrite the operating system in Rust?

No. Next question, please.

<comment><USER45> How constructive of you...

</comment></comment><comment><USER46> [http://www.erights.org/elang/intro/index.html](http://www.erights.org/elang/intro/index.html)

<comment><USER47> Hadn't heard about this before, and it does look interesting. But not sure why you're linking to it in this context without comment? Especially since it seems to be a moribund project.

<comment><USER46> E had a pretty interesting security model and there were in various E writings expressions of pipe dreams that operating systems should be rewritten using it. I should probably have linked to one of those to make the connection more explicit, but really it was just a momentary bit of snarkiness that didn't deserve more than what I gave it.</comment></comment></comment>


The US should grow the deficit, not shrink it - <AUTHOR> http://www.guardian.co.uk/commentisfree/2013/feb/08/us-deficit-obama-grow

<comment><USER2> The author does not ask the question which many are asking: Why is it okay to use quantitative easing[1] for the ongoing bail-out of banks, but not for the provision of public services?

 _[1] What is quantitative easing?<http://www.bbc.co.uk/news/business-15198789>

"As of September 2012, the Bank of England had committed a total of £375bn to QE, while on 14 September the Fed said it would spend a further $40bn (£25bn) per month. This was on top of the $2.3 Trillion the Fed had already put into QE since 2008... are the UK and US's actions different from 1920s Germany and Zimbabwe?"_</comment>


Don't Believe Anyone Who Tells You Learning To Code Is Easy - <AUTHOR> http://techcrunch.com/2014/05/24/dont-believe-anyone-who-tells-you-learning-to-code-is-easy/ <comment><USER3> "They don't tell you that a lot of programming skill is about developing a knack for asking the right questions on Google and knowing which code is best to copy-paste."

No, no, no! This always frustrates me. This is not 'coding' (maybe it is, and we should be doing less of it, and more programming). This is gluing together pre-coded snippets and trying to make it work. Continuing to do this is an impediment to getting better. Thinking that somehow this is what 'coding' is, is missing the point.

I will read a stack overflow page perhaps in a search for some direction, look at all the 'solutions' like surveying a landscape of others approaches to the problem. Then I'll throw them all away and code my own. Possibly it will share a lot with one of the answers, what I would consider a good approach. But a literal copy and paste just doesn't happen. I would consider a copy and paste a recipe for inviting trouble, because you haven't really reasoned through the problem yourself, and thus don't really understand the solution intimately.

Programming is a process of mental reasoning around your problem with an eye on the form of reasoning computers use, so you can express that reasoning to the computer in the language you're using. Because computers don't reason like humans 'reason' (ie. humans don't really 'reason'...), knowing how a computer reasons and behaves is alien and takes time to understand and learn and it takes time to become quicker at comprehending this. This is the path of becoming a better programmer. Gaining that experience so the process is less alien and you more easily can fathom how a computer will respond and behave with a certain approach of laying out of the logic you are trying to express.

Copy and paste doesn't help you at all with this. In some cases it may prevent you learning essential lessons and hinder your improvement.

<comment><USER4> Absolutely disagree.

I personally learned (as I think many people did) by copying code out of books. Whenever something went wrong, I had to figure out whether it was my typo or the book's typo or my conceptual error or the book's conceptual error. That process helped me to learn a lot, and quickly. If everything went perfect, I got to play some creative game which I loved and gave me a sense of acheivement that helped me to progress.

I no longer do this, because it's not relevant to me at this stage of my learning, but I view that as an important part of my early learning process. If you reflect on your own early learning process, I would be extremely surprised if you didn't copy and paste code. Frankly, you are surely still dependent on other people's code now, you just might call it a 'library' instead.

I agree if you're saying professional developers should avoid copy-paste (there are also legal consequences), but new learners can make great progress by using copy-paste. I would say it's an _essential_ part of studying what other people have done.

<comment><USER5> I think there's a large difference between copy-paste and what you're describing (which I'll dub 'manual transcription'). I have no formal training in learning or cognition, but I do have quite a bit of personal, anecdotal evidence to suggest that manual transcription is far more useful, from a pedagogical standpoint, than straight copy-paste.

Rather than take a boring example from my programming career I'd rather draw from my brief mathematical studies in college. In undergrad I was taking a course on Real Analysis. The course redefined, much more rigorously, certain concepts that I had understood at a much higher level--think the limit, derivatives and the Riemann Integral. Suffice it to say that these new concepts challenged my understanding of introductory Calculus, and when I was tasked with writing proofs based on the underlying concepts (e.g. neighborhoods), I struggled.

In what can only be described as frustration I decided I was going to start copying the proofs over and over. I repeatedly transcribed half a doze proofs for a few days straight (I did each one a few times each night). A strange thing happened. I began to understand the proofs. By that I mean I started to understand the intuition required to make the transition between each step of the proofs. At that point I found the material much more accessible. Reading the book was easier, the lectures made more sense, I could do homework, and consequently I could complete the exams.

I like this example because there is no copy-paste alternative. I had to engage with the material, but I chose to engage at a very mechanical level. Still, there was something about the process of reading and writing that aided in understanding the material.

I don't believe you can get that with copy-paste unless you find some other way to engage with the code.

<comment><USER4> I'm very interested in whether or not manual transcription is pedagogically beneficial.

I personally write a lot. I certainly find it useful to do that.

However, I would not normally recommend Zed Shaw "Learn Code the Hard Way" type of method of writing out over and over again. I think it probably works and you can do it yourself, but I think it's quite inefficient. I don't need to type 10 PRINT "HELLO" 20 GOTO 10 more than once to get a good sense of what's going on.

I think you most of all benefit here from the time you're forced to put in. If you can understand nothing, there's really no other sensible thing that allows you to concentrate for the time you need to make decent progress.

However, I don't think this means transcription is pedagogically ideal. IMHO building something for yourself is more effective; getting expert tuition is more effective: in terms of time spent vs benefit received.

</comment></comment></comment></comment><comment><USER6> You need multiple things to come together. Some are abstract and general, some are more specific. You need to know the tools you are using, the capabilities of your platforms.

At some lowest level it is about solving problems and knowing how to drill down and understand requirements, split a large problem into sub-problems. In that respect it is not unlike an architect or an engineer or carpenter.

Then it comes to about learning how to translate to an intermediate mental representation. Here where you you already think about the typical language paradigms. Like someone used to object oriented design starts seeing objects, factories, inheritance hierarchies. Someone used to actor based programming (like Erlang) starts seeing actors sending messages to each other. A Haskell programmer starts thinking about type-classes (presumably, I am not one).

Then it comes down writing it. Here one needs to know the tools in detail. The specific language, platform, API. Say something object oriented at the higher level could become something in C++, Java or Python here. Here is where Google-ing helps. Knowing that say oh Python has this cool built-in module that can help me. Or yeah, I'll use a smart pointer here. Well you have to know about the smart pointers.

Then here is boring but important stuff. Knowing how to use version control. Knowing how to estimate time, communicate with team-mates. Not being stupid about security.

Anyway a lot of things have to come together to make someone a successful programmer in the general sense. Some acquire these capacities formally by going to college. Some acquire these on their own.

The interesting thing is that regardless of how it was acquired, the usual instinct is to discount it while looking back. "Oh I just write Python, here is a book on syntax, learn it and start programming". That always somehow seems easy to programmers. And I have made the that mistake. Friends and family member I have tried to show/teach programming.

<comment><USER7> "And I have made the that mistake. Friends and family member I have tried to show/teach programming."

I'm just curious, knowing what you know now, how would _you_ go about trying to show someone how to program?

I may have that opportunity soon and I was going to suggest thinking about a simple yet everyday problem that arises, and try to make it better with an app (could be phone, web app, client app, etc).

<comment><USER8> I learned programming with HTML/PHP. It's great in that HTML is really easy to understand and lets you draw colorful text and pictures to the screen almost immediately. Then, you can jump to Turing-completeness with a new kind of tag, "<?PHP" that can handle form inputs and generate new HTML!

And then get them over to Python or something ASAP. PHP doesn't have enough structure for a beginner to learn good software design principles, it's best kept to just teaching a thing or two about loops and control structures.

Teaching HTML + JS is tempting, but then you kinda have to explain the whole DOM too, which just makes things complicated.

</comment></comment></comment><comment><USER9> >They don't tell you that a lot of programming skill is about developing a knack for asking the right questions on Google and knowing which code is best to copy-paste"

This is a misleading simplification. I'm sure I'm preaching to the choir here, but I'm going to elaborate anyway.

Learning to program isn't fundamentally about learning what text to type in to a box somewhere. It's about learning to think computationally. "Think computationally" is vague and doesn't mean very much to the beginner. That's because it's something you need to learn with practice.

Think about writing in normal human languages. You could say there are two things going on when you are writing an essay, for example. At one level, you are thinking about the concepts. What are your arguments? How are you going to support them? At another level, you are thinking about how to write them down -- how to encode them in a way that readers will understand.

The same distinction exists in programming. At one level, you need to think computationally. What are the inputs I have access to? How can I use them to produce the right outputs? What data structures should I use? How should I handle this edge case? At another level, you are thinking about how to write all of this down so that the computer will actually be able to do it.

Copying and pasting will help you with the second part -- figuring out how to write down the structures you come up with -- and real, experienced programmers do that all the time, but it won't help you with the first part -- figuring out what structures to write down.

<comment><USER10> "Learning to program isn't fundamentally about learning what text to type in to a box somewhere. It's about learning to think computationally."

But learning how to _start_ programming isn't about that at all, even a little bit.

Writing your first program is learning what a text editor is (no, it's not quite the same as a word processor), maybe learning about the command line interface on your computer for the first time, learning about the various dependencies between the tools and libraries you need to install to get started. There is Googling and discovering tutorials that are out of date or have mistakes in them, and figuring out what to do then.

</comment></comment><comment><USER11> > They don't tell you that a lot of programming skill is about developing a > knack for asking the right questions on Google and knowing which code is > best to copy-paste. And they don't let you in on a big secret: that there is > no mastery, there is no final level. The anxiety of feeling lost and stupid > is not something you learn to conquer, but something you learn to live with.

Just because you haven't achieved mastery yet doesn't mean it doesn't exist. It takes a very long time.

Until you've worked with masters, you may doubt they exist. But they do.

<comment><USER12> I disagree with the author -- I never feel lost and stupid. There is always a way of bringing an idea to life, even if there are compromises and tradeoffs.

But nowadays, I am forced to rely on third-party libraries. These libraries often change constantly and have "in-development" nuances. So, the OP regrettably is correct that searching the Internet is a requirement for working on modern applications.

I do reminisce about the pre-Internet days, when all I needed was my brain and a simple reference book!

<comment><USER13> I bet the person who maintained your code felt lost and stupid though! The benefit of libraries is that the reference exists at all.

<comment><USER12> You assume that all libraries are bug-free and documented accurately! I assure you that few are.

<comment><USER14> That depends. Use a well known library in Python or Perl, and they usually are well documented and tested.

Now choose some obscure JavaScript library from Joe Random on github, and what you say is probably true.

</comment></comment></comment></comment></comment><comment><USER15> I'll hijack here a bit (sorry).

A good friend of mine in in a PhD program at UCLA. She's into solid-state physics and modeling. They use IgorPRO a lot in this field (oddly, also audiology). However, she can't use it a lick. She tries, she really does, but she just can't.

Why? Dyslexia. She has dyslexia. All the variables on the screen just look the same. i++ and i--, or +i and 'hi', or for() and if(). Just the same stuff to her. Its something not usually discussed, as I think most programmers don't have it so bad. 'Up to 17% of the population'[0] may have some form of dyslexia. It's something that really does impede many many people from just reading, let alone coding and programming. Does anyone know of a work-around for this at all? Thank you.

[0][http://dyslexiahelp.umich.edu/answers/faq](http://dyslexiahelp.umich.edu/answers/faq)

<comment><USER16> This is perhaps more fitting in one of those QA sites or as an ask hn but i did some googling for you:

[http://programmers.stackexchange.com/questions/9657/programm...](http://programmers.stackexchange.com/questions/9657/programming- with-dyslexia)

<comment><USER15> Thank you!

</comment></comment></comment><comment><USER10> I have been programming a long time, and even now I often feel getting the environment set up to start something than just writing the actual code to solve the problem.

Compiler versions, dependency injection configuration files (why yes, I am a Java developer, how did you guess?), build systems, source control, dependency management, library incompatibilities, setting up a test environment, setting up and configuring databases and web servers, etc.

Maybe I don't actually spend as much time on these things as it feels like I do, but I do know futzing with this stuff when you just want to write real code to solve real problems is soul sucking and demoralizing.

So I definitely relate to the hard part of programming, beginner or not, as just getting to the point where you can actually write some code and see what it does.

<comment><USER17> I really see your point on that. I am a hobbiest scripter, I know HTML/CSS, dabble in PHP and Javascript and can read a lot of C.

I tried learning Ruby/Rails a while back and spent 3-4 hours just trying to get the environment setup. I finally realized that Windows 7 was not a very popular OS to learn Ruby on and gave up.

On the contrary, getting a PHP/Python/Javascript "environment" setup is no problem. Notepad + a hosting account or any Linux/Mac and you are good to go.

</comment></comment><comment><USER18> Programing is easy for who has already learned it. The second language is easier to learn than the first one. I think that's why programers keep telling programing is easy.

I admit that the learning curve of programing is a little steep. But isn't every skills in the world the same? Think about the first time a child learn to walk, the first time a child learn to speak. No healthy adults think these things hard to do now.

The conclusion: the programing is just like any skills in the world, they are always hard for the new beginners but become easier and easier while you are getting familiar with them. Saying if it is statically hard or not isn't an accuracy statement.

</comment><comment><USER19> To borrow from PG, treat learning to code like learning to paint (or any other creative process). You might pick up the basics pretty quickly, but the quality of your first webapp will probably be comparable to that of your first self portrait.

</comment><comment><USER20> There's merit in reminding people that a lot of development contains a decent amount of Googling, but I'm not sure that "knowing which code is best to copy- paste" is the main trait of coding.

What's certainly true is that learning how to code is dramatically easier than it ever has been; and is likely to get easier as time passes. Learning how to code is indeed pretty easy, knowing how to build a complex product goes beyond that, though.

<comment><USER21> You know what? I don't think it _is_ easier to learn to program now. Many years ago when I was a child and I got my first computer, it booted straight into a BASIC interpreter. The computer also came with a manual that taught you about if statements, for/next loops, gotos and gosubs. It showed you examples of how to draw to the screen and get inputs.

Compare that to today. There was _nothing_ to install. It was all already there. There wasn't even an environment to launch, you booted into the REPL. You didn't have to hunt for tutorials on the internet, everything you needed to get started was in the manual that came with the computer. And everything in that manual was appropriate to the computer. You didn't have to worry about having the wrong version of dev environment, making the tutorial incorrect.

That's not to say that programming hasn't improved in other respects. I could spend years trying to build a basic TCP/IP stack on that old 8bit computer, which already comes pre-installed on a modern computer. I can grab a free copy of just about any language I've heard of. Huge numbers of libraries freely available allow me to stand on the shoulders of giants. But, nothing available today approaches the simplicity of that old 8 bit system for _learning_ to program...

</comment></comment><comment><USER22> I highly disagree. The author says one of the main reasons coding isn't easy is because setting up the environment is so difficult. The problem is that if you try and learn "iOS" using XCode then of course the environment has a lot more weight and cause more issues that you really don't need to deal with as a beginner. A better option would be to fire up a simple Scheme or Ruby interpreter in a terminal and watch them go (after giving them a copy of your favorite programming book). Heck, with things like CodeAcademy you can just visit a website and eliminate the environment issue completely.

I'd say the problem with programming isn't that it's difficult, but that it's intimidating. Writing a bunch of arcane symbols and words in a text file scares people off, while really it's just everyday logic people use in a different form (at least, the very basics are). I think that's also why programmers keep telling people it's so easy, so that they get over that irrational fear.

</comment><comment><USER11> Also see Peter Norvig's "Teach Yourself Programming in Ten Years".

[http://norvig.com/21-days.html](http://norvig.com/21-days.html)

</comment><comment><USER23> >And they don't let you in on a big secret: that there is no mastery, there is no final level. The anxiety of feeling lost and stupid is not something you learn to conquer, but something you learn to live with.

One of the biggest surprises when I started to learn, LANGUAGES ARE STILL BEING UPDATED. ?_? Totally thought that was done and over with, then I come to find language/framework updates can break entire programs. First time learning Rails was when they just upgraded to 4.x and all the tutorials was in 3.x. Now that was a "FUUUUU" moment.

P.S. I thought the pictures was done quite nicely ^.^

<comment><USER24> Not all languages ignore backward compatibility. There's Fortran code written in the 1960s and C code written in the 1970s that will still compile correctly with today's compilers, even though these languages have evolved continually over the years.

</comment></comment><comment><USER25> I've been programming for maybe too long now, but likely not nearly as long as the higher level advanced developers, but still the idea that people copy & paste code from Google/SO is horrifying. You are really just going to work on some real life project and just blindly copy some random crap you found online without even knowing what it does completely? Yikes.

<comment><USER26> Uhm, that's how I still learn new languages. Copy, paste, modify just to get something done.

The modify part leads to more concrete questions, more Googling, more detailed reading of docs, until at some point I'm engaged enough to go back to zero and actually start learning the language from the basics.

(This doesn't work for those languages who's paradigm you first need to understand before being able to do anything, but most languages allow for hacking straightforward procedural code at the basic level.)

<comment><USER25> I mean this in the best way possible, but do you like actually take your mouse over to the webpage, highlight the code, copy it, and then paste it into your editor? I am genuinely curious.

<comment><USER27> Yes. I do this from time to time. Recent example, wasn't sure what the event was called in JavaScript when the window changed. Couldn't remember if it was resize or windowResize or whatever.

SE had a sample dummy event listener add function, complete with // do stuff here. I cut and paste the whole thing and added what I needed.

I suppose I could've retyped the addEventListener function from scratch but...I dunno, that seemed inefficient. I just needed the name.

</comment></comment></comment></comment><comment><USER28> I've been coding PHP html css and JS for nearly 20 years and I still learn huge swathes of new information and techniques all the time. I wouldn't say I've mastered it. I'm pretty good at foreach though.

</comment><comment><USER29> This is misleading. Learning to "code" or do the work horrifically called "software engineering" is definitely a huge pain in the ass. It's all about half-working fragile dependencies and outdated documentation. Don't do web programming. Don't do iOS. You can try it after you have used good tools first.

Instead, start by learning about computational processes. Use Racket — it's a stable, excellent environment. Read SICP or at least HtDP. You'll have fun. It's challenging, because it requires an adjustment to the way you think, but it is not particularly hard.

<comment><USER30> Oh, do iOS. You will know how elegant APIs look like.

</comment></comment><comment><USER31> With programming, art, carpentry and many other things, you just have to accept that the first project you finish will likely not be very good and the best thing to do is to throw it away and start over.

If you can embrace that idea, you can eventually learn to code.

The goal is to understand what you are doing and why, not just blindly copy and paste code that seems to work. Break it by changing something and fix it enough times and you will gain insight about how it all goes together.

Even the most complex problems can be made easy if you can break it into smaller tasks and build up to the finish.

</comment><comment><USER32> >>> One of the most dangerous things I've seen happen to people who are just starting to code is being told that it's easy.

I've encouraged my kids to learn programming. The one thing I haven't done is tell them it's easy. Anyway, they've seen me in bug hell, so they're under no illusions. But they're no strangers to learning hard things.

>>> And they don't let you in on a big secret: that there is no mastery, there is no final level. The anxiety of feeling lost and stupid is not something you learn to conquer, but something you learn to live with.

Yes! Bring it on! Bright kids spend their entire school day at the final level -- 99th percentile on every possible measure. Those kids would benefit from an extracurricular activity with no final level (traditionally, "classical" music) that they can pursue at their own pace.

>>> They don't tell you that a lot of programming skill is about developing a knack for asking the right questions on Google and knowing which code is best to copy-paste.

In my view, that's a general skill in its own right, worthy of learning. I fixed my refrigerator and clothes dryer that way. I rarely tackle any technical task without first seeing if somebody has blogged a tutorial. And I grew up fixing things before the Internet age. But I'd start kids on coding without the Google Everything approach.

>>> [the anxiety / boredom graph]

I enjoyed that. It does seem to ring true.

</comment><comment><USER14> Depends on what you want to do.

I see lots of bioinformaticians writing simple scripts usually just counting stuff up, and doing some stats. It needs to run once, on one machine and often only on one dataset.

That type of programming is easy.

I am working for a sequencing centre, doing the database to run the place. I inherited a self taught bioinformaticians code after she had left. Second worst code I have ever seen (the worst was also a self taught bioinformatician, who didn't even indent stuff). The code was so bad, I had to refactor it just to debug it. The team leader didn't see a problem. It had worked. He didn't see the fact that it would have taken me a day or two to write this from scratch, if I had had an original specification, rather than spending a week to refactor her code until it worked. To this day, I have no idea what parts of the code are doing (I can see it is reading byte 8 of a binary file and doing something. I have no idea what the contents of that file are). At least now I have made the code modular so I can see the output of reading the file into a huge nested dictionary.

Learning to code is easy. Learning to code well is not. Hell we can't even decide what coding "well" means. 100% test coverage? Shit that works? Something that is readable and maintainable? Something that runs faster than all the equivalent software? In the end I think experience will mean a developer can work out which of these is most important. Maybe just getting something that works is what is important, and the example I gave above is perfectly acceptable code.

<comment><USER33> There are so many, many categories of program that its futile to say what it means any more. Expertise in any category doesn't mean squat about anything else.

I've spent a lot of time doing embedded stuff. Totally different world. What matters here is irrelevant elsewhere.

So any time someone says "I can program" you have to ask "Where? With what tools? For what audience?" and so on. Because there are so many niches (and so many being invented every week) its impossible to guess.

</comment></comment><comment><USER34> I only tell my friends that programming is simple as a way to encourage them to get started.

Once they have begun, I tell them "sure, basic programming is simple, but you need to think hard about what you really want to do".

That generally has a good outcome and they continue to be interested in programming and wanting to learn more about it.

If you tell an interested person straight away that "it is incredibly difficult" then you will be discouraging a large number of people before they even begin.

</comment><comment><USER35> At the college I use to work at they had a sound arts program and they still do. They decided to change this a bit and make a foray into the 'cool' world of programming. Instead of hiring software engineers to design the course they let the previous "sound recording" course directors and a few lab instructors attempt to write the program . All 4 or so of those people had never done any real programming with the exception of one, who as far as I know has never been in a professional programming or software development environment. In short he did some SuperCollider stuff as a personal hobby and was good at teaching MaxMSP. However, this is a different beast than teaching python or IOS which is what they intended. Especially at it pertains to audio.

Eventually they wrote a course that included Python.

I assume the instructors realized what they had bitten off as last I looked Python is no longer on the official curriculum. This story actually gets much worse as they wanted to do Objective C but they originally hired a former instructor who was a DJ to learn and teach it. That guy didn't show up for work one day ..... and never did again.

</comment><comment><USER36> Although the basic assumption by the author seems to be correct, the author himself is not very far in his journey to become a programming master. I now study and work in programming for about 7 years. About 3 years into programming I thought the same way as the author: Tutorials and copy&paste.

If you reach a certain level tutorials become a waste of time, because you don't need structural help any more. You also understand that you shouldn't google how to implement a specific solution in the language of choice but which solution in that language solves the given problem. You also don't copy&paste because just solving a single problem is not the question any more. You can already solve most problems. It's more that the desire to improve leads to learning new principles, which means hand-copying small code examples (sometimes from actual programs not from SO questions) and playing with them until you get a feel for it and then start to use it in your daily programming tasks.

</comment><comment><USER37> When I see "programming is easy" I think "dirty, filthy lies!" When people say everyone should know how to program I think "why?" There's some weird nerd myopia going on with the programming literacy movement.

Programming takes an odd kind of thinking and is about as easy as anything else that takes a large amount of time and effort (read not easy).

</comment><comment><USER38> This is a topic I have been thinking about a lot lately, so this article is quite timely.

I was a bad programmer for a long time. For a few years, I was an engineer and basically wrote quick and dirty matlab or python scripts to do physics based modeling and simulations. But, it was never elegant or efficient or anything that I guess you learn about in upper level CS courses.

It didn't have to be. A customer would never see the code, it would never have to perform under critical conditions, it could almost never be reused because each project data set was completely different. The code was just supposed to crunch input and produce meaningful output that could be analyzed.

I got to thinking that I was a pretty good programmer because I could write those scripts.

Then I quit that job and moved to a different country. The only job here that I managed to get was as a software engineer. Here, I learned how very wrong I was. Writing quick and dirty scripts that crunch data is easy. Programming is hard. Really really hard.

</comment><comment><USER39> The kind of brain necessary for programming is the one that sees something it doesn't understand and then does everything it can to learn what it didn't understand.

The real reward in programming is clearly seeing how much your understanding has grown. But at the same time you're humbled by how much you have yet to learn.

</comment><comment><USER40> The only useful class I took in university was first year programming.

I felt like god when I first wrote an output stream to a file. I couldn't believe it was possible. Most people didn't have those kind of feelings. I think that's the difference. You're either captivated or you're not.

<comment><USER41> Then you read some science fiction and futurology forecasts and understand that there is no way future isn't going to be revolving around programming in every way. And you feel even better.

</comment></comment><comment><USER42> I found the free cs50 courses at Harvard helpful. I honestly didn't have the patience to sit through the videos, but I listened to the mp3's while exercising. All the buzz words started to make sense. I don't think I'll ever become a Programmer--just don't have the drive, but I can put up websites-- half ass, but they are improving. Yea, I know a bit about ROR, and Django, but would never call myself a Programer, or a cutesy Coder. In terms of making a living in this field, I honetly think who you knows matters more than what you know? I guess that's the case in a lot of fields? I've never had the stomach to suck up to someone I didn't truely like. I guess you have too though?

<comment><USER10> I really feel like, relative to many other fields, programmers sincerely their field to be a meritocracy. They don't always live up to the ideal. For example, a lot of programming interviews used to heavily feature mathematical riddles and brain teasers. More recently this has come to be considered a bad way to evaluate potential programmers, but at least the intent was trying to find out something about the candidate's intelligence, and not just trying to make a personality fit or something.

</comment></comment><comment><USER43> If you are considering a career as a web engineer, I think the first thing you need to ask yourself, do you enjoy tying and untying knots over and over again. If you do, you probably have the right stuff to be a really good programmer.

<comment><USER44> I've also heard web programming described as plumbing.

I wish I knew this before I started my Master's degree in IT. Programming is frustrating if you don't have an engineering background... you keep running into new problems and people telling you what you could do better.

<comment><USER45> I would never describe either finding new problems or people telling me what I could do better as frustrating! They are both some of my favourite things to experience!

</comment></comment></comment><comment><USER46> My learning has progressed from one area to the next--each person learns differently, and coding can be easy to learn, but like everything else it's difficult to master. I started out on google, pulling snippets/coaxing them to do my will, then I became good at reading docs -- and implementing straight from the docs, for instance in Laravel/Rails apps.

The next big change for me was going beyond the docs to the actual API to do even more customization, and override existing methods. It's a progression from low-level understanding to higher, and whatever gets you there - <USER2> don't give up.

</comment><comment><USER47> Coding is easy. The problem is too many "teachers" expect you to have a larger vocabulary than you need.

I taught 3rd graders to code. I also taught 1st graders, but the 3rd graders it really clicked. They would come up with solutions to things I would not have thought were possible given the limited language we were working in.

We started in "Project Europa" it is object oriented, module based, and the vocabulary is very limited. But students built all sorts of virtual robots to do all sorts of interesting things.

When I learned to code I learned in RPG, and that doesn't stand for Role Playing Game. Then I moved on to Basic. Turbo Basic, and later QBasic. I wrote a 3D boxing game in QBasic. Yes. 3D graphics from QBasic.

To this day my vocabulary in any programming language is pretty limited. Those around me get upset because I'll use a While loop and increment a counter rather than a For loop and the Index of the thing I am looping through. It is not that I don't want to use the wider vocabulary, or that I have anything against Lambda's. I don't dislike Tuples. I have nothing against using a Class. But I don't usually need more than my 12 word vocabulary to build things. If I do, that is a performance optimization. What? Itertools and product will do the same thing I did with nested For Loops? So? I didn't know there was an itertools. I didn't know there was a product.

Someone said you need to develop a knack for asking the right question of google... Nah, sure StackOverflow has 90% of the answers you'd ever need to know, and they have a clever code snippet that I will admit comes in handy, but if you have to break thought to Google, you aren't breathing the code. It is like trying to learn Spanish by carrying the pocket guide with you rather than making do with the 12 words you know until you can learn 6 more, and then 12 more then 24 more words.

Take the training wheels off and suck it up. Machines are big and fast, large vocabularies are for people who want to speak concisely. A 3rd grader may not use the best choice of words, but he can still explain to you how to make a peanut butter sandwich, or build something in mine craft.

So don't let anyone tell you Programming is hard. Programming is easy. But there are a lot of ass hats who care if you should have built a function rather than copy and pasting the same code with minor variations 20 times. Or will say "you could have done that in one line with a lamba and a reciprocal function"

"Yeah, and Einstein had someone else do most of the math for his proofs because he kind of sucked at calculus. I'll get to optimizations after I have something that runs."

<comment><USER48> _> But there are a lot of ass hats who care if you should have built a function rather than copy and pasting the same code with minor variations 20 times._

That larger vocabulary you sneer at is much of what allows developers to be multiplicatively productive, allows them to do much more work and do it in a faster and less error-prone way.

Or, put another way: are they having to maintain your code when you get tired of it and move on _or_ are they having to deal with second-order effects from your code being more brittle, less flexible, and slower to work on? 'Cause if so, they're not the asshat.

<comment><USER49> I looked at the nightly order-processing workflow for the regional retailer I worked for one time. I was gobsmacked to find that one section of it consisted of launching the same suite of 5-6 programs one time for each of our 25 locations. And "launching" meant setting a handful of run-time variables, executing the object, waiting for it to finish running, and examining the result.

It was fairly easy to see why this happened. That workflow was the heart and soul of the company's revenue processing, and no one wanted to touch it any more than absolutely necessary, to avoid breaking anything. So when they expanded from one warehouse to two, it made more sense to simply re-iterate the existing code with the new location id. When they added another location, re-iterate it again, and so forth.

I created a Launch subroutine, then replaced all those hundreds of lines of code with a for loop that simply called the Launch subroutine for each object needed. Then I went through the rest of the workflow and swapped in Launch calls where appropriate. Overnight, that workflow became much shorter, more readable, and most importantly, significantly more maintainable. Previously, if you wanted to change what programs were run per branch, you had to insert the launching logic in twenty-five separate spots. Now? Once.

 _That,_ my friends, is why we build functions, rather than copypasta-ing the same code over and over.

</comment></comment></comment><comment><USER50> "The anxiety of feeling lost and stupid is not something you learn to conquer, but something you learn to live with."

I started practicing mindfulness meditation a few years ago. Mindfulness trains you to experience your emotions without judging them; in other words, it helps you to "live with" feelings like frustration and anxiety without getting overwhelmed by them. It's been an invaluable addition to my programming toolkit.

</comment><comment><USER51> Though I'm a novice C++ programmer (working with templates at the moment), the only time I'd ever felt lost and stupid, which was just recently, was when it came time to write the end-of-chapter program in the book I'm reading.

Oddly enough, the program wasn't difficult to understand. I've even written it and got it to run before! I think what happened this time around, is I had read the chapter again, started writing more notes and had a better grasp on the material than before, that when it came time to bring all the concepts together, the example program didn't include them! For the first time in years, I actually felt stupid, borderline retarded (in the literal sense).

The example involved an abstract base class, Dragon, with 3 derived classes. The idea was to have a player fight a randomly selected dragon via Base class array and Base class pointer. At this point in the book, aggregation was discussed and shown in an earlier example, but wasn't implemented in the example. Mind you, no player class was created! So basically, arguments were passed to xDragon's defend and attack member functions via variables within the main function.

So I'd decided to create a Player class instead, and have the Player And Dragon objects interact with each other in the main function. Problem was, I hadn't learned enough to know how to do that, to which I didn't realize until error after error and trying desperately to get it running. I'd refrained from using Google and Stack Overflow for the most part, save for a few compiler errors I'd never received.

In the end, I'd decided to create a Game class that layered a Player and Dragon object. I had a feeling I should have written it that way from the start, but felt uncertain. The last errors that I was stuck on for a few days, I'd solved by way of "I wonder if this will help" lol.

Up until then, I wasn't aware that if you don't have a separate implementation file for a class, and should you decide to layer an object from that class, the class must be defined within the class declaration. Having defined member functions outside of the declaration, although within the header file, gave me: include\BlackDragon.h|22|multiple definition of `BlackDragon::calcDamage(short)', first defined here.

I will admit, it did put a damper on me. I felt like I was on a roll up until that. Perhaps I'll take a week or two break from programming get the feeling back again.

</comment><comment><USER52> There is an enormous difference between writing in English and writing like Shakespeare, Hitchens, Rushdie, or Stephen King. When it comes to coding most people confuse learning syntax with writing great software.

</comment><comment> vezzy-fnord _They don't tell you that a lot of programming skill is about developing a knack for asking the right questions on Google and knowing which code is best to copy-paste._

And this is how the security industry makes its living.

</comment><comment><USER53> "The anxiety of feeling lost and stupid is not something you learn to conquer, but something you learn to live with"

That's exactly my daily felling, but I'm just a junior soft eng

</comment><comment><USER54> A lot of coding today is "integration". This is where the code snippets and tutorials come into play. Imho, coding is probably less than 20% of development.

</comment><comment><USER55> Processing.js

[http://sketchpad.cc/h3QngEM9Vu](http://sketchpad.cc/h3QngEM9Vu)

</comment><comment><USER56> Learning to Code is really really easy. Learning to create something useful by code is the hard one.

</comment><comment><USER57> Learning to code is actually easy. What's difficult is, to master it.

<comment><USER24> Exactly. To expand on what you said:

Learning to code is easy, just as learning to write English prose is easy - kids routinely do both of these things. However, learning to be a professional software developer or a commercially successful novelist or journalist is very different from learning to code or learning to write - for most people, it requires hard work, many years of experience and learning from lots of mistakes.

<comment><USER49> I would further refine this to, "Learning to code is like learning to write prose: Easy to learn, and easy to do, but not so easy to do _well._ Especially since 'well' is at least a little bit subjective." There are plenty of people who can write well, who are not commercially successful. And there are people who are commercially successful who do not write very well at all. Cough- DanBrown-Cough.

</comment></comment></comment><comment><USER58> It is easy. It just takes years and years to become any good.

</comment><comment><USER59> With strong tests, who cares about copy-paste though?

</comment><comment><USER60> Coding is easy.

<comment><USER61> But software engineering is hard.

</comment></comment><comment><USER62> " As a programmer, there is a limitless amount of stuff to learn"

I absolutely disagree with this. I learn new things at least once a week about computer science in general. No one knows everything.

"They don't tell you that a lot of programming skill is about developing a knack for asking the right questions on Google"

So, she relies on S.O. for all her programming problems, what if other people don't? SO is _not_ my first choice anymore. Man pages are such high quality.

<comment><USER63> "As a programmer, there is a limitless amount of stuff to learn"

"I learn new things at least once a week about computer science in general. No one knows everything."

How do these statements contradict each other?

<comment><USER62> I'm not sure what you mean, but I am saying that there is not a limit to what you can learn, as programmer.

<comment><USER64> ... which is exactly what "limitless" means</comment></comment></comment></comment>


Ymacs - An Emacs-like editor for the web - <AUTHOR> http://www.ymacs.org/

<comment><USER2> Well that's impressive stuff! Especially as it doesn't use designMode or the like.

I too have had 'fun' with text editing in browsers. And I need to revisit it at some point. :-(

Here's an experiment of mine: <http://www.fluffy.co.uk/stediting/> \-- very proof of concept, only left+right keyboard navigation works so far. However, it does show that proportionally spaced text is possible with this kind of technique. Using monospaced fonts, like Ymacs does, is cheating.

I was going to do make something which would sort this out once and for all: <http://code.google.com/p/editable-framework-js/> but as is the way with many an open source project, it didn't get much further than thinking about the design.

I found this linked from the Ymacs site <http://marijn.haverbeke.nl/codemirror/story.html> which is a nice explanation about why using designMode is a nightmare.

<comment><USER3> > Using monospaced fonts, like Ymacs does, is cheating.

It was cheating, initially, but now it supports variable-width fonts as well, as you can see by selecting some other font from the menu (right-side). Of course, some serious hacks were needed. ;-)

</comment></comment><comment><USER4> Win32 firefox is hijacking the Control key.

Impressive web app. It's written with the author's own javascript library <http://www.dynarchlib.com/> which is both beautiful and extensive.

<comment><USER5> DynarchLIB documentation seems to be quite comprehensive: <http://www.dynarchlib.com/dl/index.html>

</comment></comment><comment><USER6> On a related but completely different note, if you are looking for Emacs key bindings in Firefox, try Firemacs:

<https://addons.mozilla.org/en-US/firefox/addon/4141>

</comment><comment><USER7> Another "Emacs-like editor" which misses the point. The "Emacs experience" is not about keybindings, but about an interactive and fully customizable environment. Nonetheless, great work.

<comment><USER8> It is written in JS and it looks like that JS can be edited in the editor and reloaded on the fly. That's the core of Emacs I think, being able to recode the editor on the fly.

I haven't actually tried that with YMacs so I don't know how well it would work. But I could see something like this forming the basis of an actual serious editor. The one thing I feel is missing from Emacs is a decent display engine. Of course that's not a new idea.

EDIT: I just fact checked my comment and it turns out that you can't just reload code into a running YMacs. If that were supported then I think it would be fair to call it an "Emacs like editor" or even just an "Emacs".

</comment></comment><comment><USER9> "Load it's own code". I guess it's my inner grammar nazi, but things like this at such a prominent position in an app make me cringe.

Surprisingly snappy and pleasant to use though. Does not work perfectly on Opera, but still more than I expected.

</comment><comment><USER10> Nice.

However, on my Opera10.10/Linux, '(' seems to do the same as Shift-Down, and '.' deletes. Strange...

<comment><USER11> Same here, Safari4/Mac.

<comment><USER12> I'm afraid you may need to pay close attention to the first paragraph. The one where the guy says that it only works in Firefox. By which he means "Firefox".

Given the ambition of this hack, I'm not surprised that he's not rushing to make it work cross-browser...

<comment><USER11> Ah, point taken. I guess I was too interested in the editor itself to bother reading the whole page first.

<comment><USER10> I, too, plead guilty of not reading the text before trying the demo. I mean, if there's a demo, why bother reading?

See also "Treating user myopia" on Coding Horror. <http://www.codinghorror.com/blog/archives/001306.html>

</comment></comment></comment></comment></comment><comment><USER13> Isn't there any projects to build a hosted gnu emacs? Like an ajax+canvas interface and a thing a-la mod_emacs on a server side. =)

<comment><USER14> I guess I could hack something up with rxvt-js , I don't really think it would be that useful. Would you use it?</comment></comment>


Solving mysteries of ice in the world's northernmost archipelago - <AUTHOR> https://maptia.com/coryrichards/stories/mysteries-of-ice

<comment><AUTHOR> It's pretty clear that the melting ice is bringing significant changes to Russia's far north – the questions are: Why is the perennial ice melting? How far will that melting go? And with what ecological consequences?</comment>


You have no rights - <AUTHOR> http://blog.oleganza.com/post/52698404368/you-have-no-rights

<comment><USER2> >When no one steals, it's easy to be a thief. If somebody is stealing from you, then you either put a bigger lock, or you figure out why so many people hate you so much. That's why only thief will go to great lengths to educate people to not steal to have a whole territory open only to him.

Ah, so thats why I was taught not to steal by my school teachers, parents and other mentors. Its because they were all thieves, just trying to clear their territory of competition. I'd better go buy some locks from the lock shop...

<comment><AUTHOR> Teaching that "if you steal, people won't like it" is not a commandment with a death sentence attached to it. It's just teaching how things work in society. But making a commandment or a law, and forcing people to obey it, in most cases is just a shield for violating this very principle by someone else.

</comment></comment><comment><USER3> One of the real things is that we need a framework for rights which is not dependent on "Wouldn't it be nice if everyone...." The problem, as the article notes, is that rights applied universally, are not a liberating concept.

I am going to propose one here. Rights, I see as emergent from cultural context, rather than inherent in the human condition. Culture is always an interplay between the group and the individual, groups of individuals repurpose culture all the time.

So my definition is very simple. Rights to the individual and subgroups are held where necessary for the reasonably just functioning of the culture. We recognize abortion as a right in contemporary American culture because women cannot have equality in a soul-crushing corporate workplace without it, but that doesn't mean one can declare that it always has been a right to everyone.

Similarly free speech and due process are necessary for our form of governance to survive. Otherwise we just have turn our country into something fundamentally unjust according to the ideals of our culture.

<comment><AUTHOR> Rights have "due process" attached to them, as you noted. This is exactly what creates violent religion called "state".

My suggestion is to use "contracts" as a basis for all social agreements. People voluntarily agree to certain behaviour between each other and "lock up" themselves in voluntary obligations. Breaking these obligations is punished by economic ostracism by others, who'd like to keep their obligations and benefits. If you steal, we will not sell you bread until you pay your debts. That simple. If some bunch of people agreed to not pollute the river and you come and pollute, they would not deal with you. If you disagree, no one kidnaps you, please feel free to negotiate and boycott back. Just like on your interview: if you don't like job conditions, you withdraw your service. But also employer withdraws his payment if he doesn't like your conditions. So you either come to some common grounds (without any need for "rights" or "morality"), or you go different ways.

On a large scale it can work beautifully with internet and crypto proofs of agreements. You can have millions of people easily lock up in common agreements on intellectual property, pollution, insurance against disasters etc. Anyone willing to go against existing relations will face ostracism from millions of people absolutely automatically (via dispute resolution organizations that will act as delegates/proxies).

The trick is only to grow such "contract / dispute resolution" network to a large enough scale when bullying is big economic risk. Today, people trust state to make decisions who's bad, who's good and state makes a good job to hide these people in jail and courts, so you don't even have a chance to negotiate openly. Almost no one has millions of chances to find supporters. In voluntary society you can always go to a competing agency and try to convince them that you are right and others are wrong. If they can successfully prove that to customers, they'll win the market. So what is acceptable and what is not will be decided locally by the market, never set in stone, always renegotiable to the maximum satisfaction of everyone.

<comment><USER3> Due process is a cultural thing too. I wouldn't say that aboriginal peoples whose due process is a shaman pointing a bone at someone and uttering curses necessarily is violating anyone's human rights.

<comment><AUTHOR> Typically, people were beating shit out of someone who was not behaving "correctly".

<comment><USER3> But is your view that small tribal societies without a professional judiciary are necessarily violating human rights for lack of a professional judiciary or even clear code of laws?

<comment><AUTHOR> I don't hold people responsible for their actions until they've been exposed to an argument against them. E.g. ancient doctor is not responsible for not using antibiotics. But if he does not use them when he knows about them (and they are accessible), then he is responsible.

<comment><USER3> Doesn't that mean though that it is our moral imperative to modernize all traditional peoples in the world? Under that argument, shouldn't indigenous peoples be discriminated against to encourage them to modernize?

<comment><AUTHOR> I don't believe in moral imperatives. I simply try to teach people things I understand when they are willing to listen. I'm not obliged to do that. They are not obliged to listen. But if it happens that I tell you arguments why government is evil, I will hold you responsible if you simply disagree without a convincing counter-argument. So we could have been friends before, but after could be not anymore.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> >If people steal from you find out why they hate you

This whole blog is gibberish. Juveniles apparently up vote without reading.

<comment><USER5> Same as your reply really...</comment></comment>