3 ms·

You know what, that is some pretty readable code.. COBOL might have been on to something there. I've gotten so used to syntax soup this is refreshing. https://

You know what, that is some pretty readable code.. COBOL might have been on to something there. I've gotten so used to syntax soup this is refreshing. https://github.com/icitry/FPS.cob/blob/main/fps.cob https://github.com/icitry/FPS.cob/blob/main/fps.cob

giraffe_lady 4mo ago
I had to get into an old tcl program for work recently and had the same thought. I wouldn't necessarily pick it today but it was kind of nice in a way that's unfamiliar to me from modern development.
- moregrist 4mo ago
  The tcl syntax is fine. And modern tcl is fine. But tcl 7.x and before was a pure string-based language. Everything was essentially a eval(). People would hit syntax errors on production code. Fun, painful times. The flip side: the interpreter is super simple and fun to write.
  - IshKebab 4mo ago
    Tcl is still entirely stringly typed. That's never changed. There are under-the-hood optimisations to make it less insanely slow but that only affects performance. Tcl is a cool hack (the interpret is simple to write) but it's insane to actually use it. I wish the EDA industry would realise that.
    - kevin_thibedeau 4mo ago
      Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.
      - IshKebab 4mo ago
        That's just a performance optimisation. It doesn't change the semantics at all. From the changelog: > Tcl automatically manages these values so their type is transparent to the Tcl script writer. https://www.tcl-lang.org/software/tcltk/whatsnew.tml https://www.tcl-lang.org/software/tcltk/whatsnew.tml
        kevin_thibedeau 4mo ago
        Saying it's "just strings" is disingenuous. You could make a js interpreter that uses strings internally too.
        IshKebab 4mo ago
        No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string. Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer. JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat). To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".
        kevin_thibedeau 4mo ago
        tcl::unsupported::representation will expose the actual internal type.
        IshKebab 4mo ago
        > ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.
ternaryoperator 4mo ago
That readability is the upside of COBOL’s oft-assailed verbosity.
- MBCook 4mo ago
  I remember being taught in my COBOL class (early 2000s, needed an elective, thought it would be fun) that that was the point. The stupid engineers could write the code like the grunts they are, and then the manager could read it and verify that it was correct without having to know how a program. That wasn’t exactly how it was put. And there are obviously some assumptions in they are on how good a job a manager who doesn’t know how to code could ever do. Certainly an interesting idea though.

giraffe_lady 4mo ago

I had to get into an old tcl program for work recently and had the same thought. I wouldn't necessarily pick it today but it was kind of nice in a way that's unfamiliar to me from modern development.

moregrist 4mo ago
The tcl syntax is fine. And modern tcl is fine. But tcl 7.x and before was a pure string-based language. Everything was essentially a eval(). People would hit syntax errors on production code. Fun, painful times. The flip side: the interpreter is super simple and fun to write.
- IshKebab 4mo ago
  Tcl is still entirely stringly typed. That's never changed. There are under-the-hood optimisations to make it less insanely slow but that only affects performance. Tcl is a cool hack (the interpret is simple to write) but it's insane to actually use it. I wish the EDA industry would realise that.
  - kevin_thibedeau 4mo ago
    Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.
    - IshKebab 4mo ago
      That's just a performance optimisation. It doesn't change the semantics at all. From the changelog: > Tcl automatically manages these values so their type is transparent to the Tcl script writer. https://www.tcl-lang.org/software/tcltk/whatsnew.tml https://www.tcl-lang.org/software/tcltk/whatsnew.tml
      - kevin_thibedeau 4mo ago
        Saying it's "just strings" is disingenuous. You could make a js interpreter that uses strings internally too.
        IshKebab 4mo ago
        No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string. Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer. JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat). To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".
        kevin_thibedeau 4mo ago
        tcl::unsupported::representation will expose the actual internal type.
        IshKebab 4mo ago
        > ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.

ternaryoperator 4mo ago

That readability is the upside of COBOL’s oft-assailed verbosity.

MBCook 4mo ago
I remember being taught in my COBOL class (early 2000s, needed an elective, thought it would be fun) that that was the point. The stupid engineers could write the code like the grunts they are, and then the manager could read it and verify that it was correct without having to know how a program. That wasn’t exactly how it was put. And there are obviously some assumptions in they are on how good a job a manager who doesn’t know how to code could ever do. Certainly an interesting idea though.