Tcl/tk vs the web : we should abandon web based technologies.

Long before firefox & modern browsers existed, we had to do stuff like visualizing graphically and interactively simulations in physics.

So in 1996 I learnt Tcl/Tk. At the same time it was the heavy client realm based upon java. Java awt is a descendant of Tk (oak).

I speak french. My theoretical cognitive load for speaking everyday is 350k words + extra thousands of slang plus grammar. I am very much into slang. However french being a high context language, it is estimated that a mere 600 words vocabulary is enough to understand and guess the remaining.

I have a tad of german, spanish and english also loaded in my skull. And talk and exchange with people.


When I compare to computer languages they seem pretty pathetically easy: from 50-200 reserved keywords. That maybe the reason why I have practiced 13 of them. From Forth to VHDL going through C(?|++|#) python, Perl. I left PHP because of the 5000 inconsistent reserved keywords. I was thinking it was insane. When facing in my last years the deprecation of my old languages (I did Perl and C# too), I chose python over ruby because ruby had so many useless methods on stuff like lists while python was small and consistent.

However most of my programming in python (even though I learnt myselft a tad of python-tk) has been to deal with : making the stateless HTTP connection stateful by handling sessions, javascript, and angular for making application bi directional and asynchronuous.

My real cognitive load for web programming includes the HTTP stack, MIME encoding so that spamassassin & al did not blacklisted our mails (I rewrote smtplib in python 2 to handle PHP kind of bug that have pissed me of), SSL cipher suites,  resource exhaustion in middle ware, DNS, OS issues ... and reinventing the wheel.

I had to deal with poorly coded rewrite of expect, the box model of CSS, dealing with the "dependency hell" in js, callback hell in js.

But why are we using web in the first place?

Because of hype and stupid sysadmins that blocked everything but HTTP protocol (Deep Packet Inspection might block TCP:80 because people are scared it could be an SSH server with tunneling enabled on the other side).

Also because in the 2000 good coders were hard to find. Especially thinking asynchronously.

I learnt microelectronics. I coded a device driver for linux. Asynchronuous thinking is the basic of microelectronics (VIA, ACIA). You cannot self teach it yourself. Some knowledge require apprenticeship. Human limitation: words do not magically jump in your brain.

So people figured that HTTP with their "native widget" and synchronuous kind of programming could be cool. In fact it was the porn industry.

Porn industry in the 1990s invented : chatrooms, e-commerce with visa card, dynamic contents.... and ubiquitous content delivery without fear of being detected by any "black list/antivirus/safe guard". I met one pornmaster. They often were one man armies self taught and not software engineers but they cared about time to market and costs. The one I met was a technical writer. But he was making profits.

They were so good that web agency (at least in France) would suck their websites change the pictures and resell them for  at least 10 000 $.

And in front java GUI was requiring a lot more money to develop and operates the servers.


Why did not tcl tk had any traction?

Because java was the language that was taught with all the OOP, structured object messaging that was a promise to solve distributed problem challenge. Corba, DCOM, RPC was the way to do client/server.

Company hired educated engineers to be CTO pushing the tools they were "brainwashed" to work. The decision makers. The same guys that in France decided TCP/IP could not worked because it was designed by scientists and not serious engineers. Cyclades, ATM were to be the good protocols.

And pOrn industry powned their asses. So everybody said ... hey let's do what actually works else we are dead! 

It is called a law of externality. As soon as it was adopted it became the defacto standard of the industry because: it was less expensive to hire self taught programmers than students that had loans to pay. The education bubble fueled by post wwII need to replace dead skilled workers. The stuff that has enabled USA able to build their new techs with the subsidies of education from Europa.

Maybe most programmers are not exactly engineers but however inefficient actual superior education is, it beats no education. And the offer supersedes so much the demand that coders are very cheap compared to what they produce as values. Plus without union/diplomas they are unable to negotiate or defend themselves collectively. And IP laws are literally ripping the actual patrimonial and moral rights of coders.


So ... do we do web for the right reasons?

I think not.

Let's review why Tcl/Tk is way better than the web stack.
 TL;DR : a long list of reason why Tcl/Tk is more interesting than web. And what it proves concerning our stupidity. And the conclusion is how to efficiently use tcl/tk in the optic of its design : as a very good gluing language that thus makes most of the actual needs for frameworks disappear...


It has a while loop that waits infinitely and it is really annoying.

Well so does tornado, and any other asynchronuous frameworks.

Everything is string. 

Well it was built for unix where everything is a string. So are mail, web pages, messages. String at least do not have endianness problems.

And tcl Tk type coercion from string is way more sane than JSON, javascript, PHP, python ....


You need an interpreter

Well, a web browser is a JS interpreter too. Plus in 20+ years Tcl/Tk is only 24Mb with rarely all the insanity of having to use jquery to solve incompatibility with different versions of the same browser.

You have to install an interpreter while web is ubiquitous


Well I call this the Stockholm syndrome. Being forced to make choices that are wrong does not make them right. However who uses the default web browsers?

And how safe is it to not update your web browsers?

Tcl/Tk has very few versions. And does not have the constant delivery insanity that made version numbers disappeared. And Tcl/Tk does not SPY on you.

And it is pretty sanely slowly delivered without too much regressions. 

I can execute remote code from everywhere "securely" thanks to Oauth/HTTPS

Tcl have modules. Tcl can do TCP/IP and other protocols, even HTTP. Tcl has cryptographic libraries. And you know what? You can tunnel clear text easily with TLS tunnels. You can ask LDAP for credentials, you can talk to the system that already have the informations on the users.  If you are crazy enough you can even use the ancestor of Oauth that is Kerberos token.

Web browser are supposed to be sandboxed. So every systems stuff are reinvented. Tcl/Tk is not an autistic process it can ask the system for information that are already there. It can even talk to your ssh agent. 

Plus https relies on central authorities that have proven to be less than trustable when it comes to government issues.

It is not portable

Tcl/Tk is 24Mb portable cross platform. You can even easily have it on embedded system. Firefox, python, ruby, Perl, chrome, safari are all bigger.

And, wonders of old programs, you can share the logic between servers and client by the use of module.

Yes, at the opposite of node & client side js, tcl/tk can really share sanely code with no differences of behaviour.


It does not show web pages

You can use an html canvas. 

It is not C/ python.

Well, tcl make binding on external binaries easy. It has the classical pack/unpack function to translate data from binary memory structure into ... strings.

It is not strongly typed, nor functional.

In asynchronous programming you rely heavily on clocks. Clocks are mutable. They are finite state machine whatever you are doing.

But still, you can do higher order functions if you love the thrill of coroutines//functional.


Strong types would be nice if OS inter process communication were natively strongly typed.

Unix relies heavily on pipes, and doing fork/dup/pipe is very easy in any languages (especially in C) on every OSes. By default, strings have no bytes ordering problems. They are portable.

Which make tcl a very social language that can be talked to through any streams.

You can import "parsers" for handling data types the way you want : integer, floats, entier, decimal for instances.

Why negate the truth? The computers rawest communications are string based. All our broken overhead do not always worth the price of having language + grammar for communicating.

HTML requires a broken XML parser. JSon requires an interpreter. CSS requires yet another parser.

It may not be functional, but it is functioning. Why not have "drivers" instead of stacks?

With Tcl you can flatten the stacks.

It does not have messaging/rabbitmq ... 

It has pipes that are atomic at the concurrence of PIPBUF.

It has EXPECT. I have seen people using cli interaction has messaging for instance to talk with routers, with a shell (over ssh), or deamons (asterisk, zebra...) and stumbling on the problem of interaction with stateful connection.

Expect is sane. Because states are required in asynchronuous. Trying to avoid facing the problems with layers of abstraction that hide the problem and try to flatten asynch in nice linear code is stupid.

You WILL have callbacks in asynchronuous. And the more layers the more states and callbacks need to be handled. So expect expects callback on premises.

States are inherent to asynchronuous communications better deal with it than hide it.

It does not have CSS

Widgets are objects that inherits from one another from root to bottom. They inherit attributes that are basically the exact equivalent of CSS. Basically these can be mapped to a JSON tree. It is equivalent BUT!

But tcl does not mix insanely the placement of objects with the apparence of them.

The CSS box model is shit.

tcl tk instead have geometry managers with features such has : put this box at this place and let a constraint based algorithm expand the widget the way you want.What a bright idea, let software do the hard job for you instead of letting programmers and designers do stupid grunt jobs without any business added value.

I like python ... ruby, java, c#, c++ .... and I don't want to program in this sub Perl insanity

Me too. python-tk is there for you. It is used by matplotlib and that is another secret of tck/tk: thanks to the C libs of tcl you can easily embed it in another language.

Tcl Tk is so social it can either pilot other languages or be piloted by other interpreters.

You can do a #include "tk"  you can use expect, you have R bindings ....

We are in 2016 one language do not do everything right, use languages that are social instead of socializing language through the http stack//cookies insanity.

Basically programming paradigm should have switched to the use of gluing languages has the top stack language and specialized one for the handling of specific issues.

ASM for speed. C for reuse of the existing stuffs, R for stats, matlab for signal processing...

It should be social not only with static stateless libraries  but also with stateful dynamic interpreters.

 What Tk really is

Tk is a sane GUI event driven model that does the boring work for you. It is just an extension of Tcl, but you can embed it in ANY languages.

Tk is the original GUI model that everyone has been copying often wrongly. (Oak existed before, I got it but look who did it).

What Tcl really is

And tcl is just a Domain Specific Language for gluing. Reusing existing code/libraries. It is also very good with talking with others interpreter and interacting statefully with applications.

What Tcl is not

Tcl is no silver bullet. Just a normal tool.

ADDENDUM

What the web should be used for? 

Presenting public documents and leveraging the URI and references. Like gazette, pamphlet, schedules, encyclopedia, public domain content, government communications (like informing populations when accident happens)...

It should be signal based (signal vs noise) and used mainly to transfer content. I am not sure the web should do the styling part.