Thanks to visit codestin.com
Credit goes to programming.dev

  • AnarchoSnowPlow@midwest.social
    1251·
    17 天前

    Programming languages, much like the jackass in the middle, are tools. Different tools are for different things. The right tool for the job can make your day. The wrong tool can make you question your entire career.

  • Johanno@feddit.org
    431·
    16 天前

    The language is as important as architecture and stuff.

    Pick the right language for the right task.

    Performance? Don’t use python.

    Everything else? Use python because everyone does.

    /s

  • AldinTheMage@ttrpg.network
    34·
    16 天前

    That’s why we use JavaScript on the front end, JavaScript on the back end, and you can streamline it even more by using JavaScript for the db layer too. After all, if you have too much data to be reasonably parsed in a single .json file, you are probably just architecting wrong.

      • Lucy :3@feddit.org
        1620·
        16 天前

        Average Rust code:

        macro_rules! sum {
    ( $initial:expr $(, $expr:expr )* $(,)? ) => {
        $initial $(+ $expr)*
    }
}

fn remove_prefix<'a>(mut original: &'a str, prefix: &str) -> &'a str

let mut up = 1;
    'outer: loop {

        Hell I don’t want to know what you define as ugly then.

          • tatterdemalion
            21·
            16 天前

            Sorry, I love Rust but I can’t really agree with you here. They only showed a macro_rules! definition, which is definitely rust syntax. Lifetime annotations are relatively common.

            I will concede that loop labels are incredibly rare though.

            • fruitcantfly
              4·
              16 天前

              Loop labels are rare, but they lead to much simpler/clearer code when you need them. Consider how you would implement this kind of loop in a language without loop variables:

              'outer: while (...) {
    'inner: while (...) {
        if (...) {
            // this breaks out of the outer loop, not just the inner loop
            break 'outer;
        }
    }

    // some code here
}

              In C/C++ you’d need to do something like

              bool condition = false;
while (...) {
    while (...) {
        if (...) {
            condition = true;
            break;
        }
    }
    if (condition) {
        break;
    }

    // some code here
}

              Personally, I wouldn’t call it ugly, either, but that’s mostly a matter of taste

              • Ephera@lemmy.mlEnglish
                11·
                15 天前

                Well, you’d typically put the loops into a function and then do an explicit return to jump out of there. I believe, there’s some use-cases where this isn’t possible, which is why I’m cool with loop labels existing, but I’ve been coding Rust for seven years and have not needed them once…

              • tatterdemalion
                1·
                15 天前

                I guess I see what you mean if we want to get very technical about what a syntax extension is. But I think for the purpose of this discussion, it’s reasonable to think of macro_rules! as a part of the Rust language. Practically speaking, it is syntax provided by the language team, not just users of the language who are free to extend the syntax by using macro_rules! to do so.

            • calcopiritus@lemmy.world
              81·
              16 天前

              You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.

              This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.

              The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.

              And the loop doesn’t contain any codeblock. Just an opening bracket.

              Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.

              Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.

        • fuck_u_spez_in_particular@lemmy.world
          7·
          16 天前

          Definitely not your average Rust code, more like a very ugly example of it.

          Also, as the syntax first put me off as well, I gave it a chance years afterwards, and have now (or rather years ago) officially joined the church of Rust evangelism.

          A lot of the syntax you define as ugly makes sense when you learn it, it’s just so much more explicit than a more dynamic language, but that exactly saves your ass a lot (it did for me at the very least) (I don’t mean macros, macros are ugly and should be avoided if possible)

    • EthanEnglish
      48·
      17 天前

      Almost any language is ok but some ecosystems make me want to turn into a murder hobo (looking at you, JavaScript).

        • jackr@lemmy.dbzer0.com
          5·
          16 天前

          Perl is ugly but great. It’s like shell scripting with a more solid programming language. I’d never use it outside of simple scripts in my os, but whenever I do use it it’s very fun. Anyway, yeah, rust looks fine to me. Maybe they are not very experienced with it? I know some of my programs used to have lines with just x.unwrap().unwrap().unwrap() or whatever, which is not pretty.

          • Ephera@lemmy.mlEnglish
            4·
            16 天前

            I know some of my programs used to have lines with just x.unwrap().unwrap().unwrap() or whatever, which is not pretty.

            That goes away with experience, though. At least, I can’t think of a reason why you’d nest three Results or Options. Normally, you would collate them right away.

            The most you see in the wild is something like Result<Option<_>> to express that a check can fail, but even if it doesn’t, then a valid result can still be that there is nothing there.

            If you don’t care that your program crashes (like .unwrap() does), then anyhow is the error handling library of choice. With it, you can just write a ? in place of an .unwrap() for practically any error type. And well, it automatically combines the errors, so you won’t be writing ??? either.

      • rtxn@lemmy.world
        1713·
        17 天前

        Enums and nested blocks. I understand the importance of Option and Result, but it’s fucking infuriating when I have to check and destructure the result of every function call and either bubble the result up the stack from six levels of nested if let blocks or risk Cloudflaring my program by using .unwrap(). And while I like being able to extract a return value from an if...else expression, the structure gets really convoluted when multiple if and match blocks are nested (of course each one returning a value), and it gets completely fucked once closures are introduced.

        I like Rust, but calling it pretty is delusional.

        • marcos@lemmy.world
          224·
          17 天前

          have to check and destructure the result of every function call

          Learn how to use enum error types, how error bubbling works, and how to convert between Options and Results.

          It’s Rust you are talking about, not Go.

          • rtxn@lemmy.world
            69·
            17 天前

            This isn’t about some feature of the language being good or bad. It’s about Rust being ugly or not. The things I mentioned will always look ugly in the source code.

            • 5C5C5C
              132·
              16 天前

              It’s hilarious to me that people talk about “ugly” as if their opinions are objective.

              I found Rust unpleasant to look at for the first two weeks of learning it, and now that I’ve been using it professionally for three years I loathe when I need to read code in other languages.

              No other language can rival Rust in showing the exact information needed to understand the code — never too much and never too little — while being concise, correct, and handling all edge cases.

              You can be more concise in other languages, but it will come the loss of handling every little possible bug. You can be prettier in other languages, but it will come at the price of adding a lot of useless boilerplate.

              Of course there are cases where Rust can be verbose or confusing, but that’s when you’re doing very esoteric things that would be just as confusing in other languages.

              Like any opinion on aesthetics, how someone feels about the prettiness of a language will have far more to do with familiarity than with any objective metrics.

          • balsoft@lemmy.ml
            412·
            17 天前

            Sadly there’s still no truly good way to handle errors in rust. TBH I’m not sure if we as an industry have figured out an efficient, foolproof, composable, not overly verbose way to handle errors, so it’s not entirely on Rust.

            • calcopiritus@lemmy.world
              4·
              16 天前

              Rust allows you to choose whatever method you want.

              • Early return propagating the error
              • Early return ignoring the error (maybe by returning a default value)
              • Explicit handling by if-else (or match) to distinguish between error and not error cases.
              • Early return and turn the error into another type that is easier to handle by the caller.
              • Assume there is no error, and just panic if there is. (.unwrap)

              There are only 2 error handling methods that you cannot do:

              • Exceptions
              • Ignore the error and continue execution

              And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.

              If your concept of “not ugly” is “I just want to see the happy path” then you either write bad code that is “not ugly” or write good code that is “ugly”. Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.

              • balsoft@lemmy.ml
                1·
                16 天前

                I am well aware, I wrote quite a lot of Rust, including professionally. I’m not necessarily talking about the “clear happy path”, even though that is relatively nice to have (Rust sort-of allows that with the ? sugar and the pseudo-functor and pseudo-monad methods on wrappers); I’m talking more about the fine line between the overly verbose lists of all the errors that a function could produce (thiserror-style) or just a single messy error type that makes error handling difficult (anyhow-style). There surely must be something in between there that is concise, type-safe, and composable, but I haven’t seen it in any language yet.

                • calcopiritus@lemmy.world
                  2·
                  16 天前

                  In my case, I don’t usually encounter cases where I can’t just ?. But when I do, just make an error enum (kinda like thiserror) that encapsulates the possible errors + possibly adds more.

                  On the call site, just convert to string if I don’t care about specifics (anyhow-style).

                  I don’t find this much painful.

                  Concise: not much on the declaration side, since you have to create an entire enum for each function in worst-case scenario. But on code side, it’s just .map_err(MyError)?.

                  Type-safe: can’t beat errors as enum values wrapped in Result.

                  Composable: i don’t think you can beat rust enums in composability.

                  I don’t use anyhow/thiserror, so I’m not sure. But I believe thiserror fixes the conciseness issue for this.

            • Ephera@lemmy.mlEnglish
              3·
              16 天前

              Yeah, I was gonna say, error handling easily makes up 80+% of the code paths, and depending on whether you’re building a library or service or script etc., different strategies are most suitable for how to deal with those code paths.

              In a script, you often just want it to crash. In a library, you want to make these code paths matchable, in case the user cares why something failed. And then you have the awkward in-between, which is that 99% of your application codebase will be used by your main-function like a library, but you don’t want to spend as much effort on error handling for that as a proper library does, in particular also because you know what all consumers of your application-library need to know.

              So, it’s kind of multiple different problems, with overlap, and people are hoping for one easy solution to cover all these problems.

        • SorryQuick@lemmy.ca
          8·
          16 天前

          You can also use let else.

          let (Some(count\_str), Some(item)) = (it.next(), it.next()) else {
    panic!("Can't segment count item pair: '{s}'");
};

          But really it’s the exact same as other languages, it just forces you to handle it better. C-based languages will return 0/null/-1 and you’ll have to check all 3 of those because they might not mean the same thing. How is that better?

        • tatterdemalion
          6·
          16 天前

          Enums are the best part of the Rust language IMO, so I’m not sure how you can view them as ugly. Having the choice to destructure something is fantastic. You generally aren’t required to destructure every return value. Make sure you’re using the ? operator as much as possible. If destructuring is getting in your way, it sounds like the code is not very idiomatic.

          I can’t really comment on your issue with nested if and match. Too much nesting is bad in any language; try extracting more functions and let bindings to make it more readable.

          You can enable a clippy lint to deny .unwrap() if you’re worried about it.

        • calcopiritus@lemmy.world
          3·
          16 天前

          Most of the times you can just let ... else (which is basically a custom ? if you need if let ... else it’s because you actually need 2 branching code paths. In any other language you also do if ... else when you have 2 different code branches. I don’t see why this is a rust-specific issue.

          • Lucy :3@feddit.org
            25·
            16 天前

            Key point being, similar to some random languages. JS and Python Syntax don’t fit a typed and compiled language at all.

            Pretty syntax would probably be something like C, where not every single character already widely reserved for specific keywords (like !, ', =) is reused in completely random ways.

            • Kacarott@aussie.zone
              8·
              16 天前

              Ah yes I also found macro syntax like vec![ and println!( to be a bit jarring at first. However I don’t know if I would say that C’s approach to macros is any nicer, with it’s #define magic

        • 5C5C5C
          35·
          16 天前

          Being unable to give an actual example proves you’re just a foaming-mouth hater with nothing to contribute.

          • Lucy :3@feddit.org
            716·
            16 天前

            From the first syntax examples on Wikipedia:

            fn main() {
    let foo = 10; 
    // Suddenly, types are implicit now. A safe language should never have implicit types (now it's the (IDEs) implementations judgement which type that is. Combined with the variable shadowing "feature", this seems like a major clusterfuck. Now the IDE is the sole thing to tell you that you totally fucked up the logic, and both declarations/definitions (well which one is it? Would be nice to always have a direct KEYWORD telling you which type this fucking variable has. But no, the lazy piece of shit Rust 'programmer' left that as an exercise to the dear reader. Because in they just need to leave that part out instead of explicitly stating "I'm a lazy piece of shit" by *instead* typing 'auto'.) This is just Python-level BS. Yes, I also hate C++ for its auto keyword - but at least it explicit.
    println!("The value of foo is {foo}");
    let foo = 20;
    println!("The value of foo is {foo}");
}

            fn add_two(x: i32) -> i32 {
// That is, again, the syntax of Python. Why? Because Python is explicitly untyped. So having types be a *literal* afterthought is Ok. They're fully optional anywhere there. Now we're in Rust. They're sometimes optional, sometimes not, but they're always preferred. Yet, they're also an afterthought, seemingly.
    x + 2
    // Implicit statements are bad. Very bad. They so much invite to glossing over stuff, especially when your brain expects to see something else. Also, having every statement ended with ;, except context blocks, but suddenly *not* having statements ending with ;, is fucking ugly (which is the entire point of this rant). It's completly inconsistent. Which in itself is a huge magnet for errors.
}

            if x > 5 {
// Now why would you leave the parantheses, which are a major contributor to readability, away. Or even allow this. Rust is just memory safe, like dozens of other mainstream languages, but continues by allowing, promoting and requiring hazardous practices.
    println!("value is greater than five");
}

            Now I’m slowly getting annoyed from typing on phone (at least in nvim), and my throat gets clogged with mucus again.

            Remember, some of that are subjective preferences and opinions. And the core idea of Rust - fast but safe programs - is good, yet very obvious and not innovative at all, while the syntax and implementation (of cargo (yes I like to wait an hour for a simple webapp to compile because there aren’t binary crates and cargo just doesn’t multicore 99% of the time)) is subpar to something that’s hailed as the savior for everyone and everything by such a large cult.

            • 5C5C5C
              181·
              16 天前

              Types are not implicit, they’re inferred by the compiler when there is no ambiguity about what the type needs to be. This is a huge benefit for refactoring code and reducing maintenance. I acknowledge that sometimes you might care to know the exact type of the variable, and sometimes that’s not as easy for a human to infer as it is for the compiler, but every decent IDE will provide inline type hints for you. Interpreting code by reading it in plaintext is an exercise in masochism.

              Python is actually the opposite on this, and it’s one of Python’s worst characteristics. The type is unknown until runtime unless you annotate it, and then the annotation isn’t really enforced. It’s the worst of every dimension.

              C++11 introduced auto, and now the community is split between “almost always auto” and “never auto”.

              JavaScript needed a whole new compiled language (Typescript) to fix its type system problems, and Typescript is only an incremental improvement at best.

              Rust has the best type system of any modern language by far. If you’re tripped up by not always seeing the type declarations then you’re either focusing on the wrong details in the code or you just need a little more practice. The key thing that needs to sink in for new Rust users is that the compiler is always providing safety rails. That means it’s no longer your job to verify that every aspect of the code is correct. You can relax a little and actually have something akin to duck typing without all the pitfalls that usually come with it.

              • Shanmugha@lemmy.world
                15·
                16 天前

                Sorry for intrusion, but mhm, nah. I get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is. So no, Rust, just like JavaScript, can be liked by some people, but it is in no way something that has “best type system”

                There actually is no such thing as best type system, same way there is no such thing as best language

                • 5C5C5C
                  9·
                  16 天前

                  I get it there are people who want to play around and have language/compiler babysit them, but there are also people like me who want to see exactly what something is.

                  This is a false dichotomy when it comes to Rust. Despite everything I said and despite Lucy’s complaint, there is nothing that actually stops someone from explicitly annotating the exact type when declaring a variable. It’s just not required by the language, and most developers eventually realize that it’s not actually useful.

                  You’re right that these preferences are subjective, be although much of that subjectivity has more to do with how our past experiences have shaped what we’re familiar with, rather than any intrinsic characteristics of person. By that I mean, someone who uses Rust enough will most likely come to like the way the general community styles its code, sooner or later. In the meantime you’re welcome to do things in a way that suits your needs.

                  The only thing that Rust’s type system is weak on is runtime reflection. There are ways to achieve it within Rust’s type system, but it’s considerably more work than what you get in Python and JavaScript. Imo the only reason to choose a language other than Rust for a greenfield project is if you have a strong need for runtime reflection all over the place and aren’t very concerned about performance, threading, or avoiding entire categories of bugs that the Rust compiler protects you from.

            • fruitcantfly
              8·
              16 天前

              In practice, type inference in Rust is not a problem since the language is so strongly typed. In fact, it is more strongly typed than both C and C++, and will force you to cast values explicitly in cases where C and C++ will happily mess up your variables without warning. The absence of type inference would also be a major pain, since nested types such as iterators can get quite complex and very verbose. If you’ve programmed using older C++ standards, then you know this pain

      • Lucy :3@feddit.org
        414·
        16 天前

        Average Rust code:

        macro_rules! sum {
    ( $initial:expr $(, $expr:expr )* $(,)? ) => {
        $initial $(+ $expr)*
    }
}

fn remove_prefix<'a>(mut original: &'a str, prefix: &str) -> &'a str

let mut up = 1;
    'outer: loop {

        This is on the level of the esolang I made at 8 y/o, with random characters denoting random actions everywhere, at random positions.

        • 5C5C5C
          171·
          16 天前

          It’s incredibly disingenuous to call this average Rust code and further erodes your credibility. I may as well point to hundreds of lines of preprocessor macros in a C++ header and call it average C++ code.

          This is not what an average Rust developer is writing 99% of the time. If someone on my team submitted a PR with an implementation of sum that uses macro_rules! I would almost certainly reject it.

    • BehindTheBarrier
      20·
      16 天前

      I can actually see where this is coming from, as I found Rust hard to read when I started out. I do really like Rust for reference, but I do agree Rust is hard to read for someone that has not learned it.

      For example:

      return statements that are implicit just because the semicolon isn’t there. Even better if they occur inside a if block or something like that. Very hard to understanding when you don’t know the syntax rules.

      Lambda functions, especially when using move semantics too. They are quite simple, but if you don’t know the meaning, it’s more arcane characters. Especially when this is used inside lots of chained methods, and maybe a multi-line function in the lambda.

      A lot for the if let x =… type of stataments are tough the first time around. Same for match statements.

      Defining types for use with function::<Type>() and such.

      Lifetimes, especially when they are all named a, b, c etc. It quickly gets messy, especially when combined with generics or explicitly defined types.

      Macros, though not entry level rust to begin with, they are really cumbersome to decode.

      None of these are sins of Rust, but for new people they are a hill to climb, and often hard to just “get” based on previous programming experience and reading the code. Rust can be really hard to approach because of these things. This happens in other languages too, but I do feel Rust has a particularly large amount of new concepts or ways to do something. And this is on top of learning lifetimes and borrow semantics.

      • 5C5C5C
        13·
        16 天前

        This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don’t give them a second thought.

      • wewbull@feddit.ukEnglish
        42·
        16 天前

        I think that’s a great set of criticisms.

        None of these are sins of Rust, …

        They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.

        Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.

        (BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)

        • 5C5C5C
          9·
          16 天前

          Something about the language promotes writing it using these kinds of idioms.

          As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.

          It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.

          But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.

          • wewbull@feddit.ukEnglish
            1·
            16 天前

            I recognise that different languages have different styles, strengths and idioms. One of my pain points is when people write every language as if it’s naughties java. Enough with the enterprise OoP crap.

            I’ve also learnt languages like Haskell to expand and challenge the way I think about software problems. I learnt a lot doing it. That doesn’t stop a lot of Haskell code looking like line noise to me because it over-uses symbols and it being close to impenetrable in a lot of cases when you read somebody else’s code.

            I think the aesthetics of Rust are the wrong side of the line. Not as bad as something like Haskell (or Perl), but still objectionable. Some things seem to be different even though there’s pre-existing notation. Things seem to be dense, magical, and for the compilers benefit over the readers (as an outsider).

            I’ve been learning Zig recently and the only notational aspect I struggled with was the pointer/slice notation as there’s 5 or 6 similar forms that mean fairly different things. It has other new concepts and idioms to learn, but on the whole it’s notation is fairly traditional. That has made reading code a lot more approachable (…which is a good thing because the documentation for some aspects sucks).

        • BehindTheBarrier
          3·
          16 天前

          The implicit return is perhaps the most dubious of them. I don’t mind it for simple functions, but they are not so good in anything large and with multiple return sites. Even more so when developers choose to implicitly return 4 chained method calls inside a closure with else cases.

          But the rest aren’t really sins, they are mostly new or different concepts or ways to do something. And if there is a sin, it’s largely because the language itself has a complexity larger than others.

          Taking my own examples here, lambdas are just fine, but the move semantics are cumbersome to deal with. But we need to do it some way, to indicate that a value is actually being moved into the closure. Maybe there are better ways and they make into the language in the future.

          Conditional values and let statements and such is a good consequence of Rusts design choice with returning Results or Option types. Just because it’s different doesn’t make it a sin. Just takes time to learn the right way. I think most come from an exception based language, and that has a differnet code flow than what Rust has.

          Lifetimes are hard though, and I feel a lot of the introduction is made excessively hard with the simple naming. It’s as of every programming tutorial used single letter variable names. Lifetimes isn’t something I’m that good with either, mostly because I haven’t had to use that complexity yet.

        • Ephera@lemmy.mlEnglish
          2·
          15 天前

          I’m not sure, what you mean by “Chekhov’s footgun”, but well, it isn’t a footgun, so you won’t accidentally return a wrong value from the function, if that’s what you’re thinking.

          It’s not a Rust invention, most functional programming languages have implicit returns, but basically think less of them as a function return and more just as the value that a scope evaluates to.

          So, here’s a simple example:

          let sum = {
    let x = 5 + 9;
    3 * x
};

          Obviously, this is an extremely contrived example, but yeah, as you can see, it does not even have to involve a function. The implicit return makes it so that sum is set to the result from 3 * x.
          And the scope-braces are nice here, because you can do intermediate steps without having x in scope for the rest of your function.

          In practice, if you see scope-braces and the line at the end does not have a semicolon, then that’s the value that the whole scope evaluates to. Those scope-braces can also be the braces of a function, but then you need to annotate what the function is going to return, too, so it’s practically impossible to return a wrong value.

          Well, and I would actually argue that explicit returns are a footgun in comparison.
          Because someone might introduce clean-up code at the end of the function and not realize that an explicit return skips that clean-up code, somewhere further up in the function.
          The implicit return always has to be at the end of the scope, so it’s not possible to accidentally skip code.

    • LiveLM@lemmy.zipEnglish
      121·
      16 天前

      Go look at that Lisp kojumbo then tell me Rust is ugly.

      (defmethod wake ((object magic-packet) address port)
  (let* ((payload (encode-payload object))
         (size (length payload))
         (socket (usocket:socket-connect nil nil :protocol :datagram :element-type '(unsigned-byte 8))))
    (setf (usocket:socket-option socket :broadcast) t)
    (usocket:socket-send socket payload size :host address :port port)
    (usocket:socket-close socket)))

      Actually unreadable.

      • bigfondue@lemmy.world
        8·
        16 天前

        Maybe Emacs has fried my brain, but that is perfectly readable. Common Lisp has one of the most advanced object systems around, so yea you can write hard to read stuff if you want

      • Zak@lemmy.world
        5·
        16 天前

        Entirely readable to someone who knows Common Lisp, and unreadable to someone who doesn’t know any kind of Lisp. Mostly readable to someone who knows Emacs Lisp, Clojure, or Scheme.

        Being able to correctly guess what the syntax does without knowing the language is a function of similarity to familiar languages more often than it is a characteristic of the syntax itself.

          • Zak@lemmy.world
            2·
            16 天前

            I imagine the tricky part for someone unfamiliar with Lisp would be that there’s no syntactic clue that a particular thing is a macro or special form that’s going to treat its arguments differently from a function call. Someone who knows Scheme may have never seen anything like CLOS, but would see from context that defmethod must not be a function.

    • Sunrosa@lemmy.world
      132·
      17 天前

      One of the reasons i find it so hard to use non-Rust languages is how ugly they typically are by comparison. “fn” instead of “function” is such a great example of saving key presses where they’re most needed. And you get very used to seeing compact abbreviations. Idk if that’s what you’re talking about though.

      • Lucy :3@feddit.org
        103·
        16 天前

        Rust:

        fn getofmylawn(lawn: Lawn) -> bool {
    lawn.remove()
}

        C:

        bool getofmylawn(Lawn lawn) {
    return lawn.remove();
}

        With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.

          • Ephera@lemmy.mlEnglish
            6·
            16 天前

            To be honest, I think, they both have their place. In Rust, you typically wouldn’t return just a bool, but rather the element that you removed, so like this:

            fn getofmylawn(lawn: Lawn) -> Option<Teenager> {
    lawn.remove()
}

            And then with such a more complex return-type, C-style means that you can’t see the function name right away:

            Option<Teenager> getofmylawn(Lawn lawn) {
    return lawn.remove();
}

            I also really don’t think, it’s a big deal to move your eyes to the ->…

                • fruitcantfly
                  2·
                  16 天前

                  I believe that it is useful in a few places. cppreference.com mentions templates as one case:

                  Trailing return type, useful if the return type depends on argument names, such as template<class T, class U> auto add(T t, U u) -> decltype(t + u); or is complicated, such as in auto fpif(int)->int(*)(int)

                  The syntax also matches that of lambdas, though I’m not sure that adding another way of specifying regular functions actually makes the language more consistent, since most code still uses the old style.

                  Additionally, the scope of the return type matches the function meaning that you can do

                  auto my_class::my_function() -> iterator { /* code */ }

                  instead of

                  my_class::iterator my_class::my_function() { /* code */ }

                  which is kinda nice

        • fruitcantfly
          5·
          16 天前

          With Rust you safe 1 char, and gain needing to skip a whole line to see what type something is.

          Honestly, the Rust way of doing things feels much more natural to me.

          You can read it as

          1. Define a function,
          2. with the name getoffmylawn,
          3. that takes a Lawn argument named lawn,
          4. and returns a bool

          Whereas the C function is read as

          1. Do something with a bool? Could be a variable, could be a function, could be a forward declaration of a function,
          2. whatever it is, it has the name getoffmylawn,
          3. there’s a (, so all options are still on the table,
          4. ok, that’ a function, since it takes a Lawn argument named lawn, that returns a bool
          • cryoistalline@lemmy.ml
            4·
            16 天前

            types in C are pretty weird

            int *a can be read as

            1. *a is a int
            2. since dereferencing is a operator on pointers, a is a pointer to int

            int *a, b is read as

            1. *a and b are int
            2. so a is a pointer to int and b is a int

            bool getofmylawn(Lawn lawn)

            1. getoffmylawn(Lawn lawn) is a bool
            2. since calling is done on functions, getoffmylawn is a function that takes a Lawn and returns a bool

            And then you have function pointers

            bool (*foo(int a))(float b)

            1. (*foo(int a))(float b) is a bool
            2. *foo(int a) is a function from float to bool
            3. foo(int a) is a function pointer from float to bool
            4. foo is a function that takes a int and returns a function pointer from float to bool

            really weird in my opinion.

        • Sunrosa@lemmy.world
          2·
          16 天前

          “fn” was just one example. There’s also other abbreviations like “pub”, “impl”, “extern”, “mut”, “ref”, “bool”, “u64” And it’s true that some of these keywords are only relevant in Rust, however other langues have their own specific keywords, and they tend to be longer. In languages like Java (which is the worst example I can think of), you see things like “private static boolean” as function definition. In c++, you have to type “unsigned long” or even “unsigned long long” to represent “u64” (depending on data model).

          • Ephera@lemmy.mlEnglish
            2·
            15 天前

            I really don’t agree with saving keypresses being a useful metric, since auto-completion is a thing and code is read significantly more often than it is written. I am also a staunch opponent of abbreviations being used for variable names.

            But I will say that I don’t mind abbreviations in keywords, since well, you need to learn the meaning either way.
            And yeah, I’ve come to somewhat like them being used for keywords, since it reduces visual noise where it really isn’t useful, and it distinguishes keywords from actual code.
            Ultimately, keywords are just syntax where letters were used instead of a symbol. You do read them like a symbol, so if they don’t look like a real word, that seems to work quite well for my brain.

          • [object Object]@lemmy.world
            12·
            16 天前

            Ooh yeah, overall coding culture is definitely not affected by the preferred nomenclature for identifiers. The person who’s habituated to fn over function will absolutely never name their functions in the vein of chkdsk. The two are completely disconnected in the brain of the programmer who read too much K&R in their childhood and was irretrievably traumatized by it for life.

            • calcopiritus@lemmy.world
              21·
              16 天前

              I’d say it’s much more influential the names of the identifiers of the standard library.

              A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.

              We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.

    • tomenzgg@midwest.socialEnglish
      6·
      16 天前

      Not to stereotype too much but I think this is the first Blåhaj I’ve seen (in a programming context) that wasn’t team Rust.

      What your programming language of choice (if you don’t mind sharing)?

  • Gonzako@lemmy.world
    16·
    17 天前

    I like using python just cuz I can quickly get it working. I wish I had the time to undust C and try getting that to do what I want but my work cares more about iteration and speed to implement than speed of the program itself.

  • palordrolap@fedia.io
    171·
    17 天前

    This is pretty smart for the left guy. He’s usually down at the level of “HTML is a programming language” or “What’s a programming language?”.

    That said, the first one of those isn’t mutually exclusive with what he says in the meme.

    • flamingo_pinyata@sopuli.xyzOP
      151·
      17 天前

      It mostly reflects my own story. From a beginner enthusiast of multiple “cool” languages (Scala was all the rage back then), through considering myself more “mature” and thinking about business priorities, ending at understanding that using a good programing language is a business priority.

      If the team works with a language they enjoy, they will be happier (and more productive). Doesn’t even matter if the code is written by humans or machines.

  • Digit@lemmy.wtfEnglish
    12·
    15 天前

    But, Haskell…, it’s so well thought out, so evolved, the best of all functional programming in one, the ability to handle infinite lists, the lazy evaluation, the strict type checking, the compiler that catches whole classes of bugs, the curt syntax, the ability to breathe it like pure thought, the clarity like maths…

    Okay, sorry, I better leave the room too.

  • Jankatarch@lemmy.world
    10·
    16 天前

    Ngl changing paradigms can have the problems do a 180.

    I hate leetcode but it’s surprisingly fun to code certain questions in prolog when final outcome with error checking is like 15 lines.

  • SmokeyDope@piefed.socialEnglish
    7·
    17 天前

    I’m only a hobbyist no skin in the game but as an engineer first programmer second I feel like how you design the architecture of your logic and how you choose to prioritize computational optimization or feature implementation have a much bigger impact than language. Obviously theres a time and place like using luajit instead of lua if you really need that speed boost, but in big complex programs I’m willing to bet lazy programmers skip optimization steps and copy paste thousands of lines to ship quickly regardless how performance optimized the underlying language is.

    I make a module that does a specific thing for version 1, after initial bug patches and maybe a feature addition theres usually an epithany that the logic can be generalized into an api type registry structure that allows the code to be reused and configured as needed on per item basis. Along the way you do stuff like ask what the not expensive calls are, add accumulator timers to reduce unneeded CPU usage , ensure early returns are up top when it makes sense, choosing to render a cleverly crafted sprite instead of a full 3d entity.

    A conditional if then logic loop Is a logic loop no matter what Turing complete language its written in. What really matters is how you use the loop not which syntax its written in.

    • EthanEnglish
      13·
      17 天前

      Any function can be written in any Turing complete programming language. That doesn’t mean a sane person would use malboge or brainfuck for a production system. Language choice can have a huge impact on productivity and maintainability and time is money.

    • expr@piefed.socialEnglish
      8·
      17 天前

      No one actually copy/pastes thousands of lines of code. We use libraries.

      Languages do matter a lot. Yes, they are all technically equivalent, but the craft of software engineering is much, much more about social/cultural/community considerations than it is computational ones. What the community around a programming language values matters, because it informs a great deal about what’s idiomatic in a language, what libraries are available, what kind of bugs are possible (or not), how easy code is to read, comprehend, and maintain, and much more.

      What makes a language good is not what programs you can write in it, but how it constrains what you can do such that you naturally writing good code. For example, null pointer exceptions (or segfaults in C, etc.) are a classic problem that plagues many mainstream languages like Java, C#, Python, etc. In Haskell (and a handful of other languages, including Rust), null pointer exceptions are not possible, because nulls do not exist in these languages. Taking away this language “feature” actually increases the power of the language, because you can guarantee that a certain class of common bugs are not possible in your program. So languages that restrict known bad programming practices lead to programmers writing better programs and, more generally, a community around the language that resonates with these philosophies.

    • AnarchoSnowPlow@midwest.social
      7·
      17 天前

      “We have decided that we will use deck screws to build our deck, it’s the right pattern and architecture for the job. Now get started with this hammer, the tool you use doesn’t matter as long as it’s functional as a tool. If it’s not working well that’s an optimization problem because you’re bad at your job.”

    • Caveman@lemmy.world
      4·
      16 天前

      You make a fair point, programming skill is more important than language but picking a programming language is still important in a lot of cases.

      Ecosystem size can reduce “reinvent the wheel” code.

      Some languages just have dogshit performance like Ruby, lua is pretty good though and it absolutely matters when you have to crunch a lot of data. Access to developers is big since you ideally want to find someone with experience in the language your project is in.

      Some languages like Rust are very good for making safe code but very bad if you want to get out a microservice fast. I could make an equally correct version of some adapter in a fourth of the time in python compared to rust and I know them similarly well.

      Then there’s low RAM requirements like embedded devices, it’s best to run something that compiles to machine code and doesn’t need a big runtime. Java and C# become almost useless in very low RAM environments and you’d have to use Zig, C or Rust instead.

      So long story short, depending on what you’re writing it can just not matter or matter a lot.

    • theneverfox@pawb.socialEnglish
      3·
      16 天前

      It’s extremely important, because you’re never really picking a programming language, you’re picking a stack

      You can technically write an android app in Python, but should you? You’re now locked into a framework used to run apps in Python, which are going to be much more limiting than other languages and frameworks. But you’ll also have access to Python libraries, which gives you options in that direction

      Then you examine the context. How good are you at learning other languages? How long/complicated is what I want to do? Does this need to be performant? How long do I need to keep this working?

      And most importantly, and you really have to think this one through… Will I need to extend the original goals in the future?

      So really, yes, it’s very important. A bad decision in the beginning could cause problems for decades

    • EthanEnglish
      816·
      17 天前

      Keep your Rust to yourself. I don’t care what language someone else uses for their projects but Rust is an unreadable mess that I don’t want anywhere near my projects.