4 ms·

Cat: A statically typed concatenative language

29 points by azhenley 6y ago

codezero 6y ago
I just don’t want the first comment here to be about the name already being taken. Let’s discuss the substance of this language and let its authors figure out marketing. If I’m reading it right, it’s a functional programming language but has higher level language capabilities built on top of it and each level of capabilities is packaged as a “level” to help know what runtime/capabilities are available to any program. I could be way off though. It also seems very dead as the original site points to a GitHub 404. Edit: bad forward on the domain but the GitHub repo is here, last update was three years ago: https://github.com/cdiggins/cat-language https://github.com/cdiggins/cat-language
- colomon 6y ago
  Are you sure that github points to the same Cat language? The stuff in the readme there seems like the same sort of idea as the other Cat, but vastly more primitive.
  - codezero 6y ago
    I mean... I dunno, it's the same GitHub user and project name as the redirect is... that it's not aligning seems more to do with the claims in the 2015 archive vs the reality of today... I didn't do any research on the continuity of it all, just pasted links and commented on hacker news :)
transfire 6y ago
Obligatory reference to Cat-inspired Kitten: https://kittenlang.org/ https://kittenlang.org/
dfischer 6y ago
If this interests you, check out: https://factorcode.org/ https://factorcode.org/ It’s seriously impressive in my opinion.
4bpp 6y ago
I imagine that if you compiled an idiomatic program in a language like this down to machine code, the result would actually look quite different from assembly generated for an idiomatic imperative program for the same task. For instance, even if you optimised your compiler to keep the top of the stack in registers as often as possible, the "calling conventions" of your functions would be all over the place. At the same time, presumably, common processor architectures have all undergone decades of targeted optimisation to improve their performance on the typical imperative code that is encountered in system and user programs. What are the implications of this? Should we expect a theoretical cap on the real-world performance of concatenative programs that is well below what we can achieve with mainstream programming languages?
- Arnt 6y ago
  I beg to differ... CPUs have undergone decades of targeted optimisation, but not for typical code. Rather, for optimal code. CPUs have been designed to let you write C that runs fast, not to make typical C run fast. Maybe the CPU-wallahs wanted the latter, but they haven't really achieved it — avoiding pipeline stalls and unpredicted branches can make factor-of-100 differences and and that's not something "typical C" (or Java for that matter) does. I mean: If you want to avoid pipeline stalls due to uncachable main memory reads, writing code like typical C isn't your first solution.
  - fooker 6y ago
    This seems wrong. I work on compilers, most CPU design advancements from the last several decades are aligned towards making bad code run fast. This is usually a problem for people who write 'fast code', they have to hire a bunch of compiler devs to stop the compiler and CPU invalidating each other's optimizations, and to implement one-off domain specific optimizations. This is how a vast majority of compiler people are employed nowadays.
    - dfischer 6y ago
      Hardware is hiding the rot and stink that is plaguing software. This will be coming to collect sooner than later.

29 points by azhenley 6y ago

I just don’t want the first comment here to be about the name already being taken. Let’s discuss the substance of this language and let its authors figure out marketing. If I’m reading it right, it’s a functional programming language but has higher level language capabilities built on top of it and each level of capabilities is packaged as a “level” to help know what runtime/capabilities are available to any program. I could be way off though. It also seems very dead as the original site points to a GitHub 404. Edit: bad forward on the domain but the GitHub repo is here, last update was three years ago: https://github.com/cdiggins/cat-language https://github.com/cdiggins/cat-language

colomon 6y ago
Are you sure that github points to the same Cat language? The stuff in the readme there seems like the same sort of idea as the other Cat, but vastly more primitive.
- codezero 6y ago
  I mean... I dunno, it's the same GitHub user and project name as the redirect is... that it's not aligning seems more to do with the claims in the 2015 archive vs the reality of today... I didn't do any research on the continuity of it all, just pasted links and commented on hacker news :)

transfire 6y ago

Obligatory reference to Cat-inspired Kitten: https://kittenlang.org/ https://kittenlang.org/

dfischer 6y ago

If this interests you, check out: https://factorcode.org/ https://factorcode.org/ It’s seriously impressive in my opinion.

4bpp 6y ago

I imagine that if you compiled an idiomatic program in a language like this down to machine code, the result would actually look quite different from assembly generated for an idiomatic imperative program for the same task. For instance, even if you optimised your compiler to keep the top of the stack in registers as often as possible, the "calling conventions" of your functions would be all over the place. At the same time, presumably, common processor architectures have all undergone decades of targeted optimisation to improve their performance on the typical imperative code that is encountered in system and user programs. What are the implications of this? Should we expect a theoretical cap on the real-world performance of concatenative programs that is well below what we can achieve with mainstream programming languages?

Arnt 6y ago
I beg to differ... CPUs have undergone decades of targeted optimisation, but not for typical code. Rather, for optimal code. CPUs have been designed to let you write C that runs fast, not to make typical C run fast. Maybe the CPU-wallahs wanted the latter, but they haven't really achieved it — avoiding pipeline stalls and unpredicted branches can make factor-of-100 differences and and that's not something "typical C" (or Java for that matter) does. I mean: If you want to avoid pipeline stalls due to uncachable main memory reads, writing code like typical C isn't your first solution.
- fooker 6y ago
  This seems wrong. I work on compilers, most CPU design advancements from the last several decades are aligned towards making bad code run fast. This is usually a problem for people who write 'fast code', they have to hire a bunch of compiler devs to stop the compiler and CPU invalidating each other's optimizations, and to implement one-off domain specific optimizations. This is how a vast majority of compiler people are employed nowadays.
  - dfischer 6y ago
    Hardware is hiding the rot and stink that is plaguing software. This will be coming to collect sooner than later.