I like programming and anime.

I manage the bot /u/mahoro@lemmy.ml

  • 2 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle


  • I also like the POSIX “seconds since 1970” standard, but I feel that should only be used in RAM when performing operations (time differences in timers etc.). It irks me when it’s used for serialising to text/JSON/XML/CSV.

    I’ve seen bugs where programmers tried to represent date in epoch time in seconds or milliseconds in json. So something like “pay date” would be presented by a timestamp, and would get off-by-one errors because whatever time library the programmer was using would do time zone conversions on a timestamp then truncate the date portion.

    If the programmer used ISO 8601 style formatting, I don’t think they would have included the timepart and the bug could have been avoided.

    Use dates when you need dates and timestamps when you need timestamps!


  • Do you use it? When?

    Parquet is really used for big data batch data processing. It’s columnar-based file format and is optimized for large, aggregation queries. It’s non-human readable so you need a library like apache arrow to read/write to it.

    I would use parquet in the following circumstances (or combination of circumstances):

    • The data is very large
    • I’m integrating this into an analytical query engine (Presto, etc.)
    • I’m transporting data that needs to land in an analytical data warehouse (Snowflake, BigQuery, etc.)
    • Consumed by data scientists, machine learning engineers, or other data engineers

    Since the data is columnar-based, doing queries like select sum(sales) from revenue is much cheaper and faster if the underlying data is in parquet than csv.

    The big advantage of csv is that it’s more portable. csv as a data file format has been around forever, so it is used in a lot of places where parquet can’t be used.



  • Dude, if you’re being obtuse on purpose because you have an ax to grind against Rust, try a different approach. You’re not getting anywhere, clearly by the fact that no one agrees with you.

    If you don’t like that Rust has a restricted trademark, then call that out instead of trying to label the software and it’s license as non-free. It’s literally called out in my source that name restrictions ipso facto does not violate freedom 3.

    But if you genuinely believe that the implementation of the Rust language and it’s trademark is burdensome to create a fork, and you want people to believe you, then you gotta bring receipts. Remember, the benchmark that we both quoted is that it “effectively hampers you from releasing your changes”. It being “not a piece of cake” doesn’t cut it.

    Hint: Google Rust forks since their existence also undermines your claim.

    Good luck.







  • Just because you can get part of your education remotely or through self-learning didn’t mean “anything can be learned online”.

    And if you were hiring a math tutor for your kid, would you prefer a self-proclaimed expert from watching YouTube videos or would you want someone who got a degree from a credentialed university? And even if you don’t care, why are you surprised that others would be skeptical of the YouTube expert?

    Remote learning can be fine for some things, and self learning through informal channels are also fine, but it’s not a full on replacement for formal education in all cases.




  • The first way to use it is with any type annotation: you just use it for documentation.

    # int annotation
    def add_1_to_number(x: int) -> int:
        return x + 1
    
    # callable annotation
    def printer(x: int, func: Callable[[int], int]) -> None:
        results = func(x)
        print(f"Your results: {results}")
    

    These type annotations can help document and make editors parse your code to make suggestions/auto-complete work better.

    The second way to use it is by creating a callable. A callable is an abstract base class that requires you to implement the __call__ method. Your new callable can be called like any function.

    class Greeter(Callable):
    
        def __init__(self, greeting: str):
            self.greeting = greeting
    
        def __call__(self, name: str):
            print(f"{self.greeting}, {name}")
    
    
    say_hello = Greeter("Hello") # say_hello looks like a function
    say_hello("jim")  # Hello, jim
    



  • Most of us have bad memories of over-complex hierarchies we regret seeing, but this is probably due to the dominance of OOP in recent decades.

    This sentence here is why inheritance gets a bad reputation, rightly or wrongly. Inheritance sounds intuitive when you’re inheriting Vehicle in your Bicycle class, but it falls apart when dealing with more abstract ideas. Thus, it’s not immediately clear when and why you should use inheritance, and it soon becomes a tangled mess.

    Thus, OO programs can easily fall into a trap of organizing code into false hierarchies. And those hierarchies may not make sense from developer to developer who is reading the code.

    I’m not a fan of OO programming, but I do think it can occasionally be a useful tool.




  • Ehhh, I don’t quite agree with this. I’ve done the same thing where I used a timestamp field to replace a boolean. However, they are technically not the same thing. In databases, boolean fields can be nullable so you actually have 3-valued boolean logic: true, false, and null. You can technically only replace a non-nullable field to a timestamp column because you are treating null in timestamp as false.

    Two examples:

    1. A table of generated documents for employees to sign. There’s a field where they need to agree to something, but it’s optional. You want to differentiate between employees who agreed, employees who disagreed, and employees who have yet to agree. You can’t change the column from is_agreed to agreed_at.

    2. Adding a boolean column to an existing table. These columns need to either default to an value (which is fair) or be nullable.