jwecker

Spam-detection poisoning

It doesn't look like it's trying to be a startup at all, just showing an idea to HN- but I guess you're saying it should be more of an "ask for early feedback on HN" instead of "Show HN"- which implies show something that is working. I'm OK with "Show HN" being the default idiom for anyone posting their own link. Guess it could have had a "(proposal)" or something in the title.

True, but that's my point- it's a backend issue, not a front-end "help the user" issue.

An email address isn't a document though, it's a routing command. I don't mean sanitization in the sense of inserting backslashes. I mean sanitization in the sense of "we don't allow people to set their email address to a mailbox on localhost at our mail server."

Back when SMTP servers still had remnants of UUCP etc.- where the address could actually contain characters that specify intermediate servers to route to, I would have argued that front-end sanitization was important as, for example, html sanitization from end-users from a security perspective.

However, IETF made lots of progress simplifying things- to the point where, at the very least, the standard tells us specifically that we should leave it up to the destination host to interpret the local part of the email address-- that is, the thing to the right of the @ should be given the thing on the left unmolested ideally- even being ignored by intermediate relay servers. Since that's what most people complain about, any validation to the left of the @ should become extinct.

But off the top of my head that still leaves the thing on the right of the @ (such as localhost), buffer overflows by allowing longer strings than the standard allows (those limits do exist), and the problem with multiple @ which the MTA may or may not handle well... Since I'm not a security expert I'm going to go out on a limb and assume that I'm missing a bunch of other things.

My point is not that the article is wrong, though- my point is that if he wanted to convince me to only validate by sending the email on any string, he should convince me that those security concerns are not an issue- not that it's not good at catching type-os.

I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses.

With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localhost. Now it becomes a problem- or at least a question and concern- for the backend system. Whether the backend interprets root@localhost as valid and does exactly what it's told or rejects it due to some configuration- it has become a backend complication and a DOS attack vector.

A simple policy of only handling a subset- the common class of email addresses- is one of the things that allows us to have a simple mental model of what the MTA is supposed to do. The fact that it sometimes caught a type-o, or not, is incidental. "Invalid email" wasn't meant to imply the email address doesn't fit the spec- it was meant to imply that a particular site or service has chosen not to accept email addresses like that.

Or at least that's what I assumed :-)

I know the one. http://boxcar2d.com/ is similar (possibly based on the one you're referring to but it looks like it's been updated). Also this: http://rednuht.org/genetic_cars_2/

Replying to myself- too late to edit. Some other comments in here lead me to believe there would be experience-related questions ideally these days. Again, my experience was a few years ago :-)

This sounds like a huge improvement from when I talked with them a few years ago.

I agree with you, but it's still easier to fire someone than to un-not-hire someone ;-)

Makes sense for google. And it's not that I didn't appreciate doing all that (and I did do well), it just struck me how they knew nothing else about me afterward except that I could answer academic questions, and how different that was from the startup world- where, at the very least, you want to know what they're passionate about and that they are productive.

Asking an engineer what their strengths are and then to demonstrate or explain in concrete terms is how you find out their unique value proposition. I'm not talking about "I'm a hard worker" type garbage, I mean "my strongest experience is in systems programming on Linux." "How so?" "For example, I wrote a specialized TCP kernel module that works like this..."

Again, not saying that should be the whole interview- but there are some non-academic skills and experience (like managing and leading a critical system used by thousands of people) that are worth more than a few weaknesses in problems that were already solved years ago and that are easily looked up. It's how you should judge people looking to get into a graduate program, but falls short if you're trying to build teams of awesome fury that need more broad experience and even (gasp) unique experience that you don't have a ready-made question for ;-)

I interviewed @ google several years ago as part of some due-diligence they were doing to decide if they wanted to acquire the startup I was working at, [redacted].

It was several hours, with many interviewers one at a time, of academic exercises. Some I could see were relevant to some of Google's projects, but that wasn't the emphasis- it was very much a "how much do you remember from CS courses?" (with a few exceptions- one had me explain why a snippet of C would crash- something more what I would expect a senior engineer to know that was more practical-oriented).

I _think_ I did pretty well (again, it was part of a bigger due-diligence-- another story altogether, so I never heard), but in the end I was struck by the fact that (a) not a single interviewer had looked at or asked about any of my publicly available work, and (b) not a single one even asked something along the lines of "what are your strengths / what do you think your contribution would be" (or weaknesses, for that matter, but that seems less important).

Of course, one of the other guys I worked with lucked out and got interviewed by one of the paypal-mafia, and ended up with a reportedly very stimulating hour long discussion about actual work, strengths, and actual situations that one would hypothetically need to handle at google.

I was very excited to learn about recursive neural networks and how they are different from recurrent neural networks. I began imagining self-similar fractal topologies and automatic convolution layer creation etc... Disappointed to see it was just a typo :-)

Quick fix, in nim:

  foo_bar = fooBar
  Foo_bar = FooBar
  foo_bar != FooBar

I've mentioned elsewhere that this one bugged me at first, but in practice it simply means that you get to use the language as if your preferred convention (whether snake or camel) is the "official" one- even when calling other libraries. Nothing more and nothing less. Cases where you need both styles but need them to be different things tend to be non-existent / code-smell.

Comment voting ala hackernews / reddit would be useful but in this case so would some attached polls. The +1, -1 was from "back in the day" when it was a useful way for the active contributors to actually vote on something (or straw-poll it) in a mailing list etc.

It's annoying in some cases now because 1) it's anyone, not just the active contributors or even users, 2) people don't use it as a vote but as a general expression of support, 3) -1 isn't really used anymore so you can't scan them and see what the sentiment is, and 4) in this case, it's not even clear what they are lending support to- the merge, or that it is time to discuss a merge seriously.

So yeah, in this case it's noise but in some contexts +1/-1 is a quick and simple way to govern code and it has historical roots. Just ranting as I think they and some in this thread are a little too quick to judge. +1/-1 from the right people could be considered very relevant information to a discussion (esp. within a focused community).

In addition to ignoring the big picture economics, it makes rather silly claims such as "And with that [the elimination of the need to own cars], the elimination of entire industries built up around the existence of car ownership like: mechanics, car washes, parking..."

I think he's confusing eliminating the need to buy a whole car (dubious in the first place even if/ especially if they're automated) with the elimination of cars in general (???) Or he somehow thinks that part of "self-driving" means also self-fixing, self-washing, and cars that never park... roaming the streets in packs I suppose, ganging up on people when the cops aren't looking and stealing their jobs...

For posterity: The paper is here- and is very readable:

http://www.impactjournals.com/oncotarget/index.php?journal=o...

The pdf: http://www.impactjournals.com/oncotarget/index.php?journal=o...

Fun fact- Nimrod means mighty hunter. The negative connotation came from early Bugs Bunny cartoons where he applies the name sarcastically to Elmer Fudd.

This is my least favorite "feature" of Nim as well and almost killed my interest in it. But it hasn't come up in practice yet for me.

Fun to try with code (mildly). Here's the geekiest I could do that's worth sharing :-) http://i.imgur.com/IBaLCn4.png - based on the first stanza from the following:

   Tiger got to hunt,
   Bird got to fly;
   Lisper got to sit and wonder, (Y (Y Y))?

   Tiger got to sleep,
   Bird got to land;
   Lisper got to tell himself he understand.

      — Kurt Vonnegut, modified by Darius Bacon,

I was thinking the same thing. Best I could find was the developer email listed for his calculator app: https://play.google.com/store/apps/details?id=com.projectfan...

[Edit] Which makes me realize that the submitter for the original was him: https://news.ycombinator.com/user?id=pr_fancycorn - so that may lead to some way to contact him.

I enjoyed that far, far more than I expected. His intro from the index:

"So I was me and I was in math class watching paint dry it was starting to crack when suddenly I realized there was a page for which the internet was invented. I set out to create that page, ultimately succeeding with the sierpinski triangle page to end most sierpinski triangle pages ™.

...

So while the sierpinski triangle page to end most sierpinski triangle pages ™ purports to be some kind of exploratory rundown of the Sierpinski triangle, it's also a fractal expression of just how carried away I get..."

It's math like I like my music: when the author takes the subject seriously without taking themselves too seriously.

Thanks for the thoughtful response- it didn't come across as combative at all to me.

The true, provable safety of Rust was what drew me to it as well. I've always hated having to choose between un-principled memory management (with it's security and functionality vulnerabilities that can lie dormant for many years before kicking your butt) and garbage-collection forcing you away from the metal and removing deterministic reasoning about memory usage, runtime behavior, and runtime overhead.

I've been going through the academic papers, forerunners, and source-code for Rust's static memory routines and borrowing semantics. My hope and suspicion is that it can be added to Nim without core changes to the language like lifetimes. It's definitely not a guarantee, but with lots of experience in both languages now I feel very strongly that adding region-based-memory-management to Nim is possible while adding Nim's clarity, abstractions, and efficiency to Rust feels impossible.

I agree that at the moment Rust is the only responsible choice right now if provable memory safety is a primary concern, but I suspect that will change. In the mean-time, for us anyway, the price was too high in productivity when we discovered that we could do manual memory management in Nim in very well-considered isolated places and confidently use Nim's fast, real-time deterministic per-thread garbage-collection for everything else without a noticeable performance penalty.

Having said that, I don't think I actually disagree with anything you said (:

I actually coded a predecessor to the system under development a few years ago and have used Erlang and more recently Elixir a lot, but in the end it just wasn't low-level enough, fast enough, or runtime-free-enough for our current project (for example we need to generate real-time processing kernels that can run on GPUs and FPGAs-- a realm not even really contemplated at the Erlang level).

In my experience it's very responsive and rational. It benefits as a language from being opinionated which is sure to ruffle feathers from time-to-time. Obviously not as big of a community as some others, but that hasn't been an issue for us.

I've seen heated flamewars about important issues rarely, about non-important/emotional issues only very rarely and only in IRC (where the current official policy is "we're a new language so don't kick someone out unless absolutely necessary"). More often with Nim you'll see the occasional "wtf- who implemented this? it needs to change to ---". To be honest, IRC isn't the best place to judge a "community"- trolls and good people venting have disproportionate voice there. And to be honest, if that exchange referenced was disturbing... just hope you never have to be involved in a decision with the Linux kernel team or (the most abrasive example I have first-hand knowledge of) the Apache development team 10 years ago ;-)

Notice there's only one comment there from Araq and it's trying to de-escalate things. If you were to pop onto IRC and ask something technical or philosophical that wanted a rational response Araq or many of the others not represented in that slashdot comment will most likely answer very politely and rationally within a minute or so (I think he's in Germany though? so timing may be an issue).

I think a better "feel" for a community can be gauged by the tone and quality of blog entries coming out and threads in github issues / pull-requests than IRC snippets.

That and the fact that if you decide to use Nim based on its technical merits then you _are_ the community- and at this early stage you can easily influence the tenor of discussions and decision-making for good if you choose.

We just switched from Rust to Nim for a very large proprietary project I've been involved with after rejecting proofs of concept in Go and Erlang earlier in the process. This despite the fact that we had formally decided on Rust, had tons of code developed in it, and only stumbled upon Nim by complete accident randomly one day. Even though many large components were already developed in Rust we have already reached par and have shot ahead of where we were at. I don't want to diss Rust in any way (or Go for that matter), but I figure they both have corporate backing and can easily speak for themselves, whereas Nim does not- so I don't feel too bad offering our somewhat informed opinion :-)

In a nutshell, Go ended up not really being a systems language and Rust has the beautiful goal of memory safety and correctness without garbage collection but in the end feels like it's designed by committee.

Nim, with Araq it's benevolent dictator, has had the opportunity to be highly opinionated. Much of the time that seems to simply allow projects to either shoot themselves in the foot or stagnate, but occasionally it produces true gems- and I really feel like that's what Nim is.

Some aspects of Nim that keep blowing me away more and more:

* Truly allows you to be close to the metal/OS/libraries (most beautiful and simple ffi ever) AND simultaneously allows you to think about the problem at hand in terms of the problem- i.e., high level abstractions and DSL creation like you can do with Ruby (but even cleaner in many ways). I always thought those were two opposite ends of a spectrum and didn't expect a language to even attempt to bridge the chasm- then along comes Nim and not only attempts but succeeds beyond what I ever would have thought possible. To illustrate: it has become my go-to language for quick scripting, faster to whip something together than shell or ruby or perl (and many orders of magnitude faster to run- often even including the automatic compilation the first time)- while also being the fastest, cleanest, safest way to do something low-level, like a mmapped memory-mirrored super-fast circular buffer or cpu-cache optimized lock-free message passing...

* Even though it has C as an intermediate step, it doesn't feel or act anything like C. While not as strong as Rust in this area (I know, Rust goes straight to LLVM's IR instead of C- but the risks are the same)- it generates code that is much more safe (and concise) than writing it straight in C. I know, there are other language that do this well also- but usually by sacrificing the ability to easily and cleanly do system-level coding- like a raw OS system call, for example.

* On a related note, despite feeling more high level than Rust, it can do so much more at a low level. For example, using musl instead of glibc (which at least last time I checked wasn't possible in Rust due to some accidental coupling).

* So fast. While premature optimization is considered the root of all evil, and linear optimization often does not end up adding significant real value, I've been reminded more in the last few weeks than ever before that when speedups are around 2+ orders of magnitude _it is often a complete game changer_- it often allows you to model the problem in a completely new way (don't have a generally understandable example for Nim offhand but take docker vs dual-boot for an extreme non-Nim example- VMs were a mostly linear improvement over dual-booting and other network-based workarounds, but only with linux containers and their orders-of-magnitude "startup" time, snapshotting, etc. etc. was docker able to say "these are so cheap and fast we can assume a single running process per 'image'").

* Even though it's not as formally safe as Rust yet, in practice it feels and acts as safe, without the cognitive overload.

* Rust gets tons of new commits from tons of contributors every day. I worried when looking at Nim that the lower volume of commits meant that the language was less... alive or long-term-tenable. But on closer evaluation I realized that there was literally less that needed changing, and that the changes that seemed to need code to change all over the Rust repository would, given an equivalent scope in Nim, require trivial changes to just one or two files. (for example, Rust's massive [and extremely slow] bootstrapping pipeline and parsing architecture, vs Nim's built in PEG syntax and 5-line loop that keeps compiling itself using the last iterations' outputs until the outputs don't change anymore).

In short:

- All the simple beauty (IMO) and conciseness of a python-like/pseudocode-like syntax without all the plumbing and pedantic one-way that comes with python. In other words, beats python at python's own strengths (not even mentioning speed or language features etc...)

- Top-down modeling and DSL affinity like Ruby with less feeling of magic- e.g., better "grep"-ability and tracing. In fact, the DSLs and up being cleaner than idiomatic Ruby ones. So beats Ruby IMO at one of Ruby's core strengths.

- Seems as safe as Rust with much cleaner syntax and simpler semantics. (this is something we're actively quantifying at the moment). Easily 10x the productivity. _Almost_ beats Rust at its core strength.

- Easiest FFI integration of any language I've worked with, including possibly C/C++.

- All the low-level facilities of C/C++ without the undefined-behavior, with better static checking, much better meta-programming, etc. etc. Beats C/C++ at their core strength.

- Utterly intuitive obliteration of autotools/configure/makefile/directives type toolchains required for system development using C/C++.

- It's very fast and efficient per-thread garbage-collection (when you want it) essentially allows it to eat Go and Java's lunch as well.

- It's a genuinely fun language (for us at least).

I've already been too verbose and am out of time but I should include for some sense of completeness some current weaknesses of Nim. None of these ended up being remotely show-stoppers for us, but at least initially we worried about:

* Too much attention to windows (doing nix and even linux-only development is so easy it has turned out to be a non-issue).

Less safety than Rust when doing manual memory management (hasn't been an issue and we believe unlikely to be an issue in practice).

* Lack of (implied) long-term corporate support (already more stable than some others and community is strong where it counts. Also, no matter how much corporate support they get- Rust will still be more verbose and designed by committee and Go will still fall short of being a true to-the-metal systems programming language and neither will ever have Ruby and Lisp's moldability and endless potential to get out of your way).

* Smaller community/package ecosystem than many others (so easy to do FFI or to even _reimplement something done in C using 1/5 the code_ that it also has turned out to be a non-issue. Now I worry that it's so easy to code that it will have a library-bloat issue like Ruby requiring something like ruby-toolbox)

* "How have I not heard about this before?? Why isn't it bigger? Is something wrong with it?" I start worrying about things like D's standard-library wars or lisp & scheme's utter flexibility combined with poor readability... Nope, just new and only spread through word-of-mouth, like Ruby, Python, and Perl long ago...

[there, once I've written three separate lists in a single comment I can safely say I've said too much and should get back to work].

Point taken, and I acknowledged in my first comment that it was a weak reason compared to the reasons for adopting. It wasn't meant as advocacy :-)

I would point out however that no one (that I know of) claims that English is the most popular because it is intrinsically the most efficient for all situations- i.e., on its merits as an efficient language rather than geopolitical factors. I definitely think that there are certain situations where communicating using non-English would be (locally) optimal- even if the parties communicating were fluent in English. Even as a native English speaker I truly wish English had the equivalent of the Tagalog particle "daw/raw," for example ( http://tagaloglang.com/Tagalog-English-Dictionary/English-Tr... ), or the fact that Cantonese can often communicate the same information as English using far fewer syllables...

In other words, I'm perfectly fine saying that using English is globally optimal (and convenient for me) because of its adoption, while still being perfectly happy knowing that some languages have attributes that make them more efficient, if you know them, in certain circumstances. I don't pretend ex-facto that English got this way because it is a truly superior solution in all circumstances if only everyone knew it. Nor do I feel like English's status as a (quasi)-standard is threatened by someone pointing out that Swedish would be more efficient in some settings (say, family history) even if everyone did know English. I would say "cool."

Defining units in terms of other units via something other than base-10 scaling in order to have more integer factors than 2 and 5- in some cases trading the 5 for 3 and 4- can be advantageous. That's all I'm saying, nothing more or less :-)

No, I assumed they had a very good way of doing it, which is why I asked about it :-) It was a sincere request for comment but it obviously came off as a cynical challenge, which wasn't my intention.

You mean similar to how stock prices used to be demarcated or how foreign exchanges use 'pip' values? ;-) (http://www.cringely.com/2012/09/05/ticked-off-how-stock-mark...)

Seriously though good question. First though it made me realize that you never see prices in thirds of a dollar- as if everyone avoids it and have simply gotten used to avoiding it. I can't imagine a situation where ease of dividing by three for money actually adds any efficiency. Similarly, while I do see the value in dividing the day into 24 hours, I certainly wouldn't advocate a unit that's defined as one 60th of a second (even though it has even more prime factors than 12 ;)

I concede that the use-cases where having more prime factors and therefore easy non-decimal division are few and far between. I guess what surprised me when doing construction was that there was a very rational reason for a foot being 12 inches rather than 10- that it's not simply a relic of the fact that a human foot seems to be about 12 thumbs long- some arbitrary number accidentally ingrained in some cultures. And as illustrated by the fact that stocks were eventually decimalized and then made to trade at penny-granularity, computers and the fact that we don't do a lot of division in our heads or on paper anymore will probably eventually erase most remaining efficiencies.

I guess the real issue is which units get names. Yes, you can do with 12cm exactly what you can do with 12in- but the latter gets its own named unit. The Imperial system has a preference for scaling its units by some slightly more practical number of sub-units- 12, 60, etc. I can imagine someone saying, for example, "why name 1000 centimeters as another unit? Can't I say 'thousands' using the same number of syllables? What's worth naming a different unit is 240cm since that's used a lot with timber..."

Someone strictly advocating the metric system would say "that's the point, kilo is another way of saying 1000 no matter where you live in the world or what you're measuring. Feel free to call 240cm a 'frob' if you like, but please, only do so in private- don't order 14 frobs of lumber, order 33.6 meters." (edit: which is a perfectly valid point. It's the slow accumulation of frobs that made the imperial system untenable. We trade a little bit of efficiency at a local level for greater global efficiency when we adopt metric.)