<dh`>
"systems language" is a political term that means "language where the designers don't insist they know better than you"
<drakonis>
it is a funny term
<drakonis>
but that's not accurate
<dh`>
similarly, "functional language" is a political term that means "language that caters to a dated superstition about state in programs"
* dh`
offends everyone. cheerio!
<drakonis>
that one's mainly related to haskell
<drakonis>
state is bad etc etc
<drakonis>
functional programming is all about a way to write code anyways
<drakonis>
a style
<dh`>
we could argue at length about what functional programming is and isn't, but when it comes down to it, it's about privileging call-stack state
<dh`>
and sometimes pretending that other state doesn't exist
<dh`>
my experience over the years has been that code written by FP advocates in functional languages is full of global variables
<dh`>
because reality demands that state exists and the languages mostly lack tools for handling it more productively
<drakonis>
use lisps alright.
<drakonis>
shed this mask
<dh`>
_everything_ that I've seen in lisp is full of global variables
<dh`>
granted that isn't a great deal, dealt with lots more ml and haskell code
<drakonis>
its more about giving zero fucks about style
<dh`>
anyway I'm being flip
<drakonis>
very much so
<dh`>
more seriously, I would say a "systems language" is one you can write an embedded RTOS in without hating yourself
<companion_cube>
ah, fun one
<companion_cube>
probably makes Ada the best systems language
waleee has quit [Ping timeout: 244 seconds]
<dh`>
not convinced about that :-)
<dh`>
but it does cut the scope down a lot
<dh`>
what I was saying before about the language designers claiming to know better is a thing, though
<dh`>
there's a tendency in some quarters for language designers to treat the programmer as the enemy
<d_bot>
<hockletock> I thought that was compiler writers
<d_bot>
<hockletock> I guess there is some overlap
<dh`>
the most glaring example I know of is in modula-3, where there's an appendix of the modula-3 book that contains transcripts from the design committee's sessions
<dh`>
where they worry at length about programmers finding ways to circumvent the type system by abuse of modules
<dh`>
(and IIRC come to some very dubious design decisions as a result; but it was years ago and I forget details)
<dh`>
there's a tendency among the ... less qualified, let's say, systems programmers to not appreciate the value of type safety or soundness of type systems
<dh`>
they just perceive type errors as an impediment to writing the program they want
<dh`>
these people are the ones that the language designers in question are concerned about; with some justification
<dh`>
and they resent languages that they feel are are set up to get in the way
<dh`>
both sides of that argument are in the wrong
<grobe0ba>
there are types other than uint8_t? i thought you just `uint8_t *all_of_ram=0x0;' and do byte manipulations with offsets into that array...
<dh`>
you probably at least need uint64_t as well so you can reason about machine registers :-)
<grobe0ba>
nah, the compiler magics that away for me. :P
<dh`>
although in that environment it would be tempting to revert to a word-addressed architecture so everything is uint36_t
<dh`>
(also, even though I was blethering/almost-trolling before, there is a problem with functional programming and stateful abstractions; if anyone wants to talk about it I'm happy to be serious)
mbuf has joined #ocaml
<d_bot>
<Bluddy> some good points here. I'm not sure functional program designers have proved their point that mutable state is problematic.
<d_bot>
<Bluddy> it's kind of an assumption based on "knowledge"
<d_bot>
<Bluddy> the body of 'knowledge' in the programming field (outside of the actual type and PL theory) tends to be extremely unscientific and mostly based around aesthetics, personal preference etc
rak has quit [Ping timeout: 255 seconds]
aspe has joined #ocaml
<dh`>
well, mutable state definitely makes things more complicated
<dh`>
because the state associated with the call stack is structured it's simpler to reason about.
<dh`>
the problem is not that functional programming isn't a simple and elegant model, it's that it's not really adequate for a wide variety of real-world programming tasks
<d_bot>
<Bluddy> it definitely seems to make reasoning about behavior more localized
<d_bot>
<Bluddy> but in my experience it does make quite a few algorithms more messy
<d_bot>
<Bluddy> and yes there's the performance problem
<d_bot>
<Bluddy> I just wish these things were backed up by more than just anecdotes
<d_bot>
<Bluddy> when you say it's not really adequate for real-world tasks, are you talking about performance?
Serpent7776 has joined #ocaml
bobo_ has joined #ocaml
spip has quit [Ping timeout: 256 seconds]
<grobe0ba>
i like having a mix of mutable/immutable, but i like having it where the compiler can tell me about it, not just C/C++ `const' which in reality does nothing useful.
<grobe0ba>
if i say something should be immutable, don't give me a supressable warning. immediately abort the compile, and refuse to proceed is the only good answer there, imo.
<d_bot>
<Ambika E.> Agreed
gravicappa has joined #ocaml
<dh`>
re performance: no, it's about program structure
Tuplanolla has joined #ocaml
<qwr>
treating programmer as enemy - i've kind of been there when creating DSL-s, and it was about avoiding bugs resulting of unintentional or accidental abuse of DSL by programmers not knowning why the shouldn't do something, a bit like why type soundness is practical issue - I guess that most restrictions placed by language/compiler designers are due similar issues
<dh`>
(const is not useless, it's just got a specific purpose and that's all it works for)
<d_bot>
<Ambika E.> I feel like my experience hasn't been that the program structure that fp is conducive to has stopped me from writing any real world programs, but maybe i don't write the kind of programs you have in mind
<dh`>
one of the things that's not widely appreciated is that compilers (and interpreters) are considerably different inside from ~everything else
<qwr>
my observation was quite like - "if something can be used wrong way, then someone sometime will find a way to do it"
<dh`>
people who work on languages write compilers and interpreters a lot and that skews perceptions
<qwr>
and then it was me who usually had to hunt the resulting bugs ;)
<d_bot>
<darrenldl> what scenarios make fp wildly incompatible?
<dh`>
qwr: not working with fools is extremely helpful :-|
<d_bot>
<darrenldl> (or at least not usable even for subcomponents
<dh`>
the conclusion I eventually came to is that you can't make any programming language idiot-proof and it's more or less hopeless to try
<dh`>
anyway in lots of non-compiler software there are problems that are naturally handled with stateful abstractions
<dh`>
if you encapsulate the state nicely it all works cleanly; if you try to make them stateless to conform to FP orthodoxy it becomes a huge mess
<dh`>
files are one obvious example
<d_bot>
<Ambika E.> Yeah I usually find that that's not really worth it nor does it really hurt much to make a few things mutable
<d_bot>
<Ambika E.> I like OCaml since it doesn't feel like i have to give up fp just because some things have to be mutable
<dh`>
what "fp" really means at that point isn't all that clear
<qwr>
large parts of haskell code tend to be using some monad representing state
<dh`>
yes
<d_bot>
<Ambika E.> The program structure isn't really that different
<dh`>
all haskell code eventually ends up in the IO monad
<d_bot>
<Ambika E.> You have some side effects but it's not like suddenly you're writing C++ or something
<dh`>
consider something like make (or your favorite other build tool) where everything it's doing is interacting with system and file state
Sankalp has quit [Ping timeout: 258 seconds]
<d_bot>
<Ambika E.> If your tool is high level enough it probably is doing enough interesting reasoning such that your code isn't entirely calls to unix file io functions
Sankalp has joined #ocaml
<dh`>
some of it; but also, one of the things you want is a caching layer so you don't need to repeat those calls unnecessarily
<dh`>
trying to make that stateless is futile :-)
<d_bot>
<Ambika E.> Totally
<d_bot>
<Ambika E.> So i wouldn't
<d_bot>
<Ambika E.> And I'd be pretty happy about that
<dh`>
(and it's a lot tidier to work with if the state is hidden inside it instead of being exposed to the caller)
<d_bot>
<Ambika E.> Right
<dh`>
in systems and application code lots of things are like that
<d_bot>
<Ambika E.> Often i find that if we need something to be mutable we try to just provide the smallest workable interface possible to encapsulate that thing and it tends to work out and not really interfere with the overall structure of the code
<dh`>
in OS code virtually everything is
<dh`>
right
<d_bot>
<Ambika E.> I write ocaml at work, we're building a general purpose P2P networking library there atm and there's a lot of mutability and unix system calls but they're all abstracted behind modules that provide functional interfaces so it tends to work out in a way that is comfy
<d_bot>
<Ambika E.> I'd assume so, i haven't really looked at anything OS level
<dh`>
OS code is layers of stateful abstractions where each layer hides away stuff you really don't want to think about higher up
<dh`>
at least when it's reasonably well written
<dh`>
you get a file; inside the kernel there are vnodes and inodes and buffers and journals and all kinds of other goop you basically never need to think about as an application writer
<d_bot>
<Ambika E.> Sure
<dh`>
not to mention that inside the kernel there are disks, but inside the disk there are all kinds of other things that we don't have to worry about inside the kernel
<dh`>
none of it would work if the state were explicit, because there's sharing you don't see
<dh`>
not to mention concurrency :-)
<d_bot>
<Ambika E.> Sure, sounds like what we do
<dh`>
yeah, I'd say it's generally pretty well understood how to do this kind of thing
<dh`>
it's just not FP
<dh`>
(nor is it exactly OO, because the OO world has lots of its own doctrine that doesn't necessarily appear either)
<d_bot>
<Ambika E.> I feel like this is just common sense and is kind of paradigm agnostic
<dh`>
yes and no
<d_bot>
<Ambika E.> We certainly do it in our functional codebases because it allows us to retain the structure we want
<dh`>
nobody understood any of this 40 years ago
<d_bot>
<Ambika E.> Well, sure
<d_bot>
<Ambika E.> Common sense tends to stand on the shoulders of whatever came before
<dh`>
I would say it's its own paradigm, just not one that has a catchy name and an army of zealots
<d_bot>
<Ambika E.> I don't really see why it should be, i definitely do this whether I'm writing C, OCaml or C#
<d_bot>
<Ambika E.> It just seems to make sense pretty much any time
<dh`>
sure
<d_bot>
<Ambika E.> Feels like that's just the whole notion of abstracting away complex systems that need to be able to manage themselves and not allow consumers who are not aware of one another to do the management for them
<dh`>
I would say that the most basic principle is that programming is programming, no matter what tools you're using
gravicappa has quit [Ping timeout: 255 seconds]
<dh`>
but if you go talk to FP zealots you'll find them not accepting the idea of stateful abstractions
<dh`>
or at least that's been my experience
<dh`>
of course maybe that's tautological since zealots definitionally don't think outside their boxes
<d_bot>
<Ambika E.> Maybe so
<d_bot>
<Ambika E.> I'd say I'm pretty enthusiastic about the paradigm, I've basically only worked in functional languages and rust for the past 5 years because i like writing functional code, but I've always felt that the goal is for writing code to be a pleasant experience
<dh`>
I got into an irc argument with someone once who claimed that functions were the vehicle of abstraction and the idea of an abstraction that wasn't a function was nonsensical
<dh`>
AFAICR
<d_bot>
<Ambika E.> Thus i have stuck to ocaml and F# and relied on mutability when necessary
<d_bot>
<Ambika E.> Hahaha
<d_bot>
<Ambika E.> What channel was that in?
<dh`>
no idea, could have been here but more likely not
<dh`>
anyway I've found that even for writing compilers a few tastefully chosen mutable things make everything much cleaner
<dh`>
writing a compiler in haskell was an extremely aggravating experience that I chose not to repeat
<d_bot>
<Ambika E.> I'd agree
<d_bot>
<Ambika E.> I think that's why OCaml is a popular language of choice for plt people
cedric has joined #ocaml
<dh`>
yeah
<dh`>
even in a compiler there's a big chunk of stuff that is mutable where the state is best hidden: compiler options
<dh`>
extremely aggravating in haskell that if you want to be able to turn anything on or off you have to plumb the config state through everywhere, or wrap the entire compiler in an additional layer of monad
<dh`>
or rather that's not even inherently mutable, it's just that by far the tidiest way to deal with it is to have a module where the settings are kept as state
<dh`>
(or maybe more than one depending on how elaborate your world is)
Sankalp has quit [Changing host]
Sankalp has joined #ocaml
bobo_ has quit [Ping timeout: 246 seconds]
spip has joined #ocaml
<d_bot>
<Bluddy> By `state` are you referring to mutable state? Because you can make a lot of your state immutable and then the high-performance parts can be made mutable.
<d_bot>
<darrenldl> absolutely - if you have a global context for all your state transitions anyway, why keep passing it around
<d_bot>
<darrenldl> ye ill agree that fp did not play a large part precisely when writing os interaction-heavy code
<d_bot>
<Bluddy> on the other hand, if you're writing fp code, you're probably passing *some* context record around, and you can often just tuck the options in there
<d_bot>
<Bluddy> it does make it easier to reason about which parts of the code use what
<d_bot>
<Bluddy> but I do wish people wrote blog posts about the lessons of writing FP code in their particular domain.
<d_bot>
<Bluddy> you can't expect the same practices that work for compilers to work for other domains
Sankalp has quit [Ping timeout: 240 seconds]
Sankalp has joined #ocaml
Sankalp has quit [Ping timeout: 272 seconds]
<d_bot>
<darrenldl> fp is still really nice for decision (tree) part of the os interaction code, cause you can run it separately for testing : v
<marlinski>
just starting with ocaml and as I am discovering and playing with the option type, I feel it is a bit repetitive to always pattern mtch on None and Some, is there an operator like '?' to basically return the Some value or the right side of the ? operator
<sim642>
The standard Option module has some useful functions
<marlinski>
thanks for the resources sim642 and d_bot ! I'll look at it right now
<marlinski>
s/d_bot/Bluddy
raskol has joined #ocaml
<Corbin>
ambika, dh`: The big pattern you're talking about is called "isolation", and it is a simplifying technique which allows us to only study part of a system at a time. Not all languages support isolating modules, even if they allow for common code to be factored out.
bartholin has quit [Ping timeout: 255 seconds]
aspe has quit [Quit: aspe]
raskol has quit [Ping timeout: 276 seconds]
hyphen has quit [Ping timeout: 258 seconds]
<d_bot>
<darrenldl> marlinski: also check custom let bindings to use Option.bind and map nicely
bartholin has joined #ocaml
hyphen has joined #ocaml
gravicappa has joined #ocaml
raskol has joined #ocaml
raskol has quit [Ping timeout: 246 seconds]
zebrag has joined #ocaml
romildo has quit [Quit: Leaving]
raskol has joined #ocaml
waleee has joined #ocaml
mbuf has quit [Quit: Leaving]
hyphen has quit [Ping timeout: 246 seconds]
hyphen has joined #ocaml
bartholin has quit [Ping timeout: 246 seconds]
hyphen has quit [Ping timeout: 246 seconds]
hyphen has joined #ocaml
bartholin has joined #ocaml
hyphen has quit [Ping timeout: 244 seconds]
hyphen has joined #ocaml
hyphen has quit [Ping timeout: 258 seconds]
hyphen has joined #ocaml
<d_bot>
<Eden> Hey. Why is it only priting some of the arguments when passing `--help`
<d_bot>
<Eden> ```ocaml
<d_bot>
<Eden> let spec { filename; operation; vals; difficulty} =
<d_bot>
<Eden> [("--file", Arg.Set_string filename, "Read sudoku from given file");
<d_bot>
<Eden> ("-f", Arg.Set_string filename, "Read sudoku from given file");
<d_bot>
<Eden> ("--solve", Arg.Unit (fun arg -> operation := Solve), "Solve the given sudoku board");
<d_bot>
<Eden> ("-s", Arg.Unit (fun arg -> operation := Solve), "Solve the given sudoku board");
<d_bot>
<Eden> ("--", Arg.Rest (fun s -> vals := Array.append !vals [|try s with Failure e -> raise (Arg.Bad e)|]), "If file is not given read from stdin")]
<d_bot>
<Eden>
<d_bot>
<Eden> let parse argv =
<d_bot>
<Eden> let filename = (Result.get_ok default_state).filename in