We have C++14 - <AUTHOR> http://isocpp.org/blog/2014/08/we-have-cpp14 <comment><USER2> When I started writing C++ around 5 years ago, I had a perception that it was a language that is "on its way out". As I learned more and more of it, I've been super impressed at how modern it is becoming, and how it is adapting to overcome its perceived flaws. It is becoming a killer language to me: blazing fast, modern, ubiquitous, stable, and expressive.

<comment><USER3> Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials.

Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects.

Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is _something_ (but not quite like) the STL which is way different from Apache C++ libs which is way different from what Google's C++ libraries are...

This is what happens when a language is "un-opinionated", throws everything including the kitchen sink at the language, tries to compile C and legacy C++ while introducing new features oh and also can't break existing code.

It's on its way out, no doubt about it. And we'll be better off as an industry for it, I'm sure of it.

Rust, Go, and others will be there to fill in the gap in a much better, saner, safer, maintainable way.

<comment><USER4> _Too bad it 's a mirage_

I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.

<comment><USER5> I don't see how that refutes the parent's comment. The areas you listed are very small niches. Frankly, very few people care about scientific computing or even animation rendering. Generally speaking, using C++ is like wearing jeans and white sneakers: popular in the 90s, but definitely out of fashion now.

<comment><USER6> Why do you need to be fashionable to be productive? Do people really ask what your finished software product is written in?

</comment></comment></comment></comment></comment><comment><USER7> OT question: I was playing with some C over the weekend (not C++), trying to figure out how to handle Unicode in a way that would work on Mac, Linux, and Windows. Despite a couple hours googling and reading, I couldn't answer really basic stuff, like:

\- Do I use char* for strings? It sounds like wchar_t is 16 bits on some systems and 32 on others, so I should avoid it?

\- If I want to read & write UTF-8 files, how do I turn the bytes into 32-bit wide Unicode strings?

\- Are there special functions I should use for handling Unicode strings?

More generally, where do you go to discover C libraries you can use?

I am (was) reasonably proficient in C, but I haven't used it much for over ten years. I'm surprised how many things I just don't know how to do!

Sorry this is not a C++ question. I'd like to get back into that also, but I'm trying to work my way up from the basics. :-)

<comment><USER8> Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want.

In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

<comment><USER9> Weeellll, your position is defensible if you're writing an application. If you're writing a library though, let me just let you know that every time I encounter a package with a C++ API, I want to drive stakes into the author's eyes, as compensation for the pain _I 'm_ about to experience.

Like it or not, C is the lingua franca of the programming world. Pretty much every other language out there provides C bindings, not C++ bindings. Which means that when your function exports something wonderful like smart pointers, _my_ world just becomes painful.

Furthermore, in embedded environments, it can be challenging (to use a euphemism) to get source code debugging up and running. If your code is written in C, it's not so bad, non-optimised machine code generated from C tends to match the actual C code fairly closely, to the point that you can very nearly read it as easily as the original source. This is not true for C++, which means that every time something goes wrong in C++ code, I'm probably going to lose a week of my life inserting trace into the code, compiling, deploying to target, and running the test, ad infinitum. Not fun.

Even in the case where you're writing an application, I'm personally dubious about the benefits of C++. Write the application in a higher-level language, personally I like Javascript (JavaScriptCore) for this, but I've had good success with Ruby and lua as well. When you hit a performance bottleneck, push the performance sensitive code into C, and create bindings. As a bonus, your C code is now easily available to be used as a library from any other language, without inducing homicidal tendencies in the user.

<comment><USER8> extern "C" {

}

Hey look, C API.

> This is not true for C++,

Depends on the code you write. If you write C in C++, you get the same near machine parity, since its the same source material. If you do not use namespaces you don't even get name mangling.

</comment></comment></comment></comment><comment><USER10> You can grab and compile the very latest _draft_ from the committees Github page:

[https://github.com/cplusplus/draft](https://github.com/cplusplus/draft)

The current version is a slender 1365 pages, including the standard library.

</comment><comment><USER11> I see a lot of discussion around C++ becoming modern. I would like to know which features are actually modern?

Is it lambdas? been around for literally decades. Is it type deduction? again been around for quite some time, far better type inference has been available in the likes of Haskell for quite some time. Is it addition of a particular threading model to the standard? this has always been available via some form of library, it just know means the language is truly obsolete if the model changes. Allow GC'd implementations? again decades.

What is modern about any of features that have been added?

<comment><USER12> > What is modern about any of features that have been added?

Nothing. On the other hand, which features of a "modern" language are missing in C++ by now? Type deduction is still a bit less powerful than in Haskell, yes, but apart from that I can't really think of anything that may or may not be missing.

This in turn implies that C++ allows essentially any style of coding you may wish for at the moment while at the same time staying some orders of magnitude faster than essentially the entire competition.

<comment><USER11> C++ is no faster than any other language, it's the code that is written which is measurable.

The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the language does not make it fast.

Any micro optimization you can make with C++ will be an order magnitude less significant than O(log n) vs O(n).

The likes of Janestreet will likely need high performance software yet have great success with Ocaml for example, which incidentally can be very fast.

Just saying C++ is fast does not make programs written in C++ actually fast.

<comment><USER12> > The real wins in performance for real world applications are in terms of > algorithmic complexity. A poorly implemented solution in C++ will still be > slow, the language does not make it fast.

Yet a well written implementation in C++ will still be faster than an equally well-written implementation in, say, Python or Haskell or whatever. Not in an asymptotic sense, but easily by a factor ranging between two and 200. For me, this can be the difference between waiting a couple of weeks or half a year for some computation to complete :)

> Just saying C++ is fast does not make programs written in C++ actually fast.

Of course not, but C++ makes it possible for programs written in C++ to be fast.

<comment><USER13> Comparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are _some_ performance advantages in C++ but they are rarely big enough to justify language choice).

<comment><USER14> An order of magnitude is a hell of a lot. I did some extensive comparisons of C++, Java, and C# back when I was working on my dissertation. Admittedly, this was about 10 years ago now, but at the time, the best I could get with Java was about a factor of 2.5 slower than C++. C# was similar, but I don't recall the specifics now.

When you read a language shootout, a lot of times a factor of 2-2.5 times slower than C or C++ is considered to be "good enough". If you get your Clojure code that fast, everyone calls it a day. For me, a typical run of my experiments took about 3 weeks on (I think) a Core 2 Quad using all four cores. So in the best optimized Java I could find, that would have been about _5 extra weeks_ spent waiting around for results, and I had several cycles like that. All told, I imagine it would have added a year to my work.

I'm not necessarily picking on you here. You did say "rarely", not "never". But I don't think a lot of people are aware of how common it is for a factor of two to be a complete deal-breaker.

<comment><USER13> A factor of two difference is something that can be a result of using different C++ compilers or even different versions of the _same_ compiler.

See this: [http://lemire.me/blog/archives/2012/07/23/is-cc-worth- it/](http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/) Particularly the comments section contains various results obtained from different compilers / versions. Variablility is higher than 2x for GCC.

Comparing with Clojure is not fair, because it is not really statically typed, and known to be much harder to optimize for speed than e.g. pure old Java.

<comment><USER14> I tossed out Clojure as a random language -- all my testing was done with the most efficient Java and C# I could write.

The link is fine, but only shows micro-benchmarks. It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example -- you're maybe exercising 5% of the optimizer?

The current version of the C++ I was using comes in at around 50kloc. The Java and C# versions were a bit smaller, since once I stopped testing the platforms, all the new code only went into the C++ version, but it's a significant piece of work. I haven't seen any significant real application for which the theoretical benefits of Java (JIT's profile-guided optimizations, etc.) have really come to pass. You can write slow C++ code, but if you know what you're doing and instrument carefully, there's very little or no evidence that Java can be as fast on real programs.

<comment><USER13> > It's much easier to get a 3x difference in execution speed between compiler > versions when you have a three-line example

Those three lines can be as well a bottleneck in a big program, responsible for 80% of its runtime. This example was to show that compiler-induced performance differences in a single language can be just as large (here: up to 4x) as differences between Java and C++ in microbenchmarks. Therefore 2x difference in a microbenchmark where Java is losing to C++ is probably not a statistically significant difference, even though it may be important to the end user. If you rerun this benchmark in 3 years from now, using newer versions, you might as well get completely different results.

As for real applications - that you don't know of any real, fast Java program, doesn't mean there exist no evidence. Sure, it is quite hard to find a pair of two programs doing exactly the same written in two different languages, but there do exist quite a few high-performance Java apps out there which are #1 in their class: Netty, Apache Cassandra, Apache Spark, LMAX disruptor (Java used for ultra low-latency app, see: [http://programmers.stackexchange.com/questions/222193/why- di...](http://programmers.stackexchange.com/questions/222193/why-did-the-team- at-lmax-use-java-and-design-the-architecture-to-avoid-gc-at-all)). Someone also ported Quake2 to Java (Jake2) just to show it was possible, and that didn't make it slower.

<comment><USER14> I'm not saying there's never a use case for Java. It's reasonably well suited for server-side work (and most of your examples are IO-bound server processes).

When your main problem is IO, thread contention, etc., Java gives you better tools to address those problems. It's just not at all well suited for the kind of client apps that people run on their desktop computers, and to a lesser (but still visible) degree, it's not well suited for CPU-bound things like a lot of scientific computing, which is more where my expertise lies.

Looking at Jake2, the author notes: "The 0.9.2 release shows a big improvent due to the new "fastjogl" OpenGL renderer. The new renderer reduces the number of native interface calls. JNI calls produce a considerable overhead and were the main bottleneck in our application." If he's doing enough JNI to make this the main bottleneck, then clearly quite a lot of the heavy lifting isn't being done with Java.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Recent standard draft (2014-03) [https://github.com/zygoloid/cplusplus/blob/master/papers/N39...](https://github.com/zygoloid/cplusplus/blob/master/papers/N3936.pdf?raw=true)

<comment><USER16> Do you know where I can find a diff?

I'd like to see whats new with 14.

Edit: [http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features](http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features)

</comment></comment><comment><USER17> Can anyone recommend a book on modern C++?

<comment><USER18> Scott Meyers' _Effective Modern C++_ will be required reading once it's released in October.

Until then (and even after), Stroustrup's _The C++ Programming Language_ (4th edition) is the canonical resource. It's a reference but is also intended to be read.

<comment><USER19> Ironically, it was (the first edition of, I believe) Meyer's "Effective C++" that made me question "WTF? Why does anybody use this???" (given that Turbo Pascal / Delphi, or Perl, actually were much easier to understand). Maybe C++ is usable now, but back in the late 90s, nobody that I respected used C++ - all the code I saw at work in C++ was by resume padding morons who wouldn't recognize polymorphism if it walked up and bit them in the ass. (the opinion being either use C, or a high level language, but not C++)

Not fair to judge the language by the fools that used it 15+ years ago, but I have no use for operator overloading, copy memory leaks and all the other C++ obfuscation.

C++ _would_ probably benefit from a "lessons learned" do-over with a new name (as referenced elsewhere in the Perl 6 / Python 3 debacles)

</comment></comment></comment><comment><USER20> I apologize if this is ignorant, but how is C++ versioned?

<comment><USER21> what do you mean?

C++ is a language designed by committee. C++14 is meant as a "tock" release, fixing some of the things in the C++11 "tick" release. ("tick" releases are larger, and "tock releases fix some of the problems in the "tick" release).

Compilers then attempt to implement the standard, and have their own versioning system.

<comment><USER22> Traditionally, "ticks" are small, and "tocks" are big. See [https://en.wikipedia.org/wiki/Intel_Tick- Tock](https://en.wikipedia.org/wiki/Intel_Tick-Tock) .

</comment></comment></comment><comment><USER23> I've started getting back into C++ after many years away and it's all coming back to me.

Now of course it's C++11, which does have some nice features, but really I think we've reached the point where we need to start again (downvote away).

Let me give you an example: I recently came across some code that was written years ago that has two size types: one 32/64 bit signed and the other 32 bit unsigned. This creates a bunch of issues when compiled on 32 and 64 bit architectures and there is a substantial amount of effort to clean it up.

I point out things like this to colleagues who are very pro-C++ and I inevitably get the same response: "well that's just bad API design".

Thing is, if you look at the history of this example it's a series of incremental changes, all well-meaning and reasoned, some of which are done by people who I could only call luminaries, and even they make significant and far-reaching mistakes.

So what hope do the rest of us have?

But my biggest problem with the C-dialects is pointers. Namely if you return or receive a pointer, it's not necessarily clear who owns it. The way this is handled is comments like "DO NOT delete this" or "you MUST delete this".

I like that a language like Rust is trying to formalize the concept of object ownership. I'd really like to see that idea mature and take hold.

Until now there hasn't really been a competitive alternative to C/C++. It's not Go (as much I love Go). Maybe it's Rust. We can but hope.

My other big problem (and this applies to Java too) is directly dealing with low-level multithreading primitives like threads, thread groups and mutexes. I really like that Go has taken a different approach here.

What I find with particularly young programmers is they don't have the appropriate fear of writing multithreaded code. It's really, really hard to write correct multithreaded code with low-level primitives. It's why (excellent) books like _Java Concurrency in Practice_ exist.

As for the feature list of C++14 [1], I wonder what all these "auto" declarations will do to the significant work required for static analysis tools, that are an essential part of modern, large-scale C++ codebases.

The literal types (like "s" for std::string or seconds) are cute but at some point the STL was optional. I'm a little leery of embedding it directly in the language but hey I'm no expert.

[1]: [http://en.wikipedia.org/wiki/C%2B%2B14](http://en.wikipedia.org/wiki/C%2B%2B14)

<comment><USER24> > code that was written years ago that has two size types: one 32/64 bit > signed and the other 32 bit unsigned. This creates a bunch of issues when > compiled on 32 and 64 bit architectures and there is a substantial amount of > effort to clean it up.

Such things happen whenever an invalid assumption that is commonly true becomes not so commonly true, such as the 32-bit to 64-bit migration. That said, C/C++ provides you the tools: size_t is an unsigned type meant for storing array indexes and the size of objects in memory. If you want a real integer, then (unsigned) int. If you need integers of a definite fixed size, u?int(8|16|32|64)_t. Granted, I've encountered that not enough people take the time to understand the tool they're using. Honestly, I wish the default integer type was not fixed size, and especially not platform dependent fixed size, like Python; for non-[indexes/sizes], I feel like this is usually what you want.

> "well that's just bad API design".

Well…

> But my biggest problem with the C-dialects is pointers. Namely if you return > or receive a pointer, it's not necessarily clear who owns it. The way this > is handled is comments like "DO NOT delete this" or "you MUST delete this".

This is true; in C++, your use of pointers should be minimal, though this can be a problem with references just as easily. In the (special) case of std::shared_ptr, ownership is clear. That said, this is a problem not unique to C++: it exists in Java, Javascript, Python, and many others as well. For example,

        some_list = [1, 2, 3]
        some_obj = MyObject(some_list)

If some_obj expects to own that list, and it's constructor is:

        def __init__(self, some_list):
            self._some_list = some_list

which I see a lot, you've got the same problem. (I'm also interested to see how well Rust tackles this, as I agree it's a problem.)

> My other big problem (and this applies to Java too) is directly dealing with > low-level multithreading primitives like threads, thread groups and mutexes. > I really like that Go has taken a different approach here.

Honestly, I've never thought multithreading was "hard". There's a set of rules you have to hold yourself too, otherwise, yes, you can make your life very hard. If you limit shared data as much as possible, and what data is shared has a well defined locking order (preferably behind code that enforces it) — often this is just a single mutex — then I don't see the problem. Thread-safe queues ("channels", I think Go calls them) are also useful to establish "service" like threads.

<comment><USER25> There's no such thing as a well defined locking order - a statement that should scream the fact that locks are not composable. Good luck documenting it in the API or in making other developers pay attention.

The problems are even worse than with manual memory management, since there you often get away with RAII. Say a function call is returning some sort of list, or some other data structure. Was the producer operating on another thread? Was that data structure signaled to other consumers as well? Can you modify it without locking?

To make matters worse, locking is extremely inefficient, it limits the possible parallelism, throughput and vertical scalability and suddenly you start thinking of not protecting reads, since shared reads should be parallelizable, right? And so you need to look at alternative means of synchronization and then suddenly you end up reasoning about happens-before relationship arising from usage of memory fences, non-blocking algorithms and single producer / multiple consumers scenarios. And then you discover that C++ doesn't have a strong memory model to speak about and that at least before C++11 it was all platform dependent.

Of course, I like this state of things, since my favorite platform (not C++) has a better memory model and plenty of higher level abstractions built on top, like actors, CSP, ring buffers, futures, Rx, iteratees, immutable data- structures, etc... but yeah, people able to reason about concurrency are also avoiding it like the plague.

</comment></comment></comment><comment><USER26> Number one wishlist item for next C++ is to add networking libraries to the STL. Its past time that C++ knew about the internet.

</comment><comment><USER27> C++ is suitable for development of cross mobile applications , since both iOS and Android tool chain has support for C++.

</comment><comment><USER28> Are modules already kind of unofficially supported, or can they be enabled ? On what platforms ?

I'm trying to make a C++ game with fat libraries like Ogre3D and bullet3D, often on a laptop, and that would really be fantastic to not wait 10s or more each time I edit a header.

I've seen a presentation, basically modules would decrease compile time from M x N to M + N.

</comment><comment><USER21> I really like the direction C++ is moving in. I just really don't like how incredibly VERBOSE it is (though `auto` helps).

<comment><USER29> In languages like C++ "verbose" means "specific and obvious" which is something you want to have when writing certain kinds of code.

It's annoying, it's a drag on productivity, but in the long run it's arguably necessary.

Some other languages which reduce verbosity by making more things implicit make it harder to understand what's actually going on behind the scenes. You lose a lot of information.

<comment><USER30> A lot of C++ verbosity comes simply from bad defaults. Const and virtual should be the default for example, not the other way around. Would stop the virtual destructor ommision problem, and if you need efficiency you could make destructors non-virtual.

Also in the "hiding stuff behind the scenes" department C++ is quite bad.

        SomeClass someMethod(SomeClass a, SomeClass b) {
            ...
        }

is doing a lot behind the scenes. Code below is better but it's longer and less convenient to write.

        const SomeClass& someMethod(const SomeClass& a, const SomeClass& b) {
            ...
        }

And actually C++ code isn't easy to reason about wihtout reading the whole program. It isn't even easy to parse.

What's going to happen when you run this?

        y = f(x);

It may be that f is function, or a type. f may return the correct type to assign to y, or it may return something else and automatically run some conversion. There may be copy constructor and some destructors involved if it's returning object and not reference. It may run overloaded operator= and do anything at all, for example add f(x) to y. Hell, f can also be a class with operator() overloaded, and you would need to track its state to see what will happen.

And we haven't even touched the subject of #define.

It's much easier to reason about Java code for example.

<comment><USER31> Uh, no, "virtual" should absolutely NOT be the default. I don't know where you got that idea from (Java?) but it's absolutely horrible.

<comment><USER32> It was the right default twenty years ago for performance reasons.

These days, the economy of a vtable pointer is not really a good reason, and all languages that have the opposite default (such as Java, as you point out) are doing quite fine.

Because of this default, I can't count the number of times where I've seen "#define private public" and other horrors that developers used to be able to extend classes that their creators were too short sighted to design properly.

<comment><USER33> I'm very glad that virtual is not the default. Most of the classes I write are simply value classes and do not use inheritance at all. Once you start using virtual, you really have to embrace traditional inheritance idioms whole hog, and then you've got std::vector<std::shared_ptr<Foo>> instead of std::vector<Foo>.

If anything, the performance difference between std::vector<shared_ptr<Foo>> and std::vector<Foo> is even greater today than it was twenty years ago.

<comment><USER34> On the flipside, if you are not using inheritance then you could have solved the same problem with abstract data types. The only big problem is that in C++ the method call syntax is much more convenient to use: foo.frob() vs Foo::frob(foo). IMO, the correct way to fix this is by adding syntax sugar to the language, not by making methods non virtual by default.

<comment><USER33> I don't understand. Do you mind elaborating? Not sure what you mean, specifically, by "abstract data type" (I think of ADT as just another synonym for a class), nor do I get the static method thing. If you were calling hard- coded static methods, you wouldn't have polymorphism anyway, so how you have virtual methods?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> And we have golang.

</comment><comment><USER36> I'm a little afraid the language will go down hill from here. Too many versions - a committee dedicated to creating new versions of the language standard is going to do exactly that. Much like has happened with OpenGL.

<comment><USER37> > Too many versions - a committee dedicated to creating new versions of the > language standard is going to do exactly that. Much like has happened with > OpenGL.

The problem with OpenGL was that they tried to retrofit an API that assumed a certain underlying hardware model to modern (i.e. less than 15 year old) GPUs. It was impossible to do in any sane manner.

</comment></comment><comment><USER38> I'm assuming C++14 will have 1320 keywords and a bunch of weird operators to use so people can ignore it even more than it's being ignored.

<comment><USER39> um, C++ is the most widely used language in the world.

<comment><USER40> Okay, that's incorrect. It's a bit hard to say whether it is Java, Javascript or C, but it's certainly not C++.

<comment><USER41> It's really neither here nor there, but every java or JavaScript engine in widespread use is written in c++, so c++ code "in use" subsumes both of them.

<comment><USER40> No language exists but x86 binary code!

<comment><USER42> Um, ever hear of ARM? (Also 680X0, IBM mainframes, 8051, Itanium, Sparc...)

But then I presume the parent was sarcasm.

<comment><USER40> Yeah, it was sarcasm on my part, at least. Point being that only binary is it's own language all the way down (which is of course not long at all).</comment></comment></comment></comment></comment></comment></comment>


You don't need a degree to become a Product Manager - <AUTHOR> https://medium.com/@thisishustler/my-journey-from-being-a-college-dropout-to-a-product-manager-3c993841e657 <comment><USER2> Cisco, Microsoft, and others have had project manager certifications for years..

<comment><USER3> Project management is a completely different discipline. Product management is about the design of a product, whereas project management is about the implementation of a vision.</comment></comment>


DebateZone - new ajaxy debate site - <AUTHOR> http://debate-zone.com Filling a niche in the market, karma + arguments = logical debates, go check it out! Feedback/comments/suggestions appreciated! <comment><AUTHOR> feedback/suggestions appreciated!</comment>


The Bozo Event Horizon - <AUTHOR> http://blogs.law.harvard.edu/waldo/2012/07/27/the-bozo-event-horizon/ <comment><USER3> _the Google process reminded me of the time, more than 20 years ago, when I interviewed at Microsoft. And we saw how well that worked_

Microsoft from 1992 onwards? I guess we did; 20x increase in adjusted share price; in OSes alone, the release of Windows 3.1 (IMO the breakthrough move to GUI on PC, away from DOS), NT 3.1 (the original seed that grew to NT 3.51, NT 4, Win2K and all current kernels), breakthrough success of Windows 95. Looks like it worked pretty well, and made a lot of people very wealthy.

<comment><USER4> _> Looks like it worked pretty well, and made a lot of people very wealthy._

The same could be said of [Insert great company here]. The same could also be said of many criminal enterprises and a variety of industries that were abusive before regulation and reform. Conclusion: The ability to say this is of no particular worth in determining if an enterprise is or isn't evil.

EDIT: Downvoters: see grey-area's granchild comment. I find it incredible to be downvoted for observing that a statement is essentially neutral.

<comment><USER5> Evil? This isn't a conversation about making moral judgements, why are you dragging moral constructs into it?

<comment> grey-area From the article:

 _All of the great companies I have worked for (Apollo and Sun in various incarnations) or heard about (DEC, PARC, Bell Labs and the like) started around a core of incredible people. These were people who are or were legends in the field._

Since the article talks of success and greatness in moral or intellectual terms, the conversation should not just be a simplistic comparison of money earned... that's not a measure of greatness.

<comment><USER6> "Legends" is partially dependent on luck (being in the right place at the right time). The stories of the "legends" are told, in part, because of their successes. We hear the stories about the right people in the right time/place. We don't hear about the right people in the wrong place.

<comment><USER7> If you are legend material, you'll, eventually be in the right place at the right time.

Odds are wherever you are has a greater chance of being the right place.

</comment></comment></comment></comment></comment></comment><comment><USER8> The most absurd thing in my opinion is self-promotion. Let's be honest, some of the most influential people in HN, Github, etc., are accomplished, naked self-promoters.

Many rants posted to HN could simply be entered as text on HN but end up being blog posts one someone's blog. Lots of creative ideas turn into blog post rants that point to code on github with no history, no evidence of the messy process of creation, only the illusion that the author typed it all as if by divine inspiration.

I wish more of the elites among us would let us see their ugly commit history, their discarded design ideas, their untested, uncommented code.

In some circles, this is called keeping it real. Open source should not require such artifice if we have a meritocracy.

On the other hand, maybe all great luminaries started out as aggressive self- promoters (picture accomplished performers busking on the street in their younger days).

<comment><USER9> How about posts describing times when the author has screwed up? I try to learn something from my mistakes and then share that knowledge in the hopes it will reduce incidences of that same mistake in the wider world. I don't care that it means admitting that I did something stupid or was ignorant of some particular technique at the time.

It's going to happen to everyone, so I just figure, why not turn it around and use it as a learning experience (for me) and then a teaching opportunity for others?

Case in point: I did something really stupid with MySQL's client library without realizing it when I designed my own interface to it, and it bit me hard enough to bring down a bunch of database-backed stuff on my systems. In fixing it, I discovered both a thing to make sure I never do again in my own code, and also uncovered a possible way to launch a denial-of-service attack on a MySQL daemon

Then I turned it into a post. So I screwed up. It happens. What I found out as a result more than makes up for it.

<comment><USER10> I wonder if the current environment where HR googles everyone leads people to not give post-mortem stories of failures. Even if a technical person would see the wisdom of your post, HR might use it to discard your resume.

<comment><USER9> What you're saying here reminds me of a short conversation I had once. Someone said to me: "this post might make it hard for you to work with <specific people> in the future." My response was: "if I have to work with <specific people>, then I will have failed."

In this case, <specific people> are the ones in HR who somehow think that skipping over someone like me is warranted because I'm honest about mistakes I've made in the past. Just what kind of company would that be, anyway? What would my coworkers be like in that environment?

If you accept that everyone makes mistakes, would you rather work with the ones who discover them and deal with them ably, or the ones who conceal them and/or don't learn from them?

That said, I do see what you are getting at. If you haven't gotten to a point where you can say "to hell with this corporate misery" and live with the consequences, maybe you don't want to rock the boat. It might impact your ability to get into yet another miserable place.

<comment><USER10> In a lot of places HR does a first filter on people, and the local job markets (where some people might be stuck) aren't exactly doing great right now. HR is often not a reflection of the rest of the company for some strange reason. I've worked at fun, great places with absolutely horrid HR.

</comment></comment></comment></comment></comment><comment><USER11> A constrained elite does seem useful within an organization. I like the idea of distinguishing those engineers who go above and beyond and really create something new. However it can also become a gerontocracy easily and can limit the adoption of innovative ideas in the long run.

The problem I have with these sorts of social structures is that it assumes that one person out of a hundred is some how "gifted." After reading Coders at Work and listening to interviews with "gifted" artists I think most of these people do not in fact consider themselves such. AFAIK they just worked really hard and the right people at the right time took notice. I assume this is why I often hear these "gifted," people say they feel really lucky to be in the position they're in -- luck did have a small role in it and that seems to be where the "gifted," term comes from. The important part is the hard work these people put into improving themselves, their skills, and the state of the art.

However these DE titles can have a negative passive-impact on hiring practices. In order to avoid, "bozos," organizations will try to, "only hire the best." However the "best," is a highly subjective threshold that is constantly in flux. What is state of the art today will be laughably archaic in 5 - 10 years (especially so for technology companies). The harmful effect is that every company will adopt this policy in order to compete and hope that the other companies will adopt the "bozos." What then will happen to the average programmer who is learning the ropes and doing their best to become a DE some day? Should they get filtered out?

There are some things about the event horizon that make sense ("one of us is not as stupid as all of us"). However one must be careful when distinguishing their fellows. While it may encourage the best of the best to join together it can also breed an elitist attitude that is counter-productive to innovation.

Interesting article and a good read! It's something that I toy with in my mind now and again. Personally I think DE's should form their own groups outside of the organizations they work at. Let people lead by reputation rather than hierarchy.

<comment><USER12> This reminds me of part of an essay PG wrote (context: it was intended for high school students, but seems relevant):

"People who've done great things tend to seem as if they were a race apart. And most biographies only exaggerate this illusion, partly due to the worshipful attitude biographers inevitably sink into, and partly because, knowing how the story ends, they can't help streamlining the plot till it seems like the subject's life was a matter of destiny, the mere unfolding of some innate genius. In fact I suspect if you had the sixteen year old Shakespeare or Einstein in school with you, they'd seem impressive, but not totally unlike your other friends.

Which is an uncomfortable thought. If they were just like us, then they had to work very hard to do what they did. And that's one reason we like to believe in genius. It gives us an excuse for being lazy. If these guys were able to do what they did only because of some magic Shakespeareness or Einsteinness, then it's not our fault if we can't do something as good."

<comment><USER13> This is huge. I once dated a girl who absolutely believed that there was some inherent skill with math / programming that I possessed, and consequently felt that my making good money was just a function of my genetics. This _entirely_ undermines the fact that I spent years upon years forgoing any sort of social life to learn more about computers. The only 'inherent' thing wasn't skill - it was an inability to not want to learn more about computers and programming.

It took sweat, and there's an entire category of people who believe in inherent genius versus really effing hard work. That category of people will never put in the work necessary for others to inappropriately categorize them as inherent genius. I hate this problem and don't know how to convince people when they've fallen into that trap :-\

</comment></comment></comment><comment><USER14> The requirement to "only promote A-players" is difficult to ensure, but I think one requirement is to teach people how to tell the difference between A and B work, and what the effect is. This difference takes a long time to learn to spot, and the ability to see it is something I've seen the technical elite take for granted. When you can't tell what a difference A versus B makes, it's hard to see why fairness shouldn't play a larger role.

This goes along with the well known effect of over-confidence from lack-of- knowledge when making judgements, or the way newcomers to a community are often overly-vocal in their judgements. I think it takes some sobering first- hand lessons to be able to see the difference between A-work and B-work.

It wasn't until I tried to code that old Windows star-spreading screen-saver in high school that I got even an inkling of how difficult it was to make all of Windows work, and it wasn't until I actually had to write something as a composition of partial recursive functions that I even began to appreciate the A++ work it took to conceive computing machines at all. Even now, I wouldn't consider myself capable of really distinguishing between A and B work except in a few very select fields.

</comment><comment><USER15> The original poster wrote:

> The other is their hiring process (full disclosure; I've looked at Google a > couple of times and it never worked) which has gotten pretty process-bound > and odd. The last time I went through it, the site manager admitted that I > was plenty smart, but they didn't know what they would do with me. Given > what they were obviously looking for, I wasn't sure what I would do with > them, either. But the whole process seems to indicate that they are looking > for people to fit a pre-defined mold, which the top performers generally > don't do all that well.

My observation would be that the primary goal of Google's hiring process is that there is a very strong bias towards _not_ hiring any bozos --- even if that means that not hiring someone who might be a top performer. It's better than you miss out on a top performer than it is to hire someone into a senior position who turns out to be a bozo. That may be the cause of the OP's perceived "oddness".

The fact that Google's promotion system is done exclusively by peers (i.e., the people who decide whether someone at level N should progress to level N+1 are composed of engineers at levels N+1 and N+2; the manager can give input to the promotion committee, but it's not the manager's call) is a good way to hopefully prevent bozos from getting promoted from within.

Is it perfect? No human-created system is. But I think it's pretty good....

<comment><USER16>
       It's better than you miss out on a top performer than it
       is to hire someone into a senior position who turns out
       to be a bozo.

Is it possible that this model stops working when you get to have tens of thousands of employees and you've scoured the planet looking for people that you end up empty-handed, so you have to increase your risk tolerance for bozos if it means you can hire a top performer?

I guess google knows better than I about their hiring practices but it seems like they have probably taken more risks in these later years than they did when they had only 1000 employees.

</comment></comment><comment><USER17> I've seen startups with rigorous hiring processes, places where only top employees are hired. But then when it comes to hiring execs, they get so focused on luring in a "superstar", that they do little to no screening. The idea is that the person is so great, all you need to do is sell.

And thats how great startups hire a bozo exec team. And we all know where that leads.

<comment><USER4> Much of the poster's concern is over their hiring process generally:

 _>...the whole process seems to indicate that they are looking for people to fit a pre-defined mold, which the top performers generally don't do all that well. In fact, the Google process reminded me of the time, more than 20 years ago, when I interviewed at Microsoft. And we saw how well that worked…_

Hiring processes can become infected from the top-down, however, as high-level employees exert influence over the process to fit their own comfort levels.

I also suspect that there's a point at which hiring like-minded people loses whatever benefit that accrues from increased group cohesion in a company, or that there's a point where such benefits start to get swamped by the effects of groupthink.

</comment></comment><comment><USER18> In my personal experience being a bozo or not has less to do with the technical/non-technical skill and more to do with motivation.

Motivation is what drives people even dummies to excel. And that's sometimes a coin flip. You will see stars perform poorly because they don't enjoy the environment or the specific task they are given.

When there's no motivation even a "star" will just procrastinate and be unhappy until he either quits or conform. When conformed unmotivated people outnumber the motivated ones that's when you are doomed.

<comment><USER19> I see them both as multipliers, at least in the short run.

Perhaps Facebook is going to hit a motivation black hole, as stock options will no longer matter and so employees won't care about what's good for the company. Instead, they will care about bonuses and resume-padding.

Google has had poor motivation for years (employees who don't really care about the success of the company), I think, but they have enough good products that it doesn't really matter.

</comment></comment><comment><USER20> Steve Kleiman, another Sun alum, had some international 'no bozo' stickers. I still have one stuck to a filing cabinet.

Its possible for someone who was once quite good to become more of a bozo, sometimes its an ill advised step outside their comfort zone, sometimes they get pushed there by well meaning management. Like many things, and perhaps related to the nostalgia effect, it is 'obvious' in hindsight when the bozos came, but often times their initial arrival is silent and unheralded.

I saw some of that going on at Google just before I left, I mentioned it to Eric (who had seen it at Sun when we were there and was well familiar with the effect). It isn't at all clear to me that its something you can stop.

<comment><USER21> Can you stop it by staying small? I don't mean a small business, I mean a small team.

<comment><USER20> Perhaps, which is to say that yes if you don't change you can avoid this fate, but not changing is its own form of death.

One of the amazing things of being at a successful company is that each passing quarter increasing revenue brings a bigger pool to spend on doing things, and there are so many things you want to do. But you can't do everything yourself, and growing means hiring, and hiring means getting larger.

Perhaps if you chose to fork the company at that point, I always wondered what would have happened at Google if they chose to 'slice off' the part that built platforms into its own universe. There are fairly natural dicing and slicing points.

But at Sun there was a huge chasm between the 'systems' folks (aka the SunOS creators) and the 'windows' folks (aka the SunTools guys and gals) and the 'language' folks and of course Sun Labs. Competition between how many DE's came from Systems (old boys club) vs other groups, and such like. I do know that one of the contributors was that Sun had a financial year that went July 1st to June 30th. Budget meetings happened in February for the upcoming fiscal year. Inevitably people would panic in April or May that Sun wasn't going to 'make the year' (meet expectations of Management or the street) and there would be wide adjustments (like hiring freezes). What we noticed was that _everytime_ managers would panic and hire anyone they had interviewed if they could 'fog a mirror' just before the freeze because they knew if they didn't they wouldn't be able to hire for another 4 - 6 months. There were some quality issues with those hires.

<comment><USER21> What I like about your answer is how you kind of say that's not possible and then immediately hit on one way it might be possible.

Why should the only kind of growth people recognize in companies be the kind that terminates in ossified monoliths? Isn't this a failure of imagination on our part? Life doesn't usually offer only one way to grow. I'm excited by the idea of a small organization whose revenue grows much faster than it does. Seems to me that this hasn't typically been thought of as the goal. What might happen if it were?

<comment><USER20> "What I like about your answer is how you kind of say that's not possible and then immediately hit on one way it might be possible."

Its an engineering crutch, like people walking around in a building cannot cause it to fall down, but if everyone jumped at the exact same cadence they could. Any thing is possible, sometimes the requirements to get there are so difficult the solution becomes _effectively_ impossible.

If you consider Google as an example, the roughly 1,500 people who are in the search and ads teams make all the money for the company. Everyone else is, rounded to the nearest billion dollars, a non-contributor. But rather than accumlate cash faster than the Federal Reserve can inject it into economy, they spend it on projects which might get them into other markets. Or sometimes create entirely new markets. But that gives them size. And at both Sun and Google its pretty clear that the Bozo Event horizon hits somewhere between 10K and 15K non-sales employees. I don't know _why_ that is, just that it has hit there two times. If Jim's reading he can pitch in DEC's number.

I agree with you're assessment that there are always other growth strategies, and I can identify things that contribute to the incursion of bozos, but that is a long way from the experiment that can show a bozo free stable organization with growing revenue.

<comment><USER21> _that is a long way from the experiment that can show a bozo free stable organization with growing revenue_

Agreed, but let's look at it from the other side. Suppose one such experiment did succeed. How significant would that be? (I say very. Because it would change people's thinking about what's possible.)

Also worth pointing out: such an organization wouldn't need to stop growing, just hire at a slower than traditional rate. Seems to me you could grow for a _long_ time before hitting "between 10K and 15K non-sales employees".

</comment></comment></comment></comment></comment></comment><comment><USER22> "Others, like James Gosling, quietly change the world by building something (the core Java language and libraries) _that make so much sense and are so elegant that you just smile when you use them_."

I'm afraid everybody says this about whatever is new. Nowadays people would say this about Guido, Matz, etc.

<comment><USER23> Man, I'm sort of with you. In the last few years, I've spent time in a variety of languages --- Python, Ruby, JS, Java, and lately Go and Haskell --- and Java just seemed completely terrible: bureaucratic, staid, and just plain mediocre by many standards.

Then I started reading a lot of C++. And I mean no disrespect to the many brilliant people who use and enjoy C++, but it wasn't until then that I really got why Java exists.

<comment><USER24> > bureaucratic, staid, and just plain mediocre by many standards.

Josh Bloch called it a "blue collar" language: a language for building things, not for looking smart.

<comment><USER23> Yeah. And as above I'm kinda sorta with you. People tend to criticize Go along similar lines, that it's not particularly innovative, and my reaction is similar. It's not meant to make you look smart or blow your socks off or whatever; it's meant to help you be productive in no small part by being very, very straightforward.

As such, I'd actually criticize Java for not being simple _enough_. It's well and good to be staid, but excessive bureaucracy is problematic. Arrays are thoroughly un-idiomatic in Java. Exceptions play hell with attempts at control-flow analysis. Lack of type inference increases repetition. The language is embarrassingly devoid of literals. Pick your poison, really.

And people should feel free to disagree, but I don't think such as type inference, literals, or multiple return values are anything _particularly_ flashy. If anything, they tend to make code simpler and/or cleaner.

</comment></comment></comment></comment><comment><USER25> Irony: complaining about bozos and then writing this sentence:

"Others, like James Gosling, quietly change the world by building something (the core Java language and libraries) that make so much sense and are so elegant that you just smile when you use them."

<comment><USER26> Yeah, I saw that too.

I would never, ever describe James Gosling as a bozo, but he doesn't make my top 50 list of language designers and researchers. Java started with a laudable goal to improve upon C, but they didn't take enough risks at the start.

</comment></comment><comment><USER27> Am I the only person who feels woefully inadequate whenever I read articles where phrases like "10 or 100 times as productive as the average engineer".

Sorry guys, I'm trying my best! :-(

<comment><USER28> Such people do exist. Notch, creator of Minecraft, is a good example. The guy virtually developed it himself. I'm currently developing a game myself and I can tell you, it is a lot of work. At minimum I would say the guy is at least 10 times more productive than the average developer/engineer.

<comment><USER29> I'm willing to bet that a lot of Notch's productivity is based on things he learned in previous projects. According to Wikipedia, he's been programming video games since 86. That's 26 years of experience.

If you use those 26 years wisely, you'll learn a lot of different things - <USER2> more importantly, you can draw on 26 years of mistakes that you now know to avoid.

I'm not saying he's not _also_ a talented programmer - but all "superstars" I know are as good as they are because they have worked hard for a long time, and they keep working hard.

(She says while posting on HN... I probably should head back over to my code ;)

</comment></comment></comment><comment><USER4> _> A number of you asked...what I'm seeing happening at Google (and what I mean by a bozo)._

The subjectivity of this is the core of the problem. One man's Zen Master is another man's Bozo. Often, they look indistinguishable to the uninitiated.

 _> Others, like James Gosling, quietly change the world by building something (the core Java language and libraries) that make so much sense and are so elegant that you just smile when you use them._

Another example of how one man's X is another man's Y. (EDIT: In putting it this way, I mean to respect both directions of opinion.)

 _> The indicator is when process and fairness becomes more important than judgement, and when it isn't ok to say that some people have reached their limit._

Process and fairness are often used as proxies for meaningful relationships and understanding among coworkers. Often they are used as a means of avoiding taking such responsibility.

</comment><comment><USER30> This article was fantastic! Thanks so much for linking it.

Steve Jobs always said that part of his job was to keep the bozos out and this article explains exactly why.

Every single company I have worked at has been on or past the Bozo Threshold... The author notes that this phenomenon may be limited to technical companies, but I would like to argue that it is not limited to technical companies and may not even be limited to companies at all! This same sort of stupidity can be seen any organization that is around long enough.

A great product is not built by comittee, because committees care too much about FAIRNESS!

</comment><comment><USER31> Isn't this the Peter Principle[1] in action? I noticed this halfway the end of the post, but nobody cited it here yet…

[1] <http://en.wikipedia.org/wiki/Peter_Principle>

<comment><USER32> Very much so.

</comment></comment><comment><USER33> I have been in organizations where there are two ladders (in a very large company). One for technical people and one for management. Needless to say, all the bozos clearly went to the Management ladder, while the technical ladder kept the people with more depth in their field, the ones who actually made stuff in the first place. However, I felt that the technical ladder had flaws as well. The higher titles (principle scientist, research fellow, etc...) were simply provided based on these people's past achievements. Once you are such levels there is very little incentive to work hard to go to a higher level, and there is virtually no risk of being fired either. So, you end up with relatively senior people who reapply what worked for them instead of trying new things and pushing new technologies or new ways of doing things. And many times when I was in touch with these people in the higher technical ladder, making presentations and all, I did not find much of what they were talking about to be very impressive or innovative either.

</comment><comment><USER34> Two cases:

1\. You work for a tech company which produces a tech product (e.g., Google, Microsoft)

2\. You work as a tech person in a business company (e.g., bank, insurance)

This article fully applies to #1 where the core competency is technology. For #2, there's debate.

<comment><USER35> For #1 you are front-office. For #2 IT is back office. Bozo explosions still happen at investment banks' front offices, e.g. when smart traders are sidelined in favour of politically savvy traders.

</comment></comment><comment><USER36> This reminds me of mushroom cap[1].

[1] [http://my.safaribooksonline.com/book/work- relationships/9781...](http://my.safaribooksonline.com/book/work- relationships/9781564147042/chapter-4-idiot-procreation/89)

</comment><comment><USER37> Simpler definition: when politics eclipses merit. When "it's not what you know, it's who you know," the organization (or society) is doomed.

</comment><comment><USER38> The old hiring slogan, which they used in the MSFT hiring and hammered even harder in hiring manager training was, "As hire As; Bs hire Cs."

<comment><USER39> Who hired the Bs?

<comment><USER38> The better question is who failed to keep the As engaged? For a variety of reasons, people stop growing and sometimes even move backwards.

There are few things more destructive to a team than smart people who've completely checked out.

</comment></comment></comment><comment><USER40> These companies seem to suffer brain-drain and increasing mediocrity in the same way that online communities suffer the constant erosion of their best users.

<comment><USER41> viz, "evaporative cooling"

[http://blog.bumblebeelabs.com/social-software- sundays-2-the-...](http://blog.bumblebeelabs.com/social-software- sundays-2-the-evaporative-cooling-effect/)

</comment></comment><comment><USER42> Is there anyone else that thinks Harvard is now spewing out "bozos" for writing this type of piece? Are you that arrogant? First of all "B class" employees are generally speaking still highly intelligent and educated. Second off, you seem to dismiss the reality of the business world in replacement for technical achievement.

To me all this article displayed is the clear distinction between the technical and the business side (that which employs the technical).

Degrading "B class" people as "Bozos" is quite frankly disgusting. You can have all the brightest minds in the world that create the next progression of technology, but without the "bozos", they will be stuck in a room congratulating themselves into perpetuity...

<comment><USER43> I'm really surprised that yours is the only comment pointing this out.

Note that the author implicitly defines "bozo" as anyone who's not a world- class programmer or researcher (or possibly, any such person that rises above a certain level in the hierarchy). So, 99.9% of programmers, including even some programmer-entrepreneurs who have built valuable companies without being world-class technically.

</comment></comment><comment><USER44> It's really about management. Companies evolve as they grow and the magic sauce that took them from Start up to Successful is not the same sauce that takes them from $1 Billion to $10 Billion and then $10 Billion to $100 Billion.

Moreover, the techno-guild at Exxon is going to have a different mandate than Cisco's or Disney's.

Managing growth, competition and markets is the job of management (CEO) and understanding the role that technology plays in their business, and then ensuring that foresight is available (CTO) to them to act on, is what they get paid for.

A Bozo at Amazon might be a god at Delta Airlines.

</comment><comment><USER45> It probably isn't safe to assume that the word "bozo" is applied in a remotely objective way. Or even that it has any kind of consensus definition.

So in any given case there is a good possibility that the "bozo detector" goes off mostly on people who don't like you, or whose lunches smell bad, or even people who might be competition, or people who are doing better than you are.

</comment><comment><USER46> I have seen the effect of an appointed organization head, hiring and promoting only those less competent than them selves. Even after the head retires, the infected organization may take a lifetime to recover.

The whole Jobs A thing is just pure BS ego speaking.

</comment><comment><USER9> I am a fan of the word "bozo", and even used it in a book title. It explains so many bad things in our industry. The fact that this author is associating it with Google is just the icing on the cake for me.

<comment><USER47> Gary Larson thought it's a good thing: [http://img.photobucket.com/albums/v479/alanganes/HSM_Board/B...](http://img.photobucket.com/albums/v479/alanganes/HSM_Board/BozoneLayer.jpg)

SCNR

</comment></comment><comment><USER48> Uh... Google and Microsoft are really successful companies, though!

</comment><comment><USER49> How to recognize during interview if company is run by bozos?

What to look at? What question ask? About process? structure?

</comment><comment><USER50> There are no bozos, just elitists. I prefer a respectful anarchy to an oligarchy.</comment>


Show HN: I implemented some colorful 2D fluid simulations[video] - <AUTHOR> https://www.youtube.com/watch?v=FDX-9gTC48o <comment><AUTHOR> Source code is here: [https://github.com/Erkaman/fluid_sim](https://github.com/Erkaman/fluid_sim)

this is some flashy fluid simulations made using the techniques described in the article "Fast Fluid Dynamics Simulation on the GPU".

The code is minimalistic and is written in only ~1000LOC of C++, and uses only OpenGL and no frameworks whatsoever, so the code should be pretty readable.

Finally, note that the primary focus was on making flashy simulations, and not on physical realism.</comment>


Trending Photos for Singapore General Elections 2015 Live Streaming #GE2015 - <AUTHOR> http://geosenti.com/cg/RHjD9ZKrDHpNBR6p8

<comment><AUTHOR> Trending Photos for Singapore General Elections 2015 now live at [http://geosenti.com/cg/RHjD9ZKrDHpNBR6p8](http://geosenti.com/cg/RHjD9ZKrDHpNBR6p8)

The data is currently collected based on related keywords (ge2015, sgelections, wprally, paprally) and 1 location (Blk 837 Hougang Central). The keywords and location will be updated from times to times. Feel free to suggest for improvement. Thanks.

Live Feeds: [http://geosenti.com/cs/RHjD9ZKrDHpNBR6p8](http://geosenti.com/cs/RHjD9ZKrDHpNBR6p8) Insights: [http://geosenti.com/c/RHjD9ZKrDHpNBR6p8](http://geosenti.com/c/RHjD9ZKrDHpNBR6p8)</comment>


How the Raspberry Pi boots up - <AUTHOR> http://thekandyancode.wordpress.com/2013/09/21/how-the-raspberry-pi-boots-up/

<comment><USER2> "The config.txt is loaded after the split is done so you cannot specify the splitting amounts in the config.txt. However, different .elf files having different splits exist in the SD Card."

This hasn't been true for some time. In fact runtime dynamic RAM management has been available since Nov '12\. See [http://elinux.org/RPiconfig#CMA_- _Dynamic_Memory_Split](http://elinux.org/RPiconfig#CMA_-_Dynamic_Memory_Split) for more details.

</comment><comment><USER3> Just reading the sections about the GPU code makes me happy I've never had to touch that board, or any Broadcom chip for that matter.

If only people understood and appreciated how _bad_ proprietary system level software is and the terrible way people (read: Broadcom) architect it.

<comment><AUTHOR> You're right, been there recently when I switched to Debian as main OS on my iMac, dealing with proprietary drivers (iMac mounts a bc) was the hardest part indeed.</comment></comment>


Funny SQL Server bug, that MS calls a "feature" - <AUTHOR> http://www.jitbit.com/alexblog/239-sql-server-bug-ms-calls-a-feature/

<comment><USER2> Why is this a bug? There are no guarantees (beyond not going backward). You can't count on dense ids anyway. What if you have concurrent transactions that get ids and some of them abort?

It's your application that's buggy if you are relying on dense ids.

Definitely not a bug, and unclear why it's a feature. It just is.

</comment><comment><USER3> A feature that you don't like is still a feature</comment>


Tens of thousands of Japanese housewives drawn into currency day-trading, lose billions - <AUTHOR> http://www.nytimes.com/2007/09/16/business/worldbusiness/16housewives.html?ex=1347595200&en=503d9ca7dcc70860&ei=5090&partner=rssuserland&emc=rss <comment><USER2> As a general rule, day-trading is a very bad idea. It would be surprising if after expenses Ms. Torii (whose success is extremely atypical) is still in the black a few years from now. Making serious long-term money is rare enough among pros. People day-trading from home don't stand a chance.

<comment><USER3> 'Making serious long-term money is rare enough among pros.'

Data sources?

<comment><USER4> Go to any investment bank. Take a look at every other desk except currency traders. You'll notice the average age is around 30. Take a look at the currency desk, and you'll realize the average age is around 50. Why?

Bonds, stocks, exotics -- that stuff is all teachable. Give someone two years and they can learn to work the markets. Currency has basically zero theory surrounding it. The guys who are really good have no idea why they're good at it. It's basically all just trapped in their heads and they can't get it out. That's why the guys who are good at it tend to stick around forever and they end up being much older than the other guys on average.

<comment><USER3> I once considered taking an $899 course on currency trading from FXCM.com, so there must be at least some people who think they can teach it and others willing to pay to learn.

Also, with other i-banking specialties you need a larger supply train, including data gathering, analysis, packaging (as a fund) and marketing. With technical trading all you need is your computer and you. Why would a young person who is skilled at technical trading work inside an investment bank? How can you be sure that there aren't thousands of skilled traders making a killing from home? Isn't this sort of like hackers?

<comment><USER5> > I once considered taking an $899 course on currency trading

Why would someone who knew how to trade bother selling an $899 course? They'd be making 10-10000 times that, trading.

<comment><USER3> I also wondered this. Perhaps they like teaching?

<comment><USER6> Because it's an elevated version of the good ol' SCAM. Akin to the "Learn how to sell on eBay" or "How to buy and flip a house" pitches that you see often. How good of an education can you buy for $899?

<comment><USER3> Probably not a very good one - but what do I know I didn't take the course. Btw, I've heard from folks that flip houses that at least some of the workshops are legit.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> "There are strict taboos against money that isn't earned with sweat from the brow"

A relative of mine grew up with many orientals and she too holds this attitude. It seems very strange to me but now at least I know where it came from.

<comment><USER8> You know that is a _good_ attitude for society. It is only during financial bubble times that people develop the flip-it mindset.

I am a PG fan, but the only thing I am not a fan of is his built-to-flip mindset. The coming downturn will cure it - most companies aren't going to find sugar-daddies, so would actually have to figure out a way to make it on their own ...

<comment><USER7> It's bad because those people ONLY plan to work hard, but not work SMART.

It isn't just about building to flipping. They would never start a business at all. There is much more honor in pushing papers around and accomplishing nothing at some huge company than ever actually doing the most you can do.

</comment></comment></comment><comment><USER9> They have dishonored their families.</comment>


HootSuite Reaches 3 Million Signups - <AUTHOR> http://blog.hootsuite.com/3-million-milestone/?utm_medium=twitter&utm_campaign=3million&utm_source=hootsuite&utm_content=blog <comment><AUTHOR> Clearly there is a profitable industry built around Twitter. Where will Twitter move next in their way to profits?</comment>


Apple's Best Product Is Privacy, Not iPhone - <AUTHOR> https://hackernoon.com/apples-best-product-is-privacy-not-iphone-9919f5fc6fb7 <comment><USER2> It's one of their selling-points, so ye that's pretty obvious.</comment>


Sheryl Sandberg went from feminist hero to total sellout - <AUTHOR> https://nypost.com/2019/11/02/how-sheryl-sandberg-went-from-feminist-hero-to-total-sellout/ <comment><USER2> >The façade began crumbling last November, when The New York Times published...

I need to call bullshit. It was readily apparent in 2013. Probably earlier, but that's when I learned she and her book existed.

I did a naughty thing though. I read the _Lean In_ book review written by a rum-fueled pirate blogging the kind of insights the NY Post is taught not to have.

<comment><USER3> Don't leave us hanging, share the link please!

<comment><USER2> [https://thelastpsychiatrist.com/2013/03/dont_hate_her_becaus...](https://thelastpsychiatrist.com/2013/03/dont_hate_her_because_shes_suc.html)

<comment><USER4> I miss The Last Psychiatrist.

</comment></comment></comment></comment><comment><USER5> Far more problematic long term, to me, was her (and Facebook's) role in making sure FOSTA/SESTA happened.

</comment><comment><USER6> "Clearly, it's been wish fulfillment to buy Sandberg as Facebook's humanist component, the good mommy reining in a precociously gifted child who doesn't yet understand his superpowers. As it turns out, she's been raising Cain all along, at our great expense."

</comment><comment><USER7> Wouldn't this make her an even bigger feminist hero?</comment>


Study: Alcohol More Deadly Than Heroin - <AUTHOR> http://today.msnbc.msn.com/id/39938704/ns/health-addictions/

<comment><USER2> Report from the BBC, and much dicussion here: <http://news.ycombinator.com/item?id=1855713>

If you prefer an American report on this British report, there's also the CNN version here: <http://news.ycombinator.com/item?id=1856456></comment>


There are many reasons why India and China have nothing on us  - <AUTHOR> http://www.thedaily.com/page/2011/02/24/022411-opinions-column-americandream-dalmia-1-2/

<comment><USER2> Written by a desi (ABCD even) who has seen her motherland only through the lenses of western/english media.

No Indian, especially those outside the English media, thinks that India is better than the US in material quality of life.

</comment><comment><USER3> The article itself sounds similar to hype.

</comment><comment><USER4> I am a indian living in US for more than 10 years and this article sounds so true!

</comment><comment><USER5> I'm an Indian living in the US for the past 9 and I agree with the article..</comment>


Show HN: Antimander – Optimize Congressional Districts with Genetic Algorithms - <AUTHOR> https://antimander.org/ <comment><USER2> "I cut, you choose" is really the only politically viable alternative to the current state of affairs.

[https://slate.com/news-and-politics/2018/02/how-the-i-cut- yo...](https://slate.com/news-and-politics/2018/02/how-the-i-cut-you-choose- method-of-redistricting-could-fix-a-broken-system.html)

<comment><USER3> It would require a more fundamental recognition of political parties than the constitution provides.

Gerrymandering is not a technological problem.

<comment><USER4> Why can't you just split elected representatives into two groups, regardless of stated political affiliation? One group then cuts, the other chooses.

<comment><USER5> Defections. Electeds will happily maximize their own personal power at someone else's expense. There are many examples of getting opposition support for inequity in exchange for safe seats.

People outside of (partisan) politics don't often get to see that the party orgs and the politicians are usually in conflict. More so on the left than on the right.

<comment><USER2> Interestingly enough, this works even for defectors. They still have to participate in a turn-based game against a competitor.

There is a whole field of study around efficient "cake cutting" algorithms, many of which contemplate and account for defectors.

[https://en.wikipedia.org/wiki/Fair_cake- cutting](https://en.wikipedia.org/wiki/Fair_cake-cutting)

</comment></comment></comment></comment></comment><comment><USER6> >Some interesting patterns emerge, such as how with you can have compact and republican-biased but not compact and democrat-biased maps for some numbers of cities. This is a direct result of one party being forced into a small geographic area (cities).

That's quite an interesting finding. I always understood that gerrymandeting is bad because the artificially winning parties get congressmen that are not representative of their districts. This guy uses "competitiveness" as a property worth optimizing for, achieving exactly that.

<comment><USER5> I've long advocated maximal competitiveness. Mostly to motivate voter participation.

I love how antimander illuminates the tradeoffs.

Along the lines of "preserving community", preserving continuity can also be a factor. On the presumption that voters don't want to have their congressional district designation changed every 10 years. For example. I know this is a consideration during redistricting.

\--

Antimander is real progress. The cites are terrific. I'm delighted that I even learned some new things, like the Seats-Votes Curve.

I've spoken with the Dave Bradlee many times over the last 15 years. He created a redistricting app that got some national media attention last cycle. [https://en.wikipedia.org/wiki/Dave%27s_Redistricting](https://en.wikipedia.org/wiki/Dave%27s_Redistricting)

Some of those talks were pretty bleak. I'm so glad so many more people have engaged with this issue.

</comment></comment><comment><USER7> This is really well done! Do you have analysis of what this would do nationwide or across multiple states? Optimizing for competitiveness is a metric I hadn't considered but seems particularly valuable especially towards increasing voter turnout.

<comment><USER6> How is it valuable? Having a "red" or "blue" district means the congressman is somebody most people can get behind, "our guy in the parliament".

Being around 50% gives you a compromise that nobody trusts and nobody feels the stake in their country.

</comment></comment><comment><USER8> On Android and Chrome, I can't read the page. The graphic takes up half the screen and the text underneath is barely visible.

<comment><USER9> I had to scroll all the way to the bottom to see if anyone could even read the site on mobile.

</comment></comment><comment><USER10> Gerrymandering is a danger to democracy and it is great that researchers shine light on the different trade-offs of districting criteria.

This website seems like a great demonstration of the fairness and competitiveness trade-offs.

<comment><USER11> I'd argue that every voting system that has gerrymandering as a possibly error mode is inherently dangerous. No amount of antimandering could ever be more than a temporal band-aid. There are many examples that successfully combine local representation with proportional outcome.

</comment></comment><comment><USER12> Interesting. GA's have some interesting use cases. We used a GA to optimize assignment of work crews to areas as part of a scheduling optimization, and achieved significant benefits

Steve

<comment><USER13> Seen similar benefits - many years ago applied GA's to schedule technicians to fix computers (based on location, part availability, skill set, etc) and also for manufacturing production lines (labor rules, parts, color changeovers, demand, margin)

</comment></comment><comment><USER14> As Congressional elections become more and more a national affair, why do we still have districts? Say a state gets 24 reps. Give me a ballot with all the candidates and let me mark the 24 I want. Yes the ballot will be more complicated, but this way we entirely avoid districting and the process is entirely fair (well until you consider states not being fairly drawn, but that's one level up).

<comment><USER15> Likely it means that big cities would get all the reps and the rest of the state gets nothing.

<comment><USER16> As that is where most of the people live, why is it wrong? Why does largely unpopulated land get a vote?

<comment><USER14> This. Why do voters living in rural areas get more weight to their votes? This is obviously more pronounced in the Senate, but clearly also a problem in the House.

</comment></comment></comment></comment><comment><USER17> Along the same thread, genetic algorithms have been used to evaluate fair land allocation in Brazil [1], which have also historically been done by hand. I agree with another user that pointed out the very same tools can be used to gerrymander even more effectively than those districts are currently, perhaps in less obvious ways, without the oddly shaped borders that stretch wildy from place to place. It would be important not to have this occur behind closed doors but left open to scrutiny where the fitness function and biases are in full view.

[1] [https://www.lume.ufrgs.br/bitstream/handle/10183/174950/0010...](https://www.lume.ufrgs.br/bitstream/handle/10183/174950/001065460.pdf?sequence=1)

</comment><comment><USER18> How hard would it be to change the congressional election system to proportional voting by party?

In California you would vote for 53 representatives, each representative would be part of a party. First the seats are divided among all parties based on some system. Then within each party the seats are given to the representatives that have the most votes within the party.

This would introduce new parties to the system, no party would be able to govern alone.

<comment><USER19> Would this require me to make 53 different votes? This sounds a like pretty complicated situation to expect educated votes for all 53 votes.

<comment><USER20> In practice, in mostly countries that use STV PR, you have smaller electoral districts, for this reason. For instance, in Ireland, electoral districts elect 3-5 TDs depending on population. This is big enough to make gerrymandering difficult and not very effective, but small enough to avoid the situation where someone has to cast 53 different votes. And 53 would be the low end here, really. That would assume you only want to vote for one candidate per seat, which is not typically the way it works out. I'm in a four seat constituency and voted about ten preferences in the last election, say.

In practice, in STV PR it is generally optimal to vote for almost everyone on the ballot; you give low preferences to people you don't care about to avoid people you actively don't want getting in (it's commonly claimed that you should optimally give a preference to everyone, even those you actively don't want, but this is incorrect).

</comment></comment></comment><comment><USER21> I've always like this article's thoughtful approach to what we should value when districting: [https://www.politico.com/magazine/story/2015/06/could- gerrym...](https://www.politico.com/magazine/story/2015/06/could- gerrymandering-be-good-for-democracy-119581)

</comment><comment><USER22> Interesting to note that the very same tool can be used to optimize the 'worst' maps as well.

</comment><comment><USER23> Now do Maryland.</comment>


Show HN: Draw characters to help computers read human handwriting - <AUTHOR> http://shaper.amees.me/ <comment><USER3> Is this even useful? Handwriting is a well studied problem with good solutions, and we have lots of data (MNIST, etc.)

Can someone explain why we need humans to create new, unreliably labeled datasets?

<comment><USER4> I agree, an 'about' page or similar would be nice.

</comment></comment><comment><USER5> Who gets the data? You alone? I.e. what is the incentive to use this?

</comment><comment><USER6> Doesn't seem to work. Getting javascript errors on Chrome 46.0.2.

Update: works fine in chrome's device emulator. Didn't realize this was only for mobile devices, but it makes sense.

</comment><comment><USER7>
        Sorry. We only accept drawings
        made with a touch-screen device

So ... I'm using a touch-screen device. Why am I getting this message?

</comment><comment><USER8> Neat idea! Two questions:

\- Do you verify inputs to ensure they are at least reasonably valid and not trolling? \- I'm getting a lot of numbers and certain letters, are you specifically trying to get the problem cases solved? If so, good idea - <USER2> how does it do right now?

</comment><comment><USER4> Wouldn't complete words be more useful? People probably change the way they write certain letters based on the adjacent letters.</comment>


How to program computers (kOS) - ah- https://www.youtube.com/watch?v=kTrOg19gzP4 <comment><AUTHOR> There was another thread about kos a while back [1] which was why I invited Geo to speak, as there seemed like a lot of interest.

[1] [https://news.ycombinator.com/item?id=8475809](https://news.ycombinator.com/item?id=8475809)

<comment><USER2> Looks like what Geo was covering in the first few minutes at least is summarized in this comment: [https://news.ycombinator.com/item?id=8476633](https://news.ycombinator.com/item?id=8476633)

</comment></comment><comment><USER3> Do you think Whitney ever considered using the NetBSD kernel code instead of Linux kernel code? No doubt, small was a priority. Why not BSD?

And why doesn't kx have binaries available for BSD? They have Solaris. Burning questions I have always had. Maybe just based on demand from their licensses?

k and kdb are some of the very few things that keep me interested in programming and computers.

<comment><USER4> kOS doesn't use the Linux kernel code. It supports a few of the same syscalls:

clone, execve(!), epoll_create, epoll_ctl, epoll_wait, dup2, stat, rename, unlink, getcwd, chdir, fstat, getdents, open, close, read, write, ftruncate, mmap2, munmap, ioctl, gettimeofday, socket, bind, connect, listen, acccept, socketpair, setsockopt

execve just runs another k interpreter (regardless of what you tell it to do) though, so it can just be used to run more k programs.

<comment><USER3> I recall seeing a solictation on the kOS website for people who could get a Linux kernel down to a certain size. I presumed that meant the intent was to use Linux code; at least I was thinking he would end up getting responses from people with a Linux bias.

But I also recall reading the line "no linux", which really piques my interest. I thought that just meant no Linux userland.

Now I like this project even better!

Sounds like you have access to the kOS source. Lucky you. Enjoy.

</comment></comment></comment><comment><USER5> Not to be confused with kOS [1]?

1\. [http://ksp-kos.github.io/KOS_DOC/](http://ksp-kos.github.io/KOS_DOC/)

<comment><AUTHOR> No, its from [http://kx.com/](http://kx.com/) see also [https://en.wikipedia.org/wiki/K_(programming_language)](https://en.wikipedia.org/wiki/K_\(programming_language\))

</comment></comment><comment><USER2> I tried to run K, but the link at [http://kparc.com](http://kparc.com) requires a password. Is it not generally available yet? Is there a mailing list or IRC channel somewhere?

[https://github.com/kevinlawler/kona](https://github.com/kevinlawler/kona) doesn't run edit.k successfully.

<comment><USER6> The free version of K can be downloaded at [http://kx.com/software- download.php](http://kx.com/software-download.php)

<comment><USER2> But it doesn't look like that version can run edit.k from kparc.com.

So for all practical purposes kx.com and kparc.com are distinct languages/dialects.

 _Edit_ : I should clarify that I'm trying to make sense of the specific code in the OP, in particular to play with the views idea (the _::_ operator). I should have probably put this thread under [https://news.ycombinator.com/item?id=8743325](https://news.ycombinator.com/item?id=8743325)

<comment><USER4> kOS is K5; it's as different from K4 as K4 was to K3.

Views are available in K4/Q/KDB+, so the version on kx.com does work with views. If you want to play with the views idea, try to solve a problem and see where a view helps you.

Here's one I did earlier this week; I've got this tool that takes a whole bunch of logfiles of userids and counts; they look like this:

        5033703751425413371 1
        5409789758109122623 4
        10102846067816284236 4

I call these columns `s(sessionid) and `c(count); I can load them with this:

        G:{g::select from(+`s`c!("*I";" ")0:"S"$":",x) where (c>0)}

Now I say something like: G"trk/tnl5/20141207/TRK_ITM" to get one of these structures into the g variable.

I actually have a bunch of filenames:

        t:{R:{(x,"/"),/:$:!"S"$":",x};,/R',/R'R"trk"}[]

So I can load the first one with: G t 0

This is convenient, since these files are big (1Gb each or so) I'll want to work with a subset:

        g:10000#g

This isn't part of my program, it's just something I do while developing. If I run "G" again it'll get the entire file again.

Now, I want to match these against another list of users. I'll do a similar trick:

        D:{d::0:"S"$":",x}

and now I can do: D"users.txt" to put this into the d variable.

My program needs to find the rows of g that d match.

Some of the sessionids in the logfiles are corrupt. They look like this instead:

        7241110807448127691320303160517889791474867567241110807448127691320312936057606400732600664532969577042775 4
        62349552899220301013203170219134834182361546234955289922030101320303170219134834182361546234955289922030101 4

These are wrong. I originally tried to figure out them by finding the longest string that was also at the beginning of the sessionid, but after talking it out with Oleg and Pierre I decided to try to simply match them against the lengths of d:

        ?:#:'d

said I only have two lengths (19 and 20), so this is a much smaller search than what I was trying before!

To do this, I used views:

        K::?:#:'d
        k::"S"$"S",/:$:'K
        f::k!+(K#\:/:g.s)

Now f is an index on g; instead of a `s column it has an `Sn column where n is length of the key; i.e. I have a `S19 and an `S20 column with the first 19 characters of `s and the first 20 characters of `s accordingly.

        s::g.s[&|/f[k]in\:d]
        c::g.c[&|/f[k]in\:d]

Now I can look at the `s and `c vars and do what I want to do; get my unique userids and my counts.

 _More importantly_ , I can apply this to all my files (I have a lot of them):

        n:0;m:0;{G x;n+:+/c;m+:+/g.c}'t

</comment></comment></comment></comment><comment><USER7> His suggestion is that the cure for code bloat is, basically, codegolf?

<comment><USER8> So... is bloat extra features, extra code, or extra resource usage? Is it bloated if you have the same features in fewer lines, or fewer lines with more resource usage?

It's almost as if bloat is a meaningless snarl term with a mostly illusory definition beyond "bad".

<comment><USER4> If they're "extra" then they are unnecessary; I define code bloat strictly as redundant code inside the source tree.

Redundant code has performance and resource ramifications: Programs that are bigger load slower (more bytes to pull from disk) and run slower (more trips in and out of cache memory).

Redundant code also has other ramifications: Two modules in the same source tree may attempt similar (or identical) algorithms and miss an opportunity to consolidate. One of them might hide a bug, where the other code path was executed more frequently and the bug fixed.

<comment><USER8> Your idea of "superfluous" is my idea of "just enough", and vice-versa.

For example, why have Bentley when we already have Ford? Multiple car manufacturers is surplus, waste, and bloat.

<comment><USER4> I didn't use the word "superfluous". I define code bloat strictly as redundant code inside the source tree.

Car manufacturers do not exist inside the source tree.

They aren't even obviously unnecessary; After all, people have different tastes about whether they like a Bentley or they like a Ford.

The computer (however) does not have taste, and it doesn't care whether you like your strcmp or my strcmp.

</comment></comment></comment></comment></comment><comment><USER9> Are there any post-scripts or notes from the ensuing conversations? An interesting point was made about humans not understanding programming and then dodges any explanation due to time.

<comment><USER4> I'm sorry: It wasn't an intentional dodge. It really was getting late in the day.

Only one person was hostile. They wanted to point out that there was no point in writing it all on one line "just to be unreadable".

I told them I thought the readability was improved by having all the words together, but maybe it made it difficult to learn. I noted Arthur had recently annotated edit.k[1] and asked them if that layout made it easier for beginner programmers to learn to read.

I don't think they liked being referred to as beginner programmers because he mentioned that he lectures at Cambridge, so of course they know how to program.

But most people were very encouraging: A lot of people wanted to share something they didn't like about different programming languages, and wanted some ideas about how they can learn more.

I got asked to read some more snippets of code [2] so that people could see this and get a better feel for it.

I got a couple of questions about syntax highlighting and development tools, and if there might be some middle-of-the-road solutions that were terse but not-as-terse.

Also: Beers.

[1]: [http://kparc.com/edit.k](http://kparc.com/edit.k)

[2]: [http://nsl.com/k/sudoku/](http://nsl.com/k/sudoku/)

<comment><USER10> > I told them I thought the readability was improved by having all the words > together, but maybe it made it difficult to learn. I noted Arthur had > recently annotated edit.k[1] and asked them if that layout made it easier > for beginner programmers to learn to read.

The issue, for me, is not readability but context. Even a word or two (e.g. cuts, begins, dims) helps greatly to establish the context of the code. Like having a map before hiking.

When I write k/q, I use the same layout as Arthur with the additions of comments for each definition on the same line beyond column 80 or 132. Works well for wide monitors.

E.g.

      c::a$"\n";b::0,1+c;d::(#c),|/-':b                / (c)uts, (b)egins, (d)ims

I've also experimented with folding editors to keep comments above their respective definition while only taking up one line when folded. Some editors (e.g. - jedit) can display the folded text as a tool tip without expanding the fold.

      / Docs
        (c)uts
        (b)egins
        (d)ims
      c::a$"\n";b::0,1+c;d::(#c),|/-':b

I hope this is useful or helpful.

<comment><USER4> It is interesting.

Can you talk more about context? How exactly does it help you?

I don't think:

       c::a$"\n";b::0,1+c;d::(#c),|/-':b                / (c)uts, (b)egins, (d)ims

is more clear than:

       c::a$"\n";b::0,1+c;d::(#c),|/-':b

Or for that matter:

       ⚁::⚀$"\n";⚂::0,1+⚁;⚃::(#⚁),|/-':⚂

because _they are just symbols_ to me, and one symbol is as good as another (except for the amount of space they take up on the screen and the ease in recognising it; I don't have many variables named lowercase L).

<comment><USER10> TL;DR - Map symbols or uses of operators to meanings.

Context is semantics/meaning. I.e. - hints, documentation, use case, approach, etc.

It's not about the code but the description of the code. The above code is the same, however, the comments loads the basic intentions into my mental cache. I can then read/use the code without having to analyze every definition completely.

This is especially helpful for k operators that can be overloaded by type or meaning. E.g. x!y can be create dict, table -> keyed table, keyed table -> table, integer -> enumerated value, ...

A hint (outside of the code) helps me out quite a bit.

Btw, the code above can be written as: d::(#c),|/-':b::0,1+c::a$"\n"

Which seems more clear, given the context.

<comment><USER4> > I can then read/use the code without having to analyze every definition > completely.

What does `(c)uts` tell you?

I'm not actually familiar with this term.

> This is especially helpful for k operators that can be overloaded by type or > meaning

We know the types of the data when we're tracing the code path.

> Btw, the code above can be written as: d::(#c),|/-':b::0,1+c::a$"\n"

You should let Arthur know.

<comment><USER10> > What does `(c)uts` tell you? Cut points (by \n, in this case) if one were to > use the cut operator _ to tokenize a by leading \n.

It's hint/reminder of the purpose of the definition.

N.B. - This feature (i.e. str$chr) is undocumented in k.txt. I would normally use &a="\n". However, as soon as I saw Arthur's comment, it made sense (and uses less memory).

> We know the types of the data when we're tracing the code path.

My goal is to avoid having to trace the code path and to understand the definition in isolation (or as isolated as possible).

E.g. - you were able to add HOME/END functionality for your Mac without understanding the entire code path.

> d::(#c),|/-':b::0,1+c::a$"\n"

> You should let Arthur know.

Will do. He definitely appreciates concision.

Btw, I'm using k5 for daily use. Are you? If so, we could share notes.

<comment><USER4> > as soon as I saw Arthur's comment, it made sense

Interesting.

I'd like to talk more about this part.

> If so, we could share notes.

Sure. You want to email me your details?

<comment><USER10> Sure thing. What's your email address?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> This was from the conference I organized a couple of weeks ago. The other videos are also available [1].

Sorry about the screen visibility on this, as it was being live coded it was a bit hard to film.

[1] [https://operatingsystems.io/](https://operatingsystems.io/)

<comment><USER11> Next time organize some microphone stands too :)

<comment><USER12> It was honestly difficult not to be distracted by that.

<comment><AUTHOR> Sorry, there was some sort of technical issue with the lectern mike.

</comment></comment></comment></comment><comment><USER13> Feel bad for the guy holding the mic

<comment><AUTHOR> Hi, thats me. Last minute issues when organizing a conference...</comment></comment>