C2Rust: translate C into Rust code - <AUTHOR> https://c2rust.com/ <comment><USER2> This is compiling C into very unsafe Rust as a target language:

        pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int)
     -> () {
            let mut i: libc::c_int = 1i32;
            while i < n {
                let tmp: libc::c_int = *p.offset(i as isize);
                let mut j: libc::c_int = i;
                while j > 0i32 && *p.offset((j - 1i32) as isize) > tmp {
                    *p.offset(j as isize) = *p.offset((j - 1i32) as isize);
                    j -= 1
                }
                *p.offset(j as isize) = tmp;
                i += 1
            };
        }

The output is unmaintainable, like the output from a compiler. This isn't translation into usable Rust.

A C++ to Rust translator would be a good thing, but it has to be much smarter than this. This doesn't even comprehend arrays in C.

A good translator might need some human help to deal with C's ambiguities. Like "Is this an array? (Y or N)" How big is it? (Enter expression). Then you get a program that's real Rust. If the user is wrong about the size, safe Rust will either allocate too much space or get a subscript error.

<comment><USER3> I know and agree that unsafe Rust is problematic, but that criticism of this is missing the forest for the trees. The original code is just as unsafe.

Refactoring from unsafe Rust into safe Rust manually is likely to be easier than directly from C into Rust: one is only trying to deal with one small delta (like changing length/pointer arguments into a slice) rather than also having to deal with syntax changes and tooling issues.

As others have said, it is essentially impossible to automatically translate to safe Rust without non-trivial annotation effort, since C the language and C in practice is very different to how Rust guarantees safety. It seems to me that that "annotation" effort is probably better spent going unsafe to safe Rust (where, subjectively, the language is nicer to use, like better enums and less error prone control flow) rather than annotating the original C.

<comment><USER4> > The original code is just as unsafe.

But the translated code being unreadable to humans adds a whole new layer of "unsafe".

<comment><USER3> While the translated code is harder to read, it's much easier to refactor into compiler-checked safe code than the original C. I think doing the translation as part of a larger migration from C to _safe_ Rust is essentially the only defensible reason to do it, as it doesn't seem like other reasons can justify the risk of (as one of the sibling comments points out) bugs in the translator and the code being unreadable, aka, in an "unnatural" representation of trying to express C idioms in Rust.

That is to say, I don't think humans should be reading or maintaining this code for more than it takes to refactor to be safe(r). (Whether this is how this sort of tool is used in practice is a different question, and one that definitely needs to be considered.)

</comment></comment></comment></comment><comment><USER5> I think the next step would be to have a tool that can convert C into _safe_ Rust with a combination of static analysis and framework/program-specific user-written rules to translate specific C framework constructs into Rust equivalents.

An eventual goal could be for instance to automatically translate the Linux kernel with the aid of a lot of custom rules to handle its constructs.

<comment><USER6> There's a real sense in which, if this were true, we might not need Rust. If we could mechanically translate the Linux kernel to safe Rust, we could prove the Linux kernel safe. If we could prove the Linux kernel safe, that would be a strong argument against a need to translate it to Rust.

Note that this point is independent of the question of whether rewriting the Linux kernel in Rust is actually good/feasible idea. I also think that Rust has other advantages over C that aren't just safety, so it's not a complete comparison--safety is just the biggest one.

<comment><USER7> The major difference would be that future versions would be in safe Rust as well. All code written after that point would be safe.

What you say is true for a single point in time, not for the long-term future.

But, I would say this is probably infeasible, so theorizing too much about it seems a little wasteful. If the Linux maintainers, Linus et al, suddennly decided to convert to Rust, it would probably done incrementally, module by module. But it's unlikely to happen given past statements.

<comment><USER6> If we had a standard for safe C that the linux kernel could feasibly meet, then it could be a condition of future changes that it continue to be safe.

As you say, it's pretty hypothetical on both fronts--we're not gonna be able to prove that about a C project like the kernel, and they're not gonna rewrite in Rust any time soon.

<comment><USER7> As I see it the main benefits of C over using other languages like Rust, are generally the ease of getting access to raw memory, sharing pointers, and direct access to hardware. Rust is actually good at all of that too, but is just as unsafe.

The point I'm making is that the mythical "safe C", would have to remove many of the benefits of why people enjoy C, so why not just use Rust at that point?

One variation I've seen is the idea of "safer C" put forward by DJB, which would remove all undefined behavior as it's main goal.

In any case, people would need to learn something new, and that seems to be a huge barrier for any language.

<comment><USER8> What DJB stands for?

<comment><USER7> Sorry, Daniel J Bernstein, a pretty famous (if you follow the space) cryptologist and software engineer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER2> If you try making p a local array of length 10, ordinary Rust subscripting comes out. So the translator knows what to do with arrays; it just makes very C-ish assumptions about them. It just needs to know when a pointer is really an array to treat it as an array.

This has potential. If you had some way to annotate or advise the translator, it could do a much better job, and turn out safe, usable Rust.

Some of that can be done automatically by looking at calls to functions. If it's always an array going in, the formal parameter can become an array. Any C that doesn't have explicit pointer arithmetic should be translated into Rust that doesn't have explicit pointer arithmetic.

</comment><comment><USER9> How's this compare to [https://github.com/jameysharp/corrode](https://github.com/jameysharp/corrode)

<comment><USER10> (I'm one of the authors of this tool)

Our original plan was to simply work to improve Corrode. We eventually decided to to implement a new tool that uses Clang as the frontend in order to get more reliable parsing, preprocessing, and type checking of the input C code. The result is that we are able to support more code and C extensions than we thought we'd be able to building on top of the good work of the Corrode project.

<comment><USER11> Is there any hope of going after even a subset of C++? I know the difference is enormous, I'm just asking the question.

<comment><USER10> We've only started pondering what subset of C++ we might be able to support in future work for the project. Currently only C is in scope. That's an obvious next goal but it seems quite a bit more daunting!

</comment></comment></comment></comment><comment><USER12> Missed opportunity to name it 'crust'

<comment><USER13> 'C-water', because it makes things rust.

<comment><USER14> Or maybe c-salt

</comment></comment></comment><comment><USER15> The insertion sort conversion example makes Rust look intimidating and verbose as compared to C :-).

<comment><USER10> Fortunately, once you start refactoring the Rust to take advantage of the functionality that doesn't exist in C (like slices, iterators, etc), things start to look much cleaner.

Translating the code into ugly, unsafe Rust is intended to only be the first step. We're working on tools to help with that refactoring process, too.

<comment><USER16> Sounds like a case of "writing C in Rust" compared with "writing Rust". You're not really writing in a language until you're thinking in its idioms.

<comment><USER17> > Sounds like a case of "writing C in Rust" compared with "writing Rust".

Duh? It's literally taking C code and generating Rust code which behaves the same.

> You're not really writing in a language until you're thinking in its idioms.

The entire point is to get your foot in the door.

This gives you a pile of Rust code which (bugs aside) should behave the exact same way C code does.

From there on you're living in the Rust world and can improve that as you see fit.

If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does.

<comment><USER18> > If you can afford doing the initial transition in one short, later > improvements are much simpler than having to maintain an internal (moving) > front between remaining C code and new Rust code as e.g. librsvg does.

That's all well and good... _if_ you don't have to maintain the project while doing the necessary C-as-Rust -> "proper" Rust conversion. This C-as-Rust output seems[1] like it woul d be incredibly difficult to do bugfixes in and there's also the issue of what happens if the C code happened to rely on implementation-defined behavior (or even UB which the implementation happens to "do the right thing" with).

Unless you have a trivial amount of code, I'd say the right thing is to do the conversion in small chunks. This also gives you a much better way to ensure (through test suites) that you're not introducing excessively many new bugs when rewriting C-as-Rust to "proper" Rust.

[1] I realize this is early days, but I'm talking about the present time.

</comment></comment></comment></comment></comment><comment><USER19> So the demo does actually translate C into unsafe Rust. I'm guessing this translator is, thus, unaware of Rust borrowing/ownership system?

<comment><USER17> > So the demo does actually translate C into unsafe Rust.

It's semantics-preserving, and C constructs are not expected to match safe Rust, so that makes sense, Corrode does more or less the same.

Citrus generates "safe rust", it also doesn't generate working code.

<comment><USER20> The compilation target could be a Rust slab [0], much like Emscripten uses Typed Arrays [1]. In doing so, it would retain much of the safety properties of Rust, but it pushes the problem into maintaining "the heap" for the C code.

[0] [https://github.com/carllerche/slab](https://github.com/carllerche/slab)

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Type...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Typed_arrays)

<comment><USER17> That would be significantly less useful if the intent is to move the code from C to Rust.

<comment><USER20> How so?

It allows unsafe C to be incorporated into safe Rust while maintaining the same level of safety.

A similar less ergonomic solution would be to load C via WASM modules.

I'd take slab or wasm over whole lib translation into unsafe Rust.

</comment></comment></comment></comment></comment><comment><USER21> What's the use case for this? Are native C binaries/libraries not invokable in rust?

<comment><USER22> Yes, you can call any C using the Rust FFI but then you need to create a safe wrapper around the unsafe Rust calls to C. This tool looks like it's for generating a first pass at porting existing C code to Rust. Once you have that C-to-Rust conversion, it becomes much easier because you can incrementally port select types instead of incrementally porting the API and dealing with the impedance mismatch between the Rust api and C api (you can work on function arguments instead of function calls).

</comment></comment><comment><USER23> This either does not work well OR there is no need for rust to exist. Is there a pressing need for rust code that is as unsafe as c?

<comment><USER24> The goal is to assist the human in translating C code to safe Rust code. Getting to unsafe Rust code as an automated first step saves a _lot_ of work.

</comment></comment><comment><USER25>
        #define a "xxxxxxxxxxx"
        #define b a a a a a a a
        #define c b b b b b b b
        #define d c c c c c c c
        #define e d d d d d d d
        #define f e e e e e e e
        #define g f f f f f f f
        #define h g g g g g g g
        #define i h h h h h h h
        #define j i i i i i i i
        main(){char*z=j;}

This fails. The error is entity not found.

<comment><USER10> There are definitely ways to overwhelm the translator web demo. I know I'm not clever enough to block all of them. I put the page up to give people a way to try out the translator without having to build it. Please don't kill it :-)

<comment><USER25> Oh sorry</comment></comment></comment>


Why clean code is more important than efficient code - <AUTHOR> http://m.techrepublic.com/blog/programming-and-development/why-clean-code-is-more-important-than-efficient-code/4284 <comment><USER3> > _Without readability and comprehensibility, you cannot easily reuse your > code._

Without reasonable efficiency, nobody would _want_ to reuse your code. In fact, one of the hallmarks of reusable code is that it is efficient in a wide variety of circumstances; frequently the author of an API cannot predict what it will be used for, and thus must at the very least avoid pathological inefficiency when possible.

> _I was not thinking about performance, about the efficiency of what I wrote, > at all; I simply did not want to think about it at the time._

Bad software happens when you don't think about the efficiency of what you're writing _at all_. This perspective is completely detached from reality; in the real world, your code runs on a real machine and does real work. Sure, in some circumstances it's entirely appropriate to write inefficient code, but that's a decision that should be made after an assessment of the problem at hand. To intentionally ignore efficiency as a matter of policy is to ignore the facts of reality.

At the very least, you need to consider the performance impacts of the data structures you use. In most modern languages, it's not terribly difficult to use e.g. a hash in place of an array, and in the right circumstances it can make the difference between usable and unusable software. I can't even count how many tools I've used that, due to a poor choice of data structure, could not scale beyond the small data set that their authors tested them against, and were thus useless beyond a very limited scope.

<comment><USER4> I would argue that it depends on the developer. Someone just starting out and not having a great deal of experience with algorithms, data structures, security, and the like will need to spend much more time focusing on those aspects. Their challenge isn't [only] writing elegant, maintainable code... it's getting their code to work at all at a reasonable level of performance.

Someone who has been writing software for a few decades will be starting out having already implicitly rejected bad algorithms, unmaintainable designs, unscalable data structures, and poor security practices. Years of development has given them an intuitive feel for the best starting point for an efficient, scalable, and secure design.

Not to mention that anybody with sufficient experience knows to figure out the overall design first before cracking open the code editor. As such, their focus should be on keeping their code elegant and maintainable because it will be built on top of a reasonably performant architecture. And when they discover areas which need greater efficiency, the ease of refactoring the well designed architecture is an inherent bonus.

<comment><USER3> I agree with that. One thing I didn't mention in my original comment is that I think that there is often a rough correlation between elegant, readable code and at least basic efficiency. I tend to think that code that uses the right data structures looks cleaner. For instance, code using an array instead of a hash tends to look a little bit funny if it's constantly looking up elements by a particular attribute. This is especially the case today when so many excellent data structures and algorithms are already implemented in library code with nice pretty APIs. (I feel that I should mention, though, that the authors of those libraries probably worried _a lot_ about efficiency!)

</comment></comment></comment><comment><USER5> I think this title is a bit link baity. Yes, clean code is important. So is efficient code. To say one is more important than the other is needlessly oversimplifying things. How about this? They're both important; and sometimes one takes precedence over the other depending on the situation and context; but most of the time, you should just strive for both.

Clean code requires less resources in terms of maintenance, bug fixes, and extensibility, because it's easier to understand and modify. Efficient code requires less resources in terms of server maintenance and bug fixes, because it actually requires less maintenance and is less likely to catch you off guard by taking your server down.

<comment><USER6> I think the author makes a good point that clean code makes it easier to refactor for efficiency when proven where the need is real. Going the other route (making efficient code readable) is a lot harder and tends to get often "forgotten".

<comment><USER7> Premature optimization and all that.

</comment></comment></comment><comment><USER8> _As computing resources continue to grow, efficiency falls further behind another concern when writing code, though._

I've spent enough time diagonalizing 10,000 by 10,000 matrices to get frustrated with anyone who claims that efficiency in time and memory ain't important any more. Maybe not for _your_ code...

<comment><USER9> I've spent enough time reading code written by people who thought that efficiency was more important than readablility to know that not only are they _spectacularly_ wrong, but 9 times out of 10 they suck at efficiency but didn't realise it because their code was so firckin' obtuse.

As soon as their code is made more readable, not only does this make life easier for the next guy, but it also makes it a lot easier to optimise once it is clear what it is actually doing.

People who don't want to write readable code seem to subscribe to the belief that there is only one way to write a particular line of code, yet they could not be more wrong. For any non-trivial section of code in any non-trivial language there are dozens, if not _millions_ of different ways of writing it. Given that, making it unreadable is either maliciousness or incompetence, and Hanlon's Razor tells me it's probably not malice.

Moreover, most of the time the poor sod who is the "next guy" to read/maintain the code is _you_. You are the next guy. You are the audience of most of your coding efforts. If you cannot read your code 6months down the track, then the only person you're shafting with your bad workmanship is future you.

You _can_ have your cake and eat it to. Code can be both efficient and readable.

</comment></comment><comment><USER10> Code is a solution, based on a model of the problem.

Understanding a problem is more important than writing a solution that is clean in itself. However, we often don't understand a problem immediately. Writing code (and seeing the results) is one way to quickly gather data about the problem, and so help understand it.

This is where clean code can help: code that clearly communicates your current model of the problem is very helpful part of the process. After a break, it reminds you of the model; someone else inspecting the code can see the model; it is easier to see where the model is incorrect; it is easier to modify the code to correct the model; when the problem itself changes, it is easier to modify the code.

However, there is a trade-off between effort and clarity: it is a mistake to spend too much time clarifying something that might not be correct (or, if the problem will change soon, making it incorrect). Just write code that reflects your understanding of the problem. Regarding efficiency: if you know how to easily make it more efficient without compromising that (e.g. without making it convoluted), then of course do it.

Code is not a final product, but a process. The faster you can iterate, the better it is. (An exception is if you already understand the problem _perfectly_.)

<comment><USER11> "...it is a mistake to spend too much time clarifying something that might not be correct.."

I think the problem is that too many people disagree on what is 'too much time'. Not trying to nit-pick but obviously it is a mistake to spend 'too much time' doing anything. That's implied in the too much. That may come off as being pedantic, but I don't mean it to be so. I think defining 'too much time' is right at the heart of the problem. And it's a hard problem to be sure.

I'd also disagree that the possibility of something being incorrect is a reason to spend less time clarifying it...I'd say just the opposite.

By clarifying code you're making it easier to comprehend and thus change in the future. I'd say you should write code with change in mind.

Regarding 'incorrectness' itself...that's the only reason code is ever changed. Whether the code is fundamentally incorrect (the type I believe you were referring to) or temporally incorrect, the incorrectness of the code is always the reason for the change.

<comment><USER10> I agree the exact trade-off is difficult. I just meant clarity is not an absolute. You shouldn't make a _project_ out of clarifying - it shouldn't be a driver of what you are doing; instead, given different ways of developing quickly, you should choose one that gives clearer code. Write it as you see it, instead of trying to be clever - that is, write in in terms of your understanding of the problem not beyond it. It's bang per buck: "a little effort for a lot of clarity" is worth it.

As for the exact trade-off: when you are iterating quickly, it is not effective to try to nail down these trade-off precisely - you need those cycles for actual coding!

For that matter, it's also difficult to define what is "clear" - or even what is "simple". Have you ever tried applying the "Single Responsibility Principle" thoroughly? It's amazing how many genuine "reasons to change" you can find - and amazing how less clear it can be. Another example is dogmatically writing "short methods". Clarity, like "simplicity" - and like the trade-off you note - is itself extremely hard to pin down precisely.

BTW: reasons to change other than correctness include: making it more efficient; making it clearer (e.g. refactoring); making it reusable (Brooks' says it's x3 the work). And, in practice, there's a continuum of correctness, not true/false, for "better" (more accurate, more reliable) results: e.g. more accurate search ranking; better collision detection; better webpage rendering; OS that crashes less often.

<comment><USER11> I'd agree that refactoring for clarity can't reasonably fall under a wide 'correctness' umbrella. Definitely more reasons to change code than correctness.

I put the word in quotes to try to express a much wider than usual connotation for the word (air quotes, if you will..). It's a shame that language is all we have to communicate on the internet.... :)

I also agree that we shouldn't precisely define tradeoffs before continuing on a single, specific, problem.

I just think that, in the macro sense, we can and should get better at defining the factors that would inform such a precise weighing of the tradeoffs for clarify, efficiency, expediency, etc... Doing so would give us better instincts for single instances where doing a precise comparison would be absurd.

<comment><USER10> I agree it would be good to improve at weighing trade-offs. This is the standard method of progress in many fields, systemization of data, the finding of rules, the development of models - theories, in short. A nice practical example is Deming's quality management. They used to think you could improve quality up to a certain point, but beyond that you just have to put up with some random amount of defects. He showed that with measurement and accurate models, you can increase quality as much as you like. Is that more or less your thinking?

But I think there's a fundamental barrier for software, because programs can differ from one another arbitrarily. This makes it hard to generalize - <USER2> generalization is the essence of theory, rules, systemization, modeling etc. I assume you'll accept that generalization is crucial, but you'll disagree that software can vary arbitrarily.

The reason I say this is because if you find regularity in software... you can automate it. Factor out a common method. Extract a "pattern" into a framework (or better, in functional programming). Derive one thing from another. It's like compression: as soon as you notice something that you can generalize, and construct a theory to model it... you can use that theory to eliminate the redundancy.

In a deeper sense, programming itself represents theories. And theories (e.g. of physics) are not generalizable: we don't have a theory of theories, that enables us to automatically generate the next correct theory. Oh, we can automatically generate theories, just not correct ones. For that, we need data to test them, to find out which one is correct. And so the unknown is the ultimate cause of the problem: we can't generalize what we don't know.

The best you can do is come up with rules of thumb, that help in specific domains - but they only work there. And if they are really accurate, someone will encapsulate them in a method, a framework, a library, a language or operating system, so that programmers don't need to deal with them, and that pattern disappears from their programs.

And to finish off with one of my favourite quotes, by Alan Turing: _There need be no real danger of [programming] ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself._

NB: in practice, there is an _enormous_ amount of repetition in programs (and parts that are common between different programs). This amounts to ongoing demand for libraries, frameworks, languages, operating systems, and extra features for them.

So, it's hard to obtain a _precise weighing of the tradeoffs for clarify, efficiency, expediency_ when the playing field keeps changing. We can get better, but not much. It's different in fields like civil engineering, where materials and techniques don't change often. BTW Another fuel for change in software is Moore's Law - which enables different techniques to become favoured that weren't plausible before (like dynamic languages, VMs, etc).

sorry, such a long and self-indulgent response. Maybe it doesn't apply so strongly to trade-offs (though I think clarity is closely related to theory). At any rate, it doesn't stop us improving, which is what you suggest.

</comment></comment></comment></comment></comment><comment><USER12> I guess "clean code" is in the eye of the beholder. A lot of my work involves supporting scripts written in an extremely terse language (q <http://code.kx.com>). Coming from a Java background, the code looks horrendous, incomprehensible even. But the language is designed for the analysis of a huge amount of data using concepts from linear algebra. Any attempt to re-write the code following the tradition "Clean Code" recipe could result in inefficient code. I think there is a sweet spot for each application or domain, somewhere between the efficient (but unreadable), "clean" (but posssibly inefficient) axis. This sweet spot depends on the tools, the problem set and constraints that the developer is working under.

</comment><comment><USER13> There aren't any easy answers in software development because it's an art, not a science. In some circumstances clean code is better, in some circumstances efficient code is better and if deadlines and money are involved sometimes a complete hack job that's both ugly and inefficient is best. Whenever writing software you have to look at all your available resources, hardware, developers, money, time and figure out the best way to utilize those resources. If a hack job will pay for a rewrite and you don't have time to do it right then do that.

</comment><comment><USER14> The author wrote: "I wrote code that correlated a short list in one record with a long list of values that resided in another record, summed values that matched between the two lists, and presented the result. ... It was all very clear and clean code. Unfortunately, it turned out to be horrifically inefficient, though I did not notice this fact at first. It was only later when I decided I needed to be able to perform this operation hundreds of times and produce tabular output to show a visible matrix of results that the failures of that approach became obvious."

This reminds me of an approach I took on a recent project, where I wrote a variety of ultra-simple routines to look up very specific numbers and results. These routines would often go out and fetch a rather large file of data, and crunch that data down to the single result the caller desired. All in all, it was a _highly_ inefficient way to do things. However, it was not a problem, because all I had to do was drop in a few caches here and there inside the routines, and voila, the whole thing became fast enough.

I found it a very liberating approach, because all of my code looked very "obvious" in its logic. In a few scattered places you see a couple lines of code to look something up in the cache first, but then it drops down into the ordinary and extremely clear logic.

The code also had a very nice "lazy", "on-demand", and decentralized feel to it, with no need for a bunch of gnarly and centralized initialization code.

</comment><comment><USER15> Because it is easier to make clean code efficient than to clean efficient code. (I m talking about implementation (in-)efficiencies, not architectural ones)

<comment><USER16> Optimizing clean code is easier, but you're gambling that your overloaded service will only lose credibility slowly enough to give you time to finish (e.g., Twitter found themselves on very thin ice for a while). Refactoring efficient code takes more work but doesn't come with that kind of deadline, it just slows down maintenance in the meantime.

<comment><USER17> Yeah, it's unfortunate that when your clean but inefficient code falls over, the engineering department takes all of the blame. But when your efficient but unclean code doesn't allow you to iterate as quickly, it's harder to place blame.

</comment></comment></comment><comment><USER18> This statement is false for people writing large scale distributed systems. It turns out tens or hundreds of thousands of computers are more expensive than engineering time. No amount of clean will fix gaping million dollar holes in the budget.

And given migration of large clusters from one piece of code to another is expensive you want to think about performance ahead of time.

<comment><USER19> Isn't the primary requirement for writing a highly scalable distributed system to have clean and strictly decoupled code? Otherwise scaling becomes a series of rewrites.

And in that scenario engineering time may be less expensive than tons of iron, the _passing_ of said time is a killer. In most software project, time is a bigger issue than money.

</comment></comment><comment><USER20> This is a false choice, and much of the discussion here is arguing for or against a strawman. Pick the right algorithm, and your efficiency battle is mostly over. Code it cleanly and have good tests for it. Then, when you discover where the actual performance problems are, you can fix them, transforming clean, correct code to faster, clean, correct code.

</comment><comment><USER21> I'm cleaning up someone else's code that didn't contain a single comment. When finished, the cost for doing this will exceed the original project (we're talking man-months here).

After that, I'll worry about correctness and efficiency.

In the mainframe days, we used to have code reviews that forced programmers to structure things properly, or they'd hear about it in the reviews.

</comment><comment><USER22> Taking a solid, well-thought-out approach to problem solving is not premature optimization. Focusing solely on "cleanliness" of code is highly misguided in many cases. It's quite possible to write clean code that adeptly solves a given problem, but in order to do that, efficiency cannot be disregarded.

</comment><comment><USER23> I'm going to be the heretic here and say both camps are wrong.

The most reasonable approach is to have clean code with a little sprinkling of efficient code where it matters. So if you've built a nice cocoa app you don't need to hand code in assembler each little part of it. Just that main image processing loop. Even in that case, document it well.

Now let me go a little further and say that clean code and efficient code are not at all mutually exclusive. If you find a programmer is producing efficient (dare I say even fast), but un readable code it may be time for them to find new employment.

It's not really hard, keep your Knuth/Dijkstra/Rivest handy, and refer to them when needed.

</comment><comment><USER24> When I'm trying to push product out the door, I always fight the urge to optimize. As a compromise, I try and make it easier for my future self to optimize later, along with a note in a dedicated 'when you have time' doc.

Sometimes it actually works ;)

</comment><comment><USER25> Did anyone else find it somewhat ironic that that page looks terrible on wide screens, and is as such quite difficult to read? Columns are important, especially when your readers may be dyslexic (Like I am), narrower pieces of text are far easier to read than 'wall to wall' solid chunks of text.

</comment><comment><USER26> Clean code is as important as efficient code.

Also I don't believe in the idea that the enhancements of hardware are to put up with lousy code.</comment>


JavaScript runtime for Unreal Engine - <AUTHOR> https://github.com/ncsoft/Unreal.js <comment><USER2> Using UE4 fulltime for months, I welcome this.

Not that it's not ridiculous, it is, but an alternative to their C++ API is a good thing. There are already other languages somewhat in there, javascript makes sense.

How ironic is it though, that if you target HTML5, you're writing javascript to be compiled to c++ and back to javascript via emscripten.

There are things that are annoying to do in Blueprints, or that you simply can't do because the API isn't exposed. A simple javascript backend might be perfect to fill that gap.

</comment><comment><USER3> Sane javascript in Unreal 4 is definitely interesting, however, take a look at the repo's owner.

This has a lot more staying power as a portion of the platform given the fact that NCSOFT, producer of Guild Wars and Aion, is the company behind it; this isn't a hobbyist hacking together a solution to build a proof of concept, this is a giant publisher potentially throwing their weight behind their new platform. Their new, opensource platform.

</comment><comment><USER4> So I can run asm.js compiled Unreal Engine in my browser then run JavaScript inside of it?

We need to go deeper!

<comment><USER5> No, because V8 has no interpreter (although they are working on one: [https://code.google.com/p/v8/issues/detail?id=4280](https://code.google.com/p/v8/issues/detail?id=4280)), only JIT, and JIT doesn't run inside asm.js.

asm.js-compiled JavaScript engine has been done already: [https://github.com/jterrace/js.js](https://github.com/jterrace/js.js).

</comment></comment><comment><USER6> See also: [https://forums.unrealengine.com/showthread.php?3958-Scriptin...](https://forums.unrealengine.com/showthread.php?3958-Scripting- Language-extensions-via-plugins)

</comment><comment><USER7> Incredible.

Other language integrations with UE4 felt half assed or plain unusable. Kudos to NCSOFT for Apache2-ing it.

</comment><comment><USER8> I'll wait for the day when a rewrite of the universe in JS is available on GitHub.

</comment><comment><USER9> nice binding.

Particularly good to see its using es6 to wrap the native api.

Since writing C++ for UE4 is rather a pain, this could hit a sweet spot between C++ tedium and blueprint madness.

</comment><comment><USER10> this feels... wrong</comment>


Facebook's 99%: Later employees may pay almost double the tax rate - <AUTHOR> http://www.insidefacebook.com/2012/02/06/facebooks-99-taxes-restricted-stock-units-rsus/ <comment><USER2> Just to spell it out - there are three (main) reasons why we would want capital gains taxed at a lower headline rate:

1) Capital gains are already taxed at the corporate level. People seem to intuitively understand how this works at the dividend level (dividends are paid with post tax dollars), but if you do the math, it works precisely the same with capital gains. (Please note: Tax incidence is complicated. Not all the corporate tax is borne by investors. Especially in small open economies like the UK, it's actually mostly paid by the workers via lower salaries.)

2) Speaking of which...capital gains are a tax on investment. Investment leads directly to increased labour productivity. Productivity leads directly to higher salaries. If we want employees to be paid a lot, we want, as a matter of public policy, to encourage investment. At this point the observant will pipe up "wait, are you saying it's good for the _workers_ if we tax worker salaries more heavily than capital gains income?!" Yes, that's exactly what I'm saying, and it's supported by a rich body of empirical and theoretical backing. Heavy capital gains taxes are the precise policy you'd implement if you wanted to keep labour poor and unproductive. (If it helps, consider that investment is saving - it's an accounting identity - and the US has a big problem with low savings rates, which in turn means that they struggle to get enough investment without borrowing from overseas lenders. See the problem?)

3) Finally, investment income isn't just already taxed at the corporate level - it's also already taxed at the personal level too. Imagine two people, Spendthrift Sally and Frugal Frank. Both work at jobs making $200k/year, _after tax_. Sally spends all her income on consumption, and saves $0. Frank spends 75% of his income on consumption, and saves $50k/year by purchasing stocks which go up in value by 5% per year. After twenty years, Frank has spent $1m total on stocks now worth a cool $1.7m (clearly he follows the buy- and-hold school of investing). He is retiring, and wants to sell them all to re-invest in safer bonds. What tax rate do you think is fair? He made those investments with _after-tax_ dollars. Do we now tax him again on the result of those investments? Don't we _want_ people to behave like Frank, instead of Sally? And if we charge him 15% on his capital gains, he'd end up paying over $100k MORE total tax than Sally. Does Frank, who has scrimped and saved his whole life, _really_ deserve to pay more taxes than Sally, who never saved a penny?

(The analysis becomes more complicated if Frank received the stock as compensation, instead of purchasing it with his salary. But keep in mind that he's still (1) taxed on that initial compensation and (2) is deferring consumption; a responsible choice which we as a society probably want to encourage.)

<comment><USER3> To your points:

1) Sure, but effectively _all_ income is multiple-taxed. Suppose I run my own business, and am paid by a consumer with their money that they earned as wages. If I turn a profit, I then pay taxes on that income. By this logic, I shouldn't have to pay taxes, because the consumer that paid me was using after-tax dollars, so taxing my income from them would be double-taxation, right? The double-taxation argument is simply not very-compelling because there's no one true wellspring of money; if there were, you'd just tax the source and call it good. But reality is way more complicated than that, and money is always taxed multiple times as it moves around the economy.

2) I don't think you're correct about there being empirical evidence of capital gains rates affecting those things. For example, see [http://www.slate.com/blogs/moneybox/2012/01/19/capital_gains...](http://www.slate.com/blogs/moneybox/2012/01/19/capital_gains_taxes_and_savings_rates.html). As far as I know, there's no credible empirical evidence that cutting capital gains rates deterministically helps investment or saving, or that raising them hurts those things. Sure, you can pick and choose examples with those outcomes, but you can also find plenty of empirical examples where those effects didn't happen. It's totally misleading to act like that's a settled question in economics.

3) He's paying more in taxes because he ended up earning more money. So yes, he deserves to pay more in taxes than Sally, because he earned more money. Otherwise, you could easily say "Sally decided to work part time and made less money than Fred. Does hard-working Fred really deserve to pay MORE in taxes than Sally?" Yes, yes he does; unless you really think that a poll tax is a good idea, even a flat-tax advocate would have to argue that someone who makes more money should pay more in taxes.

<comment><USER2> 1) Actually, no. We tax transactions. Your customer is buying a service from you, and we tax that. When you hire an employee, you are purchasing his labour, and we tax that.

But if you pay yourself a dividend, there is no transaction. If you own an asset, and it goes up in value, there is no transaction. (Capital gains tax is not on the transaction of selling your stock, but on the change in value of the stock; it's only realized at sale. Some countries do charge a transaction tax on stock sales, usually called a stamp duty, which is entirely different.)

More generally, we tax things when they change ownership. (We even tax things when you give them away!) In the case of a small business owner, everything in the business is owned by you. It's yours. You own the business, the business owns the couch, therefore, _you_ own the couch. Ownership is inherently transitive. Even in a large business, everything is owned by the stockholders. Businesses are not people. (Note: At this point, people usually bring up _Citizens United_ , despite the fact that the decision does _not_ claim that businesses are people. Try reading it; it's actually pretty interesting.)

Thought experiment: Can we tax you on the rent you are implicitly paying yourself for living in your own house? Why or why not? And if we can't tax you on the value of the rent your house is providing you, why can we tax you on the value of the things your business is providing you? (Well, obviously, we can do it because the law says we can. But morally, the difference seems remarkably theoretical.)

Further thought experiment: Should you be taxed if you hire yourself as an employee? I'm actually torn on this one. Logically, the answer seems like it should be "no"; it doesn't matter if you hire yourself as an employee for a salary, or work for "free" in exchange for equity. Intuitively, it feels to me like it's okay to tax an owner on his salary but not his dividends. _shrug_ Guess I'm not that logical. :)

2) Yglesias' post is suggestive, but doesn't really prove anything. As I said, there's a LOT of research on this point, and saying, as he does, "Germany added a capital gains tax, and their savings rate didn't immediatly change" does not really tell us as much as he thinks. Germany has also been noted for extremely low wage growth recently. Clearly the result of underinvestment caused by their pernicious capital gains tax, right? I doubt it, but it's no more implausible than Yglesias' argument.

</comment></comment></comment><comment><USER4> Meet Facebook's 1% <http://news.ycombinator.com/item?id=3561273>

Shows you how out of the loop I am about Facebook, I didn't even know who this was

 _Dustin Moskovitz has a 5% stake in Facebook, which for an $85 billion company would equate to $4.25 billion. That's around $157 million for every year of his life._

(if I understand it right, he only will pay 15% tax on that - and Forbes says he has 7.6% stake, not 5%)

<comment><USER5> In the movie, he was the guy trying to figure out if that chick was single or not, giving Zuckerberg the inspiration to add relationship status to Facebook.

<comment><USER4> Unfortunately I am at least two years behind on movie releases, not even sure I'd see that film anyway though.

</comment></comment></comment><comment><USER6> Is the article's bogeyman description of RSUs accurate at all? My understanding was that an RSU was equivalent an option priced at $0. The issue is the _exercise_ date, not option-vs-RSU. Lots of public companies (Amazon, Google, etc give at RSUs). the issue, as jpdoctor mentions in this thread, is that you pay income tax on the value of stock (minus option price, if any) on the day you exercise, which is some time between vest date and sell date (option/stock-holder's choice).

RSUs are only expensive if they vest when the stock is expensive, _exactly the same as with options_.

In either case, the earlier they vest, the lower taxes are (due to capital gains tax rates)

The only way I can imagine the article making sense is if Facebook gave employees _delayed vesting schedules_ beyond the usual 25%/yr, and so stock grants vested later (at higher market price) than they would otherwise.

Yes?

<comment><USER7> An RSU is not exactly equal to an option with a strike of $0, because you control the exercise date on an option. Not so on an RSU.

The taxable event with options is the date of _exercise_ (or the 83b election), not the date of _vesting_. The option owner has control over the date of exercise, meaning they can delay exercise until after the vesting date.

An RSU, having a "strike price" of $0, "exercises" (and therefore is a taxable event) the instant it vests.

In both cases, the gain (the surplus of fair market value over exercise price) is ordinary income and taxed as such.

In both cases, the gains (or losses) after the initial taxable event are capital gains, and the rules are not as simple as for stocks, but basically, for employees with typical vesting, hold the shares for a year after exercise and these gains are long-term capital gains.

</comment></comment><comment><USER8> They almost certainly don't understand the story: It's more likely worse than they are mentioning.

Most reporters have never heard of the 83B election. tl;dr = Zuck already paid the tax on his options for exercise, at par (0.001 $/share is typical.)

The tax system is truly brain-damaged.

<comment><USER9> Isn't that the whole point of the story? Zuck paid income tax on the initial grant's value (which may be par value), and the stock's appreciation will only be taxed at the reduced capital gains rate?

<comment><USER8> > _Isn't that the whole point of the story?_

No, it is not. This sentence in bold tells you they do not understand: "Zuckerberg will be paying taxes on $5 billion in gains from exercising options." If you don't understand why that is different than my comment, then you don't understand the issues of the 83B election also.

Now, odds are you a smart person. And that is _my_ point: It doesn't matter how smart you are; The vagaries of the tax law are so numerous and extreme and obscure that you can only come to the conclusion: The tax system is truly brain-damaged.

<comment><USER10> Can you please explain it?

<comment><USER8> First, IANAL. Second:

83b election essentially says: Dear IRS, I know I received all these unvested unexercised options, but I want you to tax me on them as though they were all exercised when I received them. You do this in the year they are assigned to you.

Since this is before the company actually takes funding, the shares are worth some stupidly low number ($0.001/sh). So 1M shares is $1000 of income. Since he was not making much money, that amounts to maybe $200 of income tax on 1M shares.

When he goes to exercise the options, _no income tax is paid_ because he already paid it! He can use those share for ALL SORTS of collateral for the future. As long as he doesn't actually sell the shares, no income tax is due.

<comment><USER11> Thanks for the explanation. I'm trying to understand whether 83b elections would apply to me-I'm an employee who received options that will vest over a certain number of years. Should I be making a 83b election every time part of my options vest? I expect the fair market value of the stock in the future to be higher than when I receive my options.

<comment><USER8> First, I am not knowledgeable enough to provide advice.

With that in mind: My experience is that it makes sense to go the 83b route before any funding rounds (when the price is 0.001 $/sh).

After that, there is usually decent money going out the door to the IRS. Since such a tiny fraction of startup shares are ever worth a damn, it just isn't worth the time, money or hassle.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Can we please knock off the nonsense of this "Buffett secretary" talking point? Debbie Bosanke is estimated to make north of $200k per year, while Buffet is paying capital gains rates. Of course her rate is higher.

<comment><USER13> "Of course her rate is higher."

I think the vast majority of people would expect a billionaire to pay a higher tax rate than an upper middle class person. I wouldn't call that nonsense.

<comment><USER12> I'm sure that you're right, but then the vast majority of people are easily swayed by cheap political rhetoric. If they're playing by the same rules, which it appears that they are, then what's the problem? It's not like he hasn't already paid income tax on that money the first time he earned it, and his absolute tax bill is vastly larger than hers is.

If not being jealous and covetous of those who make more than I do puts me in the minority, then I guess that's where I'm at. Sadly, I believe that to be the case.

<comment><USER14> Capital gains are not really double taxation. Sure he paid tax, but then he earned more. Many countries charge income and capital gains at exactly the same rate, eg the UK does now.

<comment><USER15> How are they not being taxed twice? A company (which has owners) pays income tax on their profits, so the company and therefore, owners, have less capital remaining. Then, if the owners want to cash out anything from the post-income- taxed margin, they'll have to pay capital gains as well.

<comment><USER13> It's not that simple. One could just as easily make the case that workers get a lower salary due to higher corporate taxes, therefore they should pay a lower tax rate than owners. In short, it's not at all clear that a higher corporate tax rate is purely a tax on owners, and nothing else.

<comment><USER15> Employees are payroll taxed, that is different and regardless of the company's income, net or otherwise.

<comment><USER13> I'm certain the amount of profit after taxes affects the wages a company is willing to pay. Do you really think they are completely independent?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Yes, this is truly tragic.</comment>


Get information about any country via a RESTful API - <AUTHOR> http://restcountries.eu/

<comment><USER2> This is nice if considered a programming exercise but it's actually pretty useless for real world use.

This data is static, that is it very rarely changes. The whole dataset is also very tiny. It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.

An idea on how to make it more useful is to provide downloadable data dump in several formats suited for immediate import into various data stores. An extra addition might be modules for popular frameworks providing access to this (local) data in all the ways your web service does.

I'm not trying to diss, just trying to find some value for real world usage. The service is neat otherwise.

<comment><USER3> >> It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.

Isn't this the point of rfc2616 sec13? I haven't looked, but if there are etags etc then I think a computer is better than a human at looking for new data, no?

</comment></comment><comment><USER4> "JSON Data is taken from [https://github.com/mledoze/countries"](https://github.com/mledoze/countries")

The data is cool, but seems overkill to do an HTTP call when the full dataset is 11K (gzipped).

</comment><comment><USER5> Why not just publish a JSON file? It's not like the data source is that large or changes often. No reason to have an API for this

<comment><USER4> Apparently the data does come from a JSON file: [https://github.com/mledoze/countries/blob/master/countries.j...](https://github.com/mledoze/countries/blob/master/countries.json)

</comment></comment><comment><USER6> Some of the data seems to be incorrect:

[http://restcountries.eu/rest/alpha2/za](http://restcountries.eu/rest/alpha2/za)

The South African currency is ZAR, not SOS. Cape Town is the legislative capital, but not _the_ capital.

If you search by currency for ZAR:

[http://restcountries.eu/rest/currency/zar](http://restcountries.eu/rest/currency/zar)

You get South Georgia. I assume that's meant to be South Africa.

<comment><USER7> And what about the Netherlands which has two capitals? A national capital (Amsterdam) and an administrative capital (Den Haag)?

And what about countries that use two currencies... oh wait, Cuba actually lists two currencies; never mind.

<comment><USER8> As a Dutch person I would say Amsterdam would be the correct listing as it is the official capital, which is what is listed.

</comment></comment></comment><comment><USER9> That's pretty awesome :) Simple and too the point. Nice project :)

</comment><comment><USER10> You have "CZ,Ceska" as an alternative spelling, but in fact it is "Česká republika" or "Česko".

Especially since you have "AT,Österreich" for Austria.

Shall I submit it to mledoze/countries instead?

Edit: solved - submitted a pull request

</comment><comment><USER11> (Disclaimer: I work for Mashape). I added this API to Mashape [https://www.mashape.com/community/rest- countries-1#!document...](https://www.mashape.com/community/rest- countries-1#!documentation)

</comment><comment><USER12> The callingcode endpoint only returns one result even when there is more than one that qualifies, as is the case with 1 and USA and Canada (and others that are part of the North American Numbering Plan)

</comment><comment><USER13> Maintainer of the dataset here. Most of the inacurracies have been fixed now.

More data will come soon. Thank you for all the feedback, I appreciate it!

</comment><comment><USER14> Pretty crappy search, query for "india" returns "British Indian Ocean Territory" as the first result.

<comment><AUTHOR> ordering by "relevance" is coming =)

</comment></comment><comment><USER15> Obligatory warning: API is absolutely not restful.

<comment><USER16> Just wanted to add some thoughts on how one could try to make this RESTful. First, if it were me, I'd pick a media type that can express hyperlinks in JSON (since JSON knows nothing about hyperlinks), maybe something like HAL [1]. Next, I would define my link relations for this API, which in this case would be a collection of countries and the countries themselves (so at least two different types of resources).

After creating the representations of each of these resources, I would then create URI templates in my root response (I guess found at /rest) that allow for the searching aspect that this site is providing, which would be something like:

      {
        "_links": {
          "search_by_name": {
            "href": "/rest/name/{name}",
            "templated": true
          }
        }
      }

I may build on to this to provide other resources, like a collection of capitals, each with a link to "/rest/capital/{capital_city}", or a resource of currencies, linking to "/rest/currency/{currency}".

The goal of all of this would be to tell the client how to find resources rather than having that hard-coded into the client. These are just some first steps toward being RESTful, and there are lots of different directions you could take this and still be RESTful.

edit: example was incomplete

[1] [http://stateless.co/hal_specification.html](http://stateless.co/hal_specification.html)

<comment><AUTHOR> thanks for your input. i'll think about this

</comment></comment></comment><comment><USER17> The capital of Canada is Ottawa, not Ottowa.</comment>


After Last Year's Hurricanes Caribbean Lizards Are Better at Holding on for Life - <AUTHOR> https://www.theatlantic.com/science/archive/2018/07/hurricanes-irma-maria-lizard-grip/566006/?single_page=true <comment><USER2> The surviving lizards are the ones who are capable of holding on through hurricanes. The title almost implies that the lizards as a whole trained to get better at holding on. The article explains it well:

"He found that, on average, the post-hurricane lizards had toe pads that were 6 to 9 percent bigger than those of pre-hurricane individuals, and front legs that were 2 percent longer. This wasn't because the bodies of specific lizards had changed; there's no evidence that the toes of adult anoles can grow by that amount. Instead, the storms had simply wiped out all the lizards with small toe pads. By selecting for individuals that were better at clinging to surfaces—and presumably at withstanding high winds—the storms had changed the average proportions of the population."

<comment><USER3> The title is how a lot of people understand evolution, though. As if the lizard's genes or evolution itself has intent and makes decisions based on stresses. This misunderstanding often involves a misunderstanding of epigenetics, as if an organism can concentrate really hard and change its genes (insert X-men movie special effect with the camera zooming in to the sub-cellular level and seeing helices go from blue to red) and produce larger toe pads.

Selection is an unfortunately overused euphemism for death.

<comment><USER4> > Selection is an unfortunately overused euphemism for death.

Sure, as long as you consider "failure to reproduce" or "managing to reproduce, but not at a very high rate" to be synonyms for "death".

</comment></comment></comment><comment><USER5> These lizards are amazing. They can also jump over large distances relative to their size.

I wonder if the improved toe pads will impact their jumping abilities?

Changes to the tail are known to impact them: [http://www.anoleannals.org/2012/09/15/jumping-without-the- ta...](http://www.anoleannals.org/2012/09/15/jumping-without-the-tail-is-bad- for-an-anole-and-it-might-not-get-better/)

They are slightly impacted by large meals: [http://jeb.biologists.org/content/214/12/2073](http://jeb.biologists.org/content/214/12/2073)

</comment><comment><USER6> So evolution at work as hurricanes become more frequent lizards will get bigger toe pads. It would be interesting to see 10-20 years from now how large the toe pads grow on average with smaller toe pad lizard dying out.

</comment><comment><USER7> This article seems to confuse 'selection' for 'evolution'.

These lizards haven't evolved - their genes are unchanged. It is their population that has been selected against for new pressures. This will potentially drive evolution genetically, however on such a short time scale there has been no evolution yet.

I guess you could argue that evolution describes the state of the current gene pool, however I'm not sure that is a particularly common measure.

</comment><comment><USER8> As someone who's worked on both the academic side and in the various support services of a couple universities the highlight of this article was imagining how the process of getting a large leaf blower went down.</comment>


Rust for Rubyists - <AUTHOR> https://matthias-endler.de/2017/rust-for-rubyists/ <comment><USER2> The filter_map explanation is wrong. .ok() converts a result to an Option, not a boolean. Likewise, filter_map expects an option. That's how it can both filter and map.

Docs: [https://doc.rust- lang.org/std/result/enum.Result.html#method...](https://doc.rust- lang.org/std/result/enum.Result.html#method.ok)

<comment><AUTHOR> Thanks for the hint. Will fix that and give you some credits.

<comment><AUTHOR> Edit fixed.

</comment></comment></comment><comment><USER3> The example for even numbers should be:

even_numbers = [1, 2, 3, 4, 5].find_all { |element| element.even? }

or

even_numbers = [1, 2, 3, 4, 5].find_all(&:even?)

instead of:

even_numbers = [1, 2, 3, 4, 5].map { |element| element if element.even? }

<comment><USER4> If I'm writing ruby I'd prefer Array#select for this task.

<comment><USER5> That's an alias for `find_all`.

<comment><USER6> That's one beautiful thing about Ruby. There's not just one way to do it, which means that .select and .find_all may be aliases but both are valid and will show up, depending on the author's preference.

<comment><USER7> Honestly, that sounds like a nightmare to me!

<comment><USER8> I love Ruby, but I agree. It creates unnecessary ambiguity.

Reads nicer sometimes, sure.

</comment></comment></comment></comment></comment></comment><comment><USER9> Good post, although it served to remind me again how much I love Ruby for it's emphasis on being elegant and expressive. I may not reach for it first for anymore for standing up a new service, but I still use it for personal projects and scripts unless there's a compelling reason not to.

</comment><comment><USER10> It's nice to see languages converging on a standard set of features. String interpolation, random number generation, package management, etc.

<comment><USER11> Or apparently the even more common functional list operations: "map", "for_each", "filter", "every", etc.

<comment><USER12> Well, unless your language is "go" in which case it converges on no good package management and no functional filter/map/reduce functions

<comment><USER13> Literally the worst thing about that language. Such a common operation, and every time it comes up I end up iterating over ranges like a caveman.

</comment></comment></comment></comment><comment><USER14> Great post. If you are plan to write a native Ruby extension, check out Rust Helix [https://usehelix.com/](https://usehelix.com/)

</comment><comment><USER15> Nice article, I bookmarked it. I am just now learning Rust because I want to use an open source blockchain library/framework written in Rust. Ruby used to be my favorite language until a career in machine learning literally forced me to swap scripting languages. I also really like Haskell (plug: I wrote a Haskell book) and I find that Rust borrowed many good ideas from Haskell.

</comment><comment><USER16> The section titled "Implicit returns and expressions" purports to contrast the two when as far as I can tell they work identically.

In fact, the article specifically calls out that in Rust, even if expressions have a value, which is also true in Ruby, every expression has a value (though it is sometimes nil).

</comment><comment><USER17> Or every language complicated enough is reinventing lisp partially.

<comment><USER18> For the uninitiated:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

<comment><USER19> I think GP is referring to a slew of current trending languages which are partly functional and have lisp-style macros.

</comment></comment></comment><comment><USER20> Enjoyed this, thanks for writing!

</comment><comment><USER21> > With iter(), you get a "read-only view" into the vector. After the > iteration, it will be unchanged.

> With into_iter(), you take ownership over the vector. After the iteration, > the vector will be gone. In Rust terminology, it will have moved.

I stopped reading right there. No Rubist or actually nobody, except real time system developers, should care about ownership.

It makes programming so much more complicated without any real benefit, again apart from real time systems.

<comment><USER22> Rust is faster, more energy efficient and more RAM efficient than ruby. If that is not a real benefit to you personally then you should clarify that because there are far more exceptions than just real time systems.

Don't say Rust is useless. Do say you don't need Rust.

<comment><USER21> Don't be so defensive, it is just a programming language.

> Don't say Rust is useless

Read it again. What I said was that the complexity added by the concept of ownership is not a worth the benefit of not having a garbage collector, except in a few cases.

I am not necessarily comparing it with Ruby. I am comparing it with languages equally fast, Go, OCaml, Haskell, that are garbage collected.

Instead of telling me what to say and not, why do you try to convince me that my argument is wrong. That's what this forum is about, no?

</comment></comment></comment><comment><USER23> Minor correction:

In the section about converting a vector of strings into integers the article says that the Result returned from parse() is converted to a bool via Result::ok(). However, Result::ok() actually converts the Result<T, E> into a Option<T> which is what filter_map() expects.

<comment><USER24> They should have just used `flat_map`, which does everything that `filter_map` does and more. In this case the call to `Result::ok` could have been omitted in favour of the identity function (which strangely isn't in the standard library). I wonder why rust even has `filter_map`.</comment></comment>


Ask HN: coding challenges as part of interviews: yes or no? - <AUTHOR>

just curious what the group thinks of coding quizzes / challenges that are often part of job interviews for programmers.  how predictive are they of a coder's future performance?  are they appropriate only for entry level positions (when someone has less industry experience), or are they suitable for any level?  are they more likely to pique your interest or to come across as cliche? <comment><USER3> My experience:

Successfully pasing a code challenge is not a good predictor of future success. However, failing to pass a code challenge is a very good predictor of future failure. Furthermore, making the test harder does not make it predict future success well.

Therefore, I belong to the "FizzBuzz" school: Make the test ridiculously simple. It should take no more than fifteen minutes to complete. If the person gets it obviously right, throw the result away and move on to more important quetsions. Do not try to deduce a lot of malarky about their programming style or ability from an obviously contrived problem.

For example, writing:

a = 5; b = 10

Does not mean they don't know Ruby well, and writing:

a, b = 5, 10

Does not mean they are a Ruby expert. And writing:

fsquare = lambda { |x| x * x }

Does not mean they are a closet Bipolar Lisp Programmer. If the program works, it's a pass, move on. If there is a syntax error or some such, who cares, move on.

But if they struggle... You need to investigate the reason for their difficulty with a simple problem.

</comment><comment><USER4> Trick questions, or questions with some kind of gottcha have no place in interviews, However, simple, straightforward programming exercises are essential. I've seen people who claim to have X years of industry experience who can talk a good game, but literally can't write a switch statement without reference to the internet.

I also like to ask people to peer review some code with both obvious and more subtle errors in it. That's a pretty important skill to me too. Anyway, ask them to code some fairly simple algorithm and then critique their own work. If there are several ways to solve the same problem, some more efficient than others, all the better.

<comment><USER5> Hmm... I know > 10 languages. I'm not sure I _could_ remember the exact syntax in several of those languages on the spot. Is it case, is it switch, etc. If you do this, your test is on rote memorization.

Give them a novel problem and have them solve it with a real computer and in tact syntax lookup. Then see what and how they did it and go over their reasoning. I'll hire the guy with the wisdom over the guy who can spit out syntax trivia flawlessly. Those are different skill-sets that do not predict each other.

<comment><USER6> Agreed. My first job they gave me a copy of Deitel & Deitel's "C How to program" along with the test. You actually lost points if you didn't open it!

<comment><USER7> You know the syntax of switch in the language you have been using in the last three months. If you don't, something's wrong!

<comment><USER3> I never use Ruby's case or switch or whatever-it's-called.

I could make up some mumbo-jumbo about case being a code smell and that it should actually be refactored to a method dispatch over polymorphic objects, but the truth is that I have no idea why I don't write case statements, I just don't.

<comment><USER8> Add me to the "never uses switch statements" list. I've never seen the point in learning the syntax in any of the languages I know, since a bunch of else ifs (or elseifs, or elsifs, or elifs, depending on the language) does the same thing. If I waste a few keystrokes, but save a few brain cells, I think it's a worthwhile bargain.

Of course if I had to write that kind of construction often I'd probably learn the syntax of the case statement, but in the kind of work I do it hardly ever actually comes up.

<comment><USER9> It's really just a performance optimization for C, in situations where the switching value can be hashed. In languages that make method dispatch easy, and the overhead of a function call is not something you're terribly concerned about, it makes sense to just roll your own as needed -- that's why Python never bothered with a switch statement.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> A trivial coding problem is essential. I've seen people with 10 years of experience in XML#Java.NETEnterprise2012 who don't understand conditionals, loops, or boolean expressions.

For phone screens, I find Steve Yegge's guide a useful starting point: [http://steve.yegge.googlepages.com/five-essential-phone- scre...](http://steve.yegge.googlepages.com/five-essential-phone-screen- questions)

I'm not a fan of asking candidates to reverse a string or to implement atoi or a binary search, because those have corner cases which, under interview pressure, might be too much to ask for. I just ask for an implementation of a gcd (greatest common divisor) function, in any language. I always explain the problem in detail. Only one guy (a PhD in physics) ever gave me Euclid's algorithm (section 1.1 in Knuth's AOCP Volume 1), so I don't expect it. I do expect a trivial loop, and most candidates take 15-20 minutes to come up with it, and need lots of hints.

As far as I'm concerned, anyone who can't come up with a trivial loop (or recursive or tail recursive function) for something like this shouldn't be programming for a living. Maybe "developing enterprise solutions," but never programming.

<comment><USER3> "As far as I'm concerned, anyone who can't come up with a trivial loop (or recursive or tail recursive function) for something like this shouldn't be programming for a living. Maybe "developing enterprise solutions," but never programming."

Priceless, If you ever put this on a cafepress mug or tee shirt, you can count on selling me a dozen or so as office gifts. Thanks for the laugh.

</comment></comment><comment><USER11> This reminds me of a group of main frame programmers I knew who had been forced to become Perl web developers. About a month later they were asked to hire another Perl programmer and one of their interview questions was what's the difference between 'chomp' and 'chop' (chomp removes the final character of a string if it's a newline, chop does it regardless).

They were shocked that the interviewee didn't know the answer because they considered it basic knowledge, "it's in the first chapter for gosh sake." The first chapter in this case covered differences between Perl 4 and Perl 5.

In Perl 5, nobody uses 'chop', they all use 'chomp.' Many experienced Perl programmers might even have forgotten that 'chop' existed.

And that's my major problem with gotcha questions, they tend to be pretty far from measuring if a person can actually write productive code.

</comment><comment><USER6> Programming challenges sort the wheat from the chaff - in particular those who cannot code at all, but beyond that I've rarely found them predictive of future performance. Much more important that you hire a good fit for your company. An unhappy or toxic coder can bring a startup to its knees - <USER2> slow, fire fast and all that.

<comment><USER12> This is true. I aced the coding portion, but after 6 months, I was definitely not a good fit in the culture of the last company I worked for.

</comment></comment><comment><USER13> I like them as long as pseudo-code is acceptable. I don't really care how good someone's memory is with regards to language syntax; I care about whether or not they can solve problems and think them through.

</comment><comment><USER14> /agree with most of the people here. Coding questions have a purpose.

You need to consider what you are trying to determine by asking any question. Really, what is it about the candidate you want to know? After pinning down precisely what you want to know then tailor a question to figure this out with as little peripheral stuff as possible.

If you want to know if someone can generate some code in their preferred language on the spot, fine. Pick a very simple problem, like 'Write a program to display numbers in the fibinocci sequence', and explain the fib seq to them if they don't know it. I wouldn't even count points off if they make any kind of mistake that a compiler would catch as long as they know how to fix it. Have them do it on the white board.

This kind of Q isn't designed to figure out how much they know of 10 different languages. It's designed to see if they can put some code down in their preferred language and have it do something useful.

The biggest constraint in an interview isn't the honesty of the candidate, or even their knowledge; it's the N hour time limit. Your goal as the interviewer is to squeeze as much information about who the candidate really is in the time allowed.

</comment><comment><USER15> I like to believe that I can get a pretty good understanding of someone's technical abilities by asking thorough questions about his previous experience, and maybe ask them to explain a couple of basic patterns or programming concepts to me. I remember interviewing a senior java developer who claimed 5+ years of experience and had no idea what a Singleton was. What made it worse was that even after explaining it to her, she was unable to figure out how to implement one. Developers asked the strangest questions when interviewing other developers. I worked with a guy once who liked to ask his interviewees what the decimal value of 0xFE is. One candidate didn't know the answer so my coworker didn't think he could possibly be a good software engineer. I admit that (having done assembly coding in school) it seems odd that any software engineer wouldn't be able to figure out what FE is. But I still thought it was a bad way of testing technical skills. Would you rule out a candidate who doesn't know 0xFE ?

<comment><USER16> > Would you rule out a candidate who doesn't know 0xFE ?

If they didn't know it after a moment's thought, I'd cut them some slack; If they couldn't calculate it, with pencil and paper, in 10 minutes (and that's giving them plenty of extra time for interview-nervousness), then I'd be seriously concerned.

<comment><USER17> i read through some answers here and i nodded in agreement with raganwald saying that this only worked as a filter on failure.

but then i read this and i thought "would i really want to give a job to someone who needs a pen and paper to subtract 1 from 255?"

i'm not sure what the lesson is here - perhaps that programming tests are dangerous because it is very easy to over-interpret the results, even when you start with the best of intentions?

[edited for grammar]

<comment><USER16> No, I would be very liberal in accounting for interview-nervousness.

Now, if it appeared that the candidate had no idea _how_ to solve the problem, that would be a different story.

</comment></comment></comment></comment><comment><USER18> I think taking some time to sit down and _read_ some code is one of the best and least used techniques during an interview. I think it's more of an indicator for job performance than writing some green-field code. After all, on the job, more time is spent reading and understanding code than writing code with no preexisting context.

<comment><USER19> You may use the solution your last candidate came up with as an example.

</comment></comment><comment><USER20> I think it depends on the position and responsibilities the person will have once hired. If the programmer will be coding directly from specs without any room for "interpretation" then a coding challenge may be very applicable. If you are looking for a programmer that also understands your business and will be required to make decisions and think on their feet, the value of a coding challenge diminishes.

It also depends on the time frame of the position. If you are looking to hire a programmer on a per project basis, then a solid understanding of the development language is critical. However, if you are hiring an developer for the long term, it's better to hire a smart and agile person that can contribute to the overall business as well -- which is hard to measure from a coding challenge.

</comment><comment><USER15> I also worked for a company once who had several enthousiastic , seemingly bright people with somewhat limited experience come in for interviews, but they didn't make the cut because they didn't pass some coding challenges. The guy who did get hired went to a good school and was a good coder, but was way too arrogant, difficult to work with and repeatedly refused to do what his manager asked him to work on. And how did that guy interview other candidates? He screened them by their education, and when they would come in he would give them one programming challenge without asking any other questions. Nobody seemed to realize that there were big problems with the company's hiring strategies and that developers themselves were largely to blame for that.

</comment><comment><USER21> I've always found that asking a reasonable numerical solving question where you can easily figure out the answer in your head is a good starting point to gauge programming/algorithm ability. If someone knows the solution they are trying to get at, they can focus on the program itself, as opposed to worrying about solving the problem and coming up with the algorithm. Ideally there are a few ways to solve the problem, brute-force methods or more efficient ways. It can be very difficult to test a programmer's ability in an interview, you need to focus more on seeing how the candidate thinks, how they approach problems, and whether they can admit when they do not know something.

</comment><comment><USER22> I use a simple coding challenge as a weeder question. It requires basic use of recursion (without explicitly saying so) -- no math, no big-O, no gotchas, just writing a simple recursive function to process a small tree. It takes decent coders a few minutes to complete. Less-than-decent coders really struggle with it.

This is only a wheat/chaff separator, though. If possible, I like to see code from actual projects they've worked on to get a feel for the bigger picture (tip: open source your personal projects and obsess a bit over the code, so you have something to show off). Plus there's all the other non-code aspects to the interview.

</comment><comment><USER23> If you have the sense from whiteboard discussions that the candidate understands computer science (like gets recursion) but you want to make sure they can code, why not choose a subset of a problem that you (your company) needs to solve?

<comment><USER24> Good way to get some free consulting ;-)

<comment><USER25> I don't think he means _open_ questions, but things related to the problem.

I interviewed once with a company that OCRed medical documents. One guy held up a sheet of paper and asked "How much memory does this take up?" which was a deliberately open-ended question. I was initially stumped, but then he started feeding me domain knowledge and assumptions, such as common DPI values and expected fidelity. Then I started coming up with estimates.

I don't think he expected me to have answer right off. I think he wanted to see how much I could figure out on my own if given hints.

</comment></comment></comment><comment><USER26> They're a necessity. For the simple reason that too many people lie on their CV, no matter how good their CV looks you have no-idea how much of it is accurate.

Obviously there are cases where you wouldn't use it, but generally they only apply when you know someone's capable of coding anyway (i.e. due to an indisputable reputation, experience working with them, etc.).

However as a predictive measure it's fairly limited in that it's a binary indicator. If someone fails then there's a fair chance they're a terrible developer, if someone passes there's a fair chance they're not a terrible developer.

</comment><comment><USER27> Necessary but not sufficient.

I always give a fairly simple problem, pencil and paper, a soda, and leave them alone for 15 to 30 minutes. Before I leave the room, I make sure they clearly understand what's expected.

What they do isn't important. _Our discussion_ about what they did is. I don't care what syntax or mannerisms they use; I _do_ care if they understand what was needed and what they did well enough to explain what they did and why they did it.

Almost every time some good follow-up questions and segues ensue. What about this? What about that? I've learned more about people in the discussion after the problem than from anything else.

</comment><comment><USER28> If I were interviewing someone, I would be more likely to test someone's general problem solving skills, questions that illustrate how a candidate thinks and approaches a challenge. This of course becomes more subjective, but can really help identify creative talent. Who knows, you might even learn something too. This is probably a big part of the puzzle type questions that companies like Microsoft and Google seem to favor.

</comment><comment><USER29> Agree with jamess, but additionally, I think interviewers that _don't_ ask coding questions might be an indication of something negative at the company. Basic coding ability has to be one of those checkbox questions that determines your eligibility for the position, and if the interviewer doesn't ask anything technocal, it makes me wonder what kind of dumbasses I might end up working with.

<comment><USER30> Indeed, whether candidates write code during their interview is one of the items on the Joel Test (<http://www.joelonsoftware.com/articles/fog0000000043.html>).

</comment></comment><comment><USER31> Writing code is artwork. You can ask the artist about the specifics of his tools, but you will never grasp his artistic ability until you see the completed artwork. I just ask some general questions about the tools. The tools for code writing are: starting, constants, variables, addressing, comparing, branching and ending.

</comment><comment><USER19> From the employees point of view: I would have no problem to do a coding test as part of an interview.</comment>


Twitter OAuth Outage Was A Vulnerability In OAuth Itself - <AUTHOR> http://groups.google.com/group/twitter-api-announce/browse_thread/thread/d2ee68712e015041

<comment><USER2> These community-designed security protocols make me really tired. Just leave it to the experts.

</comment><comment><USER3> The advisory is up at <http://oauth.net/advisories/2009-1> and the blogs are abuzz with more (or, in enough cases, less) information. Basically, the problem is that an attacker can keep a request token around and have the victim complete the authentication with the old request token, thus gaining authorization in the victim's name. There is no way for the consumer to tell what's going on, currently.

The suggested workarounds are monitoring and a strong statement about starting Auth workflows from untrusted places. But we all know how well those work. I'm curious about OAuth 1.1 or whatever.

</comment><comment><USER4> Didn't _any_ qualified security researchers do a security assessment of OAuth when it was in development? This spec was finalized in 2007 which means we've had at least two years to find this _obvious_ problem.

We've known from the start that OAuth and OpenID are vulnerable to various social engineering attacks, and I guess the communities using each have accepted that as the lesser of two evils. But, you know, somebody has to check that the protocol actually works at least a little.

</comment><comment><USER5> Any blackhats have any clues as to what this is about? I'm too impatient to wait 7.5 hours :P

<comment><AUTHOR> The CNet article claims the vulnerability involves "social engineering" attacks that will coerce users into giving up personal information. "Social engineering" in web apps is usually code for "landmine links", and the OAuth protocol itself doesn't communicate any user information of any sort (just an opaque token).</comment></comment>


Show HN: Pruun – Python CL utility for creating AWS Lambda deployment packages - <AUTHOR> https://github.com/alexkosj/pruun <comment><USER2> Hi there. Nice work. I've been tinkering with wrapping a bash script around the serverless and aws CLI tools. Out of curiosity, does this do anything that serverless doesn't?

I fully appreciate that "intellectual curiosity" is a fully valid reason for creating something like this :)

<comment><AUTHOR> Hey thanks man. While I haven't used serverless myself, I'm pretty sure it can do what pruun does and way more. In terms of usage and functionality, I had a very specific breadth in mind for pruun, i.e creating deployment packages. No AWS auth needed, no config — I wanted pruun to require as little buy- in/learning-curve as possible, while still addressing what I've always found to be a pain-point. Also, I felt like coding some shit that wasn't work stuff :P</comment></comment>


3D Printed Surgical Mask - <AUTHOR> Want to help?  Stop talking about ventilators and leave that to professionals.  Instead, put your 3D printers to work and make a bunch of these.  It is designed by doctors, which, I am going to assume, means they approve of their use.
https://www.billingsclinic.com/foundation/3d-printed-surgical-mask/
In fact, if you own injection molding equipment, adapt this design and start to pump them out by the thousands. <comment><USER2> It's not going to get a good seal. Not on anyone.

CPAP masks are a good example of what you can do to get a decent seal with a hard plastic, but they take a lot of trial and error to get right, and there are hundreds of different models on the market.

You have to address the sealing issue first. If you don't, then nothing else really matters — unless you're just making vibrantly colored cloth masks to help encourage you to stop touching your face and to scare others into staying far away from you.

<comment><AUTHOR> In the video I saw they seem to have added a gasket material to the edge.

Yes, you are right, getting a good seal with a hard plastic is difficult (unless you impale it into your skin). I wonder how carefully they adjust their N95's to have a good seal? If you don't, particularly at the nose bridge, you can have some pretty big gaps.

<comment><USER3> For anyone interested, here's a video of a junior doctor in England testing his FFP3 mask fitting. [https://youtu.be/7XZ2_xSHKMw?t=555](https://youtu.be/7XZ2_xSHKMw?t=555)</comment></comment></comment>


Tim Cook to donate his entire fortune to charity - <AUTHOR> http://money.cnn.com/2015/03/27/technology/tim-cook-wealth-charity-fortune/index.html

<comment><AUTHOR> Tim Cook is the kind of CEO we need more of. I recently read an article where he said he didn't come out as gay because he felt he needed to, but because he felt it would encourage others to feel comfortable doing so if they wanted to. He just seems like a good guy.</comment>


Clive James Got It Right - <AUTHOR> https://www.newyorker.com/culture/postscript/clive-james-got-it-right <comment><USER2> One of my favourite Clive James things was the translation of Dante's Inferno he did. Instead of the usual 'Abandon all hope, ye who enter here' he came up with 'Abandon your hopes, they are what got you here'. Subtle genius.

<comment><USER3> Damn. Haven't heard that one before but it's quite poignant.

</comment></comment><comment><USER4> If you like to read, read Clive James. He is perfectly at home discussing anything from Buffy the Vampire Slayer to George Orwell, and his essays are just beautifully done.

Sadness that he died, but he knew it was coming, was grateful the sentence had been deferred for 10 years, and died at home surrounded by "his family and his books". A good end to a brilliant life.

I think this is his final interview:

[https://www.newstatesman.com/culture/qa/2019/11/clive- james-...](https://www.newstatesman.com/culture/qa/2019/11/clive-james-my- earliest-memory-roar-rain-my-back-yard)

<comment><USER5> _Chronicles from a Death Foretold_

Fortunately also a Death Postponed.

<comment><USER5> P.S. He hated magical realism - sorry Clive!

 _The most overrated books almost all emerged simultaneously from a single genre: magic realism.

I can't stand it._

[https://www.theguardian.com/books/2019/oct/05/clive-james- bo...](https://www.theguardian.com/books/2019/oct/05/clive-james-books- overrated-all-magic-realism)

</comment></comment></comment><comment><USER6> I've always been a Clive James fan - his silly TV show "Saturday Night Clive" was appointment viewing in my household when I was a teenager. And his fantastic end of year New Years specials were great as well.

Later I read some of his written works. His book companion to his TV documentary series "Fame in the 20th Century" was by turns wry and thoughtful.

I am not normally a poetry kind of guy, but this is hilarious: [https://web.cs.dal.ca/~johnston/poetry/bookofmyenemy.html](https://web.cs.dal.ca/~johnston/poetry/bookofmyenemy.html)

</comment><comment><USER7> In 1991 Clive James did a Television New Year review.

Part of that was the cultural phenomenon of Terminator 2.

They show the scene where Sarah Connor escapes her asylum cell only to round the corner and run bodily into Arnie. Sarah panics and primal screams.. Arnie gets out the shotgun and blasts the T1000...

then the camera cuts back to Clive James who said:

"... and that was just The Love Scene"

</comment><comment><USER8> His Mission: Impossible description reads like an entry from a certain site that deals in commentary on Hackernews posts:

> A disembodied voice briefs the taciturn chief of the Impossibles about the > existence—usually in the Eastern European People's Republic—of a missile > formula or nerve-gas guidance system stashed away in an armoured vault with > a left-handed chromosympathetic ratchet-valve time lock. The safe is in > Secret Police HQ, under the swarthily personal protection of the EEPR's > Security Chief, Vargas. The top Impossible briefs his black, taciturn > systems expert and issues him with a left-hand chromosympathetic ratchet- > valve time-lock opener. . . . A tall, handsome Impossible, who is even more > taciturn than his team-mates, . . . drives the team to the EEPR, which is > apparently located somewhere in Los Angeles, since it takes no time at all > to get there by road and everyone speaks English when you arrive.

Brilliant.

</comment><comment><USER9> As someone trying to revive my artistic sensibility and get back to making music, this hit home hard:

 _> Writers who are not romantic about the wrong things will never be romantic about the right ones, either._

It's virtually impossible to make art while listening to the nagging voice telling my I might look foolish doing so.

<comment><USER10> Yeah, gotta find a way to ignore that voice. As a starting point, consider making art nobody else can see/hear/experience. Also, the book "Creative Confidence" is a great read.

<comment><USER11> _Steal Like An Artist: 10 Things Nobody Told You About Being Creative_ is a great book on similar themes. (The sequel _Show Your Work!_ is also good) Also _Creating a Life Worth Living_ had a huge impact on me - it's full of interviews with creative types of all kinds, and talks about how many different ways/styles of structuring your time and life there are, and how to find one that works for you.

When I was a jazz musician in my early 20s, I did a lot of negative self-talk on gigs. "Oh, that was awful! Oh yuk, Argghh that sux. Nooo...Terrible" etc. It made me sound terrible. Self-torture. Then I read a book _Effortless Mastery_ , from which I learnt _Never criticize yourself on gigs. The time for that is when you practise._ And since then I never do that. I just enjoy myself and play. It really changed my life. And also learning about _loving yourself_ \- realizing that it's all too easy to be careful about treating other people well, always being kind, while being extremely mean to yourself. Louise Hay's _How to Love Yourself_ is _the_ book on that subject, I think.

<comment><USER9> Thank you, all of those are right up my alley. I added them all to my to-read list. (Of course, the hard part is setting aside the time to actually read them...)

</comment></comment></comment></comment><comment><USER12> I knew him first as a lyric writer. The article mentions Beware of the Beautiful Stranger, which really is wonderful, but some of his other lyrics are pure genius, too.

I highly recommend the albums Beware of the Beautiful Stranger and Live Libel if you're in to slightly folky music with insanely clever words.

</comment><comment><USER13> Can thoroughly recommend his 'Cultural Amnesia' with its highly eclectic collection of thoughts on almost 100 people as disparate as Louis Armstrong, Terry Gilliam, Hitler, Mao, Kafka, Fellini, Beatrix Potter, Sartre, Tacitus, Thatcher, Wittgenstein and Stefan Zweig.

</comment><comment><USER14> I picked up his Poetry Notebook back in 2015 but never managed to find the time for it. As I've begun exploring poetry once more anyway, it is long past time to finally read the book. Rest in peace and thank you for giving so much of yourself to the world.

</comment><comment><USER15> Now that he's been remaindered, I wonder who his enemy was.</comment>


Dipping your fingers in molten lead [pdf] - <AUTHOR> http://www.falstad.com/cgi-bin/go.pl?http://www.wiley.com/college/phy/halliday320005/pdf/leidenfrost_essay.pdf

<comment> Tuna-Fish The best part of the article is the description of how after he had successfully dipped his entire wet hand into the lead without being burnt, he had to prove that it was really film boiling that protected his hand. By touching the molten lead with a dry finger. Knowing full well he was going to be badly burnt.

A true scientist.

<comment><USER2> I just thought it meant he was insane. I don't understand why he used his hands first on the experiment, with or without water. He could have used anything else-- something not attached to _him_.

<comment><USER3> For some, once an idea germinates, it burgeons until it is performed.

At some level, this becomes a battle between the mind and the idea, like some kind of stare down.

The scientist couldn't resist the urge of sticking his finger in there.

<comment><USER4> Neither can the serial killer.

<comment><USER3> That brings in an entirely different human faculty (morality?). And in terms of serial killers, abnormally functioning. The focus of my comment was on people who are fairly normal in this regard. The comparison is silly without mentioning this.

</comment></comment></comment></comment></comment><comment><USER5> Very interesting read. The final part is a bit of a stretch:

 _I have long argued that degree-granting programs should employ "fire- walking" as a last exam. The chair-person of the program should wait on the far side of a bed of red-hot coals while a degree candidate is forced to walk over the coals. If the candidate's belief in physics is strong enough that the feet are left undamaged, the chairperson hands the candidate a graduation certificate. The test would be more revealing than traditional final exams._

I think it should actually reveal the candidate's belief in his/her _knowledge_ of physics, rather than his/her belief in physics.

<comment><USER2> I thought it was fairly obviously not meant to be taken seriously.

<comment><USER5> As an instructor myself, I must admit I did take this just a little seriously.

</comment></comment></comment><comment><USER6> My college physics professor did a similar experiment, but walking on burning coals:

[http://blogs.discovermagazine.com/cosmicvariance/2006/04/28/...](http://blogs.discovermagazine.com/cosmicvariance/2006/04/28/gene- firewalker/)

It certainly was fun to watch, but I didn't really remember what it was trying to teach...

<comment><USER7> In Bulgaria, and in other countries on the Balkans, there is an old tradition of walking on fire. It's called Nestinarstvo:

<http://en.wikipedia.org/wiki/Anastenaria>

</comment></comment><comment><USER8> Mythbusters actually tested this out, using their own fingers no less. Was definitely a cool thing to see.

</comment><comment><USER9> Video of similar experiment:

<http://www.youtube.com/watch?v=sN5aMjTCfo4>

</comment><comment><USER7> Loved it :) It's like Harry Potter in real live!</comment>