Announcement

Collapse
No announcement yet.

D Language Still Showing Promise, Advancements

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

  • #51
    Originally posted by ciplogic View Post
    So, when do you start?
    Would it be possible to use D in such a way? Is it already that capable?

    Comment


    • #52
      Originally posted by varikonniemi View Post
      Would it be possible to use D in such a way? Is it already that capable?
      Yes, D2 has been stable for years and has projects built with it. Hell, D1 was turning complete since its inception (the first working compiler release, at least). All it takes to write a kernel is a turing complete language with unrestricted memory access (ie, arbitrary addressing) and the ability to add in assembler (for hardware functions not defined in language syntax), and D has both. You would need to disable the gc and that means you can't use any of the standard library, but nothings stopping you.

      Comment


      • #53
        I absolutely believe the reason Perl, Python, Ruby and PHP came to dominate web development is the rapid feedback loop. Change your source code, save the change, Alt-Tab to your browser, hit F5, and see the results of your change. Alt-Tab back to your IDE/Emacs/Vim, make the next round of changes, save it, Alt-Tab to your browser, hit F5, see the result. Repeat until you have something you can ship. I telecommute some days, I have a wonderful boss, great coworkers, and some interesting technical challenges at work. But I worked for years at Java web development, then for a while in Python, then back in Java. I'm a Python newbie and a Java veteran, and I'm still three times faster with Python. Even with all of the extra unit tests and manual tests I have to put with Python code to make up for the lack of a static type system, I'm still faster with Python.

        A half-competent Perl/Python/PHP/Ruby developer can develop a full featured website that uses 100 times the computing resources required by an identical website built by a competent C++ developer. But unless the C++ guy is absolutely world class fast, the scripting guy will be done in a third of the time. Maybe even a tenth of the time. That's why Facebook, Twitter, Reddit, Youtube, etc... were built with languages like that and only switched to more efficient languages later when the scripting languages couldn't keep pace with their expanding needs.

        D (and Go) may never match C++ for resource efficiency. But both languages supposedly can compile hundred-thousand LOC projects in less than ten seconds. That puts them at a developer feedback loop almost as good as a scripting language and performance probably within 10x of C++ (depending upon the application). I imagine there are tens of thousands of software projects that would find that combination of features better than what they have now. Obviously in some places - where absolute control of resources or real-time constraints are present - you have to stay with C++ or C.

        Comment


        • #54
          Originally posted by zanny View Post
          Yes, D2 has been stable for years and has projects built with it. Hell, D1 was turning complete since its inception (the first working compiler release, at least). All it takes to write a kernel is a turing complete language with unrestricted memory access (ie, arbitrary addressing) and the ability to add in assembler (for hardware functions not defined in language syntax), and D has both. You would need to disable the gc and that means you can't use any of the standard library, but nothings stopping you.
          So we would need a non-GC standard library first. I have no idea how to implement one, that's way out of my league.
          Last edited by varikonniemi; 24 June 2013, 05:33 PM.

          Comment


          • #55
            Originally posted by varikonniemi View Post
            So we would need a non-GC standard library first. I have no idea how to implement one, that's way out of my league.
            There is one mentioned in this blog post http://3d.benjamin-thaut.de/?p=20 . No idea how compliant/tested it is though.

            Comment


            • #56
              Originally posted by bnolsen View Post
              Exactly this. <algorithm> is pretty amazing. The half closed interval convention used by the std collection applies amazingly well in the floating point domain to easily deal with segmenting continuous intervals.

              Yeah I lived through the 90s where C++ and java coding looked almost identical. And writing unnecessary accessors for everything was common too. When inheritance has to be used (resource abstraction) you can't avoid new-ing stuff. Of course. So there's your smart pointers. The GC feature stuff seems to appeal mostly to java/c# coders who unnecessarily seem throw anything and everything onto the heap. Don't do that. And then try to compile/run this stuff on windows and you get to see what a craptastic memory allocator does to you.

              I was very excited when 'd' first came out but looking more closely and playing with it I just didn't see enough of an advantage. C+11 does a good job of killing off most reasons to use 'D' and if they don't screw up c++14 that should be the nail in the coffin. And I do like to be able to target linux, windows, macos, arm, mips, x86_32, x86_64 without much grief.
              If this under the hood works better I'm gonna revise my idea.

              Have an syntax that has inclusive syntax but store it with half closed interval convention.
              Now we have the easy of using half open interval and convenient syntax.
              Code:
              auto rangeExclu = a[1..11];
              auto rangeInclu = a[1....10];
              Really want something to write things inclusive, for some things it's easier to deal with segment stuff.
              (See my earlier post with the overlapping numbers, it just looks wrong/weird.)

              Comment


              • #57
                Originally posted by plonoma View Post
                If this under the hood works better I'm gonna revise my idea.

                Have an syntax that has inclusive syntax but store it with half closed interval convention.
                Now we have the easy of using half open interval and convenient syntax.
                Code:
                auto rangeExclu = a[1..11];
                auto rangeInclu = a[1....10];
                Really want something to write things inclusive, for some things it's easier to deal with segment stuff.
                (See my earlier post with the overlapping numbers, it just looks wrong/weird.)
                I think this approach is the wrong way to go all together, mainly because it makes language parsing much harder when you have glyphic ambiguity (and on the topic of C++, remember > > ?) rather than use c-style arrays, you should propose a modification of (thinking C++ here) std::array::slice(X,Y) for an inclusive iterator of a range of an array.

                Since C++ std::array has the performance of a c style array, you don't lose anything, but making the base language more complex makes parsing and lexing harder.

                Comment


                • #58
                  Do remember >> thing, C++ should have used () for templates.

                  The language already has to parse the difference between ., the .. and the ... operator. (the last one does what params does in C++)
                  Also the : and the :: operator. There are probably more examples of closely related operators like the dot and colon.
                  Glyph ambiguity is something that already would already pose a big problem if it is a big problem.


                  Parsing and lexing won't make it much harder.
                  Following is pseudocode: Parse it as:
                  Code:
                  if(operator == ..){
                  // stuff you do
                  }
                  if(operator == ....){
                     call operand1..(operand2 - 1); // try to optimize this step to make the arithmetic happen at compile time.
                  }
                  All the arguments for using inclusive range also count for your std::array::slice(X,Y) proposal.
                  Having both styles are very nice and want to use the thing in all kind of situations where you could use a slice.
                  Really like the short notation of using the dots.
                  Last edited by plonoma; 24 June 2013, 08:31 PM.

                  Comment


                  • #59
                    Originally posted by plonoma View Post
                    Do remember >> thing, C++ should have used () for templates.

                    The language already has to parse the difference between ., the .. and the ... operator. (the last one does what params does in C++)
                    Also the : and the :: operator. There are probably more examples of closely related operators like the dot and colon.
                    Glyph ambiguity is something that already would already pose a big problem if it is a big problem.


                    Parsing and lexing won't make it much harder.
                    Following is pseudocode: Parse it as:
                    Code:
                    if(operator == ..){
                    // stuff you do
                    }
                    if(operator == ....){
                       call operand1..(operand2 - 1); // try to optimize this step to make the arithmetic happen at compile time.
                    }
                    All the arguments for using inclusive range also count for your std::array::slice(X,Y) proposal.
                    Having both styles are very nice and want to use the thing in all kind of situations where you could use a slice.
                    Really like the short notation of using the dots.
                    I'm not concerned about the parsing of a .. operator in braces, but more that it introduces ambiguous and more complex parsing of any brace statement. Right now, when the compiler encounters [] it knows it is only either allocating an array, indexing past a primitive, or calling the [] operator on the named value. With Pythonic array semanitcs you need to consider the contents of square brace notation, which is a pretty big language hike considering very few native language operators have been introduced in 15 years (I think && as an rvalue is the only big one off the top of my head).

                    Comment


                    • #60
                      Where inclusive range is used compilers can optimize and replace the last value with the last value - 1 at compile time and plug the modified form in the algorithms.
                      Doesn't hurt execution speed or memory use of the compiled program in any way.

                      The three options you give already make it necessary to inspect what is between the square brackets.

                      Comment

                      Working...
                      X