Announcement

Collapse
No announcement yet.

GXUI: A New Cross-Platform UI Library By Google

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

  • #41
    Originally posted by Luke_Wolf View Post
    You make the invalid assumption that a craftsman always, or even usually gets to choose the tools for the job.
    You additionally make the invalid assumption that all tools are equal in quality but of different purposes, which is quite frankly not the case.
    I knew about those options, but I didn't want to elaborate all cases since this is already off-topic.
    Let's assume the job is to mount something using wood screws.
    If your tool of choice is a hammer you really shouldn't blame the hammer.
    If your boss forces you to use a hammer, you still shouldn't blame the hammer. You could blame the boss or blame yourself for accepting to work under said boss or whatever.

    On the other hand if you have to drive screws and the one below is the only screwdriver in existence, make a better screwdriver.
    If the tool does it's job, but you want it to do more things/things better/etc. , get or make a better tool. But it's not the tools fault. If the tool is proprietary, and you can not influence it to be improved, tough luck (in this case you could blame the tool maker).
    Only when the tool doesn't do what it was intended for it to do (or does it badly) should the tool be blamed.

    But really, this is way off-topic now.

    Comment


    • #42
      Originally posted by alexvoda View Post
      I knew about those options, but I didn't want to elaborate all cases since this is already off-topic.
      Let's assume the job is to mount something using wood screws.
      If your tool of choice is a hammer you really shouldn't blame the hammer.
      If your boss forces you to use a hammer, you still shouldn't blame the hammer. You could blame the boss or blame yourself for accepting to work under said boss or whatever.
      Except that sometimes that hammer is really a double ended claw hammer


      and if the Boss forces you to use this then the "tool" and the Boss deserve EQUAL blame. The hammer or double ended claw hammer IS the one preventing you from doing your job, and the Boss is at blame for forcing you to do this. You can make the argument that the coder should know better or quit their job and find another, but frankly this shares a striking resemblance to arguments that a person should have known not to go through a bad part of town despite it not being realistic option to avoid it.

      Originally posted by alexvoda View Post
      On the other hand if you have to drive screws and the one below is the only screwdriver in existence, make a better screwdriver.
      If the tool does it's job, but you want it to do more things/things better/etc. , get or make a better tool. But it's not the tools fault. If the tool is proprietary, and you can not influence it to be improved, tough luck (in this case you could blame the tool maker).
      Only when the tool doesn't do what it was intended for it to do (or does it badly) should the tool be blamed.

      But really, this is way off-topic now.

      That's nice but developing a programming language is a full time job, and to be done well requires the involvement of multiple individuals over several years, it's not like a screwdriver where you can just "make a better one" and the reality is that while the craftsman might make slight enhancements to his or her particular tools it's rare for him to significantly advance his tools. What you're effectively saying is that when a tool is crap that a developer should quit their job and spend several years of their life working for free to create a replacement which in all likelihood he's actually going to be banned from using unless he works for himself because it is too new and unproven, and the company will be screwed they just have to trust him.

      Quite frankly... That is ridiculous. Sure it doesn't help anyone if he doesn't decide to try to advance/fix the tools... but do you want to pay his paycheck to develop these things? I'm guessing the answer is no, which means that there's very little reason for him to do it, and he has no obligation to you or anyone else to do it just because he can, particularly as it would impose undue hardships on him. There's a reason we have people whose whole job it is to make better tools as opposed to expecting the craftsman to improve his own tools all the time.

      Comment


      • #43
        Originally posted by goTouch View Post
        Do people love those slow C# apps or have to use it because software companies choose to make it use C# for fast-to-market reason instead of efficiency? Not getting tired of the minutes we waste waiting for app launching every day?
        Most people don't know what c# is, let alone whether their app is written in it.

        I'll just say that if people are fine running tons of java applications on slow mobile hardware, then running c# apps on desktops can't possibly be that bad.

        Comment


        • #44
          Originally posted by smitty3268 View Post
          Most people don't know what c# is, let alone whether their app is written in it.

          I'll just say that if people are fine running tons of java applications on slow mobile hardware, then running c# apps on desktops can't possibly be that bad.
          Not only running tons of java applications on slow mobile hardware, but running tons of java applications on a slow very outdated VM on slow mobile hardware; as opposed to running C# applications on a fast VM on fast desktop hardware.

          Comment


          • #45
            Originally posted by Luke_Wolf View Post
            Except that's still wrong. Software indeed can't be fast just because it's written in C++, but it can be slow because it's written in python. Skill is required in order to make something fast, but for software to be slow is simply a question of drag, which includes the execution speed and the execution profile of the language itself in addition to factors that actually involve the skill of the individual craftsman. In effect you can have a program that is both fast and slow at the same time by implementing a fast algorithm in a really inefficient language. Yes in principle well written Python can be faster than very poorly written C++, but quite frankly I'm tired of people arguing that the tools that they use don't matter, and the lie that "only a bad craftsman blames his tools".
            If the execution speed of an application were the only consideration, then your argument would be totally relevant. But since it's not, you're right, but irrelevant.

            The amount of effort it takes to develop and maintain the application is a pretty critical factor into turning something into a program that people not only want to use, but want to continue to use. There have been plenty of great, fast applications that have been cast aside for newer, slower applications but that add interesting/useful new features. Application reliability may be a greater concern than simply running fast. Application portability may lead to greater popularity than simply being the fastest at what it does.

            Consequently, choosing the right programming language allows one to choose their tradeoffs. Else, why would C++ even exist? There's nothing you can do in C++ that can't be made to run faster in plain C. Why would C even exist? Just write it in assembly.

            Show me a finely-tuned, efficient application that compiles cleanly for different platforms, isn't a security sieve (I have a hard time thinking of any application or library as being secure anymore - it now just seems to be a question of how hard someone has to work to break it), can adapt fast enough to stay relevant, and has more than 10 sources files and more than 100,000 lines of code. I doubt such a thing even exists.

            Comment


            • #46
              Originally posted by goTouch View Post
              Do people love those slow C# apps or have to use it because software companies choose to make it use C# for fast-to-market reason instead of efficiency? Not getting tired of the minutes we waste waiting for app launching every day?
              Buy a SSD. App startup time is irrelevant these days. Hard drives used to transfer max 5 MB/s when I was a kid but now you get 100 000+ IOPS and 600 MB/s read/write. The "hugely bloated" Qt or C# app and its runtime are probably only 300 MB max so it might take 0.5 seconds to load the stuff from disk. If you want faster, consider buying a 1200 MB/s faster SSD. Problem solved. Now that SSD is here, the initial startup time is totally irrelevant. SSD speed improves 2x every 18 months thanks to Moore's law and memory banking. In other news, people have 16 to 64 gigabytes of RAM these days. The apps go to in-memory disk cache after first launch. Gotta love huge multimegabyte L3 caches and 64-bit architectures with tens of gigabytes of RAM. Even phones have 3 GB of RAM already. You usually only run a single app concurrently so you're using your mobile phone wrong if the app uses less than 3 GB.

              Comment


              • #47
                Originally posted by rabcor View Post
                I definitely will. I always check on KDE from time to time, if I didn't feel it was sluggish and it's compositing effects were unstable, I'd be using it.
                That's bullshit. KDE is most GPU accelerated desktop so you get full acceleration from 2000 CUDA cores and can have multiple 24bit 2560x1600 or 4K layers of the desktop in GPU ram. It's amazingly fast compared to legacy desktops that use CPU managed memory and slow CPU rendered graphics.

                Comment


                • #48
                  Originally posted by smitty3268 View Post
                  Most people don't know what c# is, let alone whether their app is written in it.

                  I'll just say that if people are fine running tons of java applications on slow mobile hardware, then running c# apps on desktops can't possibly be that bad.
                  There is a psychological law that all user interface events should last at most N milliseconds. The way to mitigate this is to use splash screens and visualizations like progress bars. People can easily tolerate latency in desktop if the "look and feel" is right. For example Mac OS X apps might start up slower than Linux apps but they have super smooth bounce animation when you start an app from the dock. If you want to improve startup time, there are also faster PCIe bus SSD disks.

                  Comment


                  • #49
                    .NET is completely dead?

                    So, it looks like .NET is dead and there are plenty of truly cross-platform replacements. Hey, microsuxx, can you tell us why you can't do crossplatform UI in 10 years while Google can do this in some few months?

                    Comment


                    • #50
                      Originally posted by SystemCrasher View Post
                      So, it looks like .NET is dead and there are plenty of truly cross-platform replacements. Hey, microsuxx, can you tell us why you can't do crossplatform UI in 10 years while Google can do this in some few months?
                      You're joking right?

                      http://www.mono-project.com/news/
                      https://github.com/Microsoft/dotnet
                      http://blogs.msdn.com/b/dotnet/archi...en-source.aspx

                      Comment

                      Working...
                      X