Announcement

Collapse
No announcement yet.

The Qt Company Is Now Working On Qt For Microcontrollers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by wizard69
    Any train of thought that tries to justify the use of C for GUI app development in 2020 is extremely flawed. All languages have flaws by the way, but the point is a language and it’s compiler must be partners in the process of developing high quality software. C is an anti partner.
    I agree with you, but Rust syntax is such trash. I know they can’t really help it due to their ownership system, static typing, immutable data structures and so on, but wow how do you make a modern language so unreadable? Why use the smallest symbol you can find for lifetimes?

    C has a lot of problems, but at least it is clean and easy to read. You could argue that much of it is kept in your head as opposed to written, but that is preferable when reading someone else’s code (or yours in a month or two) relative to unpacking what is going on in Rust.

    Here’s some examples from Serde, their JSON serialization library:

    Code:
    impl<'a, W, F> ser::Serializer for &'a mut Serializer<W, F>
    
    fn serialize_field<T: ?Sized>(&mut self, key: &'static str, value: &T) -> Result<()>
    
    struct NumberStrEmitter<'a, W: 'a + io::Write, F: 'a + Formatter>(&'a mut Serializer<W, F>);
    
    fn parse_str<'s>(&'s mut self, scratch: &'s mut Vec<u8>) -> Result<Reference<'de, 's, str>>;
    
    impl<'b, 'c, T: ?Sized + 'static> Deref for Reference<'b, 'c, T>
    
    pub fn pointer<'a>(&'a self, pointer: &str) -> Option<&'a Value>
    Oh hell, I was just trying to read a library but it looks like I stumbled onto the obfuscated C contest by mistake...

    Rust may be the future, but definitely not my future. You couldn’t pay me to deal with the extra eye-strain. I’d much prefer using a safe and clean language with a GC like clojure, javascript, or *shudder* python. Or something like scheme that can compile to C. I would even rather write in C or C++ and take my chances with the roulette wheel. I also formally apologize to C++. I used to call it unreadable but next to this monstrosity it is practically a Lisp. Ok I’m done.

    Comment


    • #22
      It looks like a good project! As for the license, I haven't read, but a commercial license is not necessarily a proprietary license, but there is a problem for companies that want to develop open source commercial software, not for the software itself but above all for copyright.

      Comment


      • #23
        Originally posted by cb88 View Post
        Also the complexities you note there come from python not C or Rust... you can mix C and Rust libraries with no issues. The point is that it can be done cleanly, while the same cannot be said of C++... at all.
        That is exactly it. It is why C is still so common. Bindings for other languages can be created easily for it. For example:

        C -> Python
        C -> C#
        C -> Java
        C -> C++

        The same is not true for other languages, you said so yourself:

        Python -> Rust (you have to go through C)
        C++ -> Rust (you have to basically go through C by making C linking functions and opaque pointers)
        Rust -> Python (through C)
        Python -> Java (through C, back out to the JNI)
        or my personal worst.... Java -> C# (JNI, C, CLR or if using the C++/clr then JNI directly to .NET; quite a bit nicer until Microsoft drops support for C++/clr)

        All extremely awkward.

        Yes, I am waiting for a replacement for C but I don't think we will see one in our lifespan unless hardware seriously changes and at the rate it is going; this likely will not happen. It has many issues but as far as I am concerned; in many cases it is the best we have. Its flexibility also has a knockon effect for languages which extend it (such as C++ and Objective-C) rather than try to replace it (Rust, Go). Honestly I am confident that Swift will disappear and Objective-C will make a comeback because of this connection to C.
        Last edited by kpedersen; 23 August 2019, 11:13 AM.

        Comment


        • #24
          Originally posted by carewolf View Post
          On which platforms? Qt tries to scale similar to native applications on every platform. On Linux it does it's own thing because it _is_ a standard in itself there. Unfortunately the system values Qt uses from X11, GNOME at some point decided to override with false values (for some reason..), so system scaling is a mess on X11, and non existing on Wayland.
          Eh. On Linux. Given that Qt stuff is the only one users exposed to which does not scale well, they do not care for that explanation of yours. When other products manage to solve HiDPI, even via temporary ugliness, looking at a next shiny market instead of giving users the right experience exactly shows my point: "The priorities on more markets kills confidence they care about the installed base."

          Comment


          • #25
            Originally posted by vldid View Post

            Eh. On Linux. Given that Qt stuff is the only one users exposed to which does not scale well, they do not care for that explanation of yours. When other products manage to solve HiDPI, even via temporary ugliness, looking at a next shiny market instead of giving users the right experience exactly shows my point: "The priorities on more markets kills confidence they care about the installed base."
            Qt scales just fine for me. Have done so for half a decade.

            Comment

            Working...
            X