How to Create a Self-Referential Tweet - <AUTHOR> http://www.spinellis.gr/blog/20090805/ <comment><USER2> Nice. Incidentally, similar techniques are often used in security breaches. I remember it both from the recent paper that guesses your SSN from you date of birth and other data (where it is used to extrapolate your SSN from those of dead people with a nearby date of birth), and in the recent paper on the rogue CA certificate, where it is used to guess the timestamp on the certificate to the exact second.

I highly recommend reading these two papers -- both attacks required a great deal of ingenuity to pull off, especially the second one.

<http://www.pnas.org/content/106/27/10975.full>

<http://www.win.tue.nl/hashclash/rogue-ca/>

</comment><comment><USER3> That sucking sound you hear is a day of productive programming being lost forever to Twitter ... ;)

</comment><comment><USER4> The tweet <http://twitter.com/SelfRefer/status/3128391843>

</comment><comment><USER5> Pretty cool exercise.

My lame-o half-ass solution: buy a domain name, send out a tweet containing a link to that domain, and forward the domain to that tweet.

Why write a nerdy shell script when you can just throw some money at the problem? ;)

<comment><USER6> Looks like that was forbidden in the rules... it had to have its actual URL in it.

<comment><USER7> ok, the other lame-ass brute-force long-term percentage-playing solution: buy mad badwidth, create tons of whitelisted twitter usernames, and continually send tweets with a url to a tweet id that hasn't occurred yet.

for instance, every tweet contains a url for tweet id 3149892792 (2000 more than the current most recent tweet on the public timeline at the time of this comment). once the system creates a tweet that overshoots the desired id, a new goal id is selected.

eventually, you'll get the right answer, especially if you can tweet a good percentage of tweets for a particular period of time.

</comment></comment></comment><comment><USER8> I'd rather see a tweet reply to itself.

<comment><USER9> Which would be kinda impossible because no two tweets can have the same id.

<comment><USER10> No, you can set the in_reply_to id in the request using the same approach. Then it'd say "in reply to @myname", and the "in reply to" link would link to the same tweet.

<comment><USER9> But then isn't that essentially the same thing as this challenge??? Putting a link to the tweet in itself???

<comment><USER8> yes, but the end result would be a cooler artifact

</comment></comment></comment></comment></comment><comment><USER11> also a self referencing comment: <http://news.ycombinator.com/item?id=743351>

<comment><USER8> not as hard because of the ability to edit comments edit: nobody said it was

<comment><USER12> It's also not as hard even without editing because comment ids are extremely predictable on hn.

</comment></comment></comment><comment><USER13> It's funny because just yesterday (while driving or walking the dog... one of those times when the thoughts just wander) I was thinking about how one could start a series of tweets of the kind "This tweet is the copy of the previous tweet" with a way to start and stop the series while all still being true. And then thought there could be other kinds of challenges around that theme. Apparently there are.

</comment><comment><USER14> This is silly because of the ease of URL shorteners.

      1. Use a link with a unique keyword hash (you can check) eg http://bit.ly/hn_comment
      2. Take the action, get the link
      3. Make that link with the keyword hash

Note, I didn't edit this comment to change the link. Clickable: <http://bit.ly/hn_comment>

<comment><USER15> The fun was doing that without using this.

<comment><USER14> I get it. I agree, and called it silly. I didn't say pointless.

</comment></comment></comment><comment><USER8> Note that this is now a fixed point of a function that maps a URL for a tweet onto the text of the tweet itself.

</comment><comment><USER16> Neat. Some years back I played with self-referential del.icio.us posts. <http://rubyforge.org/projects/delinquent>

</comment><comment><USER17> to much recursion!

<comment><USER18> Too! Too much recursion!

"To much recursion!" would be proper if you were, say, offering a toast on account of having loads of recursion. Like:

The Good King Lisp raised his glass and toasted with the Knights of Lambda, "To much recursion!"

<comment><USER19> Every once in a while, I fervently wish that I could upvote an HN comment more than once.</comment></comment></comment>


To Err Is Human: Mistakes and slips in skydiving and other disciplines - <AUTHOR> https://blueskiesmag.com/2018/09/26/to-err-is-human/ <comment><USER2> I skydive and BASE; from my (limited) experience, the disciplines have a risk of 'built in' complacency.

Take skydiving, for example. As a beginner, you're keenly aware that every time you toss yourself out of a plane, you're committing suicide, and every time, the parachute saves your life. Quite quickly, it can be easy to equate "wearing a parachute" to "nothing will go wrong".

A skydive rig is an incredible feat of engineering. Each fold and stitch has a history, a reason and a purpose. It's a thing of beauty. However, in a skydive rig, half the system is a black box: You're not allowed to touch or handle the reserve part. This can foster a complacency, or a shift of responsibility: It doesn't matter if my pack was terrible, I've got my reserve..

Checklists do exist: In theory you'll check your AAD (Automatic Activation Device - it basically fires your reserve if you haven't opened by a certain altitude), your pins (reserve and main), your handles (pilot chute / main handle, cut-away handle, reserve handle), straps (leg straps, chest strap), ring system (RSL and three ring system), and then your own gear (helmet, goggles, alti).

However, expectation of performance (IE, every time you've worn your chute it's worked, leads to complacency), peer pressure (it's totally 'not cool' for experienced jumpers to ask for a gear check) - rushing - and the 'laid back' environment of dropzones erode the seriousness of the task and the importance of stringent checking.

<comment><USER3> I've only ever jumped in the UK and Spain, but every dropzone I jumped at in the UK required everyone to have a gearcheck from a suitably experienced and qualified skydiver before boarding, and a signature against your name on the manifest confirming it had been done.

I do know that the US had a reputation for being significantly more... trusting of everyone to sort out their own arrangements.

I do know that in fifty-odd jumps, I checked my gear and had someone else do a check for me once I was wearing it, every time. Good habits learned early stick.

<comment><USER4> So, it's like when you have a second pair of eyes checking your code to make sure there's no bugs. That really helps, in software development, doesn't it?

</comment></comment></comment><comment><USER5> With nod to Norman's "The Design of Everyday Things," including the chapter "Human Error? No, Bad Design."

For reference, an article he also wrote with that title, discussing design and human error in major transportation accidents:

[https://www.jnd.org/dn.mss/human_error_no_bad.html](https://www.jnd.org/dn.mss/human_error_no_bad.html)

</comment><comment><USER6> Having never heard of a "CYPRES fire," just spent 10 minutes googling it and then watching terrifying skydiving videos, like this one (no injuries or deaths, just scary):

[https://www.youtube.com/watch?v=DAZXF1UZ1Yg](https://www.youtube.com/watch?v=DAZXF1UZ1Yg)

<comment><USER2> By far the most 'well known' AAD videos. The human mind is _amazing_ in its ability to adapt to new environments. To a non-skydiver, the most important thing to do when you skydive is to open your parachute.

However it's stupidly easy as a jumper to forget completely about your altitude because you're concentrating on something else. Hard to believe that you're able to easily ignore 'certain death' after a few times - but that's the case.

According to CYPRES documentation, they've had thousands of fires - so in theory - saved thousands of lives - including the ones in this video. Pretty impressive.

<comment><USER7> Not every CYPRES fire is another life saved: [https://www.youtube.com/watch?v=MmOiyrsCRNA](https://www.youtube.com/watch?v=MmOiyrsCRNA)

I'm being cynical. The occasional misfire is worth every life saved. I suppose that AAD systems are like airbags. An occasional false positive is better than even a single false negative.

</comment></comment></comment><comment><USER8> It seems that having a checklist like in aviation (that was also applied to surgery and other areas) could be useful to alleviate some of these slips.

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

<comment><USER9> Point and call

[https://www.atlasobscura.com/articles/pointing-and- calling-j...](https://www.atlasobscura.com/articles/pointing-and-calling- japan-trains)

Someone linked this article in a thread related to worker safety or hazards.

There always seems to be ways to improve safety or reduce failure rate. But the problem is lack of incentive or motivation to make those improvements.

After reading the actual article. The point and call aims to eliminate the "slip" error. By keeping the human awareness focused and engaged in the activity.

<comment><USER10> I recently went around the USS Midway museum. It struck me that the guy in charge of the catapult would point at each person in turn waiting for an OK, before making a very clear signal to launch. Not quite point and call, mainly because the deck would be too noisy for the call bit, but it worked.

</comment></comment></comment><comment><USER11> One way to mitigate slips are mnemonics.. in grain them into the students when they are learning, and they will get stuck with them for life. I have one for pretty much everything I do.

<comment><USER12> Great tip.

I wonder if exaggerated gestures and pointing with the finger, like the Japanese railway operators do would help. I'm going to start doing this myself during my checks (beginner paraglider).

<comment><USER11> That is exactly how we do them.. you say the word and point to the item with the hand you will be using.

Ex: When landing the plane: GUMPS (gas, undercarriage, mixture,prop,seatbelts ) say them all while pointing to each item.

</comment></comment></comment><comment><USER13> The theory in this article is based on "Human Error" by James Reason.

</comment><comment><USER14> I get this mag. Never would I think Id see a link to it here.</comment>


Are Tests Necessary in TypeScript? - <AUTHOR> https://www.executeprogram.com/blog/are-tests-necessary-in-typescript <comment><USER2> > In Execute Program, we always write tests around subsystems that either (1) > are critical to the product or (2) contain a lot of details that can't be > statically checked.

This is one of those things that sounds good when you're in college, and sounds, well, horrifying is too strong a word, but it will definitely set off the warning bells for anyone that's been programming for a decade or more.

My team has a simple standard: every single user-facing requirement is verified by automated testing. We don't have 100% coverage, but it's damn close, somewhere like 98%. The remaining untested code is generally weird branch paths that are hard to trigger, and "shouldn't" be seen in production.

But this goes beyond code coverage or TDD: firing up the debugger and executing a unit test is the simplest way to add a feature, period. I cannot fathom building and starting our application so that I can hand test _every time I change a line of code_.

Unit and integration tests aren't punishment inflicted on inferior developers: they'd an extremely useful tool that makes your life easier and your team more productive.

<comment><USER3> > This is one of those things that sounds good when you're in college, and > sounds, well, horrifying is too strong a word, but it will definitely set > off the warning bells for anyone that's been programming for a decade or > more.

To someone that has programmed for a good 2 decades and more, the above sounds like what a college student or junior dev that just found out about TDD would say.

Unit test and integration tests are (bad) substitutes for good and modular design, which should piggyback on a strong type system. I've seen it so often that whenever I read comments like the above I feel the need to create an HN account just to reply to them.

Junior devs in charge of major design decisions create damage that goes way beyond their limited reach. Test code is untested code. Test code is brittle code - especially integration tests are. You need tests because you're using a dynamically typed language? Well, stop using that language for anything that is even remotely complex. Your future senior dev self will thank you.

<comment><USER4> > test and integration tests are (bad) substitutes for good and modular > design, which should piggyback on a strong type system

This sounds completely hand wavy. If the design is in fact modular and built of autonomous components then it should be relatively easy to test and should be tested. Types are no substitute for testing and are completely orthogonal to testing.

> Test code is brittle code

If this is the case then the code being tested is more than likely brittle as well. Test code reflects the system under test more than anything else.

> You need tests because you're using a dynamically typed language

No you simply need tests in any language.

<comment><USER5> > Types are no substitute for testing.

I don't agree with the person you're replying to that types make tests redundant, but to claim that types can't substitute a large amount of testing can only come from inexperience.

Whatever property you can model successfully through a closed type, is a property you never have to test ever again anywhere it's being used. If you have 500 functions that take a NonEmptyString, those are 499 fewer property checks in tests (because you should have one test for the type constructor).

<comment><USER4> > types can't substitute a large amount of testing can only come from > inexperience

That is a very bold assertion I have seen no evidence for. I write very few tests in Ruby or Javascript aimed at validating types.

</comment></comment></comment></comment></comment><comment><USER6> The title is not a very good one, because it's nearly a rhetorical question: no language I've ever seen -- not even Haskell -- has a type system that _completely_ removes the need for tests. For example, even Haskell has partial functions over types like Int whose behavior can't necessarily be encoded in the type system (at least, not ergonomically/practically) and thus require actual tests to cover.

That said, I think a more accurate title for this post (based on the paragraphs beyond the first one) might be "are tests necessary for a view layer that doesn't have much business logic in it beyond passing properties when that view layer is written in Typescript?" At that point, it's really just a permutation of the question "are tests necessary for the view layer of an application?", which has highly-situational answers.

<comment><USER7> >completely removing the need for tests

That would be formal verification.

<comment><USER8> Not really. You still need tests to check whether your application is actually achieving its targets in real-world usage, including feature completeness, usability, performance; and how all of these are impacted by the environment (e.g. network issues in a distributed application).

Formal verification only tells you that the application matches its spec, given a set of assumptions. Only testing can tell you whether the spec matches the business case, and whether the spec assumptions hold.

Paraphrasing Knuth, code that has only been proven correct but not actually tested should always be approached with caution.

Edit: Knuth, not Dijkstra

<comment><USER9> Theoretically, formal verification can only tell you as much as can be encoded in a formal spec@.The problem is that no such kind of specs are known to exist (yet, if ever). As a thought experiment, if the informal specs written in English/Chinese or trapped in our head were as incomplete as a formal spec, we wouldn't even be able to reason about what to test in the first place.

@ Then there is the limitation of verification tech of course.

</comment></comment></comment></comment><comment><USER10> Short answer: yes.

Long answer: yesssssssssssssssssssssssssssssssssss

</comment><comment><USER11> The only person who would (incorrectly) answer "no" to the title question I assume is someone who only ever wrote javascript, and used tests as a way of preventing screwups with types, such as using undefined data or passing the wrong type of data to a function. Which is of course a pretty useless way of spending your day.

</comment><comment><USER12> > We don't want to go down the esoteric and labor-intensive path of automated > image capture and image diffing

Suck it up. Screenshot diffing solves a specific problem you can't address with unit/integration tests.

</comment><comment><USER13> We're running an experiment on this with our small company.

Our core web application consists of a Java backend (40k LOC, plus 12K LOC of tests) and a Typescript/React SPA frontend (12k LOC, _zero_ tests). LOC #s are 'real code' via CLOC. Not a simple CRUD app.

It's fine.

I can't say that this would be fine for everyone. We have a very small team (2 fullstack engineers) with good communication; we keep as much logic as possible in the backend; we have a robust test harness for the backend. Still, it works very well for us. Even without testing the frontend, it is very rare for bugs to hit users.

Our reasoning for skipping frontend tests: Most of the frontend code is visual. Tests can't tell you if the result is aesthetically satisfying, so you have to look at it no matter what. Since the backend diligently enforces data sanity, the frontend can't really get into too much trouble, and a page reload fixes almost anything. Frontend testing seems to be high-effort low-reward.

I don't think this would be possible without Typescript. TSX helps too since the compiler (really the IDE) catches what would otherwise be template errors. Large refactorings are pretty painless.

I would do this again.

I have also reverse engineered about a dozen other company's web applications recently (to automate them), and noticed that there are other app design philosophies that would make this approach difficult. Some teams go with a "smart frontend dumb backend" approach that can produce all sorts of nasty data corruption issues if the frontend screws up. I'm not a fan of this approach but if you take it, I don't think Typescript alone will save you.

<comment><USER14> > _Our reasoning for skipping frontend tests: Most of the frontend code is > visual. Tests can 't tell you if the result is aesthetically satisfying, so > you have to look at it no matter what. Since the backend diligently enforces > data sanity, the frontend can't really get into too much trouble, and a page > reload fixes almost anything. Frontend testing seems to be high-effort low- > reward._

This is an example front-end react component project that I wrote that benefits heavily from tests: [https://github.com/lookfirst/mui- rff](https://github.com/lookfirst/mui-rff)

Why? Because it is a wrapper around two other frameworks (React Final Form and Material-UI). Any time those two frameworks change something in a way that I didn't expect, I want test failures.

</comment></comment><comment> awinter-py > Types can't (usually) tell us when we accidentally put a "!" in front of a > conditional

critical point in any 'types vs tests' discussion. strongly typed langs can tell you that your program will run w/out crashing but not that they'll be right

(even the 'run w/out crashing' promise turns out to be not always true)

I wonder what tools will evolve in the next 10 years to measure if code is 'semantically correct'. Some sort of function that maps from code to docstrings might be able to check this.

<comment><USER15> Semantically correct is important! What _kind_ of semantics? I prefer denotational. Many programmers think in operational semantics. And how does one verify their code?

I'm trying to push our review guidelines to ensure developers submit their code/change with an argument as to _why_ it is correct. I got this idea from E.W. Dijkstra who was having a hard time keeping up with his graduate students and colleagues. In order to save his time and sanity he asked them to submit an argument as to why their change was correct. Instead of validating their algorithms, Dijkstra was able to validate their argument and check their proof.

One can use unit tests to make this argument. The level of rigor depends on the task on how difficult it would be to convince the reviewer that your change is correct. One can go beyond unit tests and write property tests, make arguments based on the type information, embed proofs in the types, or make more formal arguments by proof if they feel it's necessary.

Making unit tests _required_ is a good minimum case I think but is often not sufficient.

<comment> awinter-py I've certainly talked myself into 'correcting' unit tests that didn't agree with bad code

</comment></comment></comment><comment><USER16> The "ideology" video linked at the end of the article was also instructive for me, by framing the issue in other terms. Both tests and types are proof of correctness; tests are proof by example, types are proof by category. The architectural analogy in my head is that types are vertical and horizontal beams, while tests are diagonal bracing. The interlocking of the two is what makes the overall structure rigid.

</comment><comment><USER17> Yes. Types are a great way to communicate with the compiler and fellow humans, but they do not replace tests.

<comment><USER18> I liken a few different things to Zeno's paradox. Types might save you from 10% of your failure modes. And the next tool, and every one after, fix 10% of what's left. But you never arrive.

Or alternatively, every efficient method of code verification just results in more code. Each product is "worth" so many man-years and so anything that reduces effort just increases scope. Which may also explain program bloat; adding three libraries gives me time to... add two more libraries.

<comment><USER17> Good points. Thanks for the reminder of Zeon's Pradoxes. [https://en.wikipedia.org/wiki/Zeno%27s_paradoxes](https://en.wikipedia.org/wiki/Zeno%27s_paradoxes) +1

</comment></comment></comment><comment><USER19> I think this is somewhat funny since to think of this question at all really highlights the time people waste in JS/python etc.. Testing things that can be automatically checked by a simple compiler.

I do find that as some of these people migrate to TypeScript they write too much tests, as they are just not used to have some checks already done for them.

But to others that come from compiled/typed languages that's a question you'd never ask :)

</comment><comment><USER20> Take a non-trivial program written in a statically typed language, with 100% unit test coverage, pass it to American Fuzzy Lop and see what happens.

</comment><comment><USER21> Yes, but not to validate your syntax and any references to undefined stuff (except on the boundary where you might interface to external - not in Typescript written - libraries). Still, tests are meant for logic testing - which is something the Typescript compiler won't help you with (or any compiler probably).

<comment><USER22> > ...which is something the Typescript compiler won't help you with (or any > compiler probably)

Not so - there're languages out there in which you're able to encode your business logic within your program's types, at least to a certain extent, e.g. dependently typed languages. This can definitely replace some of your logic tests.

</comment></comment><comment><USER23> Didn't know Gary Bernhardt was working on something outside of DAS. Quality content as always.

</comment><comment><USER24> Different quesion, what kinds of tests does TypeScript eliminate?

Also, does ReasonML eliminate other kinds of tests than TypeScript?

</comment><comment><USER18> To quote Mr Babbage:

"I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."

</comment><comment><USER25> Yes.

</comment><comment><USER26> Yes. You're welcome.

</comment><comment><USER27> > We ported our React frontend from JavaScript to TypeScript, then did the > same for our Ruby backend.

Next year it will be an article on how they ported everything to rust and webassembly and how that is just so much better than everything.

Of course they come to the conclusion that types and tests aren't the same thing. Otherwise you would never need tests, not even in dynamically typed languages.

<comment><USER28> That's not really fair, they ported their stack so front end and backend share type definitions. It was not a fashion driven decision.

Wrt to types and tests, "Types" means some verifiable annotations on the code. If a type system can encode enough information in them, perhaps with preconditions or other contracts, then would tests be superfluous? If so, I don't get your assertion about tests and dynamically typed languages.

On the other hand, since typescript is unsound, shouldn't you really test like a dynamically typed language?</comment></comment>


Earthbound Battle Background JS - <AUTHOR> http://gjtorikian.com/Earthbound-Battle-Backgrounds-JS/ <comment><USER2> For fans of the game: Help me understand the appeal. I fired it up once on an emulator and played for like 15 or so minutes and was just completely "meh"-ed. Is it something that pays off later and you just have to play it for a while or what?

<comment><USER3> It's just a quirky RPG with western culture as understood by the Japanese. You fight with baseball bats and frying pans instead of swords and bows. Your enemies are zombies, cultists, aliens, and bike gangs. Your dad gives you your allowance which you collect over ATM. The towns you visit are called Onett, Twoson, Threed, and Fourside, because their only importance is the order in which they appear in the game. Depending on the version you play, you run around in your pajamas or birthday suit because you just got out of bed.

It's not a game you play so much for the mechanics, which are not bad, but not hugely novel. At the time, when all console RPGs were based on high fantasy, a quirky RPG based on a bunch of silliness was very different.

<comment><USER2> Thanks for the explanation - maybe I'll give it another try. I am totally open to quirky JRPGs. I think I was just measuring this one against Chrono Trigger (another quirky JRPG for the uninitiated, which oozes charm) - which I went into with a skeptical attitude and 10 minutes later was completely drawn into the story and felt like some kind of magical child. Didn't have the same experience with my 15 minutes of Earthbound, but maybe I just needed to give it a little time.

<comment><USER3> The story in Earthbound doesn't make a lot of sense. You play it more for the individual story elements than the actual overarching plot. Kind of like how the plot in The Big Lebowski is ultimately irrelevant.

</comment></comment></comment></comment><comment><USER4> From an 1994 Famitsu article: [https://starmen.net/mother2/publications/](https://starmen.net/mother2/publications/)

 _Itoi refers to the battle backgrounds jokingly as a "video drug". This is noteworthy because the dummied-out Video Relaxant item in EarthBound was originally known as "Video Drug" in MOTHER 2, even though the item was dummied out in that game, too. So apparently that's what "Video Relaxant" refers to: the battle backgrounds._

 _The battle backgrounds were all made by one guy, who Itoi says was a real background graphics geek. The guy spent two years doing nothing but working on the backgrounds! He says he thinks there are about 200 different ones._

</comment><comment><USER5> As a tiny reminder, for those that loved Earthbound, please go play Undertale. It is just an absolutely fucking amazing game.

<comment><USER6> or watch this chap play it, it's up next on his play list :)

[http://www.twitch.tv/cohhcarnage](http://www.twitch.tv/cohhcarnage)

<comment><USER7> If you can't play it, then watch it. But if you can play it, PLAY IT!! The game has many moments that I think are better interpreted when taken at your own speed.

</comment></comment></comment><comment><USER8> Oh wow, this is awesome. For xmas I built a game for my wife based on Earthbound (she's Paula walking around Fourside looking for things) using React. Seeing this makes me want to add battles...

[http://eb-test.surge.sh](http://eb-test.surge.sh)

</comment><comment><USER9> I never realized how much variety there was in the backgrounds of enemies in that game.

</comment><comment><USER10> 225 / 15 Chaotic swirls and spirals that occasional form a momentary glimpse of Giygas' face creeping through. Damn, had no clue how procedural those backgrounds were. Whole new respect for the game on a different level now.

</comment><comment><USER11> This is incredibly cool!</comment>


Ask HN: Selling disruptive technology - <AUTHOR>

I'm posting on behalf of an acquaintance, who approached me recently with several major ideas in the field of ceramics. He has publications and patents to back his claims, but he has trouble with investors. His website with more explanations is http://rokhv.com. Quick summary: he invented several new types of ceramics, and knows how to manufacture them. Uses: containers for nuclear waste disposal (cheaper and safer than Yucca Mountain); cheap and thin superconducting wire; incinerators which produce clean electricity.
Investors get excited, refer him to experts in the ceramics, who reply "no way." Except some of these experts work on competing ideas, or have other vested interests. This is the disruptive technology problem which PG wrote about: people either outright don't understand what you're doing, or they don't want to understand it.
I personally have no stake in this, but I'm always interested in pushing for clean energy sources. I wonder if crowd here has any suggestions. <comment><USER2> This is very exiting: his new technology will truly revolutionize many technological fields, and lead to huge savings for humanity (and make him one of the riches guys on earth in the process).

Unfortunately... extraordinary claims need extraordinary evidence. And patents and publications in peer-reviews papers do _not_ constitute extraordinary evidence.

Moreover, there is a bad bad smell form his claims and web site:

\- Nuclear waste disposal, cheap superconducting wire, new incinerators... This technology solves too many problems, it seems too powerful. Does it cure cancer too? Hey, no, he does not claim that; but he does claim (from his web site) that this could reduce worldwide GHG emissions by 15%. That's almost as good.

\- From his web site: one plant for manufacturing radioactive resistant packaging would bring owners $265MM/year. One plant manufacturing 15,000km/year of his new electric wire will cost $49MM. Some other plant would cost $51MM.

WTF? It would take months or years of experienced people to make estimates like these, and they would be much less precise. My guess is that these numbers are totally random. Moreover, some of the quoted ROI are 500%. I would guess that historically, industrial projects with projected ROI that high did not work out as planed (to put it mildly)

\- He speaks about "room temperature" superconductivity without giving any more details about what "room temperature" means.. Hum, he seems to be skipping some important details there.

I could go on.

I hate being harsh, but my guess is that this guy is either lying or delusional.

<comment><USER3> For the last 12 years here in New York, USA, I developed, tested, published in professional journals, presented on the US professional meetings, US patented and in-lab prototyped three separate cost-efficient thermo-chemical technologies and advanced ceramic products. All technologies and products relate to more efficient electricity generation or transmission and end-use; all of them will provide significant Environment protection or cleaning and are very profitable. Now I rather intent selling or licensing these innovations than getting investments. I will appreciate any help and advice. Thank you, Dr. Anatoly Rokhvarger, www.rokhv.com (sorry for unprofessional web site); firstname.lastname@example.com

</comment></comment><comment><USER4> I hate to be the bad guy, but:

 _Investors get excited, refer him to experts in the ceramics, who reply "no way."_

How do you know they are not right?

Patents in and of themselves are not proof, as we all know.

<comment><USER5> Also, it is worth keeping in mind that "nano technologies" is _the_ fad in Russian Federation at the moment. It is something that is used to milk government and private investors for grants, subsidies and any other form of loosely packed cash. At some point Putin let it slip publicly that "nano technologies" is where the future of Russia lies, and all hell broke loose.

Want to keep up with times? Make sure to wash your car in "Nano Carwash" (two dudes with buckets). How about some "Nano chocolate" if you are hungry? Or perhaps "Nano operating system" is your thing? Please have two.

I kid you not, it is this ridiculous. So anything coming out of Russia with "nano" in it should be treated twice as suspiciously.

(edit) Tangetal to what I said above. The About page on the site says

      American Ceramic Society recognized Dr. Rokhvarger among
      100 greatest innovators of the 20th century for development
      of "Conveyer Technology of Ceramic Tile Using Rollers Hearth Kiln"

This "Conveyer" invention being one of top 100 greatest inventions of 20th century has from zero or one hits in Google depending on whether it is misspelled or not. While I don't think the above statement is an outright lie, but this looks a lot like an unsubstantiated cheek puffing, and it makes me wonder if the actual subject matter is of the same quality.

</comment></comment><comment><USER6> I would suggest looking into SBIR funding. Many of the large government agencies will provide Phase 1 funding for preliminary research and if proven, phase 2 funding for commercialization. DOE SBIR programs may be applicable. <http://www.er.doe.gov/sbir/> Depending on where located, most states have organizations who can provide assistance in writing SBIR proposals. <http://www.sbir.gov/state/>

<comment><USER7> The only worry is that the same "experts" could review his application. It's worth a shot, to get a score and feedback, but it is a 12 to 18 month process. Investors have to be an additional source of financing.

</comment></comment><comment><USER8> Not to seem doubtful, but the website does not inspire a lot of confidence. It is terribly formatted and oddly has red text highlighting market sizes.

Also, the Business Development guy also designed the website with his separate company. But that company's website (jkmarketingspecialists.com) was designed by some company that is a green company directory?? I would definitely encourage an effort of legitimacy. No one can fund that website.

You mention that he has been published in peer-reviewed journals, could you put those links or articles on the website. I have never seen an academic extract mention money or be formatted like this:

 _~ $265 MM/year pre-tax net income and liberates US Government budget from > $15 billion/year expenses. The U.S. market for the RCC packages is about $10 billion/year._

The technology could be as awesome as you say but this lack of clarity could be why the experts say no way. It usually isn't a conspiracy or a vested interest conflict. A smart investor would be aware of these and would probably only refer you to someone whose honest opinion he could get.

</comment><comment><USER9> Try thinking more broadly about applications for the technology.

Find a situation where there is a guy who is looking for a solution to his problem at least as hard as you're looking for a customer for the product. Don't try to convince a bunch of people who don't seem to want to be convinced, that is a really painful process that leaves you disillusioned and makes you wonder if you should quit. Find one of the few guys who is going to love you when he sees your stuff. And if your stuff works for him, he'll probably help you expand.

Bottom line: spend more time thinking about applications and finding people, and less time trying to convince them

</comment><comment><USER10> You seem to be concerned about selling the tech to investors, but why not sell it to customers instead? Is it so expensive to make that investment is needed to make the product?

<comment><AUTHOR> Making the product definitely requires investment. Manufacturing equipment, salaries for a couple of people who will do the actual work, etc. It doesn't need a huge sum, but it isn't bootstrappable.

</comment></comment><comment><USER7> All of the uses, what's the best market? Can he build something that someone in that market wants?

How can he show that their money won't fund a science experiment but will be applied to making them more money? Traction in a market seems key.

</comment><comment><USER11> > He has publications

In peer-reviewed journals? Has someone independently duplicated his results (in effect is able to manufacture nuclear waste containers and cheap superconducting wire using his methods)?

<comment><AUTHOR> Yes, in peer-reviews journals. As for independent duplication, I gather that it's been painful to convince anyone to even try.

<comment><USER11> That's tough... How much would it cost to a college lab to duplicate some of his results?

</comment></comment></comment><comment><USER12> A lot of revolutionary technology is unbelievable until it happens. Maybe try to organize a private demo?</comment>


Why does the Semantic Web feel so over-engineered? - <AUTHOR> http://blog.georgikobilarov.com/2010/05/why-does-the-semantic-web-feel-so-over-engineered/

<comment><USER2> Because it's not going to work.</comment>


Show HN: Touch-enabled Gesture Helper for your website - <AUTHOR> https://genielabs.github.io/zkit/docs/controllers/gesture_helper <comment><USER2> Am i the only one who hates gestures that don't have immediate feedback but rather are detected only after the whole gesture is completed and then performs some predefined action.

In an image gallery if i swipe left the image should follow my finger until the next image shows up on the right side, not stay still until i finish whatever the platform consider a "swipe left gesture". Same for pinch, the image should be resized under my fingers as i move them, not after i release them.

I haven't seen predefined gestures being useful in any app or web page ever so i'm sorry to say this library will be likewise, despite it looking very clean and easy to use from a developer point of view.

<comment><AUTHOR> A gesture helper should only take care of interpreting "pointer(s)" movements.

The UI logic that takes care of actually dragging elements underneath when a "pan" gesture is detected, is implemented in the ViewPager.

Infact, if you look at the view_pager.js source code, you'll notice that it is using the gesture_helper to do its job.

[https://genielabs.github.io/zkit/docs/controllers/view_pager](https://genielabs.github.io/zkit/docs/controllers/view_pager)

<comment><USER3> Scrolling between those slides a bit and my laptop fans spun up, they rarely do so unless under heavy load. Not looking forward this being adopted elsewhere when it requires so much computing power to just be smooth.

<comment><AUTHOR> So, which one would you suggest? Did you run any performance comparison?

</comment></comment></comment></comment><comment><USER4> Someone's going to use this to override a gesture my browser provides and I'm going to hate this project when that happens. Until then, I'll appreciate it as a cool technical demo.

<comment><AUTHOR> It's not just a technical demo, it's a working component. See a practical application of it with the ViewPager example:

[https://genielabs.github.io/zkit/docs/controllers/view_pager](https://genielabs.github.io/zkit/docs/controllers/view_pager)

</comment></comment><comment><USER5> did absolutely nothing on win10 tablet mode. using firefox.

edit: your cdn was failing. now it captures all events and is not a detection, since i can't scroll touching over the target. also, shows keyboard_arrow_up/down on actual scroll

</comment><comment><USER6> whats the comparison between hammerjs and this?

<comment><AUTHOR> Hammer.js can detect more gestures: \- Pinch \- Rotate

GestureHelper detects: \- Touch \- Tap \- Pan \- Swipe

GestureHelper and the component-based library behind, which is zuix.js ([https://genielabs.github.io/zuix](https://genielabs.github.io/zuix)), are specifically designed to work on modern browsers only.</comment></comment>


Classp: a reverse approach to parsing – from AST to grammar - <AUTHOR> https://github.com/google/classp <comment><USER2> This is pretty interesting. What are the tradeoffs? Because if there aren't many, this seems like a much more desirable way of parsing a language.</comment>


Google's Document Understanding AI Assisted for Contract Review - <AUTHOR> https://lawtomated.com/google-document-understanding-a-i-features-screenshots-and-use-cases/ <comment><AUTHOR> Detailed teardown of Google's new AI toolkit to expedite the search, extraction and analysis of data from contracts for:

(1) due diligence; (2) contract reporting; and (3) general lift and shift of unstructured data from docs to third party tools.

It could shake up the busy contract extraction space currently populated by productised point solutions aimed more at law firms than enterprise.

Google's Document Understanding AI seems flexible enough to benefit both law firms and their clients, particularly legal ops use cases in financial services.</comment>


Stack Computers: the new wave (1989) - <AUTHOR> http://www.ece.cmu.edu/~koopman/stack_computers/index.html <comment><USER3> I've been playing around with some Greenarray[1] chips lately, and I have to admit that the core ideas are fascinating. Their particular variant of Forth is actually almost pleasant to use--certainly better than MIPS, which is my closest point of reference. (Ignoring crazy things like the color of identifiers controlling your program's semantics.) The chips are also _extremely_ power efficient.

[1]: <http://www.greenarraychips.com/>

I've found having a mental model of a stack-based system far easier than even a simple register-based one. However, this might also be true because the Greenarray chips themselves are far simpler than any other CPU I've ever looked at.

And, of course, the fact that you have 144 cores on a tiny chip _despite_ a cheap manufacturing process is also very neat.

<comment><USER4> Oh, please write about your experiences programming those chips. I'm sure I'm not the only one who'd like to hear all about it. I'd particularly like to know how you deploy code to the 144 cores and how they talk to one another.

Edit: that request is to anyone who has programmed the GreenArrays chips.

<comment><USER5> Yes, please write this! I'd normally just upvote your comment, but I feel like the sorts of people who play around with GreenArray chips are not that prone to blogging, at least by my googling...

</comment></comment></comment><comment><USER6> Mini book review: On the off chance you're planning on implementing a stack machine, you _must_ read this book. A few years ago I was working on a stack machine, and I didn't know what to read because virtually all of the references for fundamental material are decades old. Let me save you the trouble and tell you this is the one you want. There are newer papers you should read, of course, but if you're only going to read one thing, it should be this.

Why would you want a stack machine in this day and age? They're small. Really, really, small. The stack processor we made was so small that it fit in an empty space in the floorplan of our "real" (x86) processor.

<comment> daniel-cussen I'm using stack machines now because, like you said, they're small. Meaning, you can fit a ton of them on a chip, and if you can get them to talk to each other, you have yourself a pretty powerful parallel processor. The chip I'm working with has 144 cores running at ~700MHz, and it costs $20. It's insane how much being small buys you.

<comment><USER7> Chuck Moore's GreenArrays chip? (He's also the guy behind Forth, the quintessential stack-based VM.) How's that working?

<comment> daniel-cussen The very same. It's working really well—initially I was intimidated about the chips because of a few of the constraints the chip has in order to be as good as it is. Three challenges:

1) Figuring out how to work within the very low (but reasonable) amount of RAM each core has. They're independent computers, so each core needs to store its code and its data, all within 64 18-bit bytewords, which roughly corresponds to a tweet of information if you tweeted in UTF-8.

2) Dealing with the IDE: the IDE is attacking a problem nobody's solved: parallel compilation. That being said, it has been the second greatest challenge so far, after

3) Getting the hardware set up. My co-project-doer is light-years ahead of me in the EE department and makes most of the EE decisions, with some input from me about what capabilities the chip needs to have (a minimum amount of off-die RAM, say). Sourcing parts is something I would not have been able to do on my own, so I'd say this project requires a good deal of electronic literacy, if not dexterity.

That being said, though it's a bit of a prima-donna, it has every right and reason to be. It's an amazing, amazing chip. It's fast, powerful, unclocked, can work with all kinds of devices, is a crazy bargain both in hardware cost and in energy cost, and best of all, for me at least, an endless source of fun, hard problems. It's a fascinating chip.

<comment><USER8> Can you give a hint as to what we can expect to do with this chip?

I was a Forth enthusiast and read the book in OP (in early 2000's) and followed Chuck's work from afar, but I am not sure what exactly I could do with this chip, given its peculiar limitations.

<comment> daniel-cussen With low RAM like that, what you want to do is math, not UI. That means electrical engineering or number crunching, AFAIK.

OK, so first, it has a lot of I/O ports of different kinds on just one chip. In a lab, you could run lots of analogue knobs and many servos attached to just one chip. This means a lot less hardware debugging, which should be a Godsend.

Another possibility is HPC. You can tile a motherboard with these, cool them all down to -50 very easily and cheaply, and then overclock them as you perform number crunching that you couldn't do with a GPU. After all, these cores are truly independent, and can therefore branch independently, unlike GPU cores. That opens the door to a wide variety of algorithms that aren't GPGPU accessible.

<comment><USER8> A very peculiar kind of number crunching that would be. With 64 words, that should be some finely selected numbers :)

I'd love to be able to do some useful work with that, of course.

<comment><USER9> Don't think of the F18 computers in isolation- think about doing stream processing with a network of them. You probably can't fit your application on one F18, but you could easily fit one or two functions in 64 words, especially given that a single machine word can contain up to four instructions.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> One domain where stack machines shine is code density because of no need for register encoding. Instruction lengths aren't measured in bytes, but rather in bits. With some form of binary coding, one can reduce code size even further, 1-7 bits per instruction is not uncommon with rather elaborate instruction set which includes a handful of "macro" instructions for common tasks such as initializing array of data and random number generation and some others.

If implementing a stack based VM within a program, the stack machine has some overhead(because it has to be implemented with all the functionality and interfacing with the rest of the program) but that is mainly a curiosity - <USER2> can implement a less-well scaling ISA without binary coding and fixed opcode length with far fewer bytes for the VM, but then the cheap cost will be offset with worse code density. On the other hand a more advanced VM takes far more space, but the greater code densty pays off after certain amount of code.

Where this matters is of course demoscene. ;)

<comment> Tuna-Fish Bit-aligned instructions are a really horrible idea if you ever want to make a CPU implementing that instruction set actually fast. When you want to decode multiple instructions in parallel, having more possible locations for the beginning of the next instruction adds a lot of latency and power on a very critical path. Getting more cache to fit instructions and more bandwidth from it to the cpu is a problem that can be solved by Moore's law, having to put more muxes in front of your decoder isn't, now that Moore's law just buys you more transistors and less power, but not faster transistors.

x86 is now considered to be extremely hard to decode because it's byte-aligned instructions, and basically all modern instruction sets prefer fixed-width instructions. ARM used to tout how space-efficient it's THUMB-2/ARMv7 instruction set was compared to other RISC instruction sets because it had 2 possible instruction lengths (16b and 32b), but now that they got to (had to) reboot the ISA for 64-bit, ARMv8 is fixed-width.

<comment><USER10> This is definitely true.

For clarity for those who aren't exactly clear with all this, this only applies when the instruction set is actually compressed somehow - not for stack based machines in general.

</comment></comment></comment><comment><USER11> Since then the result seems to be that stack vs registers, it doesn't really matter as much as people thought. A modern processor that's out of order [1] has to reconstruct the dependencies in the dataflow graph anyway. Out of all the things going on in a processor, doing so from a register ISA or from a stack ISA is not that different. A bare bones stack machine may be smaller than a bare bones register machine, but nobody wants to run those anyway.

<http://en.wikipedia.org/wiki/Out-of-order_execution>

<comment><USER12> One of problems of stack machines is that it is mostly impossible to build useful out-of-order stack machine (or even in-order multiple issue). Short or non-existent pipelines and low CPI of stack machines tend to offset this for certain classes of code (lots of branching and so), but cannot rival performance of modern register based designs for other classes of code (number crunching).

<comment><USER13> It is straightforward to convert stack instructions to 3-address instructions, by keeping a counter -- a stack pointer -- that points into the register file. As instructions are decoded the stack pointer is read and the current reading is delivered on down the pipeline with the instruction itself.

From there on, the cpu is executing an instruction that calls out explicit register numbers. The stack counter is kept with the decoder at the very start of the pipeline. This "register number decoder" needs to run sequentially, and it needs to run a faster cycle time than the rest of the cpu.

</comment></comment></comment><comment><USER14> Idea: Notch should use a stack machine as the basis for his new 0x10c game. (A big part of the game involves programming an in-game 16bit computer.) It'd be a great excuse for a lot of people to explore this architecture.

<comment><USER15> They can also use the the Java VM or CLR as those are both stack machines.

</comment></comment><comment><USER16> I do hope more old technical books make it to a new life online. Otherwise whole areas will get increasingly hard to access, as there are only a limited number of library copies.

<comment><USER17> ACM has a bunch of classic books for download.</comment></comment>


Dead Code Should Be Buried – Why I Didn't Contribute to NLTK - <AUTHOR> http://spacy.io/blog/dead-code-should-be-buried/ <comment><USER4> NLTK has an active and growing developer community. We're grateful to Matthew Honnibal for permission to port his averaged perceptron tagger, and it's now included in NLTK 3.1.

Note that NLTK includes reference implementations for a range of NLP algorithms, supporting reproducibility and helping a diverse community to get into NLP. We provide interfaces for standard NLP tasks, and an easy way to switch from using pure Python implementations to using wrappers for external implementations such as the Stanford CoreNLP tools. We're adding "scaling up" sections to the NLTK book to show how this is done.

[https://github.com/nltk/nltk](https://github.com/nltk/nltk) | [https://pypi.python.org/pypi/nltk](https://pypi.python.org/pypi/nltk) | [http://www.nltk.org/book_2ed/ch05.html#scaling- up](http://www.nltk.org/book_2ed/ch05.html#scaling-up)

</comment><comment><USER5> I hate this genre of post that basically follows the line: "I went to <established project> and attempted to educate them. When they didn't listen I went and built something better. Now its clear they should have listened to me, and you should all abandon their software"

Almost always the scope of the new project is much smaller, different or much less mature than the project being bashed. Open source projects are not required to make changes to please any arbitrary user that wants to make changes, even if it's to bring technical improevements.

In NLTK's case, they have a whole book written around their project. Presumably significant changes to project structure and function would mean heavy documentation/writing work, and might not fit the goals of their project. Bashing them as a result just shows a complete lack of understanding of how/why people write and maintain software.

<comment><AUTHOR> I disagree strongly. This is the same difference as Linux vs Minix. Minix didn't want anything added as it was said to be for educational purposes even though that didn't reflect the use cases.

The author points out that whilst the stated aim of NLTK is for education, it's used for far more than that in industry and academia. You'll see it used in papers, you'll see it as the basis of real world projects, etc. This presents a problem if the aims of the project are different to the how the project is used.

The biggest flag for me is, as pointed out in the blog post, when the project doesn't even know how the part of speech (POS) model was trained[1]. That means a lack of reproducibility[2]. Given POS tags are the first level of almost any NLP task, this is strongly troubling.

[1]: "Where did the NLTK pos_tag model come from?" [https://github.com/nltk/nltk/issues/1063](https://github.com/nltk/nltk/issues/1063)

[2]: The POS tags from NLTK are used for many papers and research - <USER2> [https://scholar.google.com/scholar?as_ylo=2015&q=nltk&hl=en&...](https://scholar.google.com/scholar?as_ylo=2015&q=nltk&hl=en&as_sdt=0,5)

<comment><USER6> NLTK in research is probably mostly used as glue, its corpus interface, and its standard wrappers to common libraries. Everyone using it for research will do something like "I used data from NLTK, pushed it through my custom parser, and here's how it compares to the wrapped parsers that NLTK also interfaces with".

That's why the maintainer said, basically, "nope, we only implement the standard algorithms". Most of the researchers want to get standard data, and compare their new algorithm to the standard algorithms that every other researcher uses.

<comment><USER7> My blog post does explain the standard algorithms! Just, the ones that are standard _now_. That reply actually made no sense. I guess the maintainer thought that my post described novel research. It didn't.

There's now a ticket to implement the dynamic oracle, as I recommended: [https://github.com/nltk/nltk/issues/905](https://github.com/nltk/nltk/issues/905)

</comment></comment></comment></comment><comment><USER8> Very relatable post. Isn't NLTK primarily a teaching / demonstration tool though?

I just checked their website and the claim of _" NLTK is a leading platform for building Python programs to work with human language data... a suite of libraries for classification, tokenization, stemming, tagging, parsing, and semantic reasoning"_ does sound a little odd. But I think everyone in the industry knows NLTK's place and purpose -- you practically cannot avoid finding out quickly. NLTK's scope is clearly too broad to be meaningfully cutting edge at any one thing.

New libraries and implementations will always have an advantage. It's easier to tout "simplicity and leanness" when you don't have to carry over all the baggage and backward compatibility accumulated over the years.

For that reason, an occasional "complexity reset" is expected, and if a library would not or can not do it, another library will. Will SpaCy's fate be different, 10 years down the road?

<comment><USER7> > Will SpaCy's fate be different, 10 years down the road?

Yes --- because I consolidate my algorithms and delete dead code. I've probably written five or six times as much code as currently lives in spaCy.

I hope by then spaCy will be smaller, not bigger, as we reach a more concise understanding of how to actually solve the problem. For instance, it's reasonable to expect the boundary between the POS tagger, parser and entity recogniser to disappear, in the same way that spaCy doesn't feature a separate chunker or sentence boundary detector. I read these annotations off the parse tree.

<comment><USER9> A library that is constantly changing and removing "dead" code is a library nobody can rely on for production applications.

At first the complaint about NLTK was that it was too academic and not appropriate for real-world code, but no real-world code is going to rely on an unreliable library that keeps changing how it works.

<comment><USER7> You can maintain the API while overhauling the models underneath. spaCy so far has had almost no API breakages.

For instance, you get sentences as follows:

        doc = nlp(u'Hello world. This is a document.')
        for sent in doc.sents:
            for word in sent:
                ...

It doesn't matter to users whether behind the scenes, the sentence boundaries are being calculated from character heuristics, or from the syntactic parse. It was the former, now it's the latter. Similarly, part-of-speech tags are currently predicted in their own processing step. In future they may be predicted jointly with the parsing. The API won't change.

Other libraries ask users to choose between a variety of different statistical models, e.g. they ask you to specify that you want the "neural network dependency parser", or the "probabilistic context-free grammar parser", or whatever. By doing this they tie the API to those models.

spaCy just picks the best one and gives it to you. The benefit is that you don't need to be informed when a new model is implemented, even if the change is quite drastic. The modelling is a transient implementation detail, not exposed in the API.

</comment></comment></comment></comment><comment><USER10> Regarding dead (as in unused) code, I keep noticing the guys on my UI development team commenting out code and then committing it to Git. I remind them periodically that they can just delete the code and if they ever need it, they can use Git to pull up historical versions of the file for reference.

<comment><USER11> I think some people prefer commenting over deleting on version-control - <USER3> way, they can see how this code used to look like in the past.

It would be nice to have an emacs or vim plugin in which you select a block of code, and it slowly walks back the graph of commits, showing each commit for 5 seconds. That way you could nicely see how your code-block evolved over time... (of course in many cases the code-block itself is useless without context)

<comment><USER12> Time-traveling git blame visualization could be rad too.

</comment></comment></comment><comment><USER13> As someone who did contribute to NLTK quite a bit, it was quite useful back in the day especially when I had to teach NLP/CL to linguistics (non-CS) graduate students. I agree with Radim that NLTK has a purpose - and it's not to implement the latest and the greatest NLP algorithms. I'm glad NLTK exists and although it is not what I use today, I'm pretty sure whatever I do use today (CoreNLP, gensim, etc.) will all be superseded by the next best thing a decade from now.

</comment><comment><USER4> I've updated the NLTK issue tracker with information about how the model for NLTK's built-in POS tagger was trained: [https://github.com/nltk/nltk/issues/1063#issuecomment-138005...](https://github.com/nltk/nltk/issues/1063#issuecomment-138005116)

The second edition of the book will include a "scaling up" section in most chapters, which shows how to transition from NLTK's pure Python implementations to NLTK's wrappers for the Stanford tools.

</comment><comment><USER14> I put all dead code in a file called "deadcode.c" and get done with it. If I need it again, I can always copy from there. Easier than searching through git history.

<comment><USER15> Ouch, this sounds terrible. What if two functions/classes/top-level-constructs have the same name (and signature)? Now you have a conflict and your project won't build anymore.

Use version control, develop new features in branches, merge to master + tag. There.

<comment><USER16> > What if two functions [...] have the same name?

Presumably, the compiler never sees deadcode.c. Or did I misunderstand the question?

<comment><USER14> deadcode.c is excluded from make. It's deadcode anyway.

</comment></comment></comment></comment><comment><USER17> I like the gist of this post, but it feels somewhat incomplete: NTLK is Apache licensed and spaCy is a dual-licensed (AGPL or money) commercial product. It's a good idea and an honest business, and I hope he succeeds, but I think it would've been more honest if the article had reflected that.

</comment><comment><USER18> Can someone explain the following comments, for someone with some knowledge of ML but none of NLP? "First, it's really much better to use Averaged Perceptron, or some other method which can be trained in an error-driven way. You don't want to do batch learning. Batch learning makes it difficult to train from negative examples effectively, and this makes a very big difference to accuracy" I thought that it was typical for suitably regularized batch methods to modestly outperform or at least match (in terms of accuracy) online methods, whose main advantage is their speed.

<comment><USER7> Reading it back my comment wasn't the best explanation of the issue.

The reason is that what we're really doing here is predicting a structure (a parse tree), but we've encoded the problem as a series of local steps. Think of this like, what we want to do is navigate to a goal, and we'll do this by predicting a series of local actions.

Try stepping through the decision process.[1] This should give you a feel for the local decisions, and how they build the larger structure.

If we use an online learner, we can take advantage of an analytic method introduced in 2012 of calculating the global loss of a local action (the "dynamic oracle"), to do imitation learning.

Specifically, during training we generate examples with the parser, and label them with this "dynamic oracle". A large batch size means we're generating the examples with a model that's "out of date".

[1] [http://spacy.io/displacy/?manual=Shift%20words%20onto%20the%...](http://spacy.io/displacy/?manual=Shift%20words%20onto%20the%20stack.%20Create%20left%20and%20right%20arcs%20between%20the%20word%20on%20top%20of%20the%20stack%20and%20the%20word%20at%20the%20start%20of%20the%20buffer.%20Pop%20words%20from%20the%20stack).

</comment></comment><comment><USER19> The theoretically "best" algorithm may not necessarily be the one that fits a particular task or set of constraints the best. It is presumptuous of the author to know what's best for every user of the toolkit.

I suggest that the author, being so wise in the ways of NLP science, channel this outrage and write "NLTK: The Good Parts" to save the rest of the world from stumbling blindly in the dark wilderness of ignorance.

</comment><comment><USER20> So rather than jump in and start adding documentation you blast the developers, who are offering this stuff free and without warranty or implied fitness for any purpose?

You can contribute by adding documentation where you see it lacking, especially if you have domain specific knowledge that would help others.

Or you can blast the entire project, not help, and go write your own. The thing that bothers me is that if you know enough, and it's mostly a teaching tool (my understanding from other comments), you could greatly improve the situation for the next guy by providing your enlightened input on the subject in the form of documentation. So the whole damn community loses out on your hard-earned understanding.

Meanwhile, 10 years from now, your project will be replaced, and if NLTK is really a teaching tool, you won't even be a footnote (because teaching tools don't die unless a whole field dies).

This smacks of the kind of "bubble" Silicon Valley entitlement that I can't quite wrap my head around (I know, author isn't in SV, I just see this kind of crap coming from there).

<comment><USER21> The author clearly states why they didn't choose to contribute to NLTK: "You can't contribute to a project if you believe that the first thing that they should do is throw almost all of it away."

Whether or not you think that's actually true, if someone does believe that, that's a good reason not to contribute to a project.

<comment><USER20> Good point.

So I take umbrage with his belief that the whole thing (which is apparently well and actively used, and could benefit from his input) should be thrown out, and think he's petulant and certainly not a good collaborator (or community actor).

</comment></comment></comment><comment><USER22> NLTK would include state-of-art openly and "nicely" license implementation soon: [https://github.com/nltk/nltk/issues/1110](https://github.com/nltk/nltk/issues/1110)

</comment><comment><USER23> New to NLP we tried NLTK first for a toy project and it was very slow and inaccurate. Luckily we found spaCy, switched to it and sped things up 10x with better accuracy and it was easier to use. Based on this experience I tend to agree with the author.

</comment><comment><USER24> NLTK = education

OpenNLP = production

I thought that was a known fact

<comment><USER25> OpenNLP has never struck me as anywhere near as robust as NLTK.

<comment><USER26> We use OpenNLP in production and it is very stable/robust (though, not exactly cutting-edge anymore). We regularly push large corpora (e.g. German Wikipedia or 20 years of newspaper text) through some OpenNLP-based services, without any problems. This in contrast to some other tools, which I won't name, that have horrible concurrency issues, etc.

<comment><USER27> It would be helpful if you named the other ones -- always useful to hear examples of what works and doesn't.</comment></comment></comment></comment>


A blueprint for coexistence of humans and AI - <AUTHOR> https://www.wired.com/story/a-blueprint-for-coexistence-with-artificial-intelligence/ <comment><AUTHOR> The "singularity" hypothesis extrapolates exponential growth from the recent boom, but ignores the fact that continued exponential growth requires scientific breakthroughs that are unlikely to be solved for a hundred years, if ever.</comment>


Show HN: Cleanse – remove zero-width characters, replace text on all websites - <AUTHOR> https://chrome.google.com/webstore/detail/cleanse/pldjaflkihaacjhepjkfiadndghceiog <comment><AUTHOR> I know, another zero-width related extension, but it's a bit different.

Cleanse notifies you when a page contains zero-width characters and removes them automatically. You can still trigger the removal manually if there are any content generated dynamically after page load.

Cleanse allows you to replace/remove any string you'd like on all websites. One potential use case is for parents to replace inappropriate words with something else. Another use case is for pranks. It also parses regex.

I've never built an extension before until today so feedback is much appreciated.</comment>


Ask HN: How to scale my interactive installations freelance business? - <AUTHOR> I run an interactive installations business where I build interactive experiences for museums, public spaces, events etc. think interactive floors, tables, and other custom immersive experiences. How can I scale this beyond my work-for-hire model? thoughts? <comment><USER2> Locations are unique. Anything that is site specific has to be custom. So long as you're in the business of delivering site specific artifacts, then the business is closer to the free-lance end of the spectrum.

Products are products because they are generic/universal and can scale. Museums don't buy products. Maybe there's a middle point of a platform that the end user can customize. On the other hand, museums and events like to hire consultants to blame when things go wrong.

There are businesses that don't scale because completion of one piece of work product only has a correlation to future production of work products. I mean a successful installation contract increases the odds of getting another installation contract but has no meaningful effect on the effort to complete the second contract.

Good luck.

</comment><comment><USER3> Where are you based? Is your stuff good?

<comment><AUTHOR> Based in Europe. My stuff has won awards and I've been hired by large companies. Just tired of freelancing.</comment></comment>


Open Street Map – The Free Wiki World Map - <AUTHOR> http://www.openstreetmap.org/

<comment><USER2> Open Street Map is interesting. I decided to check out an obscure suburb where I used to live (because the data for New York City is obviously going to be fine). One issue that has been debated there for the last 30 years, it seems, is extending a freeway called Route 53. The project is called "FAP 342".

Open Street Map shows this thing as built and existing: <http://osm.org/go/ZVItJYIM->

Very confusing, as it is definitely not built (and probably never will be).

<comment><USER3> The idea is that you now go in and edit the status of this road from "under construction" to something more appropriate. The problem of course is that editing the map [1] is a lot more difficult than editing a Wikipedia page, which is why less people are participating.

I think it's also worth mentioning that in places other than your suburb, OSM is better than other publicly available maps, see for example [2].

[1] <http://wiki.openstreetmap.org/wiki/Beginners_Guide_1.3>

[2] [http://www.guardian.co.uk/news/datablog/2012/mar/28/openstre...](http://www.guardian.co.uk/news/datablog/2012/mar/28/openstreetmap- google-maps-technologies)

</comment></comment><comment><USER4> Why the heck is this on front page of HN? I am flagging it now. Apparently there are still people haven't heard of this and this is why reposts will always be popular.

<comment><AUTHOR> From the HN Guidelines[1]:

 _"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did."_

[1] - <http://ycombinator.com/newsguidelines.html>

<comment><USER4> Thanks for heads up, I didn't know that.

</comment></comment></comment><comment><USER5> <http://wikimapia.org/> is another good one. Allows for annotating buildings etc. in the satellite view.

<comment><USER6> Keep in mind that WikiMapia is breaking Google's terms of use and they don't release the data they collect. It's a neat project, but completely orthogonal to OSM.

</comment></comment><comment><USER7> i still find it very difficult to read. much harder than google's tiles.

[http://www.openstreetmap.org/?lat=48.8432&lon=2.356&...](http://www.openstreetmap.org/?lat=48.8432&lon=2.356&zoom=14&layers=M) vs [https://maps.google.com/maps?q=48.8432,+2.356&hl=en&...](https://maps.google.com/maps?q=48.8432,+2.356&hl=en&ll=48.843254,2.361374&spn=0.096028,0.264187&sll=48.839413,2.354679&sspn=0.096035,0.264187&gl=us&t=m&z=13)

here's a google cache of an analysis from a while back:

[http://webcache.googleusercontent.com/search?q=cache:k2wum-J...](http://webcache.googleusercontent.com/search?q=cache:k2wum- JAzLgJ:geoit.posterous.com/41latitude-google-maps-label- readability+&cd=1&hl=en&ct=clnk&gl=us)

<comment><USER6> Keep in mind that OpenStreetMap is a data project, not a maps.google.com replacement project. There are plenty of other ways to look at OSM data. <https://tiles.mapbox.com/newmap> and <http://maps.cloudmade.com/editor> let you style the data yourself, <http://open.mapquest.com/> lets you route and search across it. <https://github.com/mapbox/osm-bright> is a good start at building your own style. <http://osmbuildings.com/> uses CSS to draw 3D buildings based on OSM data. <http://bl.ocks.org/migurski/5130639> renders it in your browser with WebGL.

The tiles shown at openstreetmap.org are meant as a tool for mappers to help with mapping and are not our product.

</comment></comment><comment><USER8> foursquare switched to OSM last year after google changed its maps API pricing: [http://blog.foursquare.com/2012/02/29/foursquare-is- joining-...](http://blog.foursquare.com/2012/02/29/foursquare-is-joining-the- openstreetmap-movement-say-hi-to-pretty-new-maps/)

</comment><comment><USER9> link to the homepage of openstreetmap??

<comment><USER10> I was surprised too. Lots of karma whoring around here?</comment></comment>