I dunno, plenty of those sound pretty reasonable.
I dunno, plenty of those sound pretty reasonable.
Probably a good thing you got banned for advocating for child abuse.
Nah, it’s all hyped up bullshit that has to be babysat and manipulated to a degree that you may as well just write your damn code.
But beyond that, I’d argue that it’s actually damaging for engineering organizations, because it means the org is incurring the maintenance cost of code not written by its engineers and that has no real thought put behind it. Maybe you can eventually coax it to produce code that’s not completely broken shit, but it’s code that your org doesn’t actually “own” from a maintenance and knowledge-base perspective. The social aspect of code maintenance with this shit is always massively overlooked.
I made this mistake for ages because Haskell is so popular and it’s functional and pure, but it’s not actually a requirement for functional languages to be pure. OCaml isn’t.
I didn’t say that FP languages have to necessarily be pure, just that FP languages tackle the problem of mutation by arranging programs such that most things are typically pure and side effects typically happen at the periphery (logging is probably the one exception, though). This is true even in FP languages that allow arbitrary side effects in functions, it’s just not enforced by a compiler.
I agree Rust code has a different feel to OCaml code but that’s because it makes some things easier (e.g. mutation, vectors). You still could write Rust as if it was OCaml (except for the lack of currying), it’s just that nobody does that because it sucks.
That’s the entire point, though. It’s all about what the language emphasizes and makes easy to do. If it’s unnatural to write a functional program in Rust and no one does it, then it’s not really reasonable to call it a functional language. Writing functional programs is not idiomatic Rust, and that’s okay.
Fundamentally it’s a language oriented around blocks of statements rather than composition of expressions. Additionally, it takes a different approach to the mutation problem than FP languages: where FP seeks to make most things pure and push mutation and side effects to the edges of the program, Rust uses its type system to make such mutation and side effects more sane. It’s an entirely different philosophy when it comes to programming. I don’t think either approach is necessarily better, mind you, just a different set of tradeoffs.
I’m a professional Haskell developer and am very much immersed in FP. When I read Rust code, I have to completely shift my thinking to something much more imperative. Whereas if I read, say, Ocaml, the difference is mostly syntactic. This isn’t a slight, mind you. I quite like Rust. But it’s a very different paradigm.
It’s not a functional language at all, even if it borrows ideas from FP languages. It’s an imperative language through and through.
This is completely different from electron. Nix dependencies will be shared if they share the same hash. Electron just blindly copies everything over every time.
All it means is if you were to reverse the order of the characters, you’d get the same string you started with. So “dog” isn’t a palindrome because when you reverse it, you get “god”. “dog god” is a palindrome, though, because if you read it backwards, it’s also “dog god”.
Your post only showed adding functionality over the algebra, not new types on which the algebra operates (or “sorts”, as they are otherwise known). In other words, you can’t easily extend Expr
to support Boolean logic in addition to addition itself. For a concrete example, how could you represent ternary operators like in the expression 2 + 2 == 4 ? 1 : 2
, such that it’s well typed and will never result in an exception? With GADTs, this is very simple to do:
data Expr a where
Lit :: Int -> Expr Int
Add :: Expr Int -> Expr Int -> Expr Int
Eq :: Expr Int -> Expr Int -> Expr Bool
If :: Expr Bool -> Expr Int -> Expr Int -> Expr Int
eval :: Expr a -> a
eval expr = case expr of
Lit n -> n
Add a b -> eval a + eval b
Eq a b -> eval a == eval b
If p a b -> if eval p then eval a else eval b
-- >> eval example == 1 => true
example :: Expr Int
example =
If ((Lit 2 `Add` Lit 2) `Eq` Lit 4) (Lit 1) (Lit 2)
It’s not complicated at all: https://en.m.wikipedia.org/wiki/Palindrome. Not really something that’s education-specific, in this instance (though I suppose it’s commonly used in entry-level programming classes since it’s a simple concept).
This is a very common toy example we use in Haskell, though honestly this OOP version leaves a lot to be desired, comparatively
The issue is that it tries to shoehorn separation of data and functions on data into a paradigm that’s fundamentally about fusing those two things together.
Here’s the Haskell version. Note how much simpler it is because data and functions are separate:
data Expr
= Lit Int
| Add Expr Expr
eval :: Expr -> Int
eval expr = case expr of
Lit n -> n
Add a b -> eval a + eval b
print :: Expr -> String
print expr = case expr of
Lit n -> show n
Add a b -> "(" ++ print a ++ " + " ++ print b ++ ")"
Typescript can do something similar:
type Expr = {
kind: 'Lit',
value: number
} | {
kind: 'Add',
left: Expr,
right: Expr
}
function eval(expr: Expr): number {
switch(expr.kind){
case 'Lit': return expr.value;
case 'Add': return eval(expr.left) + eval(expr.right);
default:
const _impossible: never = expr;
return _impossible;
}
function print(expr: Expr): string {
switch(expr.kind){
case 'Lit': return `${expr.value}`;
case 'Add': return `(${print(expr.left)} + ${print(expr.right)})`;
default:
const _impossible: never = expr;
return _impossible;
}
Both the OOP approach and Typescript itself struggle with additions to the algebra composed of different types, however. For example, imagine extending it to handle booleans as well, supporting equality operations. It’s difficult to make that well-typed using the techniques discussed thus far. In Haskell, we can handle that by making Expr
a GADT, or Generalized Algebraic Data Type. That article actually already provides the code for this, so you can look there if you’re curious how it works.
This is really terrible advice.
I definitely write pseudocode like this, albeit perhaps with some more shorthand. It’s commonly taught this way too.
Last 3 years has been working on large backend web services in Haskell and Postgres, with some shell scripting thrown in here and there.
Before that, it was a mix of Python, Typescript (React), Rust, and C++.
Been using vim+tmux for the last 8 years and still going strong. Wouldn’t ever give it up. Vscode’s pretty lackluster in comparison.
After working at a company that had Crowdstrike installed on all machines, it is most certainly malware.
I’m not, really. They’re one of our largest operating expenses and we’re trying to work on reducing our log output to reduce the cost.
For what they do I’m not aware of any players in the space that come anywhere close, though.
It depends on the country. This is true in American English and it’s what we teach in schools. In British English (which, in my experience, is what most ESL learners outside the US end up learning), they go outside the quotes. Source.
Why in the ever-loving fuck would it do that? My hatred of Go only continues to grow.
Uh, there are an absolute fuckload of Java libs out there with nothing more than auto-generated garbage Javadocs.