/tech/ - Technology★

Tcl is probably the most confusing language I've written for. It's a piece of shit.

The real question is, what would the world look like today is REBOL/Red got the respect it deserved?

>>960994 (OP)

Interesting, but I cannot think of one area in which I'd prefer to use this over Racket, in which dynamic modifications to language constructs are made possible with well designed constructs such as hygienic macros, rather than hacks. I know Tcl is popular in the HDL world (for tooling), so I'll probably pickup a book on it to see what the fuss is about.

>>960998

Will check it out also, always interested in learning new languages. Can you give a quick summary as to what is good about it?

>>960994 (OP)

Tcl allows you to do incredible things and write working code very fast. It's also the best glue language I chanced to come across.

It also has some similarities to LISP which make it even more fun to use.

It's also incredibly easy to define new syntax structures in it. pretty wild.

>>960998

>Tcl is probably the most confusing language I've written for.

you get used to it

>It's a piece of shit.

not really

Nice link, OP. Made me want to try it.

>>961002

Do you have any book recommendations, or is the online tutorial good enough?

http://www.tcl.tk/man/tcl8.5/tutorial/Tcl0.html

It does the trick, but it seems a bit uninspired.

>What would the world look like today if Tcl/Tk

like 5x the injection vulns, directly into your daemons and desktop

>>961092

the tutorial and the wiki are good enough. I learned it on the job so never had a structured approach.

Try going through SICP with it, I think you'll have a blast

>>961093

this is probably true. I don't think Tcl was ever written for that, but it's a great extension language.

>>960994 (OP)

>love and respect it deserved

They were dogshit. That whole era was awful with everything either being Motif or Tk.

Let's do some computer science

for {set i 1} {$i <= 100} {incr i} {
    if {$i % 15 == 0} {
        puts "fizzbuzz"
    } elseif {$i % 3 == 0} {
        puts "fizz"
    } elseif {$i % 5 == 0} {
        puts "buzz"
    } else {
        puts $i
    }
}

I used it for expect scripts and on f5 ltm stuff. it's not bad. a bit messy but if you're familiar with shell scripting in general it shouldn't take you long to get in to it

>>961230

proc seq {counter n body} {
    for {set $counter 1} "$$counter <= $n" {incr $counter} {
        eval $body
    }
}   

proc fizz {k s} {
    upvar 1 i i
    if {$i % $k == 0} {
        puts $s
        return -code continue -level 1
    }
}

seq i 100 {
    fizz 15 fizzbuzz
    fizz 3 fizz
    fizz 5 buzz
    puts $i
}

>>961431

Now you're thinking in Tcl

Alright here's a quick TCL program I wrote after spending about an hour running through the entire tutorial. It's probably the most useful program any of you will ever encounter, it prints a list of all dubs found in a thread. TCL looks very useful for quick tasks, but it's admittedly a little quirky. I really appreciate the complexity that can arise from such a simple syntax though. I'd use it over Python.

package require http
package require tls
::http::register https 443 ::tls::socket

set url [lindex $argv 0]
set token [::http::geturl $url]
set dubs [regexp -all -inline -- {id="(\d*(\d)\2)"} [::http::data $token]]
foreach {_all id _d} $dubs {
	puts ">>$id"
}

Usage: tclsh dubscheck.tcl https://8ch.net/tech/res/945626.html

>>961696

That's further back than the era Tk was popular in, like back when everyone was still on x11r5 (simcity's UNIX port was around that time I think, but it's been a long time). I used to use a few tools in Tk on CDE. I swear the frontend to gdb I used to use for cracking was called tgdb (had an interface like a DOS debugger) but I can't find even a whiff of it today via google. Maybe it was something very close to tgdb.. Also, if you used a pirated version of mathematica or matlab for UNIX back then, that was me.

>>961926

That's just

curl -sL --socks5-hostname localhost:9050 "$url" | grep -Eo '<a id="([0-9]+)" class="post_anchor">' out | sed -En 's#.*id="(.*([0-9])\2)".*#\1#p'

in sh, though (used grep -o and sed -E because fuck POSIX's lacks of options). TCL is a bit more readable, though.

>>961926

Racket version for comparison, not much difference really.

#lang racket
(require net/url)

(define (dubscheck url)
  (for ([dubs (regexp-match* #px"id=\"(\\d*(\\d)\\2)\""
                             (get-pure-port (string->url url))
                             #:match-select cadr)])
    (printf ">>~a~n" dubs)))

(dubscheck "https://8ch.net/tech/res/945626.html")

>>962128

>>961926

>thinking this has anything to do with the language and not the ecosystem

>>962129

That's what's being tested you mouth-breathing tard. Everyone understands it is the standard libraries at play.

>>962133

It's a shit test.

>>962140

Propose a better one.

I don't know who this Richard Stallman guy is, but he doesn't like TCL.

Why you should not use Tcl

Richard Stallman, GNU Project

As interest builds in extensible application programs and tools, and some

programmers are tempted to use Tcl, we should not forget the lessons learned

from the first widely used extensible text editor--Emacs.

The principal lesson of Emacs is that a language for extensions should not

be a mere "extension language". It should be a real programming language,

designed for writing and maintaining substantial programs. Because people

will want to do that!

Extensions are often large, complex programs in their own right, and the

people who write them deserve the same facilities that other programmers

rely on.

The first Emacs used a string-processing language, TECO, which was

inadequate. We made it serve, but it kept getting in our way. It made

maintenance harder, and it made extensions harder to write. Later Emacs

implementations have used more powerful languages because implementors

learned from the problems of the first one.

Another lesson from Emacs is that the way to make sure an extension facility

is really flexible is to use it to write a large portion of the ordinary

released system. If you try to do that with Tcl, you will encounter its

limitations.

Tcl was not designed to be a serious programming language. It was designed

to be a "scripting language", on the assumption that a "scripting language"

need not try to be a real programming language. So Tcl doesn't have the

capabilities of one. It lacks arrays; it lacks structures from which you can

make linked lists. It fakes having numbers, which works, but has to be slow.

Tcl is ok for writing small programs, but when you push it beyond that, it

becomes insufficient.

Tcl has a peculiar syntax that appeals to hackers because of its simplicity.

But Tcl syntax seems strange to most users. If Tcl does become the "standard

scripting language", users will curse it for years--the way people curse

Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel

stuck with.

For these reasons, the GNU project is not going to use Tcl in GNU software.

Instead we want to provide two languages, similar in semantics but with

different syntaxes. One will be Lisp-like, and one will have a more

traditional algebraic syntax. Both will provide useful data types such as

structures and arrays. The former will provide a simple syntax that hackers

like; the latter will offer non-hackers a syntax that they are more

comfortable with.

Some people plan to use Tcl because they want to use Tk. Thankfully, it is

possible to use Tk without Tcl. A Scheme interpreter called STk is already

available. Please, if you want to use Tk, use it with STk, not with Tcl. One

place to get STk is from ftp.cs.indiana.edu:pub/scheme-

repository/imp/STk-2.1.tar.Z

For good measure, here's the rebuttal by Tcl's creator, John Ousterhout.

There have been so many follow-ups to Stallman's message that I'm not sure

there's any need for me to respond, but I would like to say a few things

anyway:

First, I'd like to encourage everyone to keep their responses cordial and

technical, rather than personal, regardless of how strong your opinions are.

Comp.lang.tcl has managed to avoid flame-wars pretty well so far; let's keep

it that way by focusing on the technical issues rather than worrying about

motives.

I think that Stallman's objections to Tcl may stem largely from one aspect

of Tcl's design that he either doesn't understand or doesn't agree with.

This is the proposition that you should use *two* languages for a large

software system: one, such as C or C++, for manipulating the complex

internal data structures where performance is key, and another, such as Tcl,

for writing small-ish scripts that tie together the C pieces and are used

for extensions. For the Tcl scripts, ease of learning, ease of programming

and ease of glue-ing are more important than performance or facilities for

complex data structures and algorithms. I think these two programming

environments are so different that it will be hard for a single language to

work well in both. For example, you don't see many people using C (or even

Lisp) as a command language, even though both of these languages work well

for lower-level programming.

Thus I designed Tcl to make it really easy to drop down into C or C++ when

you come across tasks that make more sense in a lower-level language. This

way Tcl doesn't have to solve all of the world's problems. Stallman appears

to prefer an approach where a single language is used for everything, but I

don't know of a successful instance of this approach. Even Emacs uses

substantial amounts of C internally, no?

I didn't design Tcl for building huge programs with 10's or 100's of

thousands of lines of Tcl, and I've been pretty surprised that people have

used it for huge programs. What's even more surprising to me is that in some

cases the resulting applications appear to be manageable. This certainly

isn't what I intended the language for, but the results haven't been as bad

as I would have guessed.

I don't claim that Tcl is without flaws. Some of the flaws, like the lack of

a compiler and the lack of module support, will get fixed over time. Others,

like the substitution-oriented parser, are inherent in the language. Is it

possible to design a language that keeps Tcl's advantages, such as

simplicity, easy glue, and easy embedding, but eliminates some of its

disadvantages? Almost certainly (there are several decisions that I would

re-think if I were starting over). Is the two-language approach really the

right one? I still think so, but reasonable people can disagree.

Language designers love to argue about why this language or that language

*must* be better or worse a priori, but none of these arguments really

matter a lot. Ultimately all language issues get settled when users vote

with their feet. If Tcl makes people more productive then they will use it;

when some other language comes along that is better (or if it is here

already), then people will switch to that language. This is The Law, and it

is good. The Law says to me that Scheme (or any other Lisp dialect) is

probably not the "right" language: too many people have voted with their

feet over the last 30 years. I encourage all Tcl dis-believers to produce

the "right" language(s), make them publically available, and let them be

judged according to The Law.

>>963401

That man is a liar and a charlatan.

http://ergoemacs.org/misc/Daniel_Weinreb_rebuttal_to_rms.html

>>960994 (OP)

No mention so far of aolserver. sad.

Back in the day, this was the choice for very large sites. Remember this was in the time where pedestrians were using cgi scripts to power their webapps. Aolserver (naviserver) ran rings around it.

The benefits to having multi-threaded, tcl based scripting, with built-in DB connection pools was a killer combo.

Looks like they posted the code to github, but seems development has stopped.

https://aolserver.github.io/

>>963402

>you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces

So many shit languages came from this kind of thinking, and it's why we're still stuck with the nightmare of shellscript today. Interesting to see that some people used to think this kind of half-assed language design was a good thing.

>>963416

>Back in the day, this was the choice for very large sites.

No, everyone either used Apache, ZEUS, or wrote it in C on IIS. aolserver was almost completely unused in '99 when it was open sourced and the oldest usage numbers I can find for after were in 2004 when it was on 7k sites vs 31M running apache.

https://panoptic.com/aolserver/chat/20041226.html

>>963435

We still have that problem today though. People want quick easy to use glue languages without having to burden themselves with the constructs needed in a systems language.

>>963448

>31M ants can carry as much as 7k super-tankers because its a bigger number

Gov schooling is terrible

The Tcl documentation isn't terrible, but the worst part is the Wiki. You search for how to do something, and you get a 20 year old discourse from guys debating over their favorite way of getting it done.To this day, I've never seen documentation comparable to the quality of the Racket Guide and Reference, in which every function in every example is hyperlinked to a reference definition.

>>963886

No one was using that shit. One of the biggest early internet sites in terms of page views was eBay which was written in C++ for IIS. Another was Google which rolled its own.

>>963977

>No one was using that shit

>AOL server

Being this young