You know this is a special pet peeve of mine. I have stopped myself several times from complaining about this very

For a period of a few years, a few years ago, I started shopping very frequently for pants, shirts, etc. I once caught myself wondering why that was the case. The answer surprised me: I was not happy with the stuff I was buying. They would not fit comfortably after the initial wear.

Then I noticed what was really the problem:

1) Pants are getting shorter, mostly in the inseams - the distance from the belt loops to bottom of the zippers. (In other words, pants now "sit below the hip", there is no more those that "sit at the hip").

2) Shirts are getting shorter too. They don't go as far down under your belt as they used too.

So, just these two combinations leave a good part of my lower belly exposed quickly and easily, something I do "not" like.

3) It is quite hard to find pants with basic options, like pleats and cuffs. Everything is flat fronted, it seems.

So, it is easy to see why no one is shopping any more unless they really have to.

Just my 2 cents :-)

Congratulations on seeing the opportunity and quickly moving to do something about it. It is unique enough at first sight that you got early coverage in the press, which is very helpful.

Quick question: I did not see anything unique to "old geek" in the website, other than the URL of course. I guess it is an implicit assumption by both job seekers as well as job posters.

On that note, where would this concept be headed if other job sites added a simple attribute called age (or something similar but more palatable) where job posters could specify their preferred age range, and job seekers could search on it?

Just curious:

What kind of a demand is there for a pipes-kind of product or even a customizable/searchable rss/feed integrator?

How much would a typical user be willing to pay for it?

A few days ago, in a moment of 6-degrees of youtube, I came across a flat earth video. Out of curisoity to see what their beef was, I watched one. It was interesting. One of the claims was that all of the earth images we have are not actual photos or pictures per se, but rather, artists renditions (I think they used a different term which I don't recall at the moment). Apparently, this point was admitted to by NASA too. And they had pictures of earth from space (taken and distributed by NASA) over the years where continent sizes change drastically on the same circle. One of them even had "sex" spelled in the clouds.

Watching this, it too looks like an artist rendition. Notice how the moon moves in a straight line. And while the earth rotates around, the moon doesn't. That is fine as we see only the same side/face of the moon but remember: this is taken from far far away so, at that distance and angle, you should be able to pick up a change in the moon's rotation as well. Here, we don't.

Interesting indeed.

OK. But I am curious how it maps a phone number to a carrier. My understanding is that carriers do not publish the list of their customer phone numbers.

It seems like textbelt does not know this information (or at least when you sign up or send a text message). Does it try in sequence to send the text to all carriers one by one until one succeeds? If so, I'd imagine textbelt would get blacklisted pretty quickly.

It would be interesting to see how the mapping is done.

That's an interesting question, but I think that Textbelt is intended to be used in a scenario where you ask the user to select their carrier in addition to their phone number.

I have used Lisp, Scheme, Prolog (and multiple dialects of each) for extended periods in large projects. Each was a pleasure to work with. They all have their own advantages. I am not sure if there is value in arguing over x feature of one language vs. y of another. As a matter of fact, it was fun to write Prolog interpreters in Lisp, and Lisp interpreters in Prolog, for example. (Many courses / textbooks (used to) present these as side projects to do and the task is simpler than it sounds.) One could say Tcl is really an extension of Lisp or Prolog in its core concepts of syntax, data and program equality, style of interpretation, etc.

I agree wholeheartedly with the last paragraph of Mr. Ousterhout's reply here - and I must say, a smart, classy and almost Tcl-ish way of a jab at its distractors:

http://vanderburg.org/old_pages/Tcl/war/0009.html

I came across Tcl/Tk while doing Motif in a large C-based project. I simply couldn't believe how powerful, simple and succint Tk was compared to Motif (or anything else since). And it ran on Windows, Unix, Linux and Mac OS, to boot. It was too late for that project to switch, but all my other projects have used Tk if they ever needed a UI.

Similarly with Tcl. I still think the best introduction is Mr. Ousterhout's original Tcl/Tk book. It stands as one of the best language books on my shelf. Combined with Tk, one can put together a working application prototype in no time.

Of course, this was eons ago. Nowadays, Tcl offers one of the best environments with a complete set of packages ranging from web servers to image and sound processing. Plus, you can distirbute your program and all of its media and support files easily as well.

I believe Tcl has been mischaracterized and has suffered in terms of open popularity. But for insiders, it remains as one of those secret indispensable Ninja tools that is used over and over again for competitive advantage.

A bit off topic: did you really use Prolog for something else than just research? That is, did you write software that was used in production? I have learned it many years ago but always had a nagging feeling that it is better to use a "normal" language with AI libraries if you need the program to actually do something... Did I miss anything?

Most of my Prolog experience was in academics - for my own research as well as for maintaining some existing packages. But I did get to use it outside as well. There are many cases where a controlled language is needed or comes in handy and solves a lot of issues. This is where Prolog shines - plus you get to use a lot of the previous stuff you developed as well.

When it comes to an "AI" language vs. typical language with an "AI" library, I will just repeat a phrase that is often used in the field: what you thinnk of as an AI problem today will no longer be considered AI tomorrow, since it will then be well-understood and implemented in many places. People used to say that in response to the (seeming lack of) progress AI had made to date. A good example of that is Siri or Amazon Echo. Not many people consider it an AI problem anymore, or so it seems.

Hello,

I haven't read the book but I am planning to.

I caught the last few minutes of your interview on NPR the other day. You said you built the FB Exchange. I made a mental note to look that up later and now serendipitously, it shows up here. Anyhow, not familiar with it but it sounded like some sort of an interface to Amazon. Would you care to elaborate?

Exchange is/was FB's retargeting/remarketing solution, AKA "we will follow you everywhere you go on the Web and remind you that you once looked at a pair of shoes on our site." Some detail would be cool -- adtech is intrinsically interesting, if ethically somewhat murky.

True!

This.

I have given similar demos. You first explain what you are going to do. Before the demo, they go all go into "no, it is impossible. I have been in this business for 20 years. Blah blah." You demo it, and once in a while, they get it, their jaws drop and they appreciate it. But mostly, it is a suspicious disbelief, followed by adversarial challenges where they insist you disclose everything under the covers right then and there.

I have even heard this: If this was possible, why hasn't IBM done it?

Sometimes, it is pretty depressing.

We have been doing this in all of our web applications for over a decade now. Essentially, whenever there is an error, we don't just display the error message as-is. All the technical or trace info it contains seems to scare users. So, we simply encrypt it and display a base64-encoded version of it. It also gets saved into a log file.

Users are more comfortable with this way: they simply copy/paste the text to us and we have all the info we need.

What happens if there's an error in the crypto handling system? Edit: Not a troll, I'm seriously interested in "minimum required functional systems" in the case.

There is no other dependency in the encoder/decoder functions so there is no point of failure there. Those functions were developed a long time ago and have not changed. They work with any stream of data and automatically chop off the input after the first few hundred characters. This contains more than enough info for the developers to see exactly what caused the error.

In any case, even if, as you say, if the crypto handling system failed, and it returned nothing, there was no critical information that was lost. Only information on an error message, which you will hear from the user anyway.

Aah, I was thinking you might be encoding stack traces or equivalents which you'd want to protect a lot more than the head of user submitted data which the user chooses to re-submit through a seperate channel that is about as secure (esp for the purposes (email)) as the original channel. A hard coded key would be fine for this imho as you don't have to protect the user from the user's own data.

Cool idea btw.