JawnV6 posted:

clang clang clang went the trolley,

Wheany posted:

bing bing bing went the bell

pokeyman posted:

flang flang flang is for fortran

Uncle Enzo posted:

and for monads you all use haskell

VikingofRock posted:

VikingofRock posted:

Sagacity posted:

Well, hot on the heels of Microsoft's plang announcement Martin Odersky has some good ideas for improving Scala as well. God bless.

Max Facetime posted:

Will this work?

code:

if                                                          if ({
    println("checking...")                                    println("checking...")
    var j = i + 1                                             var j = i + 1
    j < 10                                                    j < 10
do                                                          }) {
    println("small")                                          println("small")
    1                                                         1
else                                                        } else {
    println("big")                                            println("big")
    100                                                       100

I think it should, for symmetry




_{i may have messed up the indentation when copy-pasting, apologies}

Zemyla posted:

I half-imagined that the "code in two columns" thing was for concurrency.

Zemyla posted:

I half-imagined that the "code in two columns" thing was for concurrency.

cis autodrag posted:

what's a good scala book or tutorial

cis autodrag posted:

what's a good scala book or tutorial

cis autodrag posted:

what's a good scala book or tutorial

Thermopyle posted:

someone who is in to languages tell me if this is bad or good, thanks

https://danluu.com/empirical-pl/

Arcsech posted:

haven't read the article yet but Dan Luu is a heckin smart guy so it's probably not total garbage at least

MALE SHOEGAZE posted:

the only thing dynamic languages are better for is dealing with system boundaries.

but actually it sucks because now instead of things blowing up at the boundary like they should, they blow up deep inside your code where someone forgot to include the same type / null check boiler plate that is included in every single stupid method in your system

quote:

Formally verified systems, and figuring out how to make formal verification accessible and composable are very important building blocks at the most rigorous end of the spectrum.

Fonseca et al. examine three state-of-the-art formally verified implementations of distributed sytems: Iron Fleet, Chapar: Certified causally consistent distributed key-value stores, and Verdi. Does all that hard work on formal verification verify that they actually work in practice? No.

quote:

Through code review and testing, we found a total of 16 bugs, many of which produce serious consequences, including crashing servers, returning incorrect results to clients, and invalidating verification guarantees.

quote:

The unverified systems all contained protocol bugs, whereas none of the formally verified systems did.

[...] the unverified systems chosen “have been tested by innumerable users.” I.e., they’ve been used in the wild by lots of different people in lots of different environments, giving plenty of occasion for all sorts of weird conditions to occur and trip the software up. [...] The formally verified ones have not been battle tested in the same way. And that’s interesting, because when you look at the bugs found in the formally verified systems, they relate to assumptions about the way the environment the system interacts with behaves. Assumptions that turn out not to hold all the time.

[...]

The bugs found by the team fall into three categories. By far the biggest group of bugs relate to assumptions about the behaviour of components that the formally verified system interacts with. These bugs manifest in the interface (or shim layer) between the verified and non-verified components.

quote:

• The Verdi server wrongly assumed that the recv system call would always return an entire request in a single invocation, and failed when given a partial request.
  
• Chapar used UDP, but did not handle packet drops because it assumed the network layer was reliable.
  
• Verdi used newlines and spaces to distinguish commands and arguments, but did not escape these characters leading to a variety of issues
  
• Developers assumed that a single or set of disk operation(s) are atomic during crashes
  
•  Buffers too small to handle all possible inputs
  
•  Not respecting input size limits in library calls made by the system
  

And these are developers trying their very best to produce a formally verified and correct system.

quote:

The answer is not to throw away attempts at formal verification (“we did not find any protocol-level bugs in any of the verified prototypes analyzed, despite such bugs being common even in mature unverified distributed systems“).

[...]

Instead we must recognise that even formal verification can leave gaps and hidden assumptions that need to be teased out and tested, using the full battery of testing techniques at our disposal.

Thermopyle posted:

someone who is in to languages tell me if this is bad or good, thanks

https://danluu.com/empirical-pl/

MononcQc posted:

"my view is obviously the correct one", said the yosposter right after being linked to a long report discussing how multiple scientific papers were unable to reasonably prove this very point.

Thermopyle posted:

someone who is in to languages tell me if this is bad or good, thanks

https://danluu.com/empirical-pl/

quote:

The Unexpected Results From A Hardware Design Contest; Cooley, J

...
During the expierment, there were a number of issues that made things easier or harder for some subjects. Overall, Verilog users were affected more negatively than VHDL users. The license server for the Verilog simulator crashed. Also, four of the five VHDL subjects were accidentally given six extra minutes. The author had manuals for the wrong logic family available, and one Verilog user spent 10 minutes reading the wrong manual before giving up and using his intuition. One of the Verilog users noted that they passed the wrong version of their code along to be tested and failed because of that. One of the VHDL users hit a bug in the VHDL simulator.
...

Brain Candy posted:

otoh, the idea that science is the only way to know things is a mind poison

Brain Candy posted:

otoh, the idea that science is the only way to know things is a mind poison

MononcQc posted:

The idea that annoys me is rather that you have definitively more reliable studies regarding things impacting code quality such as organisational structure for one that comes to mind rapidly, than those about static/dynamic typing or TDD (as opposed to just iterative development) for example.

So the thing is that you have a bunch of studies that more clearly highlight what actually matters, but developers keep debating things that do not really do so. It's optimizing whether i++ or ++i is better in that one code loop when the software is choking because all DEBUG logs synchronously go to disk.

https://en.wikipedia.org/wiki/Attribute_substitution posted:

Attribute substitution is a psychological process thought to underlie a number of cognitive biases and perceptual illusions. It occurs when an individual has to make a judgment (of a target attribute) that is computationally complex, and instead substitutes a more easily calculated heuristic attribute.[1] This substitution is thought of as taking place in the automatic intuitive judgment system, rather than the more self-aware reflective system. Hence, when someone tries to answer a difficult question, they may actually answer a related but different question, without realizing that a substitution has taken place.[2] This explains why individuals can be unaware of their own biases, and why biases persist even when the subject is made aware of them. It also explains why human judgments often fail to show regression toward the mean.

Brain Candy posted:

otoh, the idea that science is the only way to know things is a mind poison