Results 1 to 7 of 7

Thread: C++, Lua and Nim

  1. #1
    Member
    Join Date
    Mar 2018
    Location
    sun
    Posts
    33
    Thanks
    18
    Thanked 15 Times in 7 Posts

    C++, Lua and Nim

    Why do people see only C++ and then if it become too much, jump into another, completely different (but still) junk? How about C ? Its so much better, simpler, quicker and you can do pretty much anything with it. In fact I find it simpler than most scripting languages. Lua is a garbage, anything of bigger project and you loose track of what is what, because in Lua anything can be anything. I really tried hard but just cannot stand it. Also tried to hack ng ntop app code once because its developer did one absolutely stupid decision since original ntop, but I just kept getting lost in it precisely because of Lua - even after weeks. But I was able to understand lz4 code within 1-2 days, without IDE. I couldn't even understand my own C++ I wrote 10y ago so quick and I write very clean.

    So my experience after 20y is that Linus was right. C++ is outright stupid, Lua and pretty much all the rest of the scripting world is a junk I cannot stand, an excuse to C++ while ignoring C which is in fact simple enough to be either script(as a syntax) or full language and feel most natural and logical(to me). OO programing in general as it is today is an atrocity, "private" keyword inside C structure was all that was needed really if you needed that encapsulation, plus single generics - aka vector<> and/or 1-2 more and you really have all you need. There is a reason why Go is becoming popular, they tried hard to make that "next gen simple but advanced C" and for a reason, but IMO failed badly in many areas.

    BTW assuming Pascal is in fact meant "Delphi" in these modern times as many here and on fileforums use, I hold same opinion about it as I do about C++. Plus I totally hate its syntax but thats just my subjective opinion. There is still a lot that could be improved in C, but it does seem to me the best compromise. The only other thing useful would be JIT + multiplatform runtime like java, but with exact same C syntax and without crime atrocities of Java(aka OO).

    (sorry for rant, I needed to vent and feel better now)

  2. #2
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    Why Lua? Because it's used as extension language. You can add new program option, config file syntax or program feature in a day and share your extension with other program users. They can download and install exactly the features they need, without using C compiler. They don't need to become seasoned programmers to modify these extensions or make their own.

    Why C++ for core? Because I have the choice which C++ features to use. I use templates to avoid copy-paste, exceptions to make code clean, lambdas to define small functions at call place, vectors/*ptrs for automatic memory management. Even Lua integration with C++ library has more high-level syntax.

    I wrote FreeArc in very high-level language, Haskell, and fa'next in C++14. Later I rewrote half of fa'next in Lua, leaving only complex core code in C++. Now I think about migrating C++ code to Nim, it's really fascinating language that avoids complexities of modern C++ while still providing similar set of features and even more (in particular GC for objects/collections, full-featured compile-time code execution and AST analysis/generation)
    Last edited by Bulat Ziganshin; 5th July 2018 at 18:28.

  3. #3
    Member
    Join Date
    Mar 2018
    Location
    sun
    Posts
    33
    Thanks
    18
    Thanked 15 Times in 7 Posts
    Why Lua? Because it's used as extension language.
    I know. Its also used a lot in games for scripting. However, my experience was very negative despite fact it was used only as a complementary tool. Maybe because it was used as a part of web project in conjuction with JS and html who knows, but still. I still dont like its too lax syntax though, language where you cannot even differentiate between variable and function and danger of returning unexpected results with certain scenarios is just so wrong to me. But I agree for a simple user scripting its probably solid. I still like your methods chaining in original FA, arc.ini, groups syntax and the way you implemented it all there. More than lua.

    Why C++ for core? Because I have the choice which C++ features to use.
    True. Unfortunately way too many go overboard for the sake of it. Even I did back then. Cherry on the top was when I saw the code of a simple files modifier program for a certain game. Its task was literally just changing some data in files based on GUI options. My god, his code was... incredible. I understood his every C++ keyword/line but as a an overall functionality, I was never been able to figure it out. Even knowing what to look for. He abstracted and subclassed every single thing including file writing operations. Code itself was a piece of art, perfectly textbook written, I even felt he used every single C++ feature for good reason and very well implemented.
    Nonetheless fact remain that it was a simple file modifying app and written so complex I just gave up - that tells you all you need to know about whole C++/OO stuff. People just don't know when to stop.

    BTW I quickly checked on Nim just for curiosity, thanks for the tip. But no, its another wreck to my hate list. Things like 'let', 'var' etc not to mention atrocious pascal like syntax...
    "var x, y: int"
    Really? Why not just "int x, y;" for lord's sake. Meh.

    Now I think about migrating...
    Again? You seem to be switching a lot Bulat, Haskell > C++ > Lua > Nim >... nothing wrong with that of course. But maybe try gnu C, not C++ but real C with C compiler and see how much you actually miss all that extra junk, especially after you revisit the code years later.

    Cheers ^_^

  4. #4
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    NOTE: this entire thread a few days later will be cutted-off and moved into offtopic area

    let's compare some C++ and Nim code:

    C++:
    int x, *y;
    auto z = &x;
    const auto t = &x;
    typedef int ty[10];
    template <int N, class T> typedef T typ[N];

    Nim:
    var x: int, y: ptr int
    var z = addr x
    let t = addr x
    type ty = array[0..9,int]
    type typ[N:static[int];T] = array[0..N-1,T]

    Each var type is sequentially written rather than cumbersome combination of modifiers enumerated in mysterious order. Auto/const declarations are as terse as in C++, and auto+const declarations are even shorter. Each var/const/type declaration is started with explicit specifier "var/let/type" followed by the declared object name, rather than f.e. any of "typedef/using/struct/class/template" with a name of declared entity in arbitrary place for C++ type declaration. Going further:

    C++: f(x); f(x,y); f(std::make_tuple(x,y));

    Nim: f(x); f(x,y); f((x,y))
    or: f x; f x,y; f (x,y)
    or: x.f(); x.f(y); (x,y).f()

    Now you see that "f x,y" syntax in Nim was simply stolen by the more frequent function call operations

  5. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    elit (6th July 2018)

  6. #5
    Member
    Join Date
    Mar 2018
    Location
    sun
    Posts
    33
    Thanks
    18
    Thanked 15 Times in 7 Posts
    Thanks for examples Bulat and I apologize for going off topic here. Frankly, every single part of your example I find C++ far better, cleaner, just right amount expressiveness and more logical(to me). I did not prefer Nim in any of your examples except maybe tuple and even then it come down to whether one prefer (()) vs function call(make_tuple). And C doesn't even have that if I recall so even better, I have yet to find myself in any situation where I cannot write elegant enough code without all that stuff.
    Now regarding C++ vs Nim, (()) is better but only if language does not use it for other constructs as well and even then it may be overseen for simply double bracing encapsulation. With function call you will always see immediately what you did. However one thing I already dislike in Nim regarding your tuple example is that it already allow 3 different syntaxes for the same thing. I always despise this, and especially your 3rd one is confusing at best. Programmers then have to learn several different things just for the same outcome(because we also want to understand other peoples code right?) - aka non productive and useless extra filler.

    Now regarding '*' and '&' vs more wordy constructs, normally I prefer clear definition so perhaps I am at bias here because I have those chars well embedded in my brain. Maybe as a newcomer I would prefer Nim syntax, after all it is closer to old Visual Basic which was my first lang. However, those are literally 2 chars, in C/C++ have a well defined meaning and overall its not like Perl where it really go ever board with all those chars and shortcuts. C/C++ is thus I guess somewhere in the middle between most and least expressive languages in that regard and again I find it just right. That said if there is one thing that I thing Nim and many other langs do better than C++ is a 'var' vs 'auto' keywords, 'var' do sound more appropriate to me.
    Regards

  7. #6
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    Algol-style C/C++ declaration syntax is shorter for simple cases, but with const/auto it's at least as long. And with more complex types, it quickly goes mad:

    C++:
    void f (int &(*a)[10])
    void (int &(*g)[10])()

    Nim:
    proc f(a: ref vec[10,ptr int]): void
    proc g(): ref vec[10,ptr int]

    In C++, I can decipher f declaration, but it requires to strain the brains. In Nim, it's easy as 1-2-3. And I don't even have an idea how to declare g in C++, and in real programs I just use typedef for return type. Nim syntax is readable even for newcomers, except for difference between ptr (raw pointer) and ref (smart GC-collected pointer, sort of shared ptr). And with actual use of shared ptr C++ isn't much more readable:

    void f (shared_ptr <(int*)[10]> a)

    Yeah, after 30 years of C/C++ I still struggle with use of such simple types!



    Now about expressions. Look at this Nim code:

    printf "%d is %s", 42, "number"

    Compared to C++, you omitted syntax clutter of "();". OTOH, when you have more complex expressions, you can use parentheses to explicitly specify where are arguments for each function. So all you need to remember is that you can omit parentheses in function call.

    Now, imagine you wrote functions to filter and sort data. Here how you need to use them together in C++ vs Nim:

    sort( filter(vec, [](int n) {return n%2;}),
    [](int x,int y) {return x<y;})

    vec.filter(proc (n:int) = n%2)
    .sort(proc (x,y:int) = x<y)

    So, the third syntax allows to chain-call global functions. This feature is already proposed (but not accepted) to the C++ standard. Current C++ also supports this syntax, but it's applicable only to class member functions. Moreover, using Boost.Range or Rangev3 (just accepted into C++20), you can have this feature with yet another syntax:

    vec
    |> filter ([](int n) {return n%2;})
    |> sort ([](int x,int y) {return x<y;})

    Again, C++ has more syntax clutter than Nim. And actually, it doesn't automagically work with filter(vec,predicate) function you defined, you need to declare your filter overload in the special way just to be used with "|>" operators.

    One more example from my real code:

    std::thread reading_thread ([&] {handle ("Reading_PROCESS", [&]{Reading_PROCESS();});});



    Finally, I given tuple example only to show difference between "f(x,y)" and "f (x,y)" code - for me, it looks like the most controversial decision in Nim. I agree that "var" is better than "auto" (you know that auto is used only due to backward compatibility with 1970s C), and OTOH I will prefer to see "const" instead of "let" in Nim.

  8. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    elit (6th July 2018)

  9. #7
    Member
    Join Date
    Mar 2018
    Location
    sun
    Posts
    33
    Thanks
    18
    Thanked 15 Times in 7 Posts
    Thanks for moving the thread as well as your last examples Bulat. Keep in mind that good 90%+ of code in any language will not be like this, it will be simple basic syntax lines(declarations, functions etc..). So when you have an overly verbose language that mean you are going to type all that filler 90%+ of time just to save maybe at ~10%(at most) places where it *may* give more clarity. That is not a good trade to me. If I write 90% time basic stuff like "int a,b; f(a, b); struct{...}" then I want language that make precisely these parts as effective as possible. But I also don't want type lax langs where you dont need to specify type such as int because such language is already hell in bigger projects. I also need language that doesn't let me confuse function for variable therefore function syntax must be clear defined and also for calling not just declaration. That is why I cannot stand languages that allow you to call function without (), such as lua, or Nim in your example above. I find your Nim's printf to be bad language design precisely because of that so I guess we will maintain different opinion on this one.

    I agree partially with your first 2 lines example, especially second line is much better to figure out in Nim. However I find first one good enough in C++ as well(here I am sure biased, as a newcomer I probably wouldn't). Curiously, then I found your C++ "shared_ptr" example very clear and easy to understand. Its basically a function 'f' having parameter 'a' which is shared_ptr array(or so I think, I haven't looked into it), very clear to me and I in fact like the idea to know immediately that I am dealing with generics.

    printf as already stated I disagree strongly here, omitting braces in functions is a bad design IMO. It may not be seen with printf but I guarantee you with custom functions it become hell, because they may have a name that may not give out its context of what it actually is. I had this self experienced with lua when deciphering someone's else code so I know.

    Your sort functions may be a little bit too much, most people will not(and should not) write that compressed. I am sure this could be written in much more streamlined and cleaner way, yes it will take more lines/verbosity/different approach but so what. Yes Nim is in fact much better here, but again we talk about ~10% of code. I will rather take C where i get not irritated oververbosing 90% of the code, language that will never confuse me by laxed design(aka omiting () in functions etc..) or automatic types and I will write those 10% lines in more basic and verbosed form but clean and not convoluted.

    As for C++ (20) though, indeed I fully agree with you here, its becoming outright retarded. Thats why I recommend C not C++.
    Best regards

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •