![](/static/66c60d9f/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/c0ed0a36-2496-4b4d-ac77-7d2fd7f2b5b7.png)
Let me simplify it: proceeds to print the same expression
Let me simplify it: proceeds to print the same expression
Deprecation warnings should contain suggestions for alternatives.
It’s not that the author picked Rust for scripting. All Rust game engines (e.g. Bevy) use Rust as the scripting language.
Compare this with Godot, which is implemented in C++, but supports GDScript and many other languages for scripting.
Also, only supporting Rust is not considered a limitation, but a feature here. Bevy’s ECS is tied up with Rust’s trait system, therefore it’s impossible to use a different language.
So if Rust as a system programming language should not be used for game scripting, then projects like Bevy are fundamentally flawed. The author is willing to go there, but I don’t know if many people would go that far.
There could be a Godot-like engine written in Rust that supports easier scripting languages, but I think that space is not explored due to the fact that Godot already exists.
In general, given a Turing machine which outputs the result of a procedure to its memory tape, you can equivalently construct a recognizer of valid input/output pairs. Say P is the procedure, then the recognizer R is let (i, o) = input in P(i) = o
The reverse is also possible. Give a recognizer R, you can construct a procedure P that given part of the input (can be empty), computes the rest of the input that makes R accept the whole. It can be defined as for o in all-strings, if R(i, o) then output o and halt, else continue
.
It might feel contrived at first, but both views can be useful depending on the situation. You’ll get used to it soon with some exercises.
For all possible input, only recognize the one input that’s (under certain encoding scheme) equal to the sum of the given list. That’s for a given list.
Another more general approach is that, only recognize the input if (under certain encoding), it’s a pair of a list and a number, where the number is the sum of the list.
Look, there’s a thing called safety-catch and that’s why my son can play with semi-auto rifles.
IMHO the reality is more complicated than what’s described here.
Open source is sustainable (in the sense that people will continue to do it), even without the maintainers getting paid, for better or worse. This is evidenced by the history and the majority of open source projects now.
The bait-and-switch problem, which gets the maintainers paid, hurts the ecosystem in the long run, which relies heavily on the good faith.
Static websites can be beautiful and easy to use without being complex.
PG’s blog and HN can definitely use some CSS tweaks. I can’t remember how many times I clicked the wrong thing in HN.
On the other hand, it’s easy to get reader mode/custom CSS/alt frontend working for such websites, so maybe it’s alright after all.
The original “agile” is a reaction to the overly rigid planning and emphasizes worker self-management. It makes sense since the people who are closest to the work (the workers) know best how to plan and implement the work.
It immediately breaks down when a specialized management tier emerges and tries to push their own agenda, i.e. to sell themselves rather than do something meaningful.
At this point, whichever form is used doesn’t matter. The management, endowed with the power from above, will exploit the weakness of any agile-shmagile methodology to push their own agenda.
I’m gett the ing UDP same vib joke
To be good at programming, a lot of knowledge is needed, but “accidental”. From practical ones like how to use git, to conceptual ones like cache performance mental model. It’s perfectly possible that git is designed with a different CLI, or the common cache line size being 512 bytes. Mathematicians usually don’t care about these things, since they are accidental. So they are bad at writing programs that’s far away from math.
It’s a completely different story when they are writing programs about math. If the tool is good enough, i.e. allowing them to express math ideas in familiar terms, mathematicians are very good at writing math programs. As can be observed in Lean and mathlib.
It’s real, but mainly aims for corrupted former officials, e.g. Operation Fox Hunt. Arresting Hong Kong dissidents might be more politically difficult.
I have to print f to show respect.
do { explain } while ( !they.understand )
Why two comment lines tho?
There you are, our CS doctor.
Thank you for raising the question. I think it’s an important one to think about. I constantly hear about good things about the REPL experience of LISP family languages. You can set up a code fragment (the test in your example) to run constantly in the background as you edit. Then you can jump to the REPL anytime and interact with the state.
I myself am more on the ML-family side of FP, where you’d encode the expected behavior with an expressive type system and work with the type checker (the smart compiler) to implement that behavior.
One important thing to note is that the type checking process is also a fast feedback loop. The difference is that it’s often on the abstract level and you’re more concerned about the expected behavior instead of the actual behavior.
It’s harder to write, but the advantage is that you’ll have more confidence once it type checks.
Of course, the two styles are not mutual exclusive, just that the tooling ecosystem will often reflect the culture of that language family. And it’s easier to add a simple watch make
task, but harder to go the other way around.
Yeah, with USB and chips. Sounds about right.
Yes for OCaml. Haskell’s inequality is defined as
/=
(for ≠).<>
is usually the Monoidmappend
operator (i.e. generalized binary concatenation).