Announcement

Collapse
No announcement yet.

Latest Trolling? The Linux Kernel In Perl

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

  • #11
    Originally posted by Tiger_Coder View Post
    All that trolling aside, may be it is not so bad to have a interpreted language support in kernel level. Not a fully featured language but a subset of python or other language may be? or may be a C scripting? It would be good for debug and quick testing? Or writing kernel modules without recompiling it fully(driver or subsystem is not performance oriented). I am not sure about even if it is possible or feasible but was just thinking.
    Yes, you are right. It might be useful at a conceptual stage for designing a new part of the kernel, provided the final implementation will be done properly.

    Comment


    • #12
      Originally posted by Tiger_Coder View Post
      All that trolling aside, may be it is not so bad to have a interpreted language support in kernel level. Not a fully featured language but a subset of python or other language may be? or may be a C scripting? It would be good for debug and quick testing? Or writing kernel modules without recompiling it fully(driver or subsystem is not performance oriented). I am not sure about even if it is possible or feasible but was just thinking.
      Or Lua, like the BSDs. But that's not what was suggested by the guy, but rewriting functional pieces of the kernel into a scripting language (Perl, in particular).
      IMO, having that in a production kernel would be weird. I'd say risky, because it just sounds like that, but as I actually know nothing about security, I'd rather look my words. Anyway, as a prototyping platform for development kernels it sounds fairly good.
      As for being possible, the article itself, IIRC, mentions one of the BSDs (was it FreeBSD?) has Lua support, so I think this proves it is possible to do.

      Comment


      • #13
        Most languages are Turing Complete

        Well, there is nothing theoretically wrong with using a language other than C for your kernel, but ultimately your choice of programming language won't affect your programs that much IMO.

        I turns out that if a problem is hard, then coding it up is hard. Even if C++ is "harder" than Java, that difference pales in comparison to most interesting projects you'll want to do.

        Also, although C# and Java are newer languages (and therefore code rot is less likely to have set in - the real problem IMO), I have seen plenty of garbage C# code, and plenty of excellent C code. Guess what? It isn't the language. It isn't even how good the programmer is...

        It's how LAZY the programmer is.

        Comment


        • #14
          What next, soon someone gets idea to write kernel in java then .C# then Pascal etc.... and finally Kernel becomes massive bloat that cannot work without those dependencies. I think Antti and those classmates/professors are smoking something thats it.

          Comment


          • #15
            Originally posted by OneTimeShot View Post
            Well, there is nothing theoretically wrong with using a language other than C for your kernel, but ultimately your choice of programming language won't affect your programs that much IMO.
            Yes it does.

            Originally posted by OneTimeShot View Post
            I turns out that if a problem is hard, then coding it up is hard. Even if C++ is "harder" than Java, that difference pales in comparison to most interesting projects you'll want to do.
            Tell me in what project is Java a better choice than C/C++ in terms of performance?

            I can promise you that Java is worse in almost every case.

            Originally posted by OneTimeShot View Post
            Also, although C# and Java are newer languages (and therefore code rot is less likely to have set in - the real problem IMO), I have seen plenty of garbage C# code, and plenty of excellent C code. Guess what? It isn't the language. It isn't even how good the programmer is...

            It's how LAZY the programmer is.
            Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?

            Why is Qt Creator lightning fast?

            Comment


            • #16
              Originally posted by board View Post
              Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?
              No, it's because Eclipse is bloated and an over-engineered/buggy POS.

              Comment


              • #17
                Originally posted by wargames View Post
                No, it's because Eclipse is bloated and an over-engineered/buggy POS.
                Netbeans is no different, and it's developed by Sun/Oracle.

                Comment


                • #18
                  Why can't I see a problem?

                  Comment


                  • #19
                    Originally posted by board View Post
                    Why do Netbeans, Eclipse and Eclipse derivatives have slow GUIs and slow startup times? Is it the programmers? Or is it Java and its crappy GUI libraries?
                    Why is Qt Creator lightning fast?
                    Possible reasons: usage of JIT compiler, CPU cache doesn't work well with Java apps, calling native function from Java function has overhead.

                    Comment


                    • #20
                      Originally posted by brosis View Post
                      Kernel A can't be upgraded to A+1, because kernel A+1 depends on Perl version B+1.
                      Perl version B can't be upgraded to version B+1, because currently used Kernel A does not support Perl version B+1.

                      Do you want to destroy the system via force install Kernel A+1 and Perl version B+1? (Y/n)

                      Welcome to circular dependency hell.
                      Wouldn't happen.. You'd embed a version of the perl interpretor inside the kernel itself so that it didnt have an external dependency. Each kernel would depend upon the version of perl embedded inside of itself

                      Comment

                      Working...
                      X