My email cleaning habit lasts only as long as my New Year’s resolution :) Every few days, I try to slim down my bloated inbox by deleting emails in bulk and then I make a promise to myself to keep doing it regularly which never happens :) If you can relate to my predicament, chances are I’m not alone.

Approximately 90% of the emails I receive are subscriptions, mailing lists, and updates. Most of them lose their relevance within 2–3 days, and if I don’t catch them during that time, chances are I never will. So what if I could set up a filter to automatically delete emails from specific senders after, let’s say, 72 hours unless I explicitly mark them not to be deleted? This simple feature would streamline email management, transforming it into a one-time task.

While services like Gmail and Outlook do offer date-based filters, they, surprisingly, cannot execute these filters automatically (like a cron job). Instead, users are required to manually run each filter. I once suggested this feature to Gmail, but it was never implemented for reasons best known to them.

What are your thoughts?

The Case for Disappearing Emails was originally published in Yusuf Motiwala on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Python developer emailed us:

Your Python APIs not working as expected …

This email was especially concerning since it came from one of our biggest corporate customers in Europe. They already deployed plenty of projects using mesibo, although using the mesibo Python APIs for the first time.

The strange part of this email was the code they shared — a piece of code having a mix of mesibo APIs that we don’t even recognize, depreciated APIs, and the latest APIs. We were puzzled by this code fusion, especially since we have very well-documented APIs and tutorials, and nowhere have we documented such a fusion code sample.

So we asked him, where he got this sample code from, and he replied,

I got it from ChatGPT

Ouch!! Didn’t expect customers to ask ChatGPT for mesibo help rather than referring to documents. But with the exploded popularity of CultGPT, this is just the beginning (there was a talk @ Stanford the last week — “Can ChatGPT diagnose me?)”

Frankly, we would have loved it if ChatGPT did the job, or even did it fairly, or would have declined to answer. However, the real problem was not the wrong answer, but rather how meticulously it composed the wrong answer that it feels more authentic than the correct answer, to the extent that the customer complained about mesibo API not working rather than doubting ChatGPT responses.

It wasn’t difficult to reproduce what our customer experienced. We learned that ChatGPT LLM (large language model) algorithm incorrectly overrides the learning with its interpretation. For example, mesibo Javascript API is documented to be hosted on api.mesibo.com. However, lots of websites host their APIs on the CDN subdomain such as cdn.example.com. The ChatGPT combined two learnings and created a fictitious domain cdn.mesibo.com which is incorrect. The answer would have been correct if the ChatGPT used its interpretation only if there was missing information in its learning dataset.

In another example, instead of using its learning from the mesibo website, it synthesized a new API and even described it — the Minority Report has some influence here :)

Precogs

On a lighter note, since the ChatGPT performed quite badly in producing correct responses, those meticulously written steps sounded a bit political — nice to read but totally incorrect :))

ChatGPT is amazing but it needs to fix the Illusionary Truth effect it exhibits right now — some cautions till then.

ChatGPT: Beautiful Liar! was originally published in Yusuf Motiwala on Medium, where people are continuing the conversation by highlighting and responding to this story.

I came across this post while checking my inactive blog on archive.org. Although the article is dated (2009) and some of the technologies, specs, and links may not be relevant today, the VoiceXML part is still relevant as much as it was in 2009 and hence thought it is worth sharing — please read keeping in mind that it was written in 2009 and posted here ASIS.

History
The original article was an attempt to identify some of the key deficiencies of VoiceXML as a programming language for voice, and why we created VoicePHP in 2008 as a viable replacement of VoiceXML On its release, VoicePHP was praised by many, a notable quote from none other than GigaOM, Om Malik — “The idea of VoicePHP is Disruptive in its Simplicity”. This article follows why we did. You can view the original blog post and comments here.

VoiceXML — Good, Bad & the Ugly

While XML (and in general any marking language) has been great for representing the data, using it for programming is like using a wrench to hit a nail. All you need is a hammer to nail! Although a wrench can do a manageable job of hitting a nail, it’s not elegant, creates a mess, and cannot address the problem with precision. The same is the case with XML It is best suited for and was designed for data representation, data-transfer and has repeatedly proven its worth for the same. Trying to use that for programming is adapting it for something that it inherently wasn’t meant to do. Let me try and explain this in detail:

Consider a typical “hello world” application in VoiceXML (courtesy, vxml.org).

It took 10 lines of code to write something as simple as that. On top of it, for a simple hello world application, one may be tempted to seek more information about <form> and <block> tags which seem like overkill.

Shocked? You are not alone. As Dominique Boucher states on his blog

from a developer’s perspective, it’s (VoiceXML) like having to program in Cobol! And I only slightly exaggerate

The same application in PHP is reduced to barely 2–3 lines of code which is more readable and intuitive.

See the difference? Don’t take my word for it, here is what veterans and users say about VoiceXML. We will soon dwell on why do they say so.

From the Industry Veterans

In early 2007, Brian OConnor commented on annoyance in VXML standards. As he states, he was unable to use <if> within a <prompt> tag. It’s an arbitrary limitation and requires a nasty workaround.

In the article “ Is VoiceXML the Right Tool for Your Voice Application?”, Brian Brown identifies very precise weaknesses of VoiceXML. For example, when even basic voice controls (pause, resume, etc) are not available in VoiceXML, how it can be even considered the language to program voice? He nailed the problem very well. Look at how VoicePHP addresses it beautifully in a sample application here.

Dannis in his interesting email and unique style shares the pain of VoiceXML,

“TCL was the most ugly languge of the 90-ies. VXML has now taken over. The language appears not to have iteration (while, for) and no recursion. But it DOES have the goto primitive, which was banned by Dijkstra 30 years ago. There is no function abstraction and neither object-oriented constructs. “

He further adds which I will elaborate on later in this post

“ VXML is an interpreted language using Javascript. Why not using only Javascript with a bundle of speech specific predefined functions? Hacking java-servlet code already entails generating HTML and Javascript. I don’t see why we have to follow the same painful route with VXML”

Even VoiceXML vendors are aware of the limitations and they have tried to create specific & proprietary enhancements to get around VoiceXML limitations, for example, CallXML by Voxeo. In fact, Voxeo CEO commented on VoicePHP coverage by Gigaom that

“ As a developer, I do not like VoiceXML. Personally, I find it to be too complicated, painful, and a barrier to entry for new developers as others have said. This is why Voxeo offers many other ways to create voice applications, including CallXML — a very powerful yet simple XML based telephony markup; “.

Do I need to say anything more?

The big question — Why do veterans say so?

Unorganized jungle of XML, JavaScript, CDATA, etc.

In my opinion, VoiceXML looks like a creation out of obsession. XML was the new kid on the block and perhaps impressed or obsessed by it, somehow fitting it to the Voice programming needs became the name of the game. Basic TTS & ASR was made to work — wow! So far so good!

Then someone realized that even simple/common programming requirements cannot be done in XML. There wasn’t a simple solution to address this in XML and that’s how Javascript (ECMAScript) became a part of the VoiceXML standard. In my vocabulary, this is nothing more than a “workaround”. If Javascript was being considered then why not do everything in Javascript? When Javascript can completely replace XML (exactly like VoicePHP), is there any logical reason to keep XML around and more importantly continue it as a “standard”? To be honest, this workaround has only made the life of programmers complex. To illustrate, consider the following sample code that reads out a caller-id ( courtesy):

Now compare this code with the VoicePHP equivalent (demo here):

What a mind-blowing difference between both the solutions. Maybe the above example demonstrates the point we all are trying to make. A workaround v/s a natural programming language. As one can see from the above example, VoiceXML has to fall back upon Javascript since XML cannot even have the basic capabilities to manipulate the numbers or strings, how can it be even considered for programming.

As you explore more, you will realize that VoiceXML is handicapped enough even not to be able to offer simple loops on its own. Can you imagine an application without such a basic control statement & despite that, such basic structures were not addressed in VoiceXML. VoiceXML simply falls back to Javascript for doing such basic stuff in a messy way.

In contrast, take a look at just about any application at http://code.voicephp.com to see how easily one can take an existing application and move over to VoicePHP with all the programming constructs usually available in most programming languages.

CDATA — Add it to the mess

Well, it keeps getting better. To bring in Javascript, VoiceXML uses the CDATA directive. What is going on? Isn’t it messy already? Why do I have to care about all the subtleties? For curious minds, the CDATA directive is used so that our script can contain characters that are normally reserved for XML syntax usage.

It’s truly getting messy — XML, Javascript, CDATA, and off-course unreadable code. Keep in mind all that we have done so far is really just “read out a phone number”. It begs to me ask this question: Why is it so damn complicated?

Consider the code for the first tutorial on Voice Recognition from vxml.org.

I am sure you need a coffee break after reading the above code; the code looks verbose, repetitive, and unmanageable. This same application when written in a commonly used ‘real’ programming language will have a lot less code and will read much better. Again refer to any code snippet at http://code.voicephp.com

Server-side programming

One cannot use VoiceXML by itself to write a complete application. For even simple client-side processing you need Javascript. Moving on, if you need to integrate some back-end logic (a.k.a Server-side programming), you need to take the help of one of the commonly used back-end technologies (e.g. PHP, ASP, .NET, etc.).

This is not me saying but vxml.org —

“ Coding an application with just straight VoiceXML is just fine and dandy, thankyouverymuch, but the *real* potential of VoiceXML is harnessed when we add some ASP or JSP into the mix “

Look at the emphasis on “real”. I sincerely appreciate their candid confession and applaud them for succinctly putting the limitation of VoiceXML across so distinctly. So as you can see, in addition to learning VoiceXML tags and attributes, Javascript, and a different programming style, one now has also to learn a server-side language. Think about it — you need a chilled beer to relax but you are being given a cocktail — like it or not!

In Closing

Any way you slice it; VoiceXML doesn’t come close to meeting the requirements of real-world applications. Voice applications would do really well if there was an easy way to bring them to life. Developers do not want to use complicated technology to achieve something simple, intuitive, and obvious — I know I won’t.

We are not against VoiceXML. In fact, VoiceXML spearheaded the way for voice programming and took away the complexity that one had to deal with in the early days (remember hardware card and proprietary drivers nightmare?). When it launched, VoiceXML was the “new” way to program voice and we were completely supportive of it too. We released the world’s first “ Adobe Flash-based VoiceXML Platform “.

But it’s about time that VoiceXML realizes its inadequacies and makes way for better alternatives. Alternatives like VoicePHP (or maybe even VoicePERL or VoicePYTHON) could do a better job. The web is evolving and solutions that can tightly integrate with it will become more and more important. Dedicated solutions to tackle a specific problem are a thing of the past. Some technologies (e.g. PHP for web programming, Flash for UI and widgets, Mobile applications using a data network, etc.) have proven themselves and it’s about time that we re-use them and not bind ourselves to technologies that began with the right attitude to solve a problem but couldn’t really establish themselves due to technical limitations.

Originally published at https://web.archive.org.

VoiceXML — Good, Bad & the Ugly was originally published in Yusuf Motiwala on Medium, where people are continuing the conversation by highlighting and responding to this story.

Well, Elon is no longer a piece of news anymore, I rather call him a daily feature :). However, the ‘Inventor of email` piqued my curiosity, because it reminded me of those early internet days when we all were inventors (just like multiple claims on who invented email) :) The internet speed was slow, browsers didn’t support compression, and my need to have faster browsing gave birth to first prototype of HTTP compression in the browser, although mostly met with mixed reactions (like any other new idea), soon it became the standard.

I wasn’t savvy enough to write about it then, nor would I have ever written about it unless this news prompted me. So here is a short article from my memory of those days and how it happened. It may sound like a tall claim, but the internet never forgets and thankfully, my post about this prototype in 1996 on Linux net archive is still live, making it easy to compare dates with compression support release dates in browsers.

Those Days…

1996, I was a student at the Indian Institute of Technology, Bombay. Not many of us could afford internet then, but we were lucky to have access to a 64kbps internet line (ernet.in). It might feel painfully slow by the current standards but it felt like an expressway in those days. This is true compared to the 9.6kbps connection offered by VSNL (for a whopping Rs. 25,000 for 250 hours).

It did feel slow sometimes though, downloading Slackware took over a day. However, browsing was more painful, especially webpages with images that could take a few minutes, we could even go and pick up tea and it was still loading which made me a tea addict :). This was especially true during peak hours, unfortunately, there were no off-peak hours, should I be reminding you of IRC during those days? :)

Need is the mother of Invention — Creation of the first HTTP compression prototype

In our quest for faster browsing and sending free emails (IIT would charge us Rs. 4 per email back than, pre-Hotmail), some of us would use an alternative — free US-based telnet servers. We would log into those servers, send emails (elm, pine), and also browse using Lynx instead of using overloaded and bandwidth-limited port 80 on the campus.

However, text browsing inside a console on state-of-the-art DEC Alpha and Silicon Graphics IRIX was no fun. I had more addictions as you can see, so I soon worked out a solution — running proxy servers on those telnet servers and setting proxy in Netscape.

Life was much better now — the browsing speed had definitely improved but it was still not good enough. However, seems like some forces wanted me to work on this, soon there was a tipping point, bzip2, which was released in 1996 and created a good buzz. Suddenly I started connecting browsing and the compression — what if all HTML files were compressed on the server and then decompressed by browsers — the browsing would be multifold faster. Wow, I praised myself and started working on a quick prototype!

Note that internet speed was not the only reason for slow browsing, there was also no compression or content negotiation used in HTTP/1.0 at that time. The entire traffic was uncompressed. No browser was supporting “Accept-Encoding:” (required to request compressed content from the server) including the most popular browser then, Netscape. The first Netscape version to support “Accept-Encoding:” was 4.06, released in Aug 1998 (history). Interestingly IE 4 did implement earlier in Sep 1997 and much later by Opera 4 (around the year 2000). Lynx was earliest in 2.6 which was released around Sep 1996 but then working compression support came later, along with the first HTTP/1.1 standard in early 1997.

I started working on combining HTTP and compression, and soon created a prototype where the contents were compressed on the fly on the server and then decompressed upon receiving it. I had to write a separate daemon process since browsers were not supporting compression then. The results were indescribable now, it took the browsing experience to the whole next level.

I made a post on the Linux-net mailing list in 1996 which is still live and undoubtedly proves that it was the first (or one of the first) prototype of HTTP compression even before HTTP/1.1 specification in 1997 and browser support much later. I wrote an email to Netscape but didn’t get any reply.

I did not get any recognition for it but the same holds true for many unsung heroes for their inventions — so it’s cool :) But, it feels nice and makes me proud seeing it being used by millions of people (or billions maybe).

Back to work and tea now :)

Did I make the Internet faster? Perhaps I did! The first prototype of HTTP compression was originally published in Yusuf Motiwala on Medium, where people are continuing the conversation by highlighting and responding to this story.