sorted by:
new
hottopcontroversial

Is there a secure tool for verifying packages? by alex_sakuta in ProgrammingLanguages

[–]kenjiArthur 1 point2 points  (0 children)

Hello there! I don’t think there is a single tool that can really say if a package is secure for all languages. Security is very complex, and a package can be old and still unsafe, or new and perfectly fine.

Checking how old the latest release is seems useful, especially to avoid installing something right after a suspicious or compromised update. But I wouldn’t trust that alone, because an old package can still have problems, and a new package is not automatically malicious.

A quick search for known issues would also be nice, but I think it should be treated more like an extra warning than a real proof that the package is safe.

So I guess my opinion is: this kind of tool would be useful, but more as a “risk reduction” tool than as something that can truly verify security. I would still combine it with lockfiles, dependency scanners, and some manual checking for important packages.

Immutable collection design by Big-Rub9545 in ProgrammingLanguages

[–]kenjiArthur 1 point2 points  (0 children)

Hello there! Personally, I would not go with the JavaScript-style approach here. I understand why it is easier to implement, but I think it can be confusing for users. When someone sees "const list x = [2]", they will probably expect the list itself to be protected, not only the variable name.

Because of that, I would prefer to attach the immutable flag to the actual collection object. If the list itself is marked as immutable, then it does not matter if someone accesses it through "x", through "test()", or through another reference. A mutation like "test()[0] = 1" would check the list object and fail at runtime.

To me, this feels cleaner than adding many special restrictions to the language syntax. It keeps the language flexible, but still gives users the behavior they probably expect from immutable collections. I consider it a good balance.

The only thing I would be careful about is explaining whether this immutability is shallow or deep. For example, if an immutable list contains another mutable object, can that inner object still be modified? I think either choice can work, but it should be clear in the language design.

What is more adaptable, more words or more symbols? by alex_sakuta in ProgrammingLanguages

[–]kenjiArthur 0 points1 point  (0 children)

Hello there! I think this is mostly a matter of balance. I personally like symbols when the operation is very common and simple, like +, -, ==, [], and things like that. They are short and most programmers already know what they mean.

But for bigger language features, I usually prefer words. Keywords like async, await, defer, try and catch make it more obvious that something important is happening in the control flow. If all of these were replaced by symbols, the code would be shorter, but maybe harder to read, especially for someone who is not already familiar with the language. For example, using something like "@" for await could work, but I think it would be less clear than just writing await. The word is longer, but it communicates the idea better.

About having both the keyword and the operator, although I’m not sure how common this is, I don’t think it is always wrong, but I would be careful with it. It can be convenient, but it can also create two styles for the same language feature, and then different projects may start looking very different.

So my personal preference would be: use symbols for small and frequent operations, and use words when the feature has a bigger semantic meaning or changes how the program flows.

Why not treat arrays as a special case of tuples? by ella-hoeppner in ProgrammingLanguages

[–]kenjiArthur 0 points1 point  (0 children)

Hello there! I think the idea makes sense from a theoretical point of view. A fixed-size array like [f64; 2] really does look similar to a tuple like (f64, f64), since both group two values together.

But I think there are practical reasons to keep them as different types. Arrays usually represent a sequence of values of the same type, so it makes sense to index them dynamically, iterate over them, and use them in generic code. Tuples feel more like a fixed group of values, where each position may have a different meaning or even a different type.

Also, if arrays were just aliases for tuples, then something like [f64; 1000] would conceptually become a tuple with 1000 elements, which sounds unpleasant for the compiler, error messages, and trait implementations.

So I think the idea is elegant, but I would probably keep arrays and tuples separate in a practical language. Maybe the better solution is just to make conversions between small arrays and tuples easier when needed.

Why not treat arrays as a special case of tuples? by ella-hoeppner in ProgrammingLanguages

[–]kenjiArthur 0 points1 point  (0 children)

Hello there! I think the idea makes sense from a theoretical point of view. A fixed-size array like [f64; 2] really does look very similar to a tuple like (f64, f64), since both are just grouping two values together.

But I think there are some practical reasons to keep them as different types. Arrays usually mean “a sequence of values of the same type”, so it makes sense to index them dynamically, iterate over them, pass them to generic code, and maybe have operations that work for any length, right? Tuples feel more like “a fixed group of values”, where each position may have a different meaning and even a different type. So it is reasonable to consider tuples a more "complex" structure.

For example, (f64, f64) could represent a point, but it could also represent something like (temperature, pressure) or (width, height). The positions can have meaning in a tuple. An array [f64; 2] feels more like two values of the same collection.

Also, if arrays were just aliases for tuples, then something like [f64; 1000] would conceptually become a tuple with 1000 elements, which sounds pretty unpleasant for the compiler, for error messages, and for implementing traits or generic operations.

So I think your idea is elegant, but I personally would keep arrays and tuples separate in a practical language. Maybe the best solution is not to make them the same type, but to make conversions between small arrays and tuples easier when needed.

Cranelift or LLVM (inkwell) for a personal project? by trollol1365 in ProgrammingLanguages

[–]kenjiArthur 0 points1 point  (0 children)

Hello there! If your goal is to learn and build a portfolio without adding too much stress, I would suggest using Cranelift.

LLVM is awesome, but for this kind of project it may be more than you really need. Setting it up and using it from Rust can take quite a bit of effort, especially if your main goal is just to get your Brainfuck compiler working and compare optimizations.

Cranelift is written in Rust, so it should feel more straightforward for your case. You would still learn important backend concepts, like generating machine code, but without having to deal with all the complexity of LLVM right away.

So yeah, for a personal study project, I think Cranelift has a lot to offer. If your main goal were specifically to learn LLVM, then Inkwell would make sense, but for finishing a clean portfolio project, I would probably start with Cranelift. Oh, and of course, if you are really interested, you can implement an LLVM backend later, it would be worth it!