Announcement

Collapse
No announcement yet.

PowerNex: A Kernel Written In The D Programming Language

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

  • starshipeleven
    replied
    Originally posted by Edogaa View Post
    Everytime a new project comes up, trying something 'different' for fun, some dumb user comes in angry that we aren't a hivemind that works collectively to only improve one existing system to bring down M$
    In the case of Master5000, it's "hivemind that works collectively to only improve Windows".

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Michael_S View Post
    Porting the drivers from where, Linux? My understanding of licensing is that if you use a piece of code as a starting point, you have to use the same license or a compatible license even if you rewrite large portions of it. So I don't understand how any of the *BSD kernels can get drivers from Linux without shifting their license to GPLv2.
    By mimicking linux kernel-driver interfaces (if they don't expect to have anyone make drivers for them, at least for now) or by using a compatibility layer in the kernel and adding precompiled binaries made from GPL sources.

    I doubt FreeBSD devs are so bright to do something like this, their "compaqtibility layer" will of course still require them to rewrite stuff from scratch as they like to make stuff that can be taken freely by everyone.

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by Master5000 View Post

    There is no God! Braindead programmers. I can't possibly understand why the fuck would you waste your life like this working on such useless shit.
    The only useless person here is you.
    Stop complaining and accomplish something of your own, FFS!

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by Delgarde View Post
    But why should they care? Most projects like this are simply about having fun, not about finding the optimal use for "manpower". They're usually started by some guy who's just done a course on OS design at university, and wants to see what he can do with his knowledge. And there's no point in him working on an existing project, because all the interesting parts have already been done...
    I guess if you find it fun then sure, go for it. I have no problem with coding for fun, but I don't understand the purpose of coding something that will likely never go beyond a proof of concept. To me, it's more fun to code something "for fun" that I can actually complete. I don't understand how it would be fun to create something that would be roughly as limited as DOS.
    I'm not saying that the creators of this OS need to contribute to something else. As I said before, there's nothing wrong with working on this. So to answer your question, they should care because this project died the moment it started. In my personal opinion, I wouldn't like starting something that will inevitably be forgotten and marked as "yet another hobbyist OS attempt". If I'm going to do something as a proof of concept for fun, I'd rather it be original. Sure, an OS entirely in D is intriguing, but that's the extent of it.

    Leave a comment:


  • coder
    replied
    Originally posted by GreatEmerald View Post
    my main experience with C++ comes from Unreal Engine 4, which is a bit of a beast and may not be what you'd expect from a standard C++ project, perhaps.
    You've already conceded this is not a good application of the language (probably due to quite a bit of legacy, much like Qt, I assume), so there's no need to debate any of that.

    Originally posted by GreatEmerald View Post
    There are also lots of times when I ran into a problem that one source file requires a header that defines a class inside it, and then it results in circular dependencies, and then you need to resort to forward declarations that may or may not work correctly for every use case etc.
    whaaaat?

    Circular dependencies are only something noobs struggle with. I see that it increases the learning curve, but once you know about forward declarations, callbacks (be they function pointers or functors), and virtual functions, there should be no problem with circular dependencies.

    Originally posted by GreatEmerald View Post
    And sure, a lot of things come down to preference. I don't like the :: notation, I don't like the -> notation, I don't like the & notation. I like the . notation, which ought to universally mean "access a member".
    I find that what's easiest to read is merely what one is accustomed to reading.

    Originally posted by GreatEmerald View Post
    I don't like having to repeat the class name every time I want to refer to other functions from within the same class.
    That's only needed to disambiguate or circumvent overrides. I rarely have to do it.

    Originally posted by GreatEmerald View Post
    I don't like duplicating my code just to make a header file (which compilers could very easily auto-generate from my code),
    I actually like the fact that header files make you think about your interfaces and distill them down by separating them from the implementation. They can speed up compilation and allow certain bugs to be discovered at compile-time. But, if you don't want to deal with them, you can just put most of your code in headers.

    Originally posted by GreatEmerald View Post
    I like strings, dynamic arrays and foreach loops, and I don't like pointers and macros.
    There's nothing really wrong with C++'s string or vector, and you can do foreach in C++11. Macros are rarely needed, and pointers are one of those low-level efficiency things.

    Originally posted by GreatEmerald View Post
    In my case, I'd rather just use C then.
    But with C++, you don't have to completely sacrifice all of the nice tools and abstractions it provides, in order to get low-level efficiency. Templates can be a very powerful tool for code optimization. Destructors reduce bugs and improve code readability. Both play a strong role in high-performance code that's maintainable and even portable.

    I'm not interested in expanding the discussion to Python, but it seems like all of your points are stylistic. Python does have its share of legitimate downsides, but I do pretty well with it.

    Leave a comment:


  • GreatEmerald
    replied
    Originally posted by RamblingMadMan View Post
    Don't blame your incomprehensible coding on the language. I've seen plenty of C++ code bases that are easily readable and self-documenting.
    I use functional and procedural syntax in most of my code and it is definitely "well-defined". The only valid argument here is that C++ gives you way too many ways to do the same thing, but to even a moderately skilled C++ developer they should be all recognizable.

    I really don't know what you mean by this. Care to elaborate?

    What makes you think you have to worry about memory management for the simplest of things? Most things are done in automatic storage. Even most complex things don't require you to bother with manual memory management. The only time you really have to do that is when interfacing with C code or doing low-level stuff, and even then you can just re-write your code using std::vector<char> or std::unique_ptr and interface with the pointers that they store.
    Mind you, my main experience with C++ comes from Unreal Engine 4, which is a bit of a beast and may not be what you'd expect from a standard C++ project, perhaps. UE4 includes quite a lot of custom templates and macros that are supposed to make everything much simpler; but in reality it makes everything much more complicated since figuring out what exactly those macros are doing (and even whether or not you're supposed to put semicolons after them...) is real difficult. You have to write things like TEXT("Some string goes here") for every string, add two or three macros before the beginning of each class (and one at the top of every header file), and figuring out what permissions your class has to access and modify members of other classes can become bewildering.

    There are also lots of times when I ran into a problem that one source file requires a header that defines a class inside it, and then it results in circular dependencies, and then you need to resort to forward declarations that may or may not work correctly for every use case etc.

    And sure, a lot of things come down to preference. I don't like the :: notation, I don't like the -> notation, I don't like the & notation. I like the . notation, which ought to universally mean "access a member". I don't like having to repeat the class name every time I want to refer to other functions from within the same class. I don't like duplicating my code just to make a header file (which compilers could very easily auto-generate from my code), and it's terrible when they go out of sync. I like strings, dynamic arrays and foreach loops, and I don't like pointers and macros. A lot of the preferences come from me being an UnrealScript developer (D is actually very close to UnrealScript), and it certainly makes me discontent that Epic dropped the easily readable, convenient language for the irksome C++ monster that UE4 now is.

    Originally posted by coder View Post
    I'm not claiming that C++ is a perfect language. What I do claim is that, if you want a powerful language with the ability to get very low-level and have great runtime efficiency, I've yet to see anything surpass C++ sufficiently (and without compromises) to justify using it.
    In my case, I'd rather just use C then. At least it's dead simple and has a cohesive syntax. (Yes, it's possible to screw things up in C too, I've seen some real nightmare code in it - ironically, said code was in .cpp files initially, with the only C++ feature used being new/delete - but it's just so much more difficult to screw it up.)

    Originally posted by coder View Post
    Now, for your purposes, perhaps a better comparison would be D vs. Java or C#. When I don't need the efficiency, safety, and control that C++ provides, I prefer Python.
    I don't. Python also has quite a few irksome things. The whole package dependencies issue; class constructors requiring making variables and setting arguments to them, and then having to go through the "self" notation every time; whitespace being required; plus meaning concatenation etc. It's workable, but it's not quite as convenient as it should be. Also, I am yet to find a good Python IDE.

    Leave a comment:


  • coder
    replied
    I mostly agree with RamblingMadMan.

    Originally posted by GreatEmerald View Post
    What the new standards do is just cherry-picking some concepts from D and putting it on top of the whole beast that C++ has become over the years.
    Actually, it's more the other way around, with D picking up proposed C++ features. I'm not going to claim that D's implementation of a certain feature has never informed or influenced people involved in C++11, partly because I think some of D's proponents are still involved in the C++ community.

    I will say that if there are any truly novel features in D, it's a very small number. But, that's true for most languages.

    Originally posted by GreatEmerald View Post
    And at least for me the most important thing about D is that writing code in it feels good: the code is readable, you don't have to worry about memory management and stuff, and all kinds of different programming paradigms can be combined into a cohesive whole with a well-defined syntax.
    This sounds like a matter of:
    1. using the right tool for the job
    2. comfort level
    3. coding style.


    Originally posted by GreatEmerald View Post
    Meanwhile in C++ you have to wrestle with all kinds of incompatible syntaxes (how many ways there are to do malloc/free or access pointers?),
    What does syntax have to do with malloc/free? The main reason people even use malloc/free is when using C code from C++, and I'm sure you'd have to do the same with D.

    Originally posted by GreatEmerald View Post
    care about memory management for the simplest of things,
    I actually come at this from a different angle. Whether or not I want explicit memory management is one of the deciding factors in language choice. I think OS and systems programming are best done with explicit memory management, because you often care about object lifetimes and it enables the powerful RAII pattern. In fact, the combination of well-defined scope (and destructors) with exceptions makes C++ uniquely suited to systems programming.

    Originally posted by GreatEmerald View Post
    try to decipher what all the custom templates and obscure modifiers for classes mean in others' code,
    whaaat?

    Originally posted by GreatEmerald View Post
    deal with dependency conflicts between header and source files etc.
    You know, the compiler and linker will check that, for you. But a lot of libraries are header-only, nowadays. I see the early binding of C++ as feature. Where the costs outweigh the benefits, maybe you ought to be using a different language.

    I'm not claiming that C++ is a perfect language. What I do claim is that, if you want a powerful language with the ability to get very low-level and have great runtime efficiency, I've yet to see anything surpass C++ sufficiently (and without compromises) to justify using it.

    Now, for your purposes, perhaps a better comparison would be D vs. Java or C#. When I don't need the efficiency, safety, and control that C++ provides, I prefer Python.

    Leave a comment:


  • RamblingMadMan
    replied
    Originally posted by GreatEmerald View Post
    And no, C++14 and stuff don't fix the issues, because they can't be fixed within C++ itself. First off it would have to drop the whole C baggage, rework the template system (and drop the old one), drop the concept of manually-created header files, rework the concept of immutability, implement a garbage collector and move away from pointers, etc. and that can't realistically be done without making a new language. What the new standards do is just cherry-picking some concepts from D and putting it on top of the whole beast that C++ has become over the years.
    All of those things (except maybe the whole header file include business/Pre-processor) are your opinion, you just want C++ to be D. Which it isn't. "Implement a garbage collector" is an especially bad argument and is actually invalid anyway because the standard has had support for garbage collection since C++11.

    Also, the C++ standardization committee does not "cherry-pick some concepts from D" to add to their language; they hold massive meetings and seminars to make decisions about what will be added based on proposals submitted by developers who actually use the language themselves. Even if an idea was inspired by some D feature, D probably didn't invent the idea in the first place.

    Originally posted by GreatEmerald View Post
    And at least for me the most important thing about D is that writing code in it feels good: the code is readable, you don't have to worry about memory management and stuff, and all kinds of different programming paradigms can be combined into a cohesive whole with a well-defined syntax.
    Don't blame your incomprehensible coding on the language. I've seen plenty of C++ code bases that are easily readable and self-documenting.
    I use functional and procedural syntax in most of my code and it is definitely "well-defined". The only valid argument here is that C++ gives you way too many ways to do the same thing, but to even a moderately skilled C++ developer they should be all recognizable.

    Originally posted by GreatEmerald View Post
    Meanwhile in C++ you have to wrestle with all kinds of incompatible syntaxes (how many ways there are to do malloc/free or access pointers?)
    How many ways are there to do it in D? Just because you can do it another way, doesn't mean you should. Most decent C++ code bases use new/new[] and delete/delete[] when they have to. Which is hardly ever, if ever.

    Originally posted by GreatEmerald View Post
    try to decipher what all the custom templates and obscure modifiers for classes mean in others' code
    I find D's template syntax infinitely more confusing than C++'s. The only problem I have with C++ templates is when you start getting too deep with SFINAE. But that shouldn't be needed in almost any case once concepts lite is finally added to the standard (I use it already with GCC6). Also, what do you mean by "modifiers"?

    deal with dependency conflicts between header and source files etc
    I really don't know what you mean by this. Care to elaborate?

    Originally posted by GreatEmerald View Post
    care about memory management for the simplest of things
    What makes you think you have to worry about memory management for the simplest of things? Most things are done in automatic storage. Even most complex things don't require you to bother with manual memory management. The only time you really have to do that is when interfacing with C code or doing low-level stuff, and even then you can just re-write your code using std::vector<char> or std::unique_ptr and interface with the pointers that they store.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by coder View Post
    You seem to be stuck in the mindset that programmers are a scarce resource. In a world of a billion coders, there's plenty of room for irrelevant and pointless projects. I see it as being like guys with machine tools building some weird contraption in their basement or shed, which some of the same people might've done like 40 years ago.
    Exactly that... it's like seeing a guy building his own car in his shed, and complaining that he should be labouring away in a GM factory instead... it misses the point that the guy is doing what he wants for fun. He's not accountable to random morons on the internet who think they know better than him about what he should do in his spare time.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by schmidtbag View Post
    Obviously, the people working on this have skill. But the way I see it, it's better to use that skill toward something everyone will benefit from or enjoy, rather than create something that will inevitably be abandoned some day. It just feels like a wasted effort on good manpower. There are other things you can code "for fun" that won't be completely overshadowed.
    But why should they care? Most projects like this are simply about having fun, not about finding the optimal use for "manpower". They're usually started by some guy who's just done a course on OS design at university, and wants to see what he can do with his knowledge. And there's no point in him working on an existing project, because all the interesting parts have already been done...

    Leave a comment:

Working...
X