Scripting: Higher Level Programming for the 21st Century (1998) | Hacker News Reader

Scripting: Higher Level Programming for the 21st Century (1998)

tcl.tk

26 pointsnetworked20 comments

I wish there was a language that was actually multiple levels of compatible languages.

At one end would be dynamic and scripted and would progress to the other side of compiled and static. You would start out at one end for speed of development and progressively optimize and compile.

I suppose python and cython are that language. But it's not as popular as it should be.

There are tons of these languages. OCaml, Haskell and Lisp even, spring to mind.

I'll bite, how are OCaml and Haskell "dynamic and scripted"? OCaml and Haskell are about as far from Tcl as it's possible to get.

Do you mean the recent GHC developments that let you defer typechecking to runtime? That seems a little too new, to attribute it to Haskell like that.

I mean, you have a REPL with very high level language constructs in which you can do exploratory work, then when you are happy, take the artifacts of your experiments and compile them down into a binary. I got into OCaml in the first place because I wanted a type-safe, natively executing Python...

Actually I would say Common Lisp, Scheme and Dylan are that type of language.

might groovy fall in to that category?

I would say yes it fits perfectly, especially if you extend it with java classes for performance critical stuff.

Groovy's still just a dynamically-typed language primarily used for scripting. It has statically typed extensions but they're not used very much. Groovy's used for scripty stuff like the 20-liners you find in a Gradle build script, but you don't find Groovy in Gradle's own codebase, only Java. Despite the heavy promotion since Groovy 2.0, developers aren't using statically-typed Groovy, but dynamically-typed Groovy is doing fine in Grails, Gradle build scripts, Java class manipulation, etc, everything except building systems. I wouldn't even be surprized if the newer additions to Groovy's own codebase like the Android stuff are written in Java rather than Groovy, despite statically-typed Groovy and Groovy for Android having the same author. That would be the ultimate vote of no confidence in Groovy's statically-typed extensions.

> I wish there was a language that was actually multiple levels of compatible languages.

I first read about multi-level programming back in the 80ies and was hooked.

Objective-C has bit of this, because the C part is static and pretty low level, but the object-oriented part is dynamic and can go quite high level [1][2].

My own project, Objective-Smalltalk[3] definitely has "multi-levelness" as one of its primary goals. The way to get there is to make the elements of the language malleable, similar to Open Implementation[4], but using a software-architectural frameworks instead of an object-oriented one.

[1] http://en.wikipedia.org/wiki/Higher_order_message

[2] http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid...

[3] http://objective.st/

[4] http://en.wikipedia.org/wiki/Open_implementation

This is what Red is aiming to be... a full stack programming language - http://en.wikipedia.org/wiki/Red_%28programming_language%29

I wish for this as well. When I was younger, I often used asm blocks in my C code to implement things like blitters. You could even use a variable name as a source/destination in instructions and the compiler did the right thing!

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

So today we should be able to write 90% of an app in a rapid application development (RAD) language like HyperTalk, MATLAB or Python (or my favorite, the language that doesn't exist that combines all of these) and micro-optimize in places that need it using C/Java/Go/Rust etc. The compiler should automatically generate all glue code for variables and function calls.

My sense of this is that functional programming is gaining popularity because most people are working a few levels too low to be productive. Short imperative code should be able to act as a black box with no access to global variables or sockets and be exercised with known inputs/outputs and be represented in a functional manner. I wish we could deal with logic as truth tables and state transitions rather than the code (declarative rather than imperative).

I am waiting for someone to say, but node.js! Then some of us old-timers can jump in with just how long Tcl's been doing this asynchronous callback thing...

I think tcl/tk is still the best quick gui writing setup I have seen. Unfortunately at some point the language dev team took a wrong turn and tried to force non-backward-compatible changes which, in combination with other factors, killed the community. Too bad! No other language has stepped up with such an easy-to-use toolkit.

If you want my take on what went wrong with Tcl and Tk:

http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-...

I disagree.

It is. And, it's awesome to rapidly prototype or quickly prove a concept.

Tcl was great. The startup I worked for back in 1999, already had something, lets call it, Tcl on Rails.

But we weren't in SV, nor the web was what it is today.

IIRC, a very succesful web framework/platform/thing back in the late nineties was based in tcl, and called Vignette.

Yes, some of the guys that left our startup went working for them.

Our product shared some ideas with AOL Server.

I would also say that Tcl has been used AI and data sciences efforts when it was once called Knowledge Discovery. http://www2.lbl.gov/Science-Articles/Archive/sabl/2005/March...

I downloaded the codebase.

Reply on news.ycombinator.com