Cello – Higher Level Programming in C - <AUTHOR> http://libcello.org/ <comment><USER2> Author here. I always get asked two questions about libCello.

1\. Why? 2\. Is anyone using it for anything serious?

The second one is easiest to answer: no. And most people are suprised to hear that I probably wouldn't use it for anything serious either.

If you hadn't noticed from my github page I love C, and while I am also very interested in the things Cello adds such as duck typing and interfaces, and all the syntactic sugar that makes thing really nice and literate; it doesn't interest me enough to choose it over C. Additionally who is going to want to use my project if it uses this weird hacky C library! People are (for good reason) very suspect of dependancies.

That isn't to say I don't like programming in Cello. I'm almost definitely the person who has written the most in it and some things are just a joy to write in it, and look so clear and functional and algorithmic. At some point in the distant future when I find the time I really will attempt something serious such as a web framework. If that takes off we seriously can decide if it really is a good project (hur hur hur).

To be fair, "why" can also be pretty easy to answer depending on who is asking: because I could. Because I thought it was kinda cool and that people would be interested. There seems to be some default position in programming that unless your project is silly or sarcastic people assume you are "advocating" something by doing it, or making some kind of political statement on software development. I didn't work on this project to try and change the world. Nor to create something better than the alternatives. It doesn't change my life if people use Cello or not. I wasn't frustrated with C++, and I wasn't looking for a cylindrical rolly thing for my cart. I just made it for fun.

<comment><USER3> > it doesn't interest me enough to choose it over C.

Why? If it's as fast as C but has the benefit of sugar, why not use it?

> People are (for good reason) very suspect of dependancies.

Not web developers. :D Although we should be.

> And most people are suprised to hear that I probably wouldn't use it for > anything serious either.

Again, why not? C performance but easier to read code sounds like a good reason to use it for something serious. What are the downsides?

<comment><USER4> It is not as fast as normally written C due to the dynamic typing.

<comment><USER5> that's not necessary for the API, is it?

<comment><USER4> The API allows 'var's to be treated as dynamically typed, so sure it is. More to the point, if you tried to change it to be statically typed, it wouldn't be expressible in the same nice-looking way in C.

</comment></comment></comment></comment></comment><comment><USER6> Previous discussion: [https://news.ycombinator.com/item?id=6047576](https://news.ycombinator.com/item?id=6047576)

This has tons of sugar; if you're just interested in how this stuff is possible in C it would probably be more instructive to look at the GNU library libffcall[0] which implements trampolines. The code is simpler and there's less syntactic sugar obscuring what's going on. Of course, the linked articles on the Cello home page are instructive too.

I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust or what have you and gain even more benefits, like a mature ecosystem that's highly compatible with the features you're using while I worry Cello, when relying on normal C libraries, might require you to slip back into some C-isms that Cello desires to avoid due to your dependencies not caring.

[0]: [https://www.gnu.org/software/libffcall/](https://www.gnu.org/software/libffcall/)

<comment><USER7> > I've yet to actually use Cello myself since I feel like if you hack C up > that much, you might as well just use something like C++, C#, Rust ....

Since the early 90's I never understood why some programmers insist in using what is basically a portable macro assembler for higher level programming.

It was already primitive when compared with the likes of Modula-2 and Turbo/Apple Pascal, not to mention all the other alternatives even higher level.

<comment><USER8> Wasn't there some issue with Pascal type system being too restricting sometimes (the unfortunate lack of cast) ?

<comment><USER9> It wasn't just the lack of a cast. (IIRC, you could work around that with variant records if you really had to, though it was really clumsy.)

Another, unfixable problem was that the size of an array was part of the type of the array. This meant that you couldn't ever access past the end of an array, which was good. It also meant that you could never have a variable- sized array - you couldn't even talk about the type of such a thing.

This meant that Pascal was completely unusable for writing, say, a memory manager (what type would you give to the return from an allocation)? But that's a low level problem. It also meant that Pascal couldn't be used for a numeric simulation where the size of your grid was a user-supplied runtime value.

Note that I am only talking about the original (Wirth/UCSD) Pascal. I believe that Turbo Pascal fixed the variable-sized array problem.

<comment><USER7> Those problems were not part of the Pascal dialects.

The largely ignored Extended Pascal ISO standard also had those issues fixed.

The first Mac OS versions were written in Apple Pascal.

<comment><USER8> I knew about Apple programs being in Pascal, but the whole OS ? did they resort to inline asm ?

<comment><USER7> Yes, they did use Assembly.

When implementing an OS avoiding Assembly is impossible. Even if intrisics are used instead, they are just another way of using Assembly like instructions.

There are lots of informations in this book, "Revolution in The Valley: The Insanely Great Story of How the Mac Was Made".

<comment><USER10> They used more than some assembly. Andy Hertzfeld:

"But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.

"We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish."

Also, about half the LOC in MacPaint were assembly.

<comment><USER7> Basic, Forth, C and Pascal were the Ruby and Python of the 80's home computers, both in compiler code quality and memory usage.

Of course anything related to graphics programming would be written in pure Assembly code, so excuse me if I misused "Some".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I really love this. Are there convenience functions to convert existing values to and from your new data types?

I would love to use this library but as C programs often requires third-party libraries I could see many instances of having to use normal C types. Is there a way, for example, to easily convert a float to and from a var (with a Real key/value)? How would I use your library to take hash table values and assign them back into standard struct members? Would I just use traditional casting? Something tells me normal casting is not an option, or at least not so easy.

<comment><USER9> Converting a C value to a Cello value is easy.

      int cValue = 5;  // because I randomly feel like that's a good number
      var celloValue = $(Int, cValue);  // I'm pretty sure this works, but I haven't proven it

Coming back from Cello to C, it appears that you can do this:

      long anotherCValue = as_long(celloValue);

</comment></comment><comment><USER12> I see lots of weird comparisons here.

I think the most apt would be a comparison to Vala, which is compiled to C and also adds higher level languages features.

That said, Vala is much heavier, and requires manual writing of interface files to use C libraries.

I can see this being a useful tool if kept lightweight. It's certainly prettier than GObjects!

</comment><comment><USER13> Has the development moved away from github[1] or has it completely stalled ? The last commit I see is from 8 months ago.

[1] [https://github.com/orangeduck/libCello/](https://github.com/orangeduck/libCello/)

</comment><comment><USER14> > To compile Cello requires a C99 compatible C compiler.

In fact, it fails to compile with -std=c99, it seems to require GNU extenstions, that's why they have -std=gnu99 in their Makefile. They use ##__VA_ARGS__, which is not in the C99 and AFAIK there is no portable way to make a workaround.

<comment><USER15> You're completely right, this definitely uses GNU extensions.

A note about the __VA_ARGS__ detail - You can portably avoid it in a lot of cases if you plan ahead and allow __VA_ARGS__ to suck-up one extra always- provided argument, but it's not as clean as the GNU extension and can't always be done.

</comment></comment><comment><USER16> Too high level IMHO... $(Int,5) is not reasonable, also everything is too opaque for it to be a C library. You can go a long way without creating such a layer of abstraction with just a set of libs implementing data structures, dynamic strings, with simple object-alike structures that are reference counted so that it is trivial to have lists of hashes or alike, but where you can also store raw stuff trivially just changing the "method" to free or dup the objects.

EDIT: AFAIK "$" is not valid ANSI-C, however I would love it... For example in a reference counting system could be cool to have $() and _() to incr/decr references.

</comment><comment><USER17> The syntax is rather reminiscent of jQuery... and just like how that has created jQuery developers who know next to no JavaScript, I could envision many Cello developers who know almost no C which given the characteristics of the language would probably be an even bigger problem. It's good that they have a disclaimer saying that this isn't for those who don't already know C.

I think it's more like a framework than a library, based solely on the principle that it basically encourages a completely different syntax and code style that someone else would have to learn in addition to C in order to work with code written using it.

<comment><USER18> I'd say it's more reminiscent of Python, sans the dollar signs.

I feel that calling it a framework is _really_ pushing it. C is such a simple language, and things like the GNU C extensions and the macros the Linux kernel provide offer some similar semantics, particularly when dealing with linear data structures. Not to mention, when dealing with POSIX, your coding style completely changes to fit what it gives you.

<comment><USER19> C is a simple language if you ignore all the traps, pitfalls, gotcha's, corner cases, and exceptions to the rules.

By that measure, maybe Brainfuck is a simple language too. But I wouldn't want to actually program in it when there are so many sane alternatives available.

<comment><USER18> > C is a simple language if you ignore all the traps, pitfalls, gotcha's, > corner cases, and exceptions to the rules.

Yes, and no. If you're sticking with just raw C and the standard libraries, it's a simple language. That doesn't mean your program will be simple, however - security concerns alone ramp up the complexity by orders of magnitude. But at its core, it is a simple language with mostly simple rules.

</comment></comment></comment></comment><comment><USER20> It would be very interesting to pair this with a very well designed minimalistic web framework, drivers for things like Redis, etc., for some _VERY_ high-performance web backends.

</comment><comment><USER21> Let C be C. For the people who don't like C for one reason or another, there are a ton of alternatives available, from x64/x86 targeting languages to manages stacks. Adding these libraries to C might look nice, but if you want to experience the things it brings to the table use a language where it's been borrowed from.

<comment><USER22> I wrote cmacro[0] and magma[1] with the goal of a augmenting C while keeping it C-like.

[0]: [https://github.com/eudoxia0/cmacro](https://github.com/eudoxia0/cmacro) [1]: [https://github.com/eudoxia0/magma](https://github.com/eudoxia0/magma)

<comment><USER23> And I wrote Myrddin[0] for the goal of seeing what C would be if I was reimagining it with the benefit of hindsight.

[0][http://eigenstate.org/myrddin](http://eigenstate.org/myrddin)

</comment></comment></comment><comment><USER24> After seeing this I started work on a simplification of libCello called Viola [0]. It has a slightly lighter syntax and takes away some (IMO) needless typing...

        [0] https://github.com/eatonphil/Viola

</comment><comment><USER25> How are you implementing the dynamic type interface? Discriminated union?

<comment><USER2> It uses raw pointers (void*) and something a little like a vtable: [http://libcello.org/documentation/hacking](http://libcello.org/documentation/hacking)

</comment></comment><comment><USER26> I'd love to know how this compares to GoLang... Conceptually similar, which is faster?

<comment><USER27> I don't know that I would call it conceptually similar to Go. At least, not if we're looking at the Big Pictures concepts, where Go has concurrency as one of its major departures from C. I don't see any mention of concurrency primitives in Cello (maybe they're there and I didn't notice, but I would think the author would have put that on the front page, if it were a thing Cello tried to solve).

Go does provide collections and iterators and such, so Cello is similar on that front. But, every modern language provide those things, and Cello collections don't seem any more Go-like than they seem Python or ObjC like.

Well written C is consistently faster than well-written Go. There are some dynamic runtime elements to Cello that could potentially hurt performance but I doubt it's a major factor.

I think Rust is probably the better modern language to compare Cello to, and I suspect they'll have similar performance. ObjC would also be a reasonable thing to compare.

But, for most things, they're all Fast Enough. Performance is probably not a useful metric. The reason I could see for using this would be modernizing an existing C codebase (though I'd be cautious about relying on something like this until it has a healthy uptake among developers), or when working in environments where only C compilers and libraries are available. If I were starting a new systems project, I would start with Rust or Go (or maybe ObjC if I ever had to work on Mac/iOS).

Mostly though, I think it's just a cool experiment, and educational.

<comment><USER28> Nim, with its Pythonic syntax and native code generation via C, compares as well [1].

[http://goran.krampe.se/2014/10/20/i-missed- nim/](http://goran.krampe.se/2014/10/20/i-missed-nim/)

<comment><USER26> TY!

</comment></comment></comment></comment><comment><USER29> Just use C++11

</comment><comment><USER30> Why does this exist?

(Serious question)

<comment><USER9> Because someone cared enough to make it.

(Serious answer.)

But I think you're really asking a different question than the one your words say. I suspect you're asking why someone should bother to write this. There are several possible reasons. "Just because they felt like it" is a perfectly fine reason. "Because they thought it was interesting" is pretty close to the same reason. "Because they thought the world needed this language" is probably not as good a reason, because it seems somewhat unlikely to be correct.

<comment><USER31> The last part might not be true. Though i won't generalize, let's just say that i have been writing industry code for almost a decade, 90% C (because of domain) and at least a quick review tells me, porting this to a couple of major platforms could be very practical and useful IF IF, it does not sacrifice the performance.

</comment></comment></comment><comment><USER32> > /* Heap objects destroyed with "delete" */

> delete(items);

This part is funny: "Higher Level" but still no garbage collection.

<comment><USER33> Why would higher level necessarily imply garbage collection?</comment></comment>


Polynesian DNA suggests epic voyage to South America 800 years ago - <AUTHOR> https://www.nytimes.com/2020/07/08/science/polynesian-ancestry.html <comment><USER2> It's also possible that Polynesians visited North America. The Chumash people had relatively sophisticated canoes called tomols which have planks that are sewn together, which was a technique unique to them in North America, but has been seen in Polynesian and South American boat construction.

[https://external- content.duckduckgo.com/iu/?u=http%3A%2F%2Fo...](https://external- content.duckduckgo.com/iu/?u=http%3A%2F%2Foil.piratelab.org%2Fwp- content%2Fuploads%2F2015%2F05%2Fsb-07-tomol.jpg&f=1&nofb=1)

[http://www.parks.ca.gov/?page_id=24433](http://www.parks.ca.gov/?page_id=24433)

> Archaeologist Terry Jones of California Polytechnic State University > acknowledges that the Malibu Lagoon Chumash could have encountered > Polynesian master navigators, who gave their tomol building skills to the > Chumash.

> Among North American Indians, only the Chumash, and later the neighboring > Gabrielino, built sewn-plank canoes. In the Western Hemisphere, this > technology is otherwise known only from the coast of Chile and among Pacific > Islanders. The tomols were able to carry large loads for long distances > which could allowed for navigation across the Pacific.

I can't seem to find information on whether there's a confirmed Polynesian genetic connection to the Chumash. Probably unlikely, but I've always found the idea interesting.

<comment><USER3> Some Polynesian canoe(s) drifting shore in California seems the simpler theory.

<comment><USER4> Something slightly related, but mostly of a tangential interest:

[https://en.wikipedia.org/wiki/Tamil_bell](https://en.wikipedia.org/wiki/Tamil_bell)

The Maori population also having descended from the Pacific Island Polynesians.

<comment><USER5> Fascinating trivia: Madagascar was populated by the Polynesians

[https://en.wikipedia.org/wiki/History_of_Madagascar#A_common...](https://en.wikipedia.org/wiki/History_of_Madagascar#A_common_Austronesian_origin:_The_Vahoaka_Ntaolo)

<comment><USER6> No, it was people from Sunda Islands (now Indonesia) who are also austronesians.

</comment></comment></comment></comment></comment><comment><USER7> Highly recommend reading the book Kontiki (or watch the movie) for the incredible story of Thor Heyerdahl demonstrating that sailing on a raft from South America to Polynesia is possible and a theory that now seems even more likely with the current DNA evidence.

[https://en.wikipedia.org/wiki/Kon- Tiki_expedition](https://en.wikipedia.org/wiki/Kon-Tiki_expedition)

<comment><USER8> The DNA evidence suggests the opposite, in fact.

Many lines of evidence, linguistic, genetic, cultural suggest that polynesia was colonized west to east, probably originating in ancient Taiwan.

Heyerdahl pulled of an impressive feat, but his raft was a real dogs breakfast compared to a voyaging canoe or flying proa.

<comment><USER9> Doesn't the DNA evidence now suggest both? The article says that polynesian populations show a DNA connection with the Americas (especially around Columbia) from sometime around 1200. It would seem that the polynesians sailed from West to East until they either hit the American continents or peoples from the American continents came out and met them. Or both.

<comment><USER10> The article also suggests some think it might just be the effect of their most recent common ancestor in Asia somewhere, and not from any kind of transplant.

<comment><USER9> The American continents are kind of hard to miss. After sailing east from tiny island to tiny island, it is kind of hard to believe that they didn't run into the continents at some point while looking for new islands.

<comment><USER10> Maybe, maybe not. Easter island is one of the most isolated islands in the world and is also one of the easternmost islands in the Pacific. It's still a long way to go to get to South America from there. Maybe a few family units arrived and then forgot about boat building and navigation for a few generations because the islands land resources were so plentiful. I think something similar happened to native people on Tasmania - they took a boat to get there, but forgot how to build boats eventually and so were stuck on their island without the ability to go to mainland Australia.

</comment></comment></comment></comment></comment></comment><comment><USER11> This is a super interesting read! In my previous conversations with Prof. Fehren-Schmitz he was highly skeptical of any Pre-Columbian contact based on his findings in [1]. He says the issue is pretty strongly politicized, because there's a modern Polynesian immigrant community in Peru that would "benefit" if admixture is found, while the Polynesians in Polynesia are a lot more skeptical due to nationalist tendencies. I might be getting this backward, not completely sure, but his point was basically that it's super hard to study this specific issue because of the surprising amount of politicization there is surrounding it.

[1] [https://www.cell.com/current- biology/pdfExtended/S0960-9822(...](https://www.cell.com/current- biology/pdfExtended/S0960-9822\(17\)31194-6)

</comment><comment><USER12> There is one thing I don't understand for these epic journeys, whether it's trans Pacific/Atlantic, the Bering straight etc, what was the motivation to risk your life? Unless there was some kind of local conflict why would you risk the move given there was relatively unlimited resources at source destinations at the time comparef to population. What makes the first person decide I'm going to sail past the horizon and everything we know and risk my life, it boggles my mind.

<comment><USER13> Part of the answer I think is that we often underestimate the level of sophistication of people who lived a very long time ago. Polynesians were expert navigators, they had a lot of knowledge of things like wind patterns, currents, birds, the positions of the sun and stars... and knew how to use those to orient themselves at sea. Long voyages were probably dangerous, but they may well have had the means to turn back and return home in case they didn't find land. This article is really interesting:

[https://en.m.wikipedia.org/wiki/Polynesian_navigation](https://en.m.wikipedia.org/wiki/Polynesian_navigation)

Maybe discovering far away lands was to them meaningful for exactly the same reasons that it was later for the European explorers who rediscovered their islands...

<comment><USER14> Having dipped my toe in mnemonic techniques, I think part of why we underestimate people of the past, is we have forgotten just how much the human brain is capable of sans external tech.

<comment><USER15> Yeah, it shocked me the first time I memorized a deck of cards with a memory palace. Plus, imagine how well trained muscle memories became since methods would have hardly changed from generations before.

<comment><USER14> One of the Polynesian navigational methods I have heard described, was laying down in the bow of the canoe and going into a meditative trace, thereby being able to feel the ocean swell, and infer the location of distant islands by the diffraction pattern of waves. [https://manoa.hawaii.edu/exploringourfluidearth/media_colorb...](https://manoa.hawaii.edu/exploringourfluidearth/media_colorbox/2539/media_original/en)

<comment><USER16> I wonder how it was even discovered this works

</comment></comment></comment></comment></comment></comment><comment><USER17> There is some additional physical evidence for this in the form of plants and animals with American origin appearing in the archaeological record in Asia well before 1492. This paper [1] lists around 100 cross-hemispheric species. I'm not an expert on this, but I found the Phaseolus species (lima bean) evidence particularly compelling -- they are species of clear American origin with multiple unambiguous archaeological examples in India from as far back as 1600 BC. It seems hard to explain that without pre-Columbian trans-Pacific contact.

[1] [http://www.sino- platonic.org/complete/spp133_precolumbian_vo...](http://www.sino- platonic.org/complete/spp133_precolumbian_voyages.pdf)

<comment><USER18> The technology to voyage over the south pacific definitely did not exists in 1600 BCE. So trans pacific human contact is an unlikely explanation. More likely these particular species might have migrated them selfs (e.g. by floating) or with non-human animals (like birds) and later picked up while still alive by human farmers in India.

There is also the possibility of more crossings over the Bering straight. Inuits and proto-inuit cultures have crossed the Bering multiple times. I find it dubious that they never crossed westwards. However, the technological niche which the cultures of the far north have mastered over the centuries have less values in warmer climates so I don't think much would have been brought from the Americas to as far south as India via the Bering.

Anything crossing the south Pacific from around 500 AD however can definitely be attributed to human crossings as the Polynesian cultures from that time period for sure had the technology for such voyages.

<comment><USER9> > The technology to voyage over the south pacific definitely did not exists in > 1600 BCE.

How do we know that? Archeological evidence of wooden boats from that long ago in the tropics would probably be hard to come by.

<comment><USER18> You are right, _absence of evidence is not evidence of absence_. However _extraordinary claims, require extraordinary evidence_ , and while there is no evidence of an ocean fairing civilization in the 16th century BCE I will believe the simpler explanation that the reason why American crops were cultivated in India is because seeds were brought by winds, currents, birds or insects, but not humans.

I guess I should have been more careful in may claim that "the technology did not exist", and should have worded it as: "we have no evidence for such technology existing at that time in human history".

</comment></comment></comment></comment><comment><USER19> Anyone interested in Polynesian exploration would enjoy learning about Hōkūle'a: [http://www.hokulea.com/voyages/our- story/](http://www.hokulea.com/voyages/our-story/)

</comment><comment><USER20> So that Norwegian guy[0] who built a raft and floated to Polynesia from Peru was right all along.

Edit: Oh actually it looks like they're claiming the direction of travel went the other way. I can't see the full article, but I wonder how they can distinguish between the two directions.

[0]: [https://en.wikipedia.org/wiki/Thor_Heyerdahl](https://en.wikipedia.org/wiki/Thor_Heyerdahl)

<comment><USER9> It looks like they aren't sure which direction the travel might have gone:

"Our earliest estimated date of contact isad 1150 for Fatu Hiva, South Marquesas. This is close to the date estimated by radiocarbon dating for settlement of that island group13, raising the intriguing possibility that, upon their arrival, Polynesian settlers encountered a small, already established, Native American population. It was on the island of Fatu Hiva—the easternmost island in equatorial Polynesia—that Thor Heyerdahl hypothesized that Native American and Polynesian individuals might have contacted one another, based on islanders' legends stating that their forefathers had come from the east39. The Marquesas lie at the latitude of Ecuador, and wind- and current-based simulations indicate that they are the islands most likely to be reached from South America via the strong east-to-west currents and winds at these equatorial latitudes4,40,41.

We cannot discount an alternative explanation: a group of Polynesian people voyaged to northern South America and returned42 together with some Native American individuals, or with Native American admixture, as speculated in ref. 10. We have dated the contact event to the time when Polynesian explorers were, according to some studies, making their longest-range voyages (the century surrounding ad 1200)—a time when these studies suggest that the Polynesian settlers discovered all remaining island groups in the Pacific, from Hawaii to New Zealand to Rapa Nui13,38,42. The Tuamotu Archipelago, which lies at the centre of the Polynesian islands in which we found a Native American component, is known to have been a Polynesian voyaging hub, and according to simulations it is the second most likely location to be reached when voyaging from South America4. Further population genetics collaborations with these genetically understudied island populations are needed to resolve these alternative hypotheses."

By "single contact event" I think they mean that all the contacts between Polynesia and South America happened around the same time period and stopped thereafter for some reason. So the contact could have been groups going in either (or both) direction around that time period.

<comment><USER21> Perhaps they lost their wayfinder before the knowledge was sufficiently passed on? [0]

[0][https://en.wikipedia.org/wiki/Mau_Piailug](https://en.wikipedia.org/wiki/Mau_Piailug)

<comment><USER22> That's an incredibly interesting link. Thanks for sharing!

Posts and comment threads like these are the reason why HN is so damn good

</comment></comment></comment></comment><comment><USER23> From the paper [1]:

> Here we analyse genome-wide variation in individuals from islands across > Polynesia for signs of Native American admixture, analysing 807 individuals > from 17 island populations and 15 Pacific coast Native American groups. We > find conclusive evidence for prehistoric contact of Polynesian individuals > with Native American individuals (around ad 1200) contemporaneous with the > settlement of remote Oceania. Our analyses suggest strongly that a single > contact event occurred in eastern Polynesia, before the settlement of Rapa > Nui, between Polynesian individuals and a Native American group most closely > related to the indigenous inhabitants of present-day Colombia.

Rapa Nui is Easter Island. No surprises on the genetic front but the navigational path sailed holds intriguing possibilities.

[1] [https://www.nature.com/articles/s41586-020-2487-2](https://www.nature.com/articles/s41586-020-2487-2)

<comment><USER20> Isn't the headline wrong then? If the contact occurred in Polynesia, then the "epic voyage" should be from South America to Polynesia.

<comment><USER9> If you read the article you will see that they aren't sure if there were people going from Polynesia to South America, or from South America to Polynesia. Or it could have been both ways.

</comment></comment></comment><comment><USER24> There's a good book that came out earlier this year about the Polynesian expansion called _Sea People_ by Christina Thompson. I thoroughly enjoyed it.

<comment><USER25> Yes, loved this book too!!

</comment></comment><comment><USER26> I always liked the Zuni/Japan theory.

[https://www.ancientpages.com/2017/12/26/mysterious-zuni- indi...](https://www.ancientpages.com/2017/12/26/mysterious-zuni-indians-and- japanese-people-may-be-related/)

</comment><comment><USER27> When I found out about William Bligh I figured these types of things must certainly been possible for a long time. [https://en.m.wikipedia.org/wiki/William_Bligh](https://en.m.wikipedia.org/wiki/William_Bligh)

</comment><comment><USER28> > One explanation: Polynesians came to South America, and then took South > Americans onto their boats to voyage back out to sea.

Isn't it easier to assume that both groups reached Easter Island independently and reproduced on the island with each other?

<comment><USER29> AFAIK there isn't much (if any) evidence of ocean-going vessels in pre- Colombian South America. So probably not.

<comment><USER9> What evidence would we expect to find? I would imagine any wooden boats from that long ago would have long ago disintegrated by water, tropical jungles, tropical fauna, etc. long ago. Lack of proof isn't proof of non-existence.

<comment><USER29> Oral history, anchor stones, parts or fragments of vessels (carvings from the prow, steering oars, and so on).

In Polynesian culture, an ocean-going vessel was a thing of great mana, having its own name and celebrated in many stories. Relics were revered and carefully preserved.

I don't think Polynesians are unique in this regard.

</comment></comment></comment></comment><comment><USER30> Great book discussing this topic in the context of human exploration: "Beyond the known" by Andrew Rader.

</comment><comment><USER31> There was a thread last week that brought up Graham Hancock.

This is yet another thing that his work speculated some 25 years ago, and I think he did a 4-part BBC documentary that tries to connect parts of the world to a single, ocean-faring civilization due to the construction methods and whatnot used in the archaeological remains we have today.

Of course, he's been dismissed as a crackpot so nevermind that.

<comment><USER32> The people who concluded Polynesians may have reached South America based on their seafaring abilities are somewhat more likely to be vindicated by this than Hancock's writings about pre Ice Age Atlantis, never mind his writings about the pyramids' connections with civilizations on Mars...

</comment></comment><comment><USER33> Kind of OT, but it bothers me that the caption of the lead photo mentions Easter Island, but the lead paragraph references Rapa Nui.

Like... why did you create a pointer to an existing variable with a different name, then use them interchangeably? Or something like that.

</comment><comment><USER34> Fuck no. DNA cannot suggest any fucking voyage, especially in time.

This kind of bullshit is an insult to intelligence and to the very principles of science.

<comment><USER34> Okay, let's state it differently.

The problem with so called peer-reviewed abstract "sciences" is the same as with theology and any sectarian movement - that reviewers are from the same sect and praise effort instead of refuting nonsense.

If you do logical refutation the whole field might collapse easily and leave reviewers out of luractive jobs and high social status. Precisely what happened to priests - from people next to God to merely funny freaks.

Socially constructed bullshit is what we have instead of science. The principles of science including the one that only which cannot be disproved and experimentally refuted is accepted as a operational approximation to the truth, NOT some fucking current social consensus among some sectarian establishment.

And no, DNA is too far removed from high level population processes to even try to establish a meaningful correlation, leave alone a causation.

<comment><USER35> Look, I don't entirely disagree. There are often problems with trying to use genetics to talk about the interactions of historical people. However, historical sciences in general don't work that way. The evidence we have generally underdetermines theories and moreover, it's often still useful to use a theory that isn't universal for a more limited application.</comment></comment></comment>


Write? Write. Sleep? Sleep. Read? Read. Don't fight it. - <AUTHOR> http://sivers.org/dont-fight-it <comment><USER2> This reminded me of a great quote of John Carmack, which says the opposite:

 _Putting creativity on a pedestal can also be an excuse for laziness. There is a lot of cultural belief that creativity comes from inspiration, and can't be rushed. Not true. Inspiration is just your subconscious putting things together, and that can be made into an active process with a little introspection.

Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better._

<comment><USER3> I don't consider Carmack to be an expert on creativity, of all things.

His game ideas can be summarized thusly: DOOM.

The best id game, the original Quake, had both John Romero and American McGee as designers, among others, AND Trent Reznor on sound effects.

Without them, id did... DOOM 3.

What Carmack is really referring to is the gruntwork of things like writing multiple rendering pipelines to support the nightmare hodgepodge of consumer 3D hardware, trying out WELL-KNOWN rendering techniques (invented for film) in games as hardware improves, and so forth, which sometimes is just tedium and sometimes requires hackery like fast stencil shadows/sqrt/bit-twiddling tricks. Trying a bunch of methods to see what works on limited hardware is a process of discovery.

You cannot brute-force creative ideas in general in that manner.

<comment><USER2> He is an expert on creative problem solving. I doubt you are in a position to dispute that. And how long do you think consumer 3D hardware has been mainstream? Carmack's career spans a lot longer than that.

I wonder if you would accuse an artist who spends lots of time exploring dead end ideas of doing grunt work? Would you dismiss an artist as adapting WELL- KNOWN ideas if they allowed you to view someone else's work in a brand new, unexpected light?

</comment></comment></comment><comment><USER4> No.

You have to work, every day, whether you are too tired or not. You must push yourself, every day, and have discipline.

Extraordinary results require extraordinary efforts.

<comment><USER5> Yeah, for some people, the advice in this article will lead to disaster. For example, I would rather be reading than doing, all the time. Reading is pure candy for me, instant gratification. To become (reasonably) successful, I had to stop reading.

<comment><USER6> I recall a study where researchers wanted to see how "natural" work was. They took a class of young children and told them they can do whatever they want. So the first day they all ran around outside and had fun. I think by the third day they were all begging to have class again and have some work to do.

<comment><USER5> That reminds me of a portion of a letter Ben Franklin wrote to Peter Collinson:

"The proneness of human Nature to a life of ease, of freedom from care and labour appear strongly in the heretofore little success that has attended every attempt to civilize our American Indians. . . . They visit us frequently and see the advantages that Arts, Science and compact Society procure us; they are not deficient in natural understanding and yet they have never strewn any inclination to change their manner of life for ours, or to learn any of our Arts.

"When an Indian child has been brought up among us, taught our language and habituated to our customs, yet if he goes to see his relations and makes one Indian Ramble with them, there is no perswading him ever to return. And that this is not natural [only to Indians], but as men, is plain from this, that when white persons of either sex have been taken prisoners young by the Indians, and lived awhile among them, tho' ransomed by their Friends, and treated with all imaginable tenderness to prevail with them to stay among the English, yet within a Short time they become disgusted with our manner of Life, and the care and pains that are necessary to support it, and take the first good Opportunity of escaping again into the Woods, from whence there is no reclaiming them."

<comment><USER7> Is there a published collection of letters you're quoting from? I'd love to read it - what book is this from?

<comment><USER5> I originally read a reference to it in Huck's Raft: A History of American Childhood. Actually, looking it up again made me interested to know if a collection of Franklin's letters has been released in a mainstream volume, too. His Autobiography was awesome.

</comment></comment></comment></comment></comment></comment><comment><USER8> This isn't good advice. It's self-gratification.

You have work to do. Do it.

Sitting at the terminal, but not sure what to type? Turn off the terminal, grab your source listings, scratch pad, and red and black pens and go to the other room. Or the library, Or starbucks. Work the problem that way and soon enough, you'll be dying to get back to the terminal.

Sitting on the sofa and analyzing that function with pencil and paper until you've worked yourself into a logic freeze? Get up and turn on your computer and code the simplest case. Before you're done, you'll find some enlightenment.

Have trouble doing either? Review old code, examine apps written by others, refactor something (you always have _something_ to refactor, right?).

But do what you feel like? No.

<comment><USER9> _"You have work to do. Do it."_

Oh, come on. Says who? You only "have work to do" to the extent that you need to survive. Beyond that, it's optional. It's equally bad advice to suggest people should force themselves to work when they don't want to, simply because they "have work to do."

The only insightful comment you can make here is that one-size advice doesn't fit everyone. Some people are workaholics, and should try harder to take breaks. Others are complete daydreamers, and maybe need more discipline. There's no one right recipe. The world is not binary.

</comment></comment><comment><USER10> A Zen student once asked his teacher, "Master, what is enlightenment?"

The master replied, "When hungry, eat. When tired, sleep."

<comment><USER11> Counterpoint:

"Before enlightenment, chop wood, carry water. After enlightenment, chop wood, carry water."

There are plenty of things you just have to _do_ if you want them to get done, enlightened being or not.

<comment><USER12> Countercounterpoint:

"There are two ways to wash the dishes. You can wash the dishes so the dishes or clean. You can also wash the dishes to watch the dishes."

The moral I got from your koan when I first read it is what the difference is not in reality, but in the mind. That _doesn't_ mean working when you don't feel like working. It means feel like working, or don't work.

</comment></comment></comment><comment><USER13> I lived (and sorta still do live) by this advice. It's good, if you have the lifestyle and means to support it, _except_ for the sleep advice:

 _But if you're tired, don't fight it. Sleep._

This worked out to be an absolute disaster for me (if you take it to its logical conclusion, if you're not tired, don't go to sleep, etc). I ended up free wheeling around the clock, sometimes getting up at 7pm, sometimes 2am, sometimes 11am.. it was nuts. And that sort of sleep pattern really messes with your head after a while.

<comment><USER14> This works fine for me, but my body has this habit of waking up when the sun is up -- even if I've only gone to sleep a few hours ago. That also isn't a problem in itself, as I will fall asleep around 16:00 on those days and catch up whatever I missed the previous night, and still be tired enough in the evening to go to bed at a normal hour.

It's a sort of built-in automatic circadian rhythm reset mechanism which kicks in after just one late night coding session.

</comment></comment><comment><USER15> I have a feeling most people here saying it's a bad advice, didn't get it in the first place. I think the key is that you got to give yourself a little freedom in the short distance, but be disciplined in the long run. For example, I think I'm going to get some sleep now and work in the morning, not tonight. But I'm still going to do the job. The only difference is: I'd be more productive.

It's like (a + b) is still the same thing as (b + a). But because 'a' is the first letter of the alphabet (for most of us) it's more natural to put it first.

And another short thought that I think is relevant: discipline is not about forcing yourself to work when you don't want to, but it's about managing the time and finding the best spots for your work to be done. Of course, self- employment is best for this.

</comment><comment><USER16> This completely abstracts the mind from the concept of self-control, and that's a logical fallacy. Conscious executive decision making originates in the mind as well. The reason you go do something is because you made the choice to do it. Period. Sure, we do things we don't 'want' to do in a narrow sense, but in the broader sense when we choose to do an unpleasant task we have decided, based on outside forces that this task is what we need/want to do.

This isn't to say that there is no merit in working with your mind and being productive when your mind is ready, but the notion that you must not bring willpower to bear on any task is taking things a bit too far.

</comment><comment><USER17> I like the sentiment but this does not really work for us "normal" (non-self- employed) folk. If I sleep/work/eat/learn whenever I feel like it then something will surely suffer.

<comment><USER12> That's why the idea is to get your life to a place where other people don't control you.

<comment><USER18> Or work at Gap. [http://www.businessweek.com/careers/managementiq/archives/20...](http://www.businessweek.com/careers/managementiq/archives/2009/09/gap_to_employee.html)</comment></comment></comment>


What's a good JS logging solution? - <AUTHOR>

Loggly is super slow. Airbrake's js client appears to be second-class at best. Nothing else I've found seems, well, great.<p>Needs:<p>* Log arbitrary events, not just caught exceptions.<p>* Support down to IE8.<p>* Decent reporting and aggregation interface.<p>* Some kind of sensible de-duping.<p>* Bonus: API to query my data. <comment><USER2> I saw this.

[http://www.sideprojectors.com/project/project/74](http://www.sideprojectors.com/project/project/74)

Not sure if it helps.</comment>


Richard Hendricks' new startup already exists - <AUTHOR> https://officehours.io/streams/post/aGKrXba6ZjnYFbq8f <comment><USER2> All I see is a purple blank page.

<comment><AUTHOR> That's strange. I'm looking at it in a number of browsers, and it's visible in all of those. What browser are you viewing in?</comment></comment>


NovaStelo: Block-style programming for multi-agent systems, based on MIT Scratch - <AUTHOR> https://github.com/EiichiroIto/NovaStelo <comment><USER2> Scratch is rad. It's so productive. Modeling threads as sprites — a physical version of actors with <touch> being the most common _message passing_ — is such a liberating / accelerating idea.

It's also a bit too easy to get, ahem, emergent properties in Scratch, but that's fine for one off playful hacking. Pong bats that accelerate balls etc.

</comment><comment><USER3> I have read "multi-agent system" or "agent based programming" a few times, but I have not yet understood what is meant by it.

<comment><USER4> This is a great explanation as to why modeling the behaviours of each "agent" (a citizen in this case) is more realistic than attempting to model the system (a city) as a whole.

[https://theconversation.com/how-big-data-and-the-sims-are- he...](https://theconversation.com/how-big-data-and-the-sims-are-helping-us- to-build-the-cities-of-the-future-47292)

<comment><USER5> That article provides excellent context. Thanks for sharing.

The featured simulation is by Nick Malleson. His website is full of excellent (and relavent) resources.

[http://www.nickmalleson.co.uk/](http://www.nickmalleson.co.uk/)

</comment></comment></comment><comment><USER5> This gives me an excuse to play around with Pharro (Smalltalk).

The author also created a block-style programming environment for tackling graph structure and graph coloring algorithm (for Pharro).

[https://github.com/EiichiroIto/Gratch](https://github.com/EiichiroIto/Gratch)

</comment><comment><USER6> Could someone familiar with how those systems are made explain how time and ordering of events work in these?</comment>


Cummins beats Tesla to the punch by revealing electric semi truck - <AUTHOR> https://www.cnet.com/roadshow/news/cummins-beats-tesla-punch-revealing-aeon-electric-semi-truck/ <comment><USER2> Interesting. There article says that it would be a Class 7 semi but Wikipedia [1] puts it as a Class 8 based on the weight limit given.

I can imagine that this could catch on in the construction industry to pull waste/concrete from job sites. There is downtime between hauls so that you could re-charge and you aren't necessarily driving very far so you may get multiple trips between charges.

[1] [https://en.wikipedia.org/wiki/Truck_classification#Table_of_...](https://en.wikipedia.org/wiki/Truck_classification#Table_of_US_GVWR_classifications)

</comment><comment><USER3> Cool stuff, but as with anything electric; battery range and charge time are always going to be the holdouts. Especially for trucks; who commonly go 400-800 miles a day. And time is money: if they can't recharge completely in the time it takes for a normal break they're not going to want to do it.

The article mentions short hauls and local freight, but even so, 100 miles is pretty limiting to those figures, even with a single-operator day-cab setup.

Torque-wise, electric makes a ton of sense, even if it's a hybrid.

</comment><comment><USER4> > Cummins does not plan to assemble the trucks, but instead views itself as a > supplier of the battery and driveline system.

<comment><USER3> This isn't a big deal. There's a whole industry devoted to making cabs for rolling chassis, they're called Glider Kits[1].

This is smart on Cummin's part, since they own most of the drivetrain anyway.

[1] [https://www.fitzgeraldgliderkits.com/what-is-a-glider- kit/](https://www.fitzgeraldgliderkits.com/what-is-a-glider-kit/) (This is a particular manufacturer, but many companies offer these cabs)</comment></comment>


South Side man pleads guilty in 2011 cyberattacks - <AUTHOR> http://www.chicagotribune.com/business/breaking/chi-chicago-hacker-hammond-20130528,0,4150726.story

<comment><AUTHOR> During the NATO protests. Black helicopters and all.</comment>


Ask HN: What should I do with an opportunity for a free grad school education? - <AUTHOR>

Due to my father's new job, I've just been given a tremendous opportunity: a free 2-year grad school education anywhere in the world (assuming I'm accepted).
I'd love your advice about how to make the most of this opportunity.
Some background: I did an undergraduate degree in psychology. I've since done 2 startups, selling one of them. I'm currently 5 months into a new startup that I've co-founded. I'm non-technical. I have strong leadership, management, people, and strategic skills.
I've never considered doing a graduate degree due to the cost, but now with this opportunity feel compelled to give it serious consideration.
Should I do an MBA and improve my strengths or do something that rounds out my skillset, perhaps by improving my technical ability?
Capitalizing on this opportunity would require starting graduate school in 2015. It's too early to say whether I'll leave my current startup for grad school. It is, however, important that I maximize my available options and at least apply.
Note: I'm a frequent contributor to this community, but have created a new account to keep my identity anonymous (I have yet to tell my co-founder of this). <comment><USER2> It is not free because you will be investing your time. In fact, the time you will be investing into graduate school is probably worth a lot more than the monetary cost of that education. There is always an opportunity cost. You could spend the two years continue working on your startup, and possibly get a much larger payout than a graduate education will yield over your lifetime.

A question you should ask yourself is: What do you want to do with your life, and how will graduate school help you with that? It seems like your goal is to do a startup. If that's the case then you probably won't benefit much from a graduate education, be it a business or technical degree.

The main resource you get out of graduate school that is directly applicable to startups are connections. Potential co-founders, advisors and early employees. The "quality" of these connections is directly related to which school you will attend. In other words, attending a top-tier school may be well worth it due the connections you will make there, even if the actual educational content will turn out to be useless (which is most likely the case for startups).

The other way to look at it is that graduate school can give you a nice break from professional life. It certainly can be a fun time.

PS: I was in a similar position. I applied to graduate school without knowing whether or not I actually wanted to go. I ended up going because it was "free" (I was paid to do research) and dropped out after a year because I felt like I was not getting enough value in return for all the time I was spending.

<comment><AUTHOR> Thanks for your comments.

>The other way to look at it is that graduate school can give you a nice break from professional life. It certainly can be a fun time.

I agree that there is still a cost to attending, but the above really resonated with me. I feel that I am wanting a bit of a break from professional life, an opportunity to freely explore new ideas without having defined milestones and roadmaps.

This opportunity has caused me to think more about what my long-term goals are. Right now, I'm not sure, but I look forward to exploring.

As I write this, perhaps I use the grad school opportunity as a vehicle for finding this out?

Thanks for your advice. It's much appreciated.

</comment></comment><comment><USER3> It sounds like you are already doing what you want to be doing (startups). Also, your skills are "soft skills" and you already have them and clearly can use them in a practical setting.

I'm not sure what you'd gain from grad school, except connections if you attend, e.g., Stanford business school. I doubt an MBA would improve your technical ability. Is it a dream of yours to go? Is your current startup making money? How invested are you in the current startup?

YMMV: I went to grad school for a technical degree and enjoyed it, but I wasn't doing anything majorly compelling beforehand. My one regret is that I didn't start a startup with all the time I had while at grad school. I'm correcting that error now, but it's a significant disruption of my life.

<comment><AUTHOR> >Is it a dream of yours to go? Is your current startup making money? How invested are you in the current startup?

No, an MBA is not a dream of mine, although I suspect that I would really enjoy it. My current startup is not making money, but I am very committed to it.

</comment></comment><comment><USER4> Bah to the MBA (unless you get it from Stanford or MIT). I would focus in more on the Psych angle, perhaps going for HCI, Anthropology (with fieldwork in the 'first world', like Gabriella Coleman did: [http://codingfreedom.com/](http://codingfreedom.com/)), or something similar. Or you could branch out a bit to Behavioral Economics.

Almost __NOTHING __will increase your future chances of success at creating new companies more than better understanding users, their needs, and how they make decisions.

That would be two years very well spent.

<comment><AUTHOR> thanks for the link and the suggestion!

</comment></comment><comment><USER5> > how to make the most of this opportunity.

An MBA is a smart play for your background. Choose a program known for it's strong alumni network and entrepreneurial faculty. Ultimately, the relationships and connections you'll forge will prove a huge asset for future endeavors.

Relative to your start-up, you may be able to still add value in a part-time capacity or reduced role. Assuming you trust your co-founders, be straight with them on your thoughts. They may already gut sense your commitment level has changed.

<comment><AUTHOR> Thanks for your suggestion. I hadn't considered staying in a part-time capacity a possibility</comment></comment>


Ask HN: How to deal with inexperienced/unqualified technical lead? - <AUTHOR> I have recently joined a small startup with a fairly small engineering team. Most of the company is non-engineers, and the engineering team is responsible for the internal tools and external tools.
The current engineering lead is unqualified and inexperienced. There have been numerous technical arguments where it is all of the other engineers against the lead, which go nowhere. There have also been times where the lead has told me to do something which is wrong, and I have to explain why it makes no sense to do things in that way and what the proper way would be to do it (which the lead eventually agrees with, usually). The code the lead has written is also atrocious, and if I didn't know better I would say it is actively malicious (in terms of nobody else is able to maintain it). The lead was the first engineer, which is the only reason I think they were promoted.
Being the first engineer is challenging and tech-debt will accumulate. However, the non-technical side of the company is very frustrated with how often everything breaks and I think they believe engineers are just bad at their jobs. It is really disheartening to have to explain that it shouldn't be like this, and that I am trying to fix things but the codebase is not in a great condition and the lead has no interest in making it better. Non-technical folks have talked to me about just doing a rewrite, since there really isn't much code, but the lead will not even consider the idea.
I really like the company as a whole and I agree with the mission. The founder is non-technical, and I think they do not know what poor engineering looks like, which is why this has continued to go on. I really want to just tell the founder "Hey, your engineering lead is awful, you really need to find someone new."
What should I do in my situation? I am currently planning on leaving, and telling the founder then. Is there another path I can take that isn't incredibly frustrating and would allow me to stay? <comment><USER2> I see only one good solution:

The dev lead was the first technical person, so he knows the history and understands the business needs best.

So convince the founders that he should become the product manager (work on deciding features), but stop coding. Not get involved in the how (technical decisions), but only the why (what to build).

<comment><USER3> This is something I can agree with. I worked with someone like OP describes but with the added side effect that he had management's ear by complaining about every developer without their knowledge. I left and have no regrets, but I agree that sometimes people could bring value by being involved in non- technical product decisions

</comment></comment><comment><USER4> You want to get the guy out of there, and you don't want to appear petty, jealous, or malicious. The solution's simple: help him get a better job. That way your motives are pure.

Internally, tell the founders he needs to be promoted to a more managerial role. It's a bizarre request, but I think if they hear it from the whole team, they'll take the hint. You're not calling for him to be fired, so when he gets wind of it, he'll thank you for it.

Externally, reach out to a few recruiters you know. Talk up his credentials, estimate how much he's making, and try to get a recruiter to entice him into leaving (for a higher-paying job). You can even cloak it in an entrepreneurial desire to get the kickback for a referral in case he suspects something.

Honey, not vinegar.

</comment><comment><USER5> That's a tough one. I think you're probably doing the right thing by leaving, but I think more good could come from sharing your grievances with the engineering lead when you leave rather than the founder. If he has gone from being an engineer to managing with no prior experience, it could be he is struggling with learning how to properly manage a team.

Basically what I'm getting at is give the guy a chance before you go scorched- earth and try to ruin him. From what you've said it seems like he is willing to listen, and you gain nothing if you're severing your relationship with the company anyways.

</comment><comment><USER6> We had such a tech lead. He had never designed a system until this one. He used the very latest techniques and technologies. He estimated the contract and recommended a fixed cost 5 month contract with 5 people. The project was terminated after 18 months with 10 people full time. All 27 developers from the company were fired and within a year the company went under.

<comment> UK-Al05 If a company can go bust just because a lead developer gave a bad estimate(not uncommon) there is something else deeply wrong at that company.

</comment></comment><comment><USER7> You like the company, and would want the tools get better. I bet the lead can vouch the same. But the tools break too often.

Track it! And make it visible to everyone both devs and non-devs. Especially non-devs, as they are likely the users to face the problem.

I would propose/demo an issue tracking system, that would quantify the failures, and the amount of time it takes to resolve. It's on the 'best practices' list and is familiar to all, your lead may indeed agree.

It's a team effort, eventually the team would come to realize how to proceed - rewrite or not, reshuffle the lead or something else.

Make it visible for everyone, then your're not alone. BTW, management loves when things are tracked, as it makes their blame job easier, but it is a good team tool too.

</comment><comment><USER8> Usually it is good to have second side of story. We can not, so, let me be the devil's advocate.

>There have been numerous technical arguments where it is all of the other engineers against the lead, which go nowhere.

If you can not convince lead, may be it is not her fault?

>The code the lead has written is also atrocious

It is hard to agree on quality of code between several programmers. It is easy to agree on quality of OTHER guy's code.

Two biases in-place here:

\- You work only on problem code, not well-functioning one

\- [https://en.wikipedia.org/wiki/Fundamental_attribution_error](https://en.wikipedia.org/wiki/Fundamental_attribution_error)

>, and if I didn't know better I would say it is actively malicious (in terms of nobody else is able to maintain it).

Skill you lack - handling problem code

>However, the non-technical side of the company is very frustrated with how often everything breaks

This is a real problem, here I can not indulge her

>I am trying to fix things but the codebase is not in a great condition and the lead has no interest in making it better.

No interest or no resources?

> Non-technical folks have talked to me about just doing a rewrite, since > there really isn't much code, but the lead will not even consider the idea.

Joel calls it "single worst strategic mistake" in [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

Code amount is not a good characteristic of system complexity. May be buisness people underestimate amout of effort required.

(Edit):Fixed EOLs

</comment><comment><USER9> Honesty will bring a resolution. Maybe not the one you want, but it will get you somewhere. If you sit down and tell your lead what you feel is going on... and make it a polite, constructive conversation, not just saying, "You suck.", then you will quickly figure out if he is willing to adapt or not. Maybe he doesn't realize what is going on because nobody has actually talked to him about it. Maybe he does know, but has low self-esteem and will want you to leave for daring to challenge him. Maybe it will be somewhere in the middle.

But most of the time, in such scenarios, you can figure out a path forward. And whether that path results in you staying or leaving, at least it will be done with honesty, transparency, and mutual respect.

</comment><comment><USER10> I was doing consulting work for a small startup that had senior-level "architect" that was responsible for designing the software.

He was producing a lot of tech debt. Instead of automating things he introduced a lot of processes that required manual work. Pretty stubborn person in general, and was adding a bunch of code that was sub-optimal and hard to read.

I quit that gig after 7 months, not worth it when people like that lead the development of the product. Eventually, that product will either have to be rewritten or the it will (along with the company) fail to deliver. Tech debt is dangerous, it can destroy the business if not handled.

</comment><comment><USER11> I think you have two good options here. The first is for the whole engineering team to present a united front to the team lead in a meeting and make the case for what the technical approach should be moving forward so that the team can help ensure the success of the company (aka your livelihoods). The second is to tell the founder that the team lead needs to be moved out of an engineering lead role and either into product management or into a non-lead engineering role for the sake of the company (aka the founder's reputation).

</comment><comment><USER12> As engineers, we have lots of options when it comes to work. When faced with a situation, you need to consider if this is a hill worth dying on. I've only faced a situation like this once in 30 years. I tried to explain it to the manager that the new guy didn't know his stuff without throwing him under the bus but it was too late. (The new guy had snowed management.) I had to drop the client. Life it too short to deal with bad situations if you have other options.

</comment><comment><USER13> Yea you are right. quitting is the only option here.</comment>


Social Javascript (cross-site ajax) - <AUTHOR> http://www.hunlock.com/blogs/Social_Javascript_(cross-site_ajax)

<comment><USER2> it's a nice article, but nothing new. lots of bookmarklets work this way (p.e. the official posterous bookmarklet).</comment>


An overnight increase approximately one megawatt - <AUTHOR>

I just received this e-mail from Hetzner, sent to all their datacenter clients.<p>"During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt.<p>The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers." <comment><USER2> My server seemed OK, but I did a 'shutdown -r now' anyway.</comment>


Heat-Loving Microbes, Once Dormant, Thrive over Decades-Old Fire - <AUTHOR> https://www.quantamagazine.org/heat-loving-microbes-once-dormant-thrive-over-decades-old-fire-20190416/ <comment><USER2> Just from the headline I knew this was gonna be about Centralia PA. Hooray! What do I win?

<comment><USER3> A Vice News subscription.

<comment><USER4> Hah! I get the reference. What do I win?

[https://youtu.be/rcKxS2rbEdg](https://youtu.be/rcKxS2rbEdg)

</comment></comment></comment><comment><USER5> I wonder how far down this diversity goes. Perhaps the outer few km of the entire planet. That'd be very hard to kill off.

</comment><comment><USER6> Is there a prose-free science version? What is the information content of the article?

<comment><USER7> It's actually pretty good reporting. I'd give it a full read.

There's enough details dropped about experiment durations, species counts, and references to the techniques used to measure that if you've already got a background in the field, you can infer quite a lot; and if you don't, you can skip those details.

What good reporting should be, in other words: a summary valid for a wide audience.</comment></comment>


Ask HN: Is a roommate finding platform for leasing a good idea? - <AUTHOR> I am thinking about creating a platform that helps people find roommates in order to rent a place together and I would like to know some opinions from the HN community regarding the business model and features.
1. Do you think there is room for another player? There are a lot of platforms out there, some better than others, tho I still find it curious how some people still rely heavily on craigslist/reddit for this. 2. What are the main features that would convince you to use something like this if ever? 3. What is the business model that would attract you? Would you pay more for freemium, or a subscription-based model?
Thanks! <comment><USER2> Is it a good idea? Yes. But the value of a roommate finding platform isn't the platform it's the amount of people who use it.

That's why most people use traditional social media. A few shares on Facebook and you've reached thousands of local people.

So for a business idea, your focus should be on adoption. I mean, any web developer can build a roommate finding website in a few weeks.

</comment><comment><USER3> I'd start with looking at a sub-segment that you can reach within the larger roommate seeking group of people you plan to target.

Say people moving for work for example. I'd first pick an area that is fertile with people moving for work and seeking roommates. I'd then pitch this platform to as many work places that I possibly can. Give out stickers/pamphlets/freebies and ask them to be handed to new/potential employees or at least get them to recommended you to to such folks.

Next, I'd reach out to popular communities that are roommate friendly and do the same to try to get them to recommend your platform to folks seeking roommates.

Next, keep track of every lead, every post on CL/Reddit/Fb in that area of focus to gain some sort of edge or insight into your customers needs.

That should provide enough data to plan next steps.</comment>


The engineer who fixed his own heart - <AUTHOR> http://www.bbc.co.uk/news/health-24524027 <comment><USER2> Aorta wrapping was actually pioneered in the 1950's, before the graft replacements that the article mentions, but generally the wrapping had a poor result and was abandonded as a technique. (see [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1802172/pdf/anns...](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1802172/pdf/annsurg01428-0088.pdf))

Generally the trend in vascular surgery these days is to less invasive procedures such as a stent graft.

<comment><USER3> And I think the journal article about this particular process is from 2009 ( [http://icvts.oxfordjournals.org/content/10/3/360.short](http://icvts.oxfordjournals.org/content/10/3/360.short) ).

So, hey, points to the BBC for writing an article about something that continues to be interesting instead of something that's "brand new".

<comment><USER2> I find it fascinating that such an old procedure has been revisited sucessfully (not completely unheard of in medicine either). Perhaps better materials (now a polymer mesh) than used previously (cellophane wrap!).

</comment></comment></comment><comment><USER4> Marfan syndrome makes you tall and lanky, so they actually have to watch for it carefully in highschool basketball teams. The build it gives them makes them a natural at the sport, but the stress of the game combined with the heart weakness caused by Marfan Syndrome can be lethal.

I suspect a lot of kids who lost their basketball dreams in a heart-attack will be lining up for this procedure.

<comment><USER5> My favourite artist has Marfan Syndrome, Bradford Cox of Deerhunter: [http://www.miscmusic.net/wp- content/uploads/2011/09/138.jpg](http://www.miscmusic.net/wp- content/uploads/2011/09/138.jpg)

</comment></comment><comment><USER6> Tal provided one of my favourite Ted talks on this subject: [http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_o...](http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_own_heart.html)

</comment><comment><USER7> For the ones wondering how the device looks like: [http://i.dailymail.co.uk/i/pix/2010/01/16/article-1243723-07...](http://i.dailymail.co.uk/i/pix/2010/01/16/article-1243723-07E18AED000005DC-926_468x446.jpg)

<comment><USER8> Does the wrapping material dissolve after a while or last for the rest of one's life?

<comment><USER9> If it dissolved, it would be pointless to have it put in.

</comment></comment></comment><comment><USER10> To the OP: thanks for posting this. You may have just changed a life very much for the better (not mine, but someone I know quite well).

</comment><comment><USER11> We need more collaboration between engineers and the field of medicine. I found the comments about the development process and his doctors' opinions of different approaches coming from outside the medical community almost as insightful and interesting as the invention itself.

</comment><comment><USER12> Sweet, finally a Hacker News post that features an actual engineer!

</comment><comment><USER13> I wish they went more into detail about the devise itself. I was hoping to see a picture.

<comment><USER11> IIRC he holds up an example / prototype during his TED talk. HN user renang found this diagram: [http://i.dailymail.co.uk/i/pix/2010/01/16/article-1243723-07...](http://i.dailymail.co.uk/i/pix/2010/01/16/article-1243723-07E18AED000005DC-926_468x446.jpg)

</comment></comment><comment><USER14> I don't have Marfan's, but I did suffer a ascending aortic dissection in aug 2009. It was repaired with a Dacron stint. (Basically about 3" of my aorta is now artificial.)

This sounds like a great thing.

</comment><comment><USER15> I have some personal experience with the related problem. At age 60 a gradually increasing "murmur" led to a diagnosis of Aortic Ectasia[0], a stretching of the ring of muscle that is the base for the aortic valve. As the valve widens, the three leaflets overlap less and the valve doesn't seal properly, making the heart less efficient. In addition my ascending aorta, the big arched tube that is the subject of the above article, was stretching in the manner described. These effects can be the result of Marfan Syndrome[1] but I don't have any of the other signs of it, such as long, spidery fingers and toes (fold your thumb across your palm: if the tip of the thumb projects beyond the outside of your palm, you should read up on Marfan).

The "garden-hose wrap" method described in this article was not mentioned to me, probably because it would have no use on the more important failure, the stretched valve.

However, I was given a clear choice of replacement valve: metal or tissue. Tal Golesworthy presumably would have had the same choice, but the article doesn't mention that there is a choice.

The metal (actually metal frame with a carbon-fiber flap) replacement valve lasts pretty much forever. On the minus side, it sometimes has a harmless, but audible "tick" noise, but its main drawback is that it can be a source of blood clots, hence the need for the lifelong course of blood thinner. Miss a few days and you could have a stroke from a clot.

I opted for the tissue valve, which is taken from a pig (or a cow, if you object to pork products). All its cells removed, leaving only the collagen form, so there's no host-graft immune reaction. It's silent, it doesn't encourage clot formation -- but it doesn't last forever. At some point in the next decade I'll need another one.

The new valve and about 7 inches of new Dacron aortic arch were sewed in. The surgeon commented afterward that my removed aorta "felt very soft" and was "poor quality tissue" and that I was "fortunate" that it hadn't failed.

This leads me to wonder: a common failure mode of the aorta is Aortic Dissection[2] in which the tube delaminates. Rather than bursting, the lining separates from the supporting wall, and high-pressure blood gets between the layers and spreads them, reducing the cross-section of the pipe. (It's reputed to be one of the most painful experiences possible.) My wonder is: while the "hose-wrap" fix described in this article might prevent ruptures, would it be an effective preventative for aortic dissection?

[0][http://en.wikipedia.org/wiki/Annuloaortic_ectasia](http://en.wikipedia.org/wiki/Annuloaortic_ectasia) [1][http://en.wikipedia.org/wiki/Marfan_syndrome](http://en.wikipedia.org/wiki/Marfan_syndrome) [2][http://en.wikipedia.org/wiki/Aortic_dissection](http://en.wikipedia.org/wiki/Aortic_dissection)

<comment><USER14> In a word, No. It wouldnt fix the false lumen.

This is me:

[http://aorticdissection.com/2011/12/06/jim- thompson-47/](http://aorticdissection.com/2011/12/06/jim-thompson-47/)

<comment><USER16> If it has already dissected it's obviously too late. The parent comment asked if it would prevent dissection in those aneurysms that haven't yet dissected which is probably a more complicated question. It would probably depend on the elasticity of the vessel since we don't see dissection exclusively on absurdly dilated aortas. At the very least we can guess that it would help to extend the life of the native artery. Of course only long term monitoring of these patients will give us a somewhat conclusive answer.

<comment><USER14> It's not always the aneurysm that causes the dissection. Sometimes the dissection causes the aneurysm. The theory is that a plaque tears a he in the surface of the aorta.

</comment></comment></comment></comment><comment><USER17> i'm wondering whether the fact that it is in UK is important, ie. wrt. who paid for the [experimental] surgery. As we all know, while coming up with idea is great, an actual implementation faces the issues of resources/money.

<comment><USER18> UK or not is probably not too important. The surgeon mentioned (Tom Treasure) is at University College London (his surgery is likely based at Guy's Hospital, as mentioned in the OP). This was most likely the beneficiary of a grant for medical innovations, funded by either the NHS or one of the non- profits such as the Wellcome Trust or the British Heart Foundation.

[1] [http://www.ucl.ac.uk/operational- research/the_team/TomTreasu...](http://www.ucl.ac.uk/operational- research/the_team/TomTreasure)

</comment></comment><comment><USER19> Hasn't Tony Stark already done this?

</comment><comment><USER20> Great title.

</comment><comment><USER21> am i the only one who was expecting a Tony Stark photo ?

<comment><USER22> I don't know why you were marked down for this. Not marked up maybe but I was going to say the same thing!

</comment></comment><comment><USER23> Sounds incredibly obvious.

<comment><USER11> Apparently the basic technique was examined in the '50s: [https://news.ycombinator.com/item?id=6770227](https://news.ycombinator.com/item?id=6770227)

However, IIRC, Tal's version is based on one that is custom-built to fit the patient, and of course uses more advanced materials.</comment></comment>


Ask HN: What is your workdesk setup at company? Dedicated Desktop/Laptop/? or - <AUTHOR> Hi, I would like to know the office/workspace hardware and s/w configuration of different companies.<p>- In past I worked in small IT company, we had a single network with not much restriction, we were allowed to experiment with setup. For hardware, we had three desktops, two Laptotps, an iMac 21", A Mackbook Pro 18". Typical desktop was i5 processor, 8-16Gigs Ram, 1TB HDD and a mediocre graphic card. One developer liked to use  desktop with multiple screen setup. We also had three different genration iPhones, an iPad and five android phones as testing devices.<p>One desktop was setup as server,every developer had his own work directory on that. One could login from any PC and work. For version controlling we had at SVN first, later migrated to git and github private repo.<p>-Current Setup, Currently I have a desktop pc with almost same config as above with extra ram and added SSD. <comment><USER2> Last company I worked at (~500 employees), almost 4 years ago, I was handed a desktop computer with the current top of the line i7, 32 gigs of RAM, 512 GB SSD and an HDD. No dedicated GPU but didn't do any GPU work so it didn't matter. A single QHD 32" monitor was provided. You could potentially request a second one, but in practice no one in my team asked for a second one.

Right now, at the smaller startup I'm working for, I'm using a Dell XPS 13. What was at the time the top CPU configuration but only 16 gigs of RAM. An additional Full HD monitor was provided but you could easily ask for more.

<comment><AUTHOR> Thanks for info, can you share how your computers were networked? Did you work on remote deployed code or just a local copy of it?

<comment><USER2> Desktop plugged into Ethernet, no further idea. My laptop connects to a secured wifi when I'm not working remotely now.

Both mentioned jobs have workflows that involve bringing up potentially most of the services being deployed in production locally.

People at my last job were starting to ask for 64 gigs of RAM to work with a full blown IDE as well as to deal with running multiple Java apps locally.

My current coworkers mostly work with light editors, and bring up smaller, containerized apps.

<comment><AUTHOR> Thanks for sharing

</comment></comment></comment></comment><comment><USER3> My current office setup is a Chromebox with VDI (Windows 10, 2 VCPU/6GB) and two ancient Dell monitors.

For input, I use an older Apple USB keyboard from circa 2008 and an IBM mouse that I find comfortable. For work at home, I use a 2014 MacBook Pro.

My personal computer is a 27" 5k iMac, and we have various iPads and Chromebooks all over the place.

</comment><comment><USER4> ThinkPad T470P, Dell P4317Q (purchased myself, default company stuff is 2 2k 27" displays), HP z440 (6 cores, 64gb ram, 2x 1TB NVM e drives), hp z840 (12 cores, 128gb ram, 2x 1TB nvme drives). Code mechanical keyboard, logitech mx master 3. I have my own office too (for now)!

<comment><AUTHOR> great, Own office sounds exciting even though its temporary. I have seen some people preferring mechanical keyboard, I have no strong preference in this case.

</comment></comment><comment><USER5> Latest MacBook Pro and accessories (keyboard, mouse, two chargers, and a branded backpack to haul it around in). One 27" external monitor is standard, but you can request a second. A laptop stand, standing desk, dongles (USB, HDMI, ethernet, etc) are also provided.

<comment><AUTHOR> Do standing desk really help?

</comment></comment><comment><USER6> At my office (~700 people; one office of many for a large international marketing agency) I have a 15-inch 2015 Macbook Pro with a 2.5 GHz Intel Core i7 and 16 GB 1600 MHz DDR3 RAM. I carry this around to meetings and stuff, but hook it up to a second screen and bluetooth keyboard/mouse while it's at my desk.

<comment><AUTHOR> Are you from marketing or also a techie? Though,I know, there are many non- programmer in HN audience.

</comment></comment><comment><USER7> X1 carbon running ubuntu with i7 and 16 GB ram, two 24" external monitors at work, one 27" external monitor at home.

Most of the people in my workplace use macbook pros though (with dual monitors).

I use my own mechanical keyboard and mx master 2s at work.

</comment><comment><USER8> At my office I'm using a dual monitor (both 1600x900) Windows 7 PC with the following specs:

\- Intel Core i5-6600

\- 3.30GHz

\- 16GB of RAM

\- x64

The wired mouse is generic but I brought my own mechanical keyboard (KB Paradise v60 Mini).

Everyone has the same computer specs, from what I can tell, and we're at a medium-sized non-tech company.

<comment><AUTHOR> yes, an almost universal specs. still I felt curious about how people manage them at scale.

</comment></comment><comment><USER9> Dedicated desktop with 32 cores and 128gb of ram plus two monitors and standing desk.

<comment><USER10> Dedicated workstation laptop w/ 32 GB RAM & 6 cores and 2 external monitors & common peripherals such as keyboard & mouse + a headset. If you don't mind asking, aprdm, what type of work do you do? If you ask me, I am working in the embedded field where I need to run a couple of virtual machines.

<comment><USER9> Computer graphics industry</comment></comment></comment>


Compilers can never generate even good code - <AUTHOR> http://www.zyvra.org/laforth/

<comment><USER2> > I know of no compiler that generates the Intel string instructions. Not even > Forth!

Yes, because they are measurably slower than their equivalent primitive instruction sequences, and the space saved isn't really all that significant when you consider all the other loads and stores necessary to run them. I think they've been actually slower since either the 486 or Pentium days. I'm pretty sure, for instance, Watcom C++ would generate "rep movsd" sequences for memcpy back in the 386/486 days, back when it was actually an optimization to do so.

<comment><USER2> Actually I have to update my own comment here, due to a completely unexpected circumstance. I just happened to diassemble some 64-bit test code I wrote tonight (unrelated to testing out the string instruction theory) and lo and behold, Apple gcc-4.2.1 with -O3 turned memset(x, 0, 7*sizeof(uint64_t)) into a 3-byte "rep stos" instruction:

        0x0000000100000cee <main+30>:	cld
        0x0000000100000cef <main+31>:	mov    $0x7,%ecx
        0x0000000100000cf4 <main+36>:	xor    %eax,%eax
        0x0000000100000cf6 <main+38>:	mov    %r15,%rdi
        0x0000000100000cf9 <main+41>:	rep stos %rax,%es:(%rdi)
        0x0000000100000cfc <main+44>:	...

It even does pretty much the same thing with -m32 and with optimization turned down to -O1. So perhaps things have changed.

</comment></comment><comment><USER3> Ironically, the vast majority of "improvements" listed in the post (everything except using scasd) are algorithmic ones that _are_ in fact doable in a compiled language.

And even special machine instructions seem quite achievable with a pattern- matching code generator.

Overall I think the HN title is very misleading - the article seems more "compilers don't do this well yet", definitely not "compilers can never do this".

<comment><USER4> And scasd probably isn't a speed improvement on modern CPUs.

</comment></comment><comment><USER5> >How do you tell a C compiler that?

You'd need dependent types and a compiler that understood exactly how much information in bits was required for a particular proposition, I'm guessing. I think this is the sort of thing (not using tricky assembly instructions specifically, but using unboxed types with expressive type systems) that makes languages like ATS[1] possibly faster than C.

The point is: good code generation is possible in theory, even if "sufficiently smart" compilers are too hard to write. (Or are equivalent to general A.I.)

[1] <http://en.wikipedia.org/wiki/ATS_(programming_language)>

<comment><USER6> Modern day CS: every problem can be solved with a better type system

</comment></comment><comment><USER7> I hope it is some kind of a joke.

It is not responsibility of a compiler to recognize specific problems in specific domains and perform optimizations, it is a job for a human programmer. Sure, you can make compiler aware of Riemann zeta function values in specific ranges, but what's the use of that outside of very specialized programs? Optimizations mentioned in the article could be programmed in C and compiler would happily translate these savings into assembly.

The reasons why we don't really program assembly anymore is that _on average and on a large scale_ compilers generate vastly better machine code than humans. Take for example register allocation problem which is proven to be NP- complete. Obviously compiler does an approximated algorithm but save for a case of few registers, no human can match it.

Some architectures, like VLIW, actually rely on the compiler to generate well- performing machine code.

</comment><comment><USER8> > It looks like the Intel 8086 architecture and its descendents will be with > us for ever ... Why not take advantage of every idiosyncrasy of that > instruction set?

Because ARM.

<comment><USER9> I was thinking that, but to be fair he gave that talk 4 years ago before the tablet/phone market took off.

<comment><USER10> Additionally, the 8086 is not much like the 386! And the 386 isn't much like the 486, which differed surprisingly from the Pentium. And each subsequent revision has followed this trend of being (at the very least) different enough from its predecessors that assembly language programmers need to re-read the manuals.

Today we even have a 64-bit version, which differs from its trail of 32-bit ancestors even more than they differed from one another...

</comment></comment></comment><comment><USER11> I'm sure he agrees that algorithmic improvements are more effective than constant-factor improvements like optimizing the assembly code. I think he'd also agree that algorithmic improvements are also easier to make in higher- level languages than in assembly. I'd argue, then, that it's more worth your time to spend your time iterating and squeezing as much algorithmic optimization of the higher-level program, than squeezing as much assembly optimization out of x86 as you can.

There is the case that there is a solution is known to be algorithmically optimal, or there is only one leading contender for optimal and it's unlikely to be toppled and you have to have a PhD and a couple postdocs in theoretical CS to begin to approach a way to challenge it, in which case it would indeed be more worth your time to optimize the assembly code. I hear Adobe Photoshop uses an FFT written in optimized assembly because almost every CPU-intensive thing they do uses it. Has he taken a gander at that? Pretty sure the fastest known way to calculate prime numbers changes a couple times a year.

However, that is only the case with textbook CS problems, and I think most HN members would agree that in industry, software engineering is almost never actually about solving textbook problems, and tends to have quirks that lead to clever algorithmic optimizations that are continually being discovered.

</comment><comment><USER12> > The current vogue among computer users is to get > as far from the real > hardware as possible. > ... > Assembly is the epitome of using the features > of > a given machine.

But what about the features of a particular language? Mucking in assembly is great if you're trying to squeeze out every ounce of power, but it's much too verbose for building complex systems. If you're trying to build _user-facing_ features, layers and layers of language abstraction is great. See <http://www.paulgraham.com/hundred.html>

If you're building a prime-number generator, go ahead and write in assembly. But if you're writing an _application_ , like most of us on here (I assume?), use a high-level language. "[Taking] advantage of every idiosyncrasy of [the] instruction set" is a waste of time.

</comment><comment><USER13> Compilers have been written which (for tiny microbenchmarks like this one) search every possible machine code sequence to find the fastest. Of course they take absolutely forever to run, but they do _exist_.

<http://www.arnetminer.org/viewpub.do?pid=600808>

[http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=8A1C...](http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=8A1CFFA39BD95B8CA4C024F422A71387?doi=10.1.1.13.7059&rep=rep1&type=pdf) [PDF]

</comment><comment><USER14> That was quite an arrogant post that really seemed to miss the forest for the trees. Sure, perhaps you can build a faster prime number generator in assembly, but you'll never build a better application in assembly (where better is defined as feature rich, secure, etc), and that's what the job is about.

<comment><USER15> Performance can also be a feature.

<comment><USER14> Absolutely! But performance in most applications is not determined at the bit level. Most apps performance needs are met at the architectural level (prevent blocking on _whatever_ ). Fewer apps performance needs are met at the algorithmic level (O(log n) is much faster than O(n log n)). It is a rare app that finds it's performance requirements in the ops and bits (Highly math- centric apps. Others exist, I'm sure).

I've generally found that's the order I go in meeting performance requirements. When I've failed to meet those requirements, I've generally worked backwards up the list, with each step getting more expensive in an exponential fashion.

</comment></comment></comment><comment><USER16> In an I/O bound world nobody can hear your hand-rolled assembler scream...

</comment><comment><USER17> Relevant to everyone interested in this topic: [http://www.linux- kongress.org/2009/slides/compiler_survey_fe...](http://www.linux- kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf)

"Abstract - People often write less readable code because they think it will produce faster code. Unfortunately, in most cases, the code will not be faster. Warning: advanced topic, contains assembly language code."

</comment><comment><USER18> I actually think this is a subtle parody of the "Scala/Haskell/Java/Ocaml is impractical because you can't write performant code in it" crowd.

On tiny and contrived micro-benchmarks, it's nearly impossible for a (non- contrived) expressive language to beat less expressive languages like machine code, X86 assembly, or C. For real, large software projects, the case for a less expressive language is not nearly as convincing, because the shortcomings of the language mean that programmers aren't able to write the same quality of code. For example, compare the outright mess that is concurrency in C or Java to the much easier concurrency available in more expressive languages. As parallelism becomes far more important for people who need high performance (yes, I know concurrency and parallelism aren't exactly the same thing, but they're similar) this advantage of the less expressive languages is likely to diminish, if not disappear outright.

[Edit: Added-- This is analogous to the static/dynamic typing debate. Dynamic typing test drives extremely well but multi-developer projects in dynamically typed languages usually turn into outright nightmares, due to problems around interfaces. Static typing's better for large projects. Same with expressive languages: assembly's going to win on microbenchmarks, but writing good code in less expressive languages becomes impossible as the size and scope of the project gets large.]

</comment><comment><USER19> Articles on how fast some program is, with no benchmarks, are not that persuasive. Especially since it's based mostly on the claim that "no compiler would do _that_ ".

<comment><USER20> I'd laugh so hard if someone knocked an equivalent up in C and it was faster...

</comment></comment><comment><USER21> Actually, if you're using a higher level language you stand a chance of implementing a much faster algorithm which would trump any of these O(1) speed-ups.

</comment><comment><USER22> Machines and CPU time are cheap...at least compared to the price of hiring additional programmers to maintain the mess of assembly code you just wrote.

<comment><USER23> Assembly code doesn't need to be a mess. Usual rules apply - you can write a mess in any language, much as you can write well structured code in any language.

<comment><USER24> Obsessive micro-optimization obscuring the function of code is _always_ a mess.

You are correct that the mess is language agnostic. For example, if he'd attempted to discard the low order bit of his prime numbers in C, it would result in the same awful maintenance.

Some optimizations waste too much programmer time to be worth tackling. Distorting the meaning of code for some tiny performance gains never constitutes "well-structured" code.

<comment><USER23> Optimisation is not the same as programming. You can program in Assembly without trying to make your code as performant as possible. Just because you use Assembly as your medium of describing your intent, doesn't mean that you're obsessive about micro-optimisation.

</comment></comment></comment></comment><comment><USER25> Maybe I am missing something but all the optimizations in this article except the xor (2) and the scasd (4) can be done in high level programming languages.

Number 3 (output of a sequence of integers as the sequence of differences between consecutive elements) is a very common optimization for inverted indexes formats, IIRC lucene, written in java, does it.

<comment><USER26> Why can't the xor be done in high level languages?

<comment><USER25> You can't force the compiler to output an xor on a single-byte register (CL). I wonder whether that's actually any faster.

</comment></comment></comment><comment><USER27> This guy has a very different definition of 'good' than I do -OR- this is funny.</comment>