needlepont

Which is a pretty abominable tool TBH. It breaks on just about every little edge and isn't very useful unless you like to see pretty colors and nested outputs + learn it's terrible output formatting spec. When using json I still use jansson for quick one offs.

As you note: your example is specious.

That is trusting user input. You don't do that, right?

Of course, but everyone wants to overdo the complexity of the time worn solution. OMG you need to null terminate the string after all the _other_ gymnastics..gee C sure does suck! Why don't we use rust|go|c++ ad-nauseam. bzero(buf,sz); /memset nazis here/ strncpy(buf,src,sz - 1);

Wasn't referring specifically to you.. but to the gist of the article and the post previous to yours I believe. On the ansi escape sequences to find matches, etc...yes, I get what your tool does but having to tokenize against ansi escape codes and other ad-hoc env artifacts is something I'm glad to leave to authors that enjoy it...not that it is terribly difficult unless you decide to reinvent the wheel and optimize everything.

I've never understood complaints like this. If you are proficient in the unix environment any sort of gymnastics can be handled via generation of some 'object' from plaintext and command generation on the fly. find $PATH -name '.c' -exec grep -l socket {} \; | awk ' {printf "mv %s %s\n",$0,sprintf("%s.old",$0)}' find $PATH -name '.c' -exec grep -l socket {} \; | awk ' BEGIN {n=0} {printf "{\"items\": \%s",sprintf("[\"%d\",\"%s\"]}\n",n++,$0)}'

If you aren't proficient or have an aesthetic or religious aversion to unix userland and traditional tools you'll play some other game I guess. Reinventing the wheel without understanding the model and power is a next-gen game. I don't have time for it.

He is pointing to a phenomenon I have witnessed which is copy-pasta and a mediocre understanding of the domain is enough to pass as a programmer these days.

How much of that (Github) code is based on du jour languages and only a casual attempt (if any) to reuse or adapt an existing codebase? I'd say at least 40% but I may be pessimistic.

I would argue that 'abuse' is the most significant characteristic of an open system. What is one persons abuse is absolute freedom to another.

The proficient design subsystems to isolate themselves from the 'abuse' and attract customers of their design. These become walled gardens. Eventually the closed system becomes oppressive.

As many others note it is a sort of dialetic that can be traced in historical political movements and other human endeavor.

Not so much these days with the devops reaction. Now you need to package your work and a good remote worker can figure out what is needed in a few minutes. Not a bad thing for either party TBH. Sysadmins can chase butterflies when they burn out and 3rd worlders get a remote gig to pay for food.

As the first engineer at a successful startup.

Responsibilities- * Take over everything technical I was good at and hired for. * Take over policy and progress on everything I was good at. * Be on call 24/7. * Do whatever the CEO/CIO didn't want to do.

Think this is pretty standard from my reading of other startups. The one lesson I should have learned and didn't is that as first engineer you should get 10% or more equity if you stay > 5 years.

"...It was a world that is now extinct. People don’t know that vi was written for a world that doesn’t exist anymore..."

And every time I use it I'm reminded that there is this devops/automation movement against interactivity with systems and that this editor is symbolic of (and best suited to) an operator culture..which is also dying if not defunct.

I've used TCL in production for 15 years. The only thing to really worry about is a consistent policy on language usage. Keeping to the base features of the language and extensions in tcllib/tclx is a pretty solid recipe.

That said here are things I advise.

* No upvar/uplevel. Use a namespace. * Use apply wisely. * No ad-hoc (say swig inline wrappers) extensions without deep review. * If you are writing a front end in tk - think twice. * If you are doing OOP with TCL choose wisely.

Interesting. I tried Lua about 6 years ago and found myself unable to see an upside to the language in comparative perspective with python and tcl.

This is for full featured *nix systems programming in the HPC world so ymmv.

TCL is a great systems programming language. When I need a glue language for an imperative model program it's my first choice.

Performance _or_ resource conservation. Which one is it?

Application design and domain knowledge are more important than rote optimization. I think that is what Ousterhout is getting at.