sagax has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 246 seconds]
waleee has joined #ocaml
<d_bot>
<darrenldl> : D
wilfred has quit [Quit: Connection closed for inactivity]
hackinghorn has joined #ocaml
infinity0 has joined #ocaml
vicfred has quit [Quit: Leaving]
[itchyjunk] has joined #ocaml
ulyssa has quit [Ping timeout: 246 seconds]
ornxka has joined #ocaml
<ornxka>
just did opam install -b coq-vst.2.6, it spent 30 minutes presumably working, but ~/.opam/default/lib/coq/user-contrib/VST/ contains nothing except some text files
<ornxka>
i dont see the build dir anywhere either
<ornxka>
is there some other place it puts coq object files?
<ornxka>
ah in .opam-switch i see the build dir at least..
<ornxka>
welp, i can just link directly from the build dir so close enough i guess
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #ocaml
[itchyjunk] has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 268 seconds]
<d_bot>
<dj charlie> ` module A = struct type 'a monad = Some of 'a | None effect Monad_none : 'a monad let (>>=) (g : 'a monad) (x : 'a -> 'b monad) = match g with Some v -> x v | None -> perform Monad_none end;;`
<d_bot>
<dj charlie> `let open A in match Some 123 >>= fun v -> None with effect Monad_none k -> continue k (Some 123) | Some v -> v | None -> 456;;`
<d_bot>
<dj charlie> not possible to do effects without concrete types? can replace 'a with string and ez
<d_bot>
<dj charlie> could someone show me how it's done?
<olle>
1) LOC is highly correlated to fault density
<olle>
2) Macros decrease LOC
<olle>
3) Hence, macros decrease fault density
<olle>
4) Languages with macros have lower fault density than other languages, all other things being equal
<olle>
So why no macros in OCaml???
bartholin has joined #ocaml
<d_bot>
<Emile Trotignon> Some people want to do macros in OCaml, and I think it is a great idea. However its hard to get right, and OCaml does not have a whole lot of devs
<d_bot>
<Emile Trotignon> What makes it hard to implement is that a nice macro implementation in OCaml would do a lot more than the C preprocessor (you can always use the C precessor on Ocaml programs).
<d_bot>
<Emile Trotignon> I think the two issues are typing the macros correctly, and making it possible to compute OCaml values at compile time, and access them at run time.
kakadu has joined #ocaml
<olle>
"Hard to get right" --> Hard to make type-safe?
<d_bot>
<Emile Trotignon> I am not a 100% sure this is the difficulty, but yes
<Franciman>
olle: what does fault density mean?
<d_bot>
<Emile Trotignon> Oh and there is an other thing : we do have PPX, and they cover some of the use cases of macros (they are harder to build, but a lot more versatile)
<olle>
Franciman: Number of defects per LOC
<olle>
Yeah, PPX covers some use-cases, but not all
<d_bot>
<darrenldl> olle: i am not convinced a system written in untyped scheme/lisp has fewer faults than an equivalent written in ocaml
<d_bot>
<darrenldl> right all other things being equal huh...
<olle>
darrendl because of types?
<d_bot>
<darrenldl> yes
<olle>
Mm, didn't see any study on that
<d_bot>
<darrenldl> im not sure how one would argue an untyped system is at least as good as ocaml in exhaustiveness check
<d_bot>
<darrenldl> anyhow, i dont know if your 1) point is fully accurate
<olle>
1) Should be "LOC per software artifact", I guess, where artifact = function, class, module
<d_bot>
<darrenldl> but that excludes consideration of other aspects of code construction?
<d_bot>
<darrenldl> also, you said correlation in 1), but you reach a causation in 3)
<olle>
darrendl, yes, I assume fault density is not causing high LOC :)
<olle>
But other things can be colinear with LOC, I guess, and cause the fault density
<Franciman>
thanks olle
<olle>
Maybe sloppy devs write more code?
<olle>
Or longer functions.
<d_bot>
<darrenldl> 3) only holds if 1) reads "high LOC leads to high fault density", which might be true i guess, idk tbh
<olle>
Lots of things can correlate with high fault density, it's a question of to which degree
<d_bot>
<darrenldl> my point is you cannot argue for causation from correlation
<d_bot>
<darrenldl> anyway im being mitpicky
<d_bot>
<darrenldl> nitpicky
<olle>
Yes, I understand
<olle>
But it's not always that easy
<olle>
Smoking correlates with cancer, but it's doesn't cause cancer
<olle>
Still, by not smoking, you can lower your chance of getting cancer.
<d_bot>
<darrenldl> im pretty sure injecting carcinogen into lung is a good enough argument
bobo has quit [Quit: Konversation terminated!]
<olle>
Not talking about arguments :)
<olle>
Arguments are not proof
spip has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<d_bot>
<darrenldl> right, the lack of true causation school of thought and so no meaningful difference between the two, only statistical significance
xiongxin has joined #ocaml
[itchyjunk] has joined #ocaml
rond_ has joined #ocaml
<olle>
No, you can have true causation in some domains.
<olle>
Physics being one
jaitoon has quit [Quit: Leaving]
<companion_cube>
Well this ain't physics
<d_bot>
<leviroth> Err, smoking does cause cancer though? I'm not following the line of thought here.
<companion_cube>
Yeah what a weird thing to say
<d_bot>
<mk-fg> I read it as "smoking is known to increase the risk of certain types of cancer" as in "people who smoke are more likely to get it" - vs "causes cancer" as in "everyone who smokes (for some definition of this word) gets cancer" (as in definitive causation)
<haesbaert>
"everything" causes cancer at some point and everyone will also have cancer at some point in time, by smoking you increase your chance of having cancer before you die of something else
<d_bot>
<mk-fg> Same as "more loc is known to generally have more faults" vs "more loc definitely has more faults"
<d_bot>
<leviroth> Sure but it seems like this was meant to be an elaboration of the point that correlation <> causation, and that isn't really the same thing.
<d_bot>
<mk-fg> But isn't that the difference there? I.e. causation would be something like "causes by definition" (as in physics) while "known to increase the risks" is very much corellation
<companion_cube>
The loc thing is also based on weak empirical evidence
<companion_cube>
Ada might be more verbose than C but I'd bet it reduces bugs
<d_bot>
<leviroth> Like if I say "X is correlated with Y, therefore X causes Y," someone could fairly point out that I'm improperly inferring causation from correlation, and it doesn't help if I say "Well, I don't mean that X definitively causes Y, I'm just saying that if you do X you make Y more likely." In either case, my conclusion isn't supported by the premise.
<olle>
Smoking does not cause cancer, because some people smoke until they're 100 without getting cancer. There is a strong correlation, however.
<companion_cube>
Then nothing causes anything
<olle>
If A causes B, then it *always* causes B
<olle>
Not just with a probability
<d_bot>
<leviroth> Yeah, that just isn't what the distinction between correlation and causation means
<olle>
No? :)
<companion_cube>
Falling from a plane doesn't even cause death
Haudegen has joined #ocaml
<olle>
companion_cube: Sure, all fundemantal forces have clear causes
<olle>
Gravity etc
<companion_cube>
Even rabies don't cause death
<Armael>
from macros to rabies
<haesbaert>
olle: this is a bad arugment since cancer is a natural phenomenon that _will_ occur for sure at some point.
<olle>
Well. Maybe there's a difference between everyday "causes" and strictly logical causality.
<haesbaert>
the only cause of cancer is "cell reconstruction"
<d_bot>
<darrenldl> > from macros to rabies
<d_bot>
<darrenldl> we have come full circle : D
<olle>
haha
<companion_cube>
Ol
<companion_cube>
olle: you don't say
<companion_cube>
Logic causation is an ideal
<companion_cube>
Just like spheres don't exist
<olle>
Hmmmm, not sure I agree
<olle>
Gravity causes items to fall towards earth, 100% of the time
<olle>
As far as we know, at least.
<olle>
I'm being hyper-sceptical
<olle>
I'm not*
<olle>
><
<companion_cube>
You are
<haesbaert>
cancer increses your chance of having cancer, 100% of the time.
<companion_cube>
Smoking statistically causes cancer
<companion_cube>
And that's what people mean by "cause"
<olle>
No, hyper-sceptical would be "you cannot prove that gravity always causes things to fall", which I'm not saying.
<haesbaert>
that doesn't mean you wont die of something else before you develop such cancer
<companion_cube>
If you're at the center of the earth you don't fall :)
<d_bot>
<leviroth> I feel like this is getting a bit abstract, though. If I observe a correlation, I'm not (absent some other ingredients) entitled to infer that there's deterministic causation, and I'm *also* not entitled to infer that there's statistical causation.
<companion_cube>
Does asbestos cause sickness! 🤔
<octachron>
Gravity is a bad example due to the lack of quantum version of gravity. But generally, any human-level description of physics relies on a effective theory which is probabilistic by nature.
<d_bot>
<leviroth> So if somebody says "fewer LOC is correlated with fewer bugs," and they want to draw *either kind* of conclusion about causation, we can reasonably ask them for the other necessary parts of the argument.
<d_bot>
<mk-fg> Don't think difference between math and reality matters for argument above anyway, as it's about some phenomena in reality :)
<octachron>
For instance all of chemistry
<companion_cube>
Also the loc thing has weaker evidence
<olle>
octachron: What, no? Theory of gravity is NOT probabilistic, that's the point.
<companion_cube>
Like all the software engineering studies, they suck
<olle>
companion_cube: Boooo
<olle>
Anti-intellectual ;)
<octachron>
The unknown correct quantum theory of gravity is not fully deterministic at the macroscopic level.
<olle>
octachron: I'm talking about Einstein, which is what's used today
<octachron>
Which is also know to be an approximation and not a fundamental theory.
<companion_cube>
Not in everyday life
<companion_cube>
In every day life people still use Newton :)
<olle>
Hehe, in their heads? Sure.
<d_bot>
<mk-fg> Wrt original argument, I think macros in lisp and god-forbid C cause enough opacity and confusion to be not worth it even if there's some relatively-small relation between loc and faults
<olle>
octachron: I'm not gonna go there xD
<olle>
mk-fg, consider C *without* macros, perhaps?
<companion_cube>
No, for engineering too
<companion_cube>
Unless you do GPS and the likes where precision is high enough
<olle>
Right
<octachron>
Even in astronomy, it is far more efficient to do your galactic cluster collision simulation with Newtonian gravity.
<Chouhartem>
companion_cube, Newton converges quite well in many cases, so it's a good numerical algorithm. Not surprising that people use it in real life
<d_bot>
<mk-fg> Hm, I'd rather consider C with better abstractions, like cross platform libraries
<companion_cube>
And in computers we use floats
<d_bot>
<mk-fg> Which would be a better alternative to macros available without them in a language
<olle>
mk-fg the argument was "everything else being equal"
<companion_cube>
Which are literally approximations of reals
<d_bot>
<mk-fg> Yeah, "everything else being equal" write libraries and don't use macros
<olle>
Not sure libs covers all macro use-cases
<companion_cube>
mk-fg: or zig!
<d_bot>
<mk-fg> Yeah, not sure either, but imo it's just a truism in practice, not an abstract "all cases"
<companion_cube>
Macros would be nice
<companion_cube>
But they'd make the compiler more buggy 🤔
<d_bot>
<mk-fg> Maybe there can be a nice macros too, as also pointed out above
<d_bot>
<mk-fg> cpp doesn't have to be some kind of ideal :)
<d_bot>
<Drup> that would be a very dystopic programming world.
<companion_cube>
Yikes, please no
<companion_cube>
Proper macros, not cpp
<d_bot>
<mk-fg> But that'd have to be included in the argument and change it
<companion_cube>
There's cppo if you're that kind of freak
<companion_cube>
:)
<olle>
We didn't discuss colinearity anything tho
<olle>
If LOC also always have higher cyclomatic complexity
<olle>
Or cross-cutting concerns
<companion_cube>
The good news is that ocaml is whitespace insensitive
<companion_cube>
You can put your whole program on one line
<companion_cube>
And thus reduce the bug count
xiongxin has quit [Ping timeout: 250 seconds]
<olle>
It's an important question if terses languages have lower fault density for similar domains
<olle>
But I dunno
<olle>
terser*
<d_bot>
<mk-fg> I think problem is that such arguments always imply some theoretical "all things being equal" and they're simply not (and very much not) between different implementations
<d_bot>
<mk-fg> I.e. you have more LOC in simplier more bugproof rewrites for sure, so without that kind of unrealistic implication, such argument is immediately invalid
<d_bot>
<mk-fg> And ditto for companion_cube's example above :)
<companion_cube>
;)
<companion_cube>
Macros also obscure your code, so, more bugs
<companion_cube>
It's honestly impossible to have scientific arguments about that
<olle>
I believe that. Just need smarter studies.
<companion_cube>
Studies with 15 people, a lot of variables...
<olle>
I don't*
* olle
damn it
<olle>
companion_cube: Increase number of people, they're normally distributed anyway ;)
<companion_cube>
It's like making studies on what makes a good book, based on average syllable count
<d_bot>
<mk-fg> Still, there are probably better general ways to do things than others, which we all follow
<d_bot>
<mk-fg> And those can maybe be discovered via scientific method
<d_bot>
<mk-fg> Instead of haphazard lore and cargo cults
<companion_cube>
If you can't measure the effect (good code) you're fucked
<d_bot>
<mk-fg> In large communities, e.g. linux kernel they kinda do such measurements via discussions and consensus from there
<d_bot>
<mk-fg> And then write this as a style guide or linus yelling at people who do things against common wisdom, even if not codified
<d_bot>
<mk-fg> So that result will be likely more bugproof and easier to maintain than a random code style which other people find hard to work with
<olle>
companion_cube: Compare with a book? Come on.
<d_bot>
<mk-fg> (even if perfectly correct from C perspective)
<olle>
companion_cube: You *can* measure good code
<olle>
Or, you can measure some aspect of good code
<olle>
Not all aspects (yet)
<d_bot>
<mk-fg> It'd still depend on people working with the code, which might change with time and culture
<d_bot>
<mk-fg> I.e. "good code" now might be "bad code" later
<companion_cube>
olle: only things you've assumed are good code
<olle>
companion_cube: Assume on good grounds
<companion_cube>
And yes, compare with a book, what matters is human readers
<olle>
No no, that's only one aspect
<olle>
And, in fact, you can measure some objectives qualities of books too
<d_bot>
<mk-fg> Of writing in the books, you mean? Doubt :)
<olle>
Font size
<olle>
Sentence structure
<olle>
Grammar
<d_bot>
<mk-fg> Oh sure, but that's not related to what actually matters
<olle>
If you need to skip between pages to follow the story
<d_bot>
<mk-fg> I.e. how all that is perceived
<d_bot>
<mk-fg> By the reader
<d_bot>
<mk-fg> You can measure font size, and one reader will say "it's too large" and other "it's tiny!"
<d_bot>
<vinz> Hi ! I'm struggling a bit around compilation of C code + ocaml: is there a way to ask ocaml to compile only .c files and build a lib*.a static library ? I only manage to build .cmxa and .cma files
<companion_cube>
Yeah and the books with creative narrations are thus bad
<olle>
mk-fg yes, and then you pick the font most people can read. easy, huh? :)
<companion_cube>
Thrillers should start with the name of the killer for better comprehensibility
<d_bot>
<mk-fg> Yup, and that's where it all ends up
<d_bot>
<mk-fg> Same as `I.e. "good code" now might be "bad code" later` above
<olle>
Good code has lower fault density and higher changeability
<d_bot>
<mk-fg> You measure it for specific community
<olle>
You can measure both those metrics
<olle>
The thing you can't measure is naming of functions and variables. But lots of other metrics.
<d_bot>
<mk-fg> Pretty sure you can measure naming too
<d_bot>
<mk-fg> Even across whole human population, if necessary
<olle>
And if comp sci will move forward, we have to drop this notion of "research doesn't matter" - that attitude will keep us in the alchemy box rather then chemistry box.
<d_bot>
<mk-fg> See which scheme works best there "in general"
<d_bot>
<mk-fg> But it might also be the case that some naming is much better for some niche of people
<olle>
mk, yes, I mean measure statically, automatically
<d_bot>
<mk-fg> E.g. all kernel coders will be MUCH better off with non-general naming scheme
<d_bot>
<mk-fg> And more LOC will end up yielding much less bugs in some specific community
<olle>
And of course code has lots more objective qualities than art, it can't be compared.
<d_bot>
<darrenldl> namely i know it can build statically, but not sure if it gives *.a
<companion_cube>
olle: how do you measure fault density?
<olle>
companion_cube: reported bugs that relate to this or that software artifact
<companion_cube>
@mk-fg: I'd argue that one letter variables are sometimes better
<olle>
So of course not objectively :) Since you cannot know the "real" number of bugs. companion_cube
<companion_cube>
olle: that assumes equal number of users, equal skill to find bugs, equal easiness to report bugs
<olle>
And missing requirements are the hardest bugs, so
<olle>
companion_cube: Yes, on average.
<companion_cube>
Can you tell me if windows is more or less good than Linux?
<d_bot>
<mk-fg> Yeah, in abstract math code they seem to be, quite often
<companion_cube>
We don't have laws of numbers when programs doing a thing and being popular are so few
<olle>
companion_cube: One study checked the binaries of Windows Vista, and how company structure correlated to faults detected in those.
wonko has joined #ocaml
<d_bot>
<darrenldl> that says more about QA and development than loc though?
<olle>
Maybe. It's a challenge to get the dependent variables. There are statistical tricks for that, but it's above my head.
<d_bot>
<mk-fg> Don't you guys already agree on something like "some social studies wrt coding can be useful, but by no means a hard rule"?
<companion_cube>
Statistics work better with huge sample sizes
<companion_cube>
Which we just don't have
<olle>
Well, comparing binaries inside Windows Vista is easier than comparing Windows with Linux :)
<olle>
Because there are thousands of binaries
<d_bot>
<vinz> @BigOof thanks I'll have a look. More context: i'm upgrading from 4.10 to 4.12, and `ocamlopt.opt foo.c -a -o foo.cmxa` used to generate `foo.a` too. Now, in 4.12 I only get the .o, not the .a
<olle>
mk-fg, hard rules are what's useful, like amount of correlation between LOC of artifact and bugs in that artifact
<olle>
Because you use that to guide your code reviews.
<olle>
Or to estimate risk
<d_bot>
<mk-fg> Presumably you make those up for your particular use-case though, based more on reality and your judgement
<d_bot>
<mk-fg> I.e. "we all use tabs in this company, period"
<olle>
That one is easy :)
<olle>
But how about, in this company, functions should preferably be small
<d_bot>
<mk-fg> Sure, but it's not a scientific thing at all
<olle>
;)
<olle>
Then this: We want to improve this code-base - where do we start? What are the high-risk modules?
<d_bot>
<mk-fg> Unless you call something like "I know 90% of people here use tabs therefore rule is tabs" a kind of a study, I guess
<olle>
And will this commit increase that risk?
<olle>
No no, tabs is trivial.
<d_bot>
<mk-fg> I agree that some rules of thumb will be applicable in that last review example, but still cherry-picked at your discretion
<d_bot>
<mk-fg> Like, "we know this is generally good practice, but doesn't apply here, because this domain is X and Y and Z"
<olle>
Yes, the crucial part is "we know" :)
<companion_cube>
olle: what if modules with high LOC are the ones tackling the hard parts of the problem
<d_bot>
<mk-fg> Presumably as you gain more familiarity with the code, there will be more and more "we know" that ignore more general rules
<olle>
"Good practices" often comes from dev stardom and fandom.
<d_bot>
<mk-fg> Therefore none of these are actually hard rules, as "we know" always overrides those easily
<olle>
companion_cube: Yes, good point. That Windows Vista study showed that senior devs caused more bugs. They argued this is because seniors touch critical code more often.
<olle>
Or they just suck :D
<d_bot>
<mk-fg> Yeah, I think just consistency is often useful, even if it comes from "stardom and fandom", but also not a hard rule
<companion_cube>
olle: there's too many variables
<companion_cube>
stick with reasonable rules but don't try to say they're objectively better
<d_bot>
<mk-fg> I think it's just a human perception thing, which might be same as "many variables" in some interpretation
<olle>
companion_cube: Well. Pick a study and we can discuss its "threat to validity" section. :)
<d_bot>
<mk-fg> Kinda same as applying "averages" to real human population in social studies
<olle>
Yeah, better than the book analogy might be weight and heart disease correlation
<olle>
BMI
<d_bot>
<mk-fg> And that you have 1.5 boob
<companion_cube>
that's so much easier to measure
<d_bot>
<mk-fg> And half a penis
<companion_cube>
weight and blood pressures are easy to measure
<companion_cube>
and the correlation is crystal clear
<companion_cube>
on millions of people
<olle>
companion_cube: LOC is also very easy :)
<olle>
"n software engineering, the lack of experimental evidence often means that anecdotal, intuitive, or sometimes just plain commercial arguments become surprisingly well-entrenched. "
<olle>
"729 projects, 80 Million SLOC, 29,000 authors, 1.5 million commits, in 17 languages"
<olle>
Good stuff
<companion_cube>
he does destroy this study though
<olle>
:O
<Corbin>
olle: This is part of why I emphasize tacit/pointfree language design; detecting duplicate code is not a guess in those environments.
<Corbin>
That said, it's cheaper for most of these tools to run locally on a developer-demanded basis rather than in CI. That's because the tools usually need to *change* the code, which should be signed off and checked by a human.
<companion_cube>
It's not just about strict duplicates, Corbin
<olle>
Right, it's also about faulty duplicates, and semantical duplicates (but syntactically different)
<Corbin>
I'm not sure I understand, sorry. Faulty duplicates sound like a language-design problem (why is bogus code legal to write?) and having two different snippets that do *exactly* the same thing sounds like the supercompiler problem, which is very expensive to solve for large amounts of code.
<Corbin>
I understand the overall desire; surely there must exist flamethrowers which can burn down the jungles of corporate codebases.
<d_bot>
<darrenldl> companion_cube: very good link, many thanks
<companion_cube>
Corbin: language design won't _entirely_ save you from bugs
jess has quit []
<d_bot>
<darrenldl> cant you still construct non-trivial duplicate code in tacit programming?
<companion_cube>
from somewhere else:
<companion_cube>
> The GitHub analysis is pointless because bugs that are caught and fixed are, by definition, not captured within the issue tracker.
<companion_cube>
oouch :D
<d_bot>
<darrenldl> (im probably missing some theorems about pointfree programming terms
<olle>
companion_cube: Disagree. One can assume that it evens out on average between projects (at least inside the same organization)
<companion_cube>
there can still be different programmers inside one organization
<olle>
NO
<companion_cube>
and projects of varying difficulty
<companion_cube>
even different managers!
<olle>
EVERYTHING EVENS OUT
<olle>
LAW OF BIG NUMBERS
<cemerick>
I'd like to pipe put through grep, and have the emitted colors retained; is there an option I'm missing to force dune to color output, even when its not outputting to a tty?
<olle>
The tricky part is to figure out which kind of distribution it is
<companion_cube>
:D
<companion_cube>
sqlite is great code even though it's mostly one person and written in C
<cemerick>
s/put/dune
<companion_cube>
what can you do with that
<Corbin>
darrenldl: We can design tacit languages so that alpha-equivalence is trivial (no binders to fuss) and eta-equivalence is trivial (because the lack of binders means that `f` is legal but not `fun x -> f x`), which makes duplicate code much harder.
<d_bot>
<cemerick> @BigOof that controls grep's coloring, which I explicitly disable; I want to force dune to emit colors (which it doesn't do when it's not on a tty)
<d_bot>
<darrenldl> aha...
<d_bot>
<mk-fg> Maybe run it in a "script" wrapper to just give it tty?
<d_bot>
<mk-fg> Probably not a perfect solution, but not sure if you're looking for one
<d_bot>
<cemerick> @mk-fg I'll have to look up how to do that, thanks
<d_bot>
<mk-fg> It's just a tool in util-linux to emulate a terminal and collect output of something that wants it
<d_bot>
<mk-fg> olle, "One can assume that it evens out on average between projects" imo is a fallacy when applied not a "oh, this should work here" kind of discretion
Everything has joined #ocaml
<olle>
Yes, you shouldn't assume it, but you can investigate that assumption
<Corbin>
Also, it's just not true; artifacts tend to follow Sturgeon's Law rather than normal distributions, and most things made by people for people are not usable.
<Corbin>
It applies any time that there's selection criteria. The average window manager is unusably bad, for example; there's dozens available but most folks can only tolerate one or two of them.
<d_bot>
<mk-fg> "you shouldn't assume it, but you can investigate that assumption" - but then it's now "law of big numbers", but rather "art of applying what works where it makes sense", no?
<d_bot>
<mk-fg> "law of big numbers" and "everything evens out" would be something like "same average size of clothes should fit every human being"
<d_bot>
<mk-fg> Which is demonstrably false, though amusingly been attempted in the army, before they came up with sizes :)
<Corbin>
For code, it's worse; any given string has only cubically-many valid (context-free) parse trees, but exponential numbers of possible invalid arrangements. The average utterance is exponentially likely to be nonsense. Language is one of those times when we are charting a very narrow path through high-dimensional space.
<olle>
Unfortunately I also have to work today :|
<Corbin>
That is the worst, and I sympathize. I hope your day improves at some point.
<d_bot>
<mk-fg> No worries, pretty sure it's a fun semantic discussion that will never end
<d_bot>
<mk-fg> One other funny anecdote about the military that comes to mind is that iirc until ww2 most militaries also had average non-adjustable seats, with common wisdom behind it along the lines of "it's tailored for best performance for the average pilot/driver/crew/etc and is best because law of big numbers"
<d_bot>
<mk-fg> But was completely debunked as adjustable seats were an incredibly cost-effective way to improve performance
rond_ has quit [Quit: Client closed]
Nazral has joined #ocaml
xiongxin has joined #ocaml
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 252 seconds]
<Leonidas>
`Queue.pop q |> ignore` is triggering warning 5, ignored-partial-application but I don't quite see where this would be partial application.
<companion_cube>
in the ignore probably
olle has quit [Ping timeout: 245 seconds]
<octachron>
The warning could be triggered if the queue items are functions themselves
<Leonidas>
ah, yes, that's exactly it
<Leonidas>
is there a nice way to say "I just wanna explicitly ignore the value"?
<Leonidas>
be it function or not?
<octachron>
You can add an explicit (_ -> _) annotation which disables the warning
<Leonidas>
I had let _foo = Queue.pop q in () but that's kinda ugly
[itchyjunk] has quit [Read error: Connection reset by peer]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
glassofethanol has quit [Quit: leaving]
mro has quit [Remote host closed the connection]
bartholin has quit [Quit: Leaving]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
kakadu has left #ocaml [Konversation terminated!]
<cemerick>
turns out that tyxml via JSX is __really__ nice
<companion_cube>
can we see? :)
<cemerick>
I only just started tinkering a half hour ago, so I have little to show, but it resolves the biggest pain points of the ppx IMO; some samples are here: https://ocsigen.org/tyxml/latest/manual/jsx
<d_bot>
<Continuation Calculus> is there a way for me to tell format that my terminal is very wide?
<cemerick>
outside of the HTML literals, I'm not fond of the reason syntax, but everything else is by and large very pleasant
<companion_cube>
@continuation calculus: Format.set_margin or pp_set_margin
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #ocaml
mbuf has quit [Quit: Leaving]
kakadu has joined #ocaml
kakadu has quit [Quit: Konversation terminated!]
<Drup>
cemerick: Thanks, I'm pretty happy with it! The ppx is also quite a good approximation within the ocaml syntax :)
<cemerick>
Drup: it's _ok_, but having to put html literals in strings makes the whole thing very awkward (to my eyes and fingers, anyway)
<cemerick>
if I need to keep the very top-level assembly of those elements in "regular" tyxml code, that's totally okay
<Drup>
yeah, that one doesn't work for a variety of reasons
<cemerick>
(I had wanted to say `<head><title>title</title> ...head_contents</head>`, but intermingling an element child and a "spread" interpolation is apparently a no-no in reason's JSX
<Drup>
you can make it work by moving the head tag inside the body
<Drup>
let head_content = .... in
<Drup>
<html><head>...</head>....
<Drup>
yeah, JSX doesn't like spread interpolation
<Drup>
the ppx does :D
<cemerick>
right, I had pulled the head out separately so as to eliminate the spread problem
<cemerick>
pity, the gist'ed bit does work fine in reason
<cemerick>
the tyxml-less equivalent, I mean
<Drup>
yeah, for sure. Maybe we should have a special html constructor for that ... it's a bit bothersom
<Drup>
(basically, tyxml wants to know statically that html has head and body children, so if you pull the head out, it can't know)
<Drup>
it's .. unfortunate
<Drup>
did we add a dedicated error message for this ? we probably should
<cemerick>
but now looking at the impl of that, I'm more confused as to why it doesn't work, as `head` has precisely the right type AFAICT
<Drup>
it does, the problem is `html`
hendursa1 has quit [Quit: hendursa1]
mro has joined #ocaml
hendursaga has joined #ocaml
Tuplanolla has joined #ocaml
gravicappa has quit [Ping timeout: 246 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
jess has joined #ocaml
greenbagels has quit [Ping timeout: 250 seconds]
greenbagels has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
Skyfire has quit [Quit: WeeChat 3.3]
Skyfire has joined #ocaml
wonko has quit [Ping timeout: 245 seconds]
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
olle has joined #ocaml
olle has quit [Ping timeout: 252 seconds]
mro_ has joined #ocaml
mro_ has quit [Remote host closed the connection]
mro has quit [Ping timeout: 250 seconds]
mro_ has joined #ocaml
olle has joined #ocaml
mro_ has quit [Read error: Connection reset by peer]
mro has joined #ocaml
mro has quit [Quit: Leaving...]
Tuplanolla has quit [Quit: Leaving.]
olle has quit [Ping timeout: 245 seconds]
shawnw has joined #ocaml
Haudegen has quit [Ping timeout: 264 seconds]
<d_bot>
<somebody> i missed yesterday's discussion but... re: "Macros decrease LOC"... well, functions do the exact same thing. *plus* they are type safe, conceptually simple etc which make them easy to reason about (in contrast to macros)