HackerLangs
TopNewTrendsCommentsPastAskShowJobs

ceronman

no profile record

comments

ceronman
·5 miesięcy temu·discuss
1. Credit cards are not that common. People usually have debit cards. Those can sometimes be used online but they're not widely accepted. My debit card is Maestro, which is not accepted in many places.

2. Even with my Mastercard credit card, the process is still inconvenient. For small purchases, it's fine. But for larger ones, there is an annoying second factor authentication, I have to enter a special password, and the wait to receive an SMS.

3. Visa and Mastercard fees. Most of the time these are paid by the merchant. But sometimes the customer has to pay more if the payment method is credit card. Some places don't accept these at all.

In general iDEAL is simple, secure and convenient. Not only to pay online, but also for example for splitting a bill with friends. I'm very happy to see this being adopted more widely in Europe.
ceronman
·6 miesięcy temu·discuss
A switch or pattern matching approach is useful, but not practical for some cases. For example, there are cases where you are interested in only a single kind of node in the three, for those cases the Visitor pattern is very helpful, while doing pattern matching is cumbersome because you have to match and check almost every node kind. That's why, for example, the Rust compiler still uses the visitor pattern for certain things, and pattern matching for others.
ceronman
·6 miesięcy temu·discuss
The parsers in crafting interpreters do not use the visitor pattern. The visitor pattern is used when you already have a tree structure or similar. The parser is what gives you such tree structure, the AST. When you have this structure, you typically use the visitor pattern to process it for semantic analysis, code generation, etc.
ceronman
·6 miesięcy temu·discuss
The visitor pattern is very common in programming language implementations. I've seen it in the Rust compiler, in the Java Compiler, in the Go compiler and in the Roslyn C# compiler. Also used extensively in JetBrains' IDEs.

What do you have against this pattern? Or what is a better alternative?
ceronman
·9 miesięcy temu·discuss
The elderly, the kids, the teenagers, the adults. Screen addiction is a pandemic. The biggest one humanity has ever seen.

The richest, most powerful organizations are spending billions every month to make it more addictive, to reach more people.
ceronman
·10 miesięcy temu·discuss
I used to agree with this, but then I realized that you can use trace points (aka non-suspending break points) in a debugger. These cover all the use cases of print statements with a few extra advantages:

- You can add new traces, or modify/disable existing ones at runtime without having to recompile and rerun your program.

- Once you've fixed the bug, you don't have to cleanup all the prints that you left around the codebase.

I know that there is a good reason for debugging with prints: The debugging experience of many languages suck. In that case I always use prints. But if I'm lucky to use a language with good debugging tooling (e.g Java/Kotlin + IntelliJ IDEA), there is zero chance to ever print for debugging.
ceronman
·10 miesięcy temu·discuss
I don't know why you're getting down voted. But you are right. Rust type system solves this in a very nice way. Maybe to clarify we can show how to do the exact same example shown with Clojure multi-methods, but in Rust:

    struct Constant { value: i32 }
    struct BinaryPlus { lhs: i32, rhs: i32 }
    
    trait Evaluate {
        fn evaluate(&self) -> i32;
    }
    
    impl Evaluate for Constant {
        fn evaluate(&self) -> i32 { self.value }
    }
    
    impl Evaluate for BinaryPlus {
        fn evaluate(&self) -> i32 { self.lhs + self.rhs }
    }
    
    // Adding a new operation is easy. Let's add stringify:
    
    trait Stringify {
        fn stringify(&self) -> String;
    }
    
    impl Stringify for Constant {
        fn stringify(&self) -> String { format!("{}", self.value) }
    }
    
    impl Stringify for BinaryPlus {
        fn stringify(&self) -> String { format!("{} + {}", self.lhs, self.rhs) }
    }
    
    // How about adding new types? Suppose we want to add FunctionCall
    
    struct FunctionCall { name: String, arguments: Vec<i32> }
    
    impl Evaluate for FunctionCall {
        fn evaluate(&self) -> i32 { todo!() }
    }
    
    impl Stringify for FunctionCall {
        fn stringify(&self) -> String { todo!() }
    }
ceronman
·10 miesięcy temu·discuss
> That's not the expression problem.

To me it looks like this is exactly the expression problem. The expression problem is not about adding methods to a trait, it's about adding an operation to a set of types. In this case every operation is defined by a single trait.

The idea behind the expression problem is to be able to define either a new operation or a new type in such a way that the code is nicely together. Rust trait system accomplish this beautifully.

> That's not unique to Rust, you can add new interfaces in any language...

Many languages have interfaces, but most of them don't allow you to implement them for an arbitrary type that you have not defined. For example, in Java, if you create an interface called `PrettyPrintable`, but you can't implement it for the `ArrayList` type from the standard library. In Rust you can do this kind of things.
ceronman
·10 miesięcy temu·discuss
Why would the the orphan rule be a problem here?

The orphan rule only disallow impls if both the trait and the type are defined outside the crate.

But in this example if you are adding a new type (struct) or a new operation (trait), well this new item should be in your crate, so all the impls that follow are allowed.
ceronman
·10 miesięcy temu·discuss
Very cool. I think Wasm is a nice instruction set, but I agree that its structured control flow is a bit weird and also the lack of instructions to handle the memory stack. But it's much more cleaner than something like x86_64.

If you are interesting in learning in more detail how to write a C compiler, I highly recommend the book "Writing a C Compiler" by Nora Sandler [0]. This is a super detailed, incremental guide on how to write a C compiler. This also uses the traditional architecture of using multiple passes. It uses its own IR called Tacky and it even includes some optimization passes such as constant folding, copy propagation, dead code elimination, register allocation, etc. The book also implements much more features, including arrays, pointers, structs/unions, static variables, floating point, strings, linking to stdlib via System V ABI, and much more.

[0] https://norasandler.com/book/
ceronman
·w zeszłym roku·discuss
I bet that if you take those 278k lines of code and rewrite them in simple Rust, without using generics, or macros, and using a single crate, without dependencies, you could achieve very similar compile times. The Rust compiler can be very fast if the code is simple. It's when you have dependencies and heavy abstractions (macros, generics, traits, deep dependency trees) that things become slow.
ceronman
·3 lata temu·discuss
Flatpak seems to follow a similar path as many other Linux technologies like Wayland or Systemd, in the sense that they seem to arouse the anger of a small but very vocal crowd who really can't stand any challenge to the status quo. So this is the template of the story:

There is a new tool or workflow trying to replace or complement an old one. This new tool tries to solve many different complex problems that the old tool, usually designed decades ago, doesn't solve well in this the current world. To do so, obviously, some sort of compromise is required, the new tool won't do certain things that the old tool used to do, but in exchange of that it will do a lot of new things that many users really want. However this small crowd is really pissed by this, without understanding that there is no holly grail solution and some sort of compromise is always required. Additionally, as it's natural with any new technology, the very first incarnations of the new technology are not very mature and there is a lot to polish, a lot of tooling missing, and a chicken and egg problem of not enough users to drive its take off. And the small crowd will use all this as much as they can to try to prevent the world from moving on.

However, as time passes, the new tool starts becoming more mature, the obvious shortcomings get fixed, and all the new possibilities that the tool enables start to really shine. And while the initial compromise will always remain, the majority of users realize that the tradeoff was worth it.

This has happened with Systemd, it's starting to happen with Wayland, and I believe it will happen with Flatpak was well. We'll see.
ceronman
·4 lata temu·discuss
Odin sounds like a nice improvement over C, however this caught my attention:

> If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you.

I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulnerabilities because you forgot a weird edge case while managing a pointer is really worrying. For simple programs is not that complicated, but for complex multi threaded ones it becomes really hard. And the fact that event the most expert programmers make these mistakes, leaves me not much hope.

So perhaps systems programming is not for me? But what exactly is systems programming? Is it developing OS kernels, writing drivers and embedded microcontroller systems? Or is it more.

I'm not very interested in writing any of those. But I do want to write programs that are fast and run as fast as C or C++, and I want a language which allows good control of resources and has minimal overhead. Sometimes these programs are multi-threaded and quite complex, so I want memory and type safety and I want tools to crate abstractions to tame complexity a little bit. Is all this out of the systems programming definition?
ceronman
·5 lat temu·discuss
I'm writing this from my Fedora laptop where Wayland works extremely well. I want to say thank you to all the developers behind it!

I know that the process of moving to Wayland has been slow and hard. It is definitely not an easy task. I know it's frustrating when something that used to work does not any more. I know the process is not complete and there are still a few things that might not work well. But for god sake, these people are volunteers. Stop bullying them with angry posts complaining about their work. You likely don't pay a penny for all this great software that you are using. If you think that X is better, just use it, and live with its unfixable issues. If you don't like distros moving to Wayland, contribute the packages to keep using X, maintain X, these guys are offering you the keys! Please stop shitposting about the work of people trying to make things better.

Apple breaks things all the time and they don't get half of the heat. And they charge a lot of money.
ceronman
·7 lat temu·discuss
I've been trying to find out which countries are eligible to receive payments, but I haven't found any information. Most likely I expect this to be like Kickstarter where basically only developers living in certain developed countries can participate.
ceronman
·10 lat temu·discuss
I honestly don't care too much if the graphical power is not up to PS4 or XBox One. Probably doesn't because of the mobile capabilities. If there are great games it doesn't really matter if they are hyper realistic. We saw that with the Wii.