<companion_cube>
Corbin: very easy to exclude python
<companion_cube>
A functional language is one where most syntactic forms are expressions, functions are values, and immutable data structures are idiomatic
<companion_cube>
Python fails 2/3 of these ;)
bartholin has quit [Ping timeout: 255 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
gopiandcode has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
bartholin has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
bartholin has quit [Ping timeout: 246 seconds]
* qwr
. o O ( common lisp is a curious case... )
<companion_cube>
:-°
<Corbin>
companion_cube: Most of Python's syntactic productions are expressions, Python functions are values, and types like `int`, `str`, and `tuple` are commonplace. If you argue the details, you'll find that Scheme and OCaml don't quite fit the requirements any better than Python; they have non-expression syntax and common idioms for mutability.
<companion_cube>
I didn't say"only immutable is idiomatic", read again
<companion_cube>
But tuple is a far cry from a real immutable structure
<companion_cube>
Compare to erlang with its maps and lists. Most python is pretty imperative.
<companion_cube>
(also most things in python are statements, not expressions. 🙄)
<Corbin>
companion_cube: Ah, we're arguing the details. Python tuples, used to implement common idioms like multiple return values, are immutable. There's a `namedtuple` reciple in the stdlib for creating customized tuples, still immutable but with lots of helper methods.
<companion_cube>
There's no immutable list or map. Sorry.
<companion_cube>
Tuple isn't one cause adding an element involves a full copy, so that's impractical.
<Corbin>
companion_cube: You've introduced a new requirement: That "functional languages" (whatever they are) are not "pretty imperative". Imperative is what, doing things in sequence? Can you imagine Scheme or OCaml idioms for sequentially applying mutable operations?
<companion_cube>
You can write a full ocaml program with immutable structures and it'll be idiomatic
<companion_cube>
In python: no way
<companion_cube>
(ocaml is multiparadigm but it supports FP well)
<companion_cube>
Bye now
<qwr>
these are all multiparadigmatic languages, but ocaml has most _defaults_ in functional style
<d_bot>
<NULL> Python doesn't have immutable efficient structures
<Corbin>
companion_cube: Wait, OCaml and Scheme have immutable maps? I understand your desire to move the goalposts in order to preserve "functional" tribalism, but I think that you ought to double-check the evidence you're working with.
<d_bot>
<NULL> OCaml had immutable maps, I don't understand where you're getting to
<d_bot>
<NULL> has*
<Corbin>
OCaml has the ability to *build* immutable maps. So does Scheme. So does Python, by copying exactly the Scheme recipe; Python has immutable builtin types corresponding to the Scheme essentials.
<Corbin>
What you're ultimately talking about is community norms and tribal boundaries, rather than properties of languages.
<d_bot>
<NULL> I don't know Scheme, but Python doesn't have OCaml-style maps where you share subtrees
<d_bot>
<NULL> Or lists where you share sublists
<d_bot>
<NULL> linked* lists
<d_bot>
<NULL> That's what I call *efficient* immutable structures
<d_bot>
<NULL> Python basically has immutable arrays (either called tuple or namedtuple or string)
<d_bot>
<NULL> And frozen dataclasses I guess
<octachron>
OCaml doesn't have a non-expression syntactical category?
<octachron>
Aka, there are no statements in the OCaml grammar.
<Corbin>
octachron: Types aren't values, right? So whatever syntax handles types is not expression syntax. But perhaps this is not the way you're looking at it.
<qwr>
one additional difference from python is that ocaml allocation is better optimized for many small allocations (althought this trait is also useful for OO style programming (for example Java), immutable data structures tend to get especially penalized by slow allocators)
<d_bot>
<NULL> (I would say that types, modules and module types don't represent the "most" used syntactic forms
<d_bot>
<NULL> )
chrisz has quit [Ping timeout: 276 seconds]
<octachron>
Types expressions are still expressions. I am not sure how types are relevant when comparing statement-oriented grammar versus expression-oriented grammmar?
chrisz has joined #ocaml
<Corbin>
qwr: Check out PyPy sometime; they have a copying generational GC with a nursery, and small allocations don't go to arenas like in CPython.
klu has joined #ocaml
klu has quit [Changing host]
klu has joined #ocaml
<Corbin>
octachron: Ah, we'll have to agree to disagree, then. I think of types as a second tier of syntax, designating a second program which is evaluated by a typechecker.
<Corbin>
NULL: https://bpa.st/LDMA may be illuminating. I am more-or-less transcribing algorithms from Scheme; the recursion style is a little different, but the overall effect is similar.
<d_bot>
<NULL> The only required disagreement is on how you read what companion_cube said. Regular expressions and type expressions are distinct syntactical forms for sure, but I personally interpreted the sentence as whether there were statements in the language grammar (and whether they are more widely used than regular expressions)
<Corbin>
Sure, that's an understandable tribal assumption. But it's clearly bogus; there are syntactic forms besides statements and expressions.
<d_bot>
<NULL> But they have little influence in the mutable vs immutable debate
<d_bot>
<NULL> Which was the context of the discussion
mro has quit [Remote host closed the connection]
<octachron>
There are also definitions. But otherwise, no OCaml grammar only consists of definitions and expressions.
noonien has joined #ocaml
<noonien>
hello folk!
<Corbin>
It's not a boolean choice. In order to benefit from the various free safety theorems, a language must have *no* mutability whatsoever. None of the languages under discussion (OCaml, Haskell, Python, Scheme) are like that. (One of my languages is, but we're not talking about my hobby projects.)
<noonien>
does anyone use ocaml on nixos? i've been using nixos for a few years, but first time using ocaml. i'm currently getting an error running `opam install discoml`: /nix/store/wp3jv9pfg9lp0r271cfh3wbq3i7h3vfw-opam-2.1.1/bin/.opam-wrapped: "create_process" failed on /home/george/.opam/opam-init/hooks/shebangs.sh: No such file or directory
<noonien>
i'm guessing this is happening because the library it's trying to install is trying to execute something that's missing
<noonien>
i would prefer not to install packages using nix during development currently
<Corbin>
noonien: I had vastly better success with Dune, using `buildDuneProject`. It does require the extra step of figuring out Dune, though.
<d_bot>
<NULL> Corbin: who said it was a boolean choice
<noonien>
Corbin: i'm using dune, but would prefer not to use nix to package yet, it's my first time using ocaml and want to learn it a bit first before i learn how to package it for nix
<qwr>
Corbin: what mutability is in the Haskell, unsafePerformIO?
<Corbin>
NULL: Why call it an "X vs Y debate" otherwise? If it's a discussion over style, then that's one thing; many popular languages are fragmented into mutually-unintelligble dialects, each with their own style, and there's no reason why any one style/dialect should be the right one.
bartholin has joined #ocaml
<Corbin>
qwr: IO, STM, and ST are the main three to consider when using GHC. Sure, Haskell encapsulates mutability, but it's still real genuine mutation in main memory. We don't let Python off the hook just because its mutation is safe, either.
<d_bot>
<NULL> Corbin: Debates can (and often are) resolved through a middle-ground solution, so I don't get why this would mean a boolean choice
<Corbin>
noonien: Understandable. I would recommend using `ocamlPackages.utop` if you want to interactively get your code set up and running; you can also bring in anything else from ocamlPackages.
<Corbin>
NULL: Me either. But it's worth inspecting why, if that's the case, folks will nonetheless insist that "functional languages" or "functional programming" is about rejecting mutability.
<d_bot>
<NULL> Corbin: At no point did I see a full-blown rejection of mutability, but a desire to see it as a less attractive solution and mostly to see immutability as a first class "paradigm"
<noonien>
Corbin: this is the library i'm trying to use: https://github.com/Mishio595/disml it seems to have a quite a few more dependencies itself, i'm not sure how many of those are in nixpkgs, how many are up to date, and how many work. there probably is a way to package ocaml projects without relying on just ocamlPackages, but that's something that i
<noonien>
want to learn a bit later, or if there is no other choice
<noonien>
i'm also guessing a lot of informational material regarding ocaml isn't nix-specific
<Corbin>
NULL: Sure, the "paradigm" point is a common one. But what *is* a paradigm? Is it the algorithms that are easy to express in a language (either easy to read, or short)? Is it the algorithms enabled by language-specific keywords? Is there a definition that would make my above Python snippet somehow not fit Python's "paradigm"? I suspect it's more about community norms than about properties of languages.
<Corbin>
noonien: Yeah. I don't want to sign you up for work, but I bet that it might be easiest to get all of the dependencies packaged. I don't know if there's docs for this, but I can help write them.
<noonien>
does dune do package management, or just builds?
<d_bot>
<Ambika E.> Fwiw I've contributed a bit to this library in the hopes of getting it working again and i did not succeed
<d_bot>
<Ambika E.> Dune doesn't do package management, gonna wanna use opam or esy for that
mro has joined #ocaml
<noonien>
Corbin: i'll give buildDuneProject a try to see how it goes! i'll report my results here, thanks!
<Corbin>
noonien: Good luck!
spip has joined #ocaml
bobo_ has quit [Ping timeout: 258 seconds]
<d_bot>
<NULL> In my case, I was at least raising the standard structures, which in Python are all mutable (bar the fixed arrays)
<d_bot>
<NULL> Regarding your snippet, you were implementing (immutable) linked lists by hand, I would expect such a basic structure to be in the standard library (or easily defined, like with a sum type like OCaml does)
<Corbin>
NULL: Sure. I think that both you and companion_cube hear me say "Python" and think "idiomatic Python, as endorsed by the PSF, taught in #python, and preached by bloggers everywhere", not "whatever _habnabit and Eevee and I discovered we can make CPython parse while bored at PyCon".
mro has quit [Remote host closed the connection]
<Corbin>
Sure. Note that standard libraries are also normative, usually published and maintained by a community. This is maybe more obvious in the OCaml world.
<d_bot>
<NULL> What I hear when you say Python is what I write in Python and what I see other people writing in Python
<d_bot>
<NULL> It's what I find is most easily written
<Corbin>
Yeah. But what you should think about is what is *possible* in Python, what is *short* in Python, and I guess maybe what is *efficient* in Python, keeping in mind that CPython isn't the only option.
<d_bot>
<Ambika E.> Why? Many things are possible short and efficient in many languages that are often not worth considering when writing code normally
<d_bot>
<Ambika E.> Isn't this what code golf is all about
<d_bot>
<NULL> I too have written a Gaussian elimination algorithm as a Python one-liner
bartholin has quit [Ping timeout: 276 seconds]
<d_bot>
<NULL> I wouldn't say it was a good way to write it
<d_bot>
<Ambika E.> It feels like we're throwing out a perfectly good descriptor for languages because it's not laser precise and because if you bend over backwards enough you can get just about anything to fit the bill
<d_bot>
<Ambika E.> But i think at the end of the day this is one of those things that more people can come to a vague but still useful agreement on than not
aspe has quit [Quit: aspe]
<Corbin>
Ambika: I don't disagree that there can arise some community notion of "functional language". What I'm interested in is *why*. I don't have a problem with *goals* of immutability or single-tiered syntax, but they are clearly incorrect *descriptors* of the actual languages being used.
<Corbin>
In any other discipline, I might agree with you; but frustratingly, computers notice every detail.
<d_bot>
<Ambika E.> If you take the immutability descriptor as one that necessitates a language adheres to it 100% then of course it is pretty much always going to be incorrect. If you take it in the way others have suggested above, i wouldn't say it's a clearly incorrect descriptor of languages in question
<Corbin>
Ambika: Yes, for languages meant to be implemented on our electronics, with mutable memory. Consider e.g. Wang tiles; there's only one syntactic form (the tile), no mutability (tiles can't shift once placed), etc. I don't know what a function looks like, though!
<d_bot>
<Ambika E.> I'm not sure I see your point. Yes, clearly this language adheres purely to immutability, but as i mentioned, i don't see why we should care about 100% immutability
<Corbin>
Because it's trivial to show that all functions are pure if there's no immutability, but it's a massive hassle if there's even a small cache or memoizing decorator. And if it's not pure, it's not *really* a function, is it? That's all. The design decision (mutability) leads to the bug class (impurity).
<d_bot>
<NULL> I don't think many programmers or computer scientists would stop calling a C function a function if it is impure
<d_bot>
<Ambika E.> I still don't understand your point, or at least I don't understand how it relates to mine.
<d_bot>
<NULL> It's quite accepted that a programming function doesn't exactly overlap with the concept of a mathematical function
<d_bot>
<Ambika E.> I think many of us are less concerned about the precision of these terms and how they're employed as descriptors than you seem to be
<Corbin>
NULL: In fact, "procedure" is a common term for precisely that reason.
<d_bot>
<NULL> Sure, but I hear "pure function" may more often than I hear "procedure"
<d_bot>
<NULL> So the ambiguity exists
<Corbin>
Ambika: Yes, I know. And I also recognize that this channel isn't to the point of #haskell, where there is serious talk of "statically-typed people" and "dynamically-typed people" as not just different styles of programmer, but different classes of person. But I intend to not let it get to that point, either.
<d_bot>
<Ambika E.> Hahaha
<companion_cube>
Corbin: yes, by python I mean the idiomatic python people actually write
<companion_cube>
not whatever fantasy you get running on rpython
<Corbin>
companion_cube: I tested my snippet on CPython 3.9. Indeed, it sounds like you're talking about community norms, rather than properties of languages. I don't mind this, but please recognize the tribalism that follows from the belief.
<companion_cube>
languages don't exist in the void
<companion_cube>
everything about cpython's design revolves around imperative OO
<companion_cube>
you can contrieve it into something else but it's not the design
<companion_cube>
(also look at how bad lambdas are)
<companion_cube>
by contrast, OCaml is designed around a mix of mutability (for the imperative part) and FP (generational GC, sum types directly integrated in the runtime, small allocation footprint) and a type system favoring ADTs and supporting immutability
kakadu has quit [Remote host closed the connection]
zebrag has quit [Quit: Konversation terminated!]
<Corbin>
companion_cube: Sure. For example, when I wrote pointfree OCaml code, I did not get good performance. And this is because OCaml is not designed for pointfree expressions.
<Corbin>
Maybe it's a difference in experiences. You say "look at how bad X is"; I say "yes". I don't really care what X is; you may well point at any feature of any programming language, and I will agree with you: X is terrible, X is bad, X sucks, X is Just Another Programming Language. Python is bad, OCaml is bad, etc.
<Corbin>
So I don't really care about whether something is designed for a purpose, just whether it has properties.
bartholin has joined #ocaml
<d_bot>
<darrenldl> i dont really follow the part about most(?) of python being expression rather than statements
<companion_cube>
Corbin: yeah, I'd say OCaml isn't great for pointfree
<Corbin>
companion_cube: So why doesn't the OCaml parser reject pointfree programs?
<companion_cube>
why would it do that
<companion_cube>
you can do some pointfree, sure
<Corbin>
companion_cube: Put another way: Why doesn't the parser enforce community norms and reject programs which don't use community-approved style?
<companion_cube>
you can also write some FP code in python, it'll just suck and be horribly slow, and overall go against the grain of all libraries and ecosystem
<companion_cube>
"community-approved" isn't a grammar category
<sim642>
That's what linters would be for
<companion_cube>
(also, the typechecker is the one that bars you from doing crazy pointfree stuff! your wish is come true)
<Corbin>
darrenldl: I guess you'd have to implement a Python parser to really get a feel for it. You can see exactly how much of the parser is expressions at https://docs.python.org/3/reference/index.html but this doesn't capture how many expressions are in the typical module; for every statement, there might be 5-10 expressions.
<d_bot>
<darrenldl> fair enough. i guess `return` irked me mostly and left me with the greatest impression
<d_bot>
<NULL> How do you have more expressions than statements in Python ?
<Corbin>
companion_cube: Okay, so if the tools that we're using to work with the language aren't using community norms, then what are they using? Perhaps they're using properties of the language! So even if the language isn't "in the void", the language and its tooling are still aligned by formal properties.
<companion_cube>
if you count every call, maybe
<d_bot>
<NULL> In terms of how many are in a file
<d_bot>
<NULL> Oh, unbound calls
<companion_cube>
Corbin: the tools will still suck for the unintended use case, again
<companion_cube>
like you discovered for pointfree OCaml: no one was banning it, it's just inconvenient and slow
<companion_cube>
just like FP in python is inconvenient and slow
<companion_cube>
(or, even worse, FP in C 😂)
<Corbin>
companion_cube: No, the lack of eta-equivalence in OCaml is definitely not something that arises in Python. Note how you circularly insist that Python is not a "functional language" by explaining that "functional programming" is slow in Python; what do you mean, exactly?
<companion_cube>
like I said: programming with expressions and immutable data structures
<companion_cube>
the ones python provides are all mutable, sometimes with a frozen version that cannot be updated in any way
<companion_cube>
there's no immutable map, no immutable list, no immutable sets; only frozen versions of the mutable versions
<companion_cube>
they even removed reduce and filter!
<companion_cube>
the main iteration mechanism is `for`
<companion_cube>
recursion is terrible, which is generally a good sign FP is not welcome
<Corbin>
There's no frozendict, it's true; but there are tuples and frozensets. There is *builtin syntax* for filter and map, akin to the builtin syntax in Haskell.
<companion_cube>
again, frozenset cannot be updated
<Corbin>
companion_cube: Recursion sucks in OCaml; I had no problem blowing the stack with pointfree code. And the semantics lack eta-equivalence, so the compiler can't simply figure it out. And, unlike in Haskell, there's no indication of when something is mutable. Clearly OCaml is not welcoming of FP either.
<companion_cube>
the only reasonable way to build one from user input is to build a set, then freeze it
<Corbin>
companion_cube: Yes, immutable values cannot be updated. That's what makes them immutable.
<companion_cube>
🙄
<companion_cube>
you can't build a new version cheaply
<companion_cube>
come on
<companion_cube>
OCaml has tailcall elimination and cheap function calls, which is a lot more than what python has
<Corbin>
Both CPython and PyPy have optimizations for cheaply rebuilding tuples and strs. The namedtuple metaclass in the stdlib has efficient methods for replacing and rebuilding.
<d_bot>
<NULL> What about all other structures (maps, sets, lists) ?
<companion_cube>
so `tup = tup + tuple([x])` is constant time? 🤔
<Corbin>
companion_cube: To be frank: I had to literally write my own CAM because OCaml's high-level interface can't compile pure functions very well and there is no blessed low-level interface. I really don't have an experience that mirrors your enjoyment of OCaml.
<companion_cube>
(same for frozensets, can you add or remove an element in O(ln n))
<companion_cube>
good on you
<companion_cube>
maybe you're trying to write Haskell in OCaml, so there's that
<Corbin>
NULL: Then you run back into the problem of whether Scheme is a "functional language".
<d_bot>
<NULL> To which I still have no answer because I don't know what its code looks like
<octachron>
If we are pointlessly trolling, I could argue that recursion sucks in haskell, with the prevalence of lazyness, there is no way to have a good mental model of time and space complexity. Hidding lazy evaulation as a ubiquitous hidden effect clearly defeats the separation of effects and pure functions. Clearly, haskell is not welcoming for FP.
<companion_cube>
if you look at my definition, scheme has 2/3 + immutable lists
<companion_cube>
so, pretty functional?
<Corbin>
companion_cube: I'm literally working with the same categorical combinators that Curien was using in the 1980s. My bytecode is based on the same VM that gave rise to Caml.
<companion_cube>
then you could compile to the OCaml VM :)
<Corbin>
octachron: It's not pointless to deconstruct "functional programming"; I view it as the root of quite a bit of tribalism. I think that folks usually mean "Lisp or ML"; they're talking about one of two syntactic traditions.
<companion_cube>
the bytecode is pretty stable
<Corbin>
companion_cube: Well, could you link to the docs for the bytecode? I recall asking you about this last year, and you told me that compiling to bytecode or malfunction was risky, and I should just emit high-level OCaml source instead.
<companion_cube>
I wish the official website listed papers
<octachron>
Corbin, syntax is a minor detail. I don't think that lot of people think of ML or Lisp as a syntactic tradition.
<octachron>
Yes, functionnal programming is not a formal definition, and it identifies mostly a branch in the phylogenetic tree of languages. It doesn't mean that the classification is not useful.
<Corbin>
companion_cube: Excellent! Thank you so much. I've mostly moved past this stage, but this could still be useful if I were to use OCaml for compiling from bytecode to native code.
<companion_cube>
I mean, this is just the bytecode VM
<companion_cube>
if you want to compile to native, malfunction (or OCaml) is the only way that I know of
<Corbin>
The native-code compiler can't take in bytecode as input? Huh, I could have sworn that that was in the ZINC paper. Maybe it never got implemented?
<Corbin>
I'm already JIT'ing bytecode to native code though, and I'm about halfway to emitting QBE (lightweight LLVM-like SSA), so I'm not sure if it's worth the effort.
<companion_cube>
maybe in caml light? but OCaml's native compiler just shares passes with the bytecode compiler
<companion_cube>
the early passes*
<companion_cube>
it diverges after `lambda`
<companion_cube>
lol your classification puts OCaml at the "less declarative" end
<companion_cube>
(or I guess, there's several entries for it, fair enough)
<Corbin>
Sure. The more-declarative end usually requires search and fancy compilers; it's a tradeoff. Any "systems language" (another silly tribal term) usually wants to be less declarative in order to gain speed or address machine-specific features. (Monte sits with E, and Cammy sits at the top since it's not Turing-complete! None of this is bad, unless everything is bad.)
<d_bot>
<Ambika E.> Why are they silly even if tribal
<d_bot>
<Ambika E.> I don't understand what makes these terms not useful in your eyes
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
<d_bot>
<Ambika E.> In my mind no matter how much the term is defined by a human community, they retain meaning and are useful for describing things quickly
<companion_cube>
I don't even know what tribe that would be
<companion_cube>
like, Elixir is clearly in none of the historical traditions, syntax wise or culture wise
<companion_cube>
but it's as FP as it gets 🤷
bartholin has quit [Remote host closed the connection]
Haudegen has joined #ocaml
<Corbin>
Well, I think that people usually mean for them to describe niches; some languages are good at some tasks, or so we might hope. But Turing-completeness kind of demolishes that; some languages might be *short* in expressing some tasks, which is good for avoiding bugs (because bugginess correlates with amounts of code, the so-called "defect rate"), but otherwise there's no clear reason for why one language is preferable to another.
<companion_cube>
brainfuck is turing complete, yet it's obviously good for nothing but being a fun toy
<Corbin>
At best, we might be able to say that some languages are comparable in expressive or abstractive power. I won't go further into this; you'll need category theory and a slow reading of https://fexpr.blogspot.com/2013/12/abstractive-power.html
<d_bot>
<Ambika E.> Some languages are particularly convenient for writing code that do specific things or writing code that adheres to a certain technical design
<d_bot>
<Ambika E.> Trying completeness does not mess with this at all
<d_bot>
<Ambika E.> The fine grain details of "ability" are far too low level to be the concern of the type of language being discussed here
<d_bot>
<Ambika E.> We are discussing terms of convenience, that people use so that they don't have to enumerate feature lists to get across what it is about some language and its distribution that makes it convenient for x or y
<d_bot>
<Ambika E.> This is useful
<companion_cube>
convenience, performance, fit with the ecosystem
<companion_cube>
aka things you need to get real things done
<d_bot>
<Ambika E.> When i say a language is a systems language it's rather likely that the person I'm talking to understands the gist of what i mean, and that's all i really care about
<d_bot>
<Ambika E.> That's enough for me to deem the term useful and worth keeping around
<Corbin>
It tells me a lot about your inner ontology, but almost nothing about the language in question. Could it be C, C++, D, Zig, Go, or Rust? It probably isn't a Smalltalk or Common Lisp, but why not?
<companion_cube>
I find "systems language" a lot less clear than "functional language" :p
<companion_cube>
like, there's some definitions that should kick Go out of the list
<d_bot>
<Ambika E.> Seeing as you guessed pretty much all the languages i had in mind, it seems the term is still useful to me
<d_bot>
<Ambika E.> I find that the why and why not of which languages fit the bill are not important so long as this is not a formal term and is moreso just a convenient way to get something across
<companion_cube>
it's another way to exclude python 🙃
<d_bot>
<Ambika E.> What is?
<companion_cube>
"systems languages" :)
<d_bot>
<Ambika E.> Lol
<Corbin>
Ambika: Well, I would point out that five of six of them are in the syntactic tradition of Algol. They aren't espeically close to the metal or ergonomic or good, but their inheritance of that tradition gives them inertia. (And note how loudly people complain about Rust, the odd one out!)
<companion_cube>
(?!)
<companion_cube>
(well, if you mean the odd one because it's good, why not :))
bartholin has joined #ocaml
spip has quit [Ping timeout: 240 seconds]
spip has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 255 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
Serpent7776 has quit [Read error: Connection reset by peer]
Serpent7776 has joined #ocaml
gravicappa has quit [Ping timeout: 246 seconds]
* qwr
has to agree that systems language is pretty fuzzy, even mandatory GC doesn't really prevent you from writing for example operating system kernel, common definition seems to be "it compiles to fast code" ;)
<d_bot>
<mk-fg> Doesn't that commonly include bash and python though?
<d_bot>
<mk-fg> Or maybe I'm thinking of languages for various os scripts
<d_bot>
<mk-fg> And that's != systems language
<d_bot>
<Ambika E.> Yeah that's very different
<d_bot>
<Ambika E.> My stance is that "can" is not what makes a language a systems language, "convenient for doing so" is moreso what i think the criteria should revolve around
<d_bot>
<Ambika E.> If the goal is to have a term or descriptor retain its usefulness then we should avoid giving it a meaning that can easily be shown to have little value
<qwr>
this imho disqualifies C ;)
<d_bot>
<Et7f3 (@me on reply)> I think lang for os need to be able to bootstrap themself
<d_bot>
<Ambika E.> Sure, companion cube added two criteria to my list and made it a better one, you can play around with the definition to approximate what we all have in our head
<d_bot>
<Et7f3 (@me on reply)> I didn't see a bash implementation in shell