>>13850 >look at this ruffle code That's a fast and well optimized DoS resistant hash function (1). While it's not the same, you can find similar assembly with a sip hash in C at -03 (2, hashmap_sip). Ruffle is slow because it's a proof of concept and not feature complete, it says so in the readme (3). I'm not sure why you have a problem with stack pointers, is it panic unwinding the call stack? You can disable that for embedded programming (4). If you would like to learn panic-free Rust, I found a neat guide that was written for you (5). (1) https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#Speed (2) https://github.com/tidwall/hashmap.c (3) https://github.com/ruffle-rs/ruffle#project-status (4) https://docs.rust-embedded.org/embedonomicon/smallest-no-std.html (5) https://docs.opentitan.org/doc/ug/rust_for_c/

>>13877 I'm another anon. I barely know anything about that stuff. I wonder what you think of other languages compiling to C. I recall some version of Scheme doing that and I also Dylan: http://www.cs.cmu.edu/~gwydion/dylan-release/docs/htdocs/d2c.html I always wondered how good the code of such languages is and how hard it would be to update their behavior to create better code.

>>13883 why would you compile to c? you wouldnt get any performance benefit since the problem is the way the code is written, heavily abstracted languages just dont translate well compared to c, you cant just rip out the abstraction unless you were coding without it in the first place, just look at c--, its basically c yet c-- is almost always slower than c, only because idiomatic c-- is stupidly more abstract and the retard oop mentality promotes an inefficient way to write code, translating those abstractions like oop into procedural code ( which is the only real way a computer works ) is inevitably going to produce inefficiency and bloat you can still optimize with c in another language though, most languages have ways to call external c functions precisely for optimization, just look up "c call in (language)" people usually just write performance critical code in c, compile to an object file or shared library, and call it from from inside the program, python scripts do this all the time because of how slow python is you could probably go further with the optimization, I know c and c-- have inline assembly too, so you can optimize on the hardware, I dont know every language but I assume other languages would have this too or at least a way to link a custom object file during compilation or with a shared library

>>13884 >you wouldnt get any performance benefit since the problem is the way the code is written What?!? Benefit compared to what? Do you honestly believe compiling some high level language code into C doesn't make the resulting code faster? If so, then I'd like to see some sources. >you cant just rip out the abstraction unless you were coding without it in the first place You lack fantasy and I'm sure this is wrong.

>>13887 Why not use Java?

>>13887 do you not know how a compiler works, all compilers just compile to assembly, theres nothing special about the c compiler its only better at optimizing only because c code is way more explicit and deterministic with the least abstraction from assembly, your giving the compiler so much information to work with that theres little guessing for the compiler, thats all code is, youre just instructing the compiler what you want to do and it figures out the assembly for it and optimizes it, the c compiler just demands more for less, higher languages do the opposite more abstraction, more implicity and less code, its easier to write but the compiler has more guesswork to fill in the blanks and figure out what youre trying to do compilers for high level languages are already specialized around optimizing implicities and the guesswork required, trying to compile an abstract language to c is just as difficult as trying to compile it to assembly, your not going to outperform the regular compiler unless you actually rewrite abstract code to be less abstract and less implicit, the only way to do that is to just use a more expressive language

>>13900 You're comparing coding in C to compiling from some language into C. That wasn't the question. Let me in peace with your nonsense. No one will write everything in C. That's is even dumber than writing everything in C++. This might be a sabotage attempt and if so, it will not succeed. We generally need no flameware on languages here. This thread should be about languages and their use case. Righ tool for the job and so on. For most of us it's going to be Python and maybe some variant of Lisp and specialized languages for specific use cases. I know that programs written C, C++ and other languages can be embedded into high level code or being called by other programs, which is exactly why I won't write in any of this till I need it. Then there might be languages which compile down to C, machine code or bytecode, whatever. Case closed, goodbye

>>13906 Yeah it's enough, I wrote that already. Im even not going to read this. The question in >>13883 is still open, but you're not willing or capable to answer it. And I don't need it answered here. You're just picking fights fot trolling. Should be moved to the basement later.

GraphQL is a query lanuage, it might be interesting for creating APIs between different internal databases. It seems to be popular with the web crowd and it's open source. https://youtu.be/8l7TxqWI1XA - It helps clients to only aks for specific data and get that, especially useful if data comes from different sources.

>>13923 The other language I'd like to bring to your attention is Grakn: https://en.m.wikipedia.org/wiki/GRAKN.AI >Grakn is an open-source, distributed knowledge graph database for knowledge-oriented systems. It is an evolution of the relational database for highly interconnected data as it provides a concept-level schema that fully implements the Entity-Relationship (ER) model. However, Grakn’s schema is a type system that implements the principles of knowledge representation and reasoning. This enables Grakn's declarative query language, Graql (Grakn’s reasoning and analytics query language), to provide a more expressive modelling language and the ability to perform deductive reasoning over large amounts of complex data. Effectively, Grakn is a knowledge base for artificial intelligence and cognitive computing systems.

>>10565 >Fast AI, Python, Swift >>13539 >Rust >>13826 >Haskell >>13883 >Scheme, other Lisps, Dylan >>13923 >GraphQL >>13926 >Grakn Ignore the trolling. Stay focused. Use the best tool for each job or the one you get along with.

>>13958 more like an inflatable hammer it looks solid and shinny, it looks useful, you start thinking about all the things you could build using that hammer then you pick it up and realize its just full of air and utterly useless

My apologies for writing all the software stuff in the math thread off topic. I was looking at random comments and came into that thread where someone was discussing something related to software and I got carried away not realizing the actual topic at hand. I've done this before not knowing about the headings. But I really don't have a good excuse this time. I didn't check the subject header when I responded. Should have. I'll try to to check this in the future.

>>20938 No worries m80. At this point in time, I'm convinced it's literally impossible not to do so within this forum format, by any practical means. As mentioned to NoidoDev, we'll investigate creating a 'janny-bot' that can migrate off-topic posts in a relatively painless manner. Until then, I'll just stay angry at Stephen Lynx for not providing such management with his software. :^) I'll migrate our convo here shortly. >=== -minor edit

>>20629 >I can already see this wll be harder than origninally thought. Yes, it will be. That's how it always goes! Thanks, Murphy!! :^) >I think you will almost have to learn C to do this. Yes, you will. >I've been downloading books to do this. I have made a couple of C programs and I really hate this stuff. Programming is something that, to me, is satisfying "after" you finish but a real pain in the ass while you are doing it. This. BTW you are exactly the kind of target-audience, for which I'm taking such tedious pains to create a programming class for all of us here on /robowaifu/ using C++ & C (>>19777). Neither language is really intended for beginners, but both are absolutely our best choices today for driving the low-level behavior of robowaifus IRL (for numerous reasons). Hey, if this was easy, then everyone would be doing it, right? :^) It's kind of a matter of 'just how much do you want this?', Anon. You can simply wait around until someone else does it open-sauce, or you can wait and swallop what the Globohomo has in store for you, or you can dig your feet in, work hard, and do it yourself. I'd personally recommend you do it yourself, since it's your best bet in the end. Finishing that C++ classroom here will put you waaay down along that road! (Please pardon me Grommet, I mean you no discourtesy personally; I'm simply using you as the general example-case here. :^) The technology of the near-term timeframe (some of which we're inventing right here) absolutely will support creating basic robowaifus by using clever design work. But it's going to be a long haul up that mountain, Anon. Best to get your climbing gear in order here & now! :^)

>C++ & C I looked at the link and found Bjarne Stroustrup "Programming Principles and Practice Using C++", but what edition? I see one and two. Will it tell me where to get a free compiler for windows? I downloaded some other books C programming_ absolute beginner's guide (2016_2014) by Miller, Dean_Perry, Greg M Learn C Programming - A beginner’s guide to learning the most powerful and general-purpose programming language with ease(2022) by Jeff Szuhay C Programming: A Modern Approach, 2nd Edition by K. N. King Beginning C: From Novice to Professional by Ivor Horton All had good reviews I think in order from best to not as good. I'm looking at the first part of your learning textbook thread and an already thinking of throwing up blood. I hate programming but I just do not know a way around it. I've looked at all sorts of programming languages and learned a good deal about them but in the end...I never had a task that I really had to learn a new language to deal with it and as soon as I started I would say, this is waste of time and I refuse to go through all this pain for nothing. I took FORTRAN ages ago. I once spent about 5 hours on a program that would not compile because...I had one too many spaces in the left margin. The teachers assistant and I spent hours on this. It left a very bad taste in my mouth. NoidoDev ##eCt7e4 mentioned Nim. I looked at that a lot. I was impressed that someone used it to make a Rebol, another language, like clone (called Ni then Spry) with a very few lines of code and I assume meta-programming. I think Nim will compile to RISCV. Now I do not know the mechanics of making this happen but programming languages with meta programming like LISP, Rebol, Red Programming Language and Nim can do almost super human task with little tiny snippets of code that can evolve and reprogram themselves. You don't have to be a programmer to see how useful that can be. We are using limited memory and need to rapidly change things. Of course with that flexibility I'm SURE comes, complexity and serious trouble setting up the code in the first place. I do tend to be wordy. The reason is people complain I don't explain enough if I don't and of course they complain if I do so...oh well. What I'm doing lately is thinking out loud about possibilities. Hoping others will look at what I found and maybe help decide what is the most efficient, least painful way to do what we need. I'm not smart enough to judge some of this stuff but if I point it out maybe someone will come along who is.

>>20948 >Neither language is really intended for beginners, but both are absolutely our best choices today for driving the low-level behavior of robowaifus It's very unfortunate but C is everywhere and on anything you can buy. Have you ever read that article on the New Jersey style programming vs MIT style? I bet you have. C is just good enough to patch something together. It's like VHS vs Betamax. The cheap knock off wins.

>>20949 >I looked at the link and found Bjarne Stroustrup "Programming Principles and Practice Using C++", but what edition? I see one and two. 2nd Edition. It's usually just called "PPP2" on the Internet. >Will it tell me where to get a free compiler for windows? We'll be using the online C++ compiler Coliru for the first few chapters for homework checkins, by default. https://coliru.stacked-crooked.com/ There many reasons to use C++ for our robowaifu's systems-engineering today. You'll probably understand why better as we go along with the class. I guess for now I'd just ask you to 'trust me on this, bro!' heh. :^) One nice comment by Anon was about our realtime processing performance needs, and why Python will not work (at all) as a systems language (>>20852). There are several other possibilities for a systems language, but C++ is our best choice overall, among every one of these. Haha, please don't worry about what any of us thinks Grommet, 'complain' away! It really helps all of us to get on the same page with fewer opportunities for misunderstandings. When you're dealing with highly-complex systems (and we are here), it can become vital to be extremely clear on things. Nice posts Anon. Cheers :^)

>>20870 >New Jersey style programming vs MIT style As a mild-rebuttal to that basic premise, I offer you file-related. > The exact reason that "The cheap knock off wins." is exactly that; it's cheap. Cheap on hardware resource requirement, cheap on performance-runtime requirements. >tl;dr There is, roughly-speaking, a near-linear inverse correlation between ease-of-apprehension, and efficient systems (particularly as concerns wall-clock perf). ASM is by far the closest language to the machine itself, and therefore highly-efficient (both in time & space). Arguably C is the next rung up the ladder and has been called 'portable assembler'. But it offers no real mechanism for abstraction, which is an absolutely essential feature for devising systems as big as the ones needed in real robowaifus. Next rung up is C++, which does bring abstraction to the table. A kind of an 'object-oriented assembly language'. This -- while it may make you want to puke -- is the primary rung we're standing on for this project (with some work on the two rungs just below). I hope you brought a few barf-bags Anon, cause it's gonna be a bumpy ride. :^) --- >Addendum We will be using Python (or, possibly, Lua as an alternative) for enabling Anon at home to piece together scripts for his robowaifus to use. Similar to the way Python is used broadly in AI today to script the backend runtime-engines written (often) in C++. So don't worry if you have to fall out of the C++ Learning class Anon. Please bring your other skills to bear on the hardware side of the table for us all here! BTW, this big programming chore is only hard for us here because we're the trailblazers, the frontiersmen. Someone has to do it, after all. However, much like the advance of civilization, the ones to come along afterwards will have a much easier time of things. You can just lay back and be comfy in that group after a few years, if you choose to instead Anon. :^) >=== -add addendum

Program the ESP32 using Nim! https://github.com/elcritch/nesper I wonder if something like this might suit me better? Not that I know. There's no doubt C++ is the 1,000 pound megabeast that does everything at lightening speed. I do not question it's utility. I worry because I always hear that it has so much to it that it's impossible to learn. That even people who have years of experience never learn it all. A labyrinth of mirrors I was looking at the above link and even it's complexity was giving me a headache. It seems that C and C+++ are all some mutating glob where you can never count on the include files or headers to be the same anywhere. I might be better off just hacking the ESP32 and learning only the stuff I need as I go. I think there's just too much.

I've been looking at Nim videos and the more I learn about Nim, the better it sounds. For those interested in a fast programming language that is set up like python to be easy to understand and then can compile to C, has macros for abstraction and is super fast, and also has libraries for ESP32 and other micro-controllers, Nim sounds SO GOOD. Here's a good video from someone who made a library linking Nim to Arduino programming. https://www.youtube.com/watch?v=0dt3icPj8Kk The problem with C++ is it's just to damn much to learn and to me it appears to be a big disjointed thing. Chobitsu don't take this the wrong way but could you be falling into the "I'm a real man" trap? Like someone who needs a tree cut down and instead of using a chain saw he uses and axe because,"he's a real man". What if using Nim you could be...50% more productive? The numbers could higher. And what if instead of churning away at C++ you could add to the existing libraries like the one in the video? Though it's not real test, I've heard all sorts of damning of C++ but I've never seen anyone damn Nim. Some have said it was not for them but I haven't seen any real damnation like you can find for C++. I read the article on why bad is good and I agree that it is good but for a very limited time because if the bad hangs around then in order to massage all it's faults, people pile more bad upon the bad until you have a huge ball of bad that ties you into a knot. php I'm told s a good example of this sort of thing. And just to throw further fuel on the fire to see if it will flare up really high. https://sites.radford.edu/~ibarland/Manifestoes/whyC++isBad.shtml

In the the math thread I wrote about Nim. It seems ideal. The creator has specifically designed it to work with 8 bit on up . So it's set up to be used with micro-controllers. People have built libraries to ease the transition. Micro-controllers will undoubtedly be used in large amounts in waifus because nothing else can so cheaply control a lot of actuators AND has built in sensor pins. MC's are explicitly designed for these type task. It's cheaper, and less work, to string a mass of these together than it is to build one off boards to control actuators and read sensors. Most of these run about $9 or so in quantity. Maybe more with more options. Rough calculations show that using about 20 of them would be good enough to control all the actuators for a robowaifu. The goal of Nim is so aligned with the hardware of robowaifus it's as if he were making it for us. He noticed a gap where python is really easy to learn compared to C++ but it was slow. He also noticed the really productive stuff like LISP and it's variants, scheme, Racket, were very productive but didn't necessarily have compilers for many different processors. So he created a python oriented syntax for ease of learning that compiles to C or JavaScript to add functionality for all processors and for browsers and the vast JavaScript infrastructure. On top of this he added meta programming as in LISP. It seems idea. Showing how Nim can be used for micro-controllers is a set of videos. One I linked before Next generation micro-controller programming "Zero-cost abstractions for better embedded programming" https://www.youtube.com/watch?v=0dt3icPj8Kk The guy above Peter Munch-Ellingsen has a large number of micro-controller videos where he wrote his own code for his keyboard and used his own micro-controllers to do so with Nim. Now a waifu is not a keyboard but it might show some of the actions needed. Look at the video above and see how super small the Nim examples complies to compared to several other micro-controller languages he used. It a big difference and we need every byte. There's also the idea that the smaller the code, roughly, the faster it runs because it keeps it's code in the MC's fast internal memory where it belongs not losing speed to interfacing with slower memory. I "percieve", may be wrong that one reason that no matter how fast our processors become they never increase the speed of the software on our computers is they pile all these massive frameworks with the kitchen sink ion them. This stuff will not fit in the processors cache memory so it;s always going to main memory dragging it down to PCI bus speeds. Way slower. However if you use meta programming techniques the software can all fit in cache and even if it takes more instructions they all stay in the cache operating thousands of times faster. Nim I believe would allow us to do this. In the video above it says,"Zero-cost abstractions for better embedded programming". So I think he is doing exactly that. There's videos n using meta-programming like LISP for Nim. A good trick to finding and super rapidly downloading these videos is to go to this address. https://yt5s.com/en163 You put in the address of a youtube video and enter it. You can then download it through them by some magic I don't understand. What I do know is it seems to be about at least ten times faster. Another tip is you can search in the above search box. It doesn't give all the links nor many of them but once you find a subject header or a name of a youtube uploader the you can use that subject or the name of the uploader to search and find more videos. A couple of good searches. Nim Programming Language Peter Munch-Ellingsen PMunch Another interesting video talking about meta programming on micro-controllers with Nim "Optimising for Humans - Nim meta-programming for 0-cost abstraction on microcontrollers" https://www.youtube.com/watch?v=j0fUqdYC71k Summation. Chobitsu has said, rightly, that abstraction, which I read as related to meta-programming like LISP, as hugely important to writing good code. I'm not a software engineer but I do get the idea in a rough way and see that it's good. What I rebel against is using C+++ when we have other tools, Nim, that can do just the same. And even if it does not have as many libraries Nim has what are supposed to be several tools to wrap or, another process I do not understand, rewrite the headers(I think) so that the C or C++ libraries are incorporated into your Nim program. Another good video "Nim Metaprogramming in the Real World" https://www.youtube.com/watch?v=yu6SC2vd3qM

Some interesting libraries for Nim futhark Automatic wrapping of C headers in Nim "...Futhark aims to allow you to simply import C header files directly into Nim, and allow you to use them like you would from C without any manual intervention..." https://github.com/PMunch/futhark The same guy has several good libraries https://github.com/PMunch Ratel Next-generation, zero-cost abstraction microconroller programming in Nim(meta-programming???) https://github.com/PMunch/ratel Nesper Program the ESP32 using Nim! https://github.com/elcritch/nesper Note in the above libraries read me,"...Nim now has support for FreeRTOS & LwIP..." So Nim has support for one of the major real time OS needed for micro-controllers, FreeRTOS. I believe the "micro robot operating system" can be used on top of the FreeRTOS. So there's a large amount of code already written for just what we need. https://micro.ros.org/ I suspect, but do not know, that the microROS will work with the larger Robot Operating System, https://www.ros.org/ which even has simulation software, ROS which can be used with larger faster processors. So higher level stuff can be done by the more powerful processor while the microOS runs the micro-controllers. While I'm sure all this is a huge mass of complexity I'm fairly sure it will be faster and easier than writing the whole conglomeration ourselves. Binding to C Libraries with Nim https://gist.github.com/zacharycarter/846869eb3423e20af04dea226b65c18f Nim Wrapping C http://goran.krampe.se/2014/10/16/nim-wrapping-c/ c2nim c2nim is a tool to translate ANSI C code to Nim https://github.com/nim-lang/c2nim I think, though foar form sure, that while Nimmay have some roguh edges in terms of library support for our specific case, if some of the better C and C++ programmers would tidy up the libraries made already for Nim this time would accelerate the programming for everyone and raise all of our productivity towards the goal.

>>20956 >>20958 >>20959 Great research work, Grommet. This post is just a quick note to let you know I've seen your posts. Now that I've moved the conversation, I'll respond to you more properly before too long.

The processor mentioned in the video I linked, "Optimising for Humans - Nim meta-programming for 0-cost abstraction on microcontrollers" ESP8266 is a older version that is now the ESP32, which I'm always talking about, which is much more powerful. The older ESP8266 could probably be used for actuators and save a great deal of money. They are super cheap. You can get six of these for $19 so roughly $3 a piece.

Above video link Nim FASTER than C++!

OK, Grommet. I'm going to delay a fuller discussion of compiling Nim for our robowaifu's microcontrollers until this weekend (hopefully). However, you're still going to need to know C if you want to do this at a pro-level -- even using Nim. There is only one book to recommend: K&R 2e > You'll be learning the C89 standard of the language. https://en.wikipedia.org/wiki/ANSI_C#C89

Arguing about programming languages misses the point. The hard part is coming up with the algorithms and ML systems needed to run the robowaifu, not writing the code itself. Thus the choice of programming language is largely irrelevant.

Youtube video LISP_ Lex Fridman's favorite programming language @2:10 "...Development of programs on LISP proceeds at, I think, at somewhere between a thousand and fifty thousand times faster..." LISP of any sort will not be on our micro-controllers but Nim will be and it can be used in a similar way.

>>20982 >the choice of programming language is largely irrelevant This is only true for already successful programmers that have a good feel for the subject but those that do not and have no inclination to be programmers the choice of tools is important. How many years does it take to become a proficient programmer, lots.

More like which programming language you would like the waifu to suit you best. What would suit the robowaifu best is python.

First off Grommet, let me thank you again for all your hard work gathering information together on Nim for us here. Great job, and you've made a good case for your position. But rather than leave you in suspense let me just cut right to the chase: There is no way that I'm not using C++ as the primary systems-programming language for this project. There, I said it. :^) Simply put, C++ by far represents our current best-bet for overall success devising real-world robowaifus. Hands-down. I wouldn't seriously think for a moment about walking away from that abundant blessing that has been dropped right into our collective laps. C & C++ are two of the most 'banged-on' programming languages out there and together represent the vast majority of systems-oriented projects in the world. There is also a big heap of applications solutions using them too. The ISO C++ Committee once did a short-list roundup during a Language Evolution Working Group meeting a few years back, and just in that room alone (with ~10 men present) the lines of code they collectively represented as leaders in their respective institutions was over 5 billion lines of working, production C++ code out in the industry. Let that sink in for a minute. And its bigger today. Also, Bjarne Stroustrup compiled a (no longer maintained) list of notable C++ projects out there. You may recognize a few of them (and I also have a good number -- for example, all BMW cars -- which are not on his listing): https://stroustrup.com/applications.html While no language is perfect, C++ brings more power and flexibility to the table, with an amazing array of libraries available to pull from, with more maturity and field-proven capability, than any other programming language. C is also a great language in these regards, but we absolutely need good support for abstractions in the vast majority of the code we're going to devise while developing our robowaifu's systems. Also, there is an abundance of C++ developers around the world, and some are doing quite remarkable work. That is a great potential talent pool for /robowaifu/ to draw from. While not an unavoidably-critical item, it's certainly an important one to consider. I don't mean to be a dick about it Anon, but quite frankly you're basically wasting your time in trying to convince me to use any other language for this project's systems code work. With humility, I claim that there is literally no better option available to us in existence, at this point in time, for that arena. --- OTOH, since the author of Nim very wisely devised a transpiler-based approach for his language, and since it has both C & C++ code-generation facilities, then I think we can with good conscience use it as a sort of 'scripting language' to create code files that can afterwards be compiled in the traditional manner with traditional toolchains into binary executables for our robowaifu's microcontrollers, sensors, and other smol devices onboard. Thus I'd approve of (and even recommend) you pursuing learning Nim on your own for just this purpose. However, you're still going to need to be able to write C to implement this process effectively & professionally. (>>20980) C++ (and C) syntax may make your eyes want to bleed, but it is what it is. Syntax is something you get used to (once you begin applying yourself to learning it). It's the algorithms that are the difficult part. Great libraries can go a long way, but our devs here are all going to have to be very clever, regardless. Please always keep in mind that everything we are doing here -- and especially in their sum-total combination -- is groundbreaking. We're striving for something that literally is on the edge of what's even possible ATM. Almost everything here is going to prove difficult until we have in fact finally succeeded at doing it. You just have to resign yourself to that situation going in. There really are no shortcuts here Grommet. As this Anon stated: >"The hard part is coming up with the algorithms and ML systems needed to run the robowaifu, not writing the code itself. Thus the choice of programming language is largely irrelevant." (>>20982) While he's a bit off-target (since efficiency in both time & space is critical for our specific domain), he's fundamentally correct overall. Thanks for reading my blogpost, Anon. Godspeed to us all! Cheers. :^) >=== -prose edit

It's exhausting to see all these bizarre literally-who languages anons have suggested. A stack consisting of C / C++ / Python is reliable, mature, has an unfathomable wealth of material to draw from, and covers every conceivable use case from metal to meta. Language-of-the-month debutantes need not apply. Learning C is not the herculean task some people are making it out to be. New programmers balking at this and running back to the shallow end is detrimental to the art and industry overall IMHO. That said, the info presented on Nim is really interesting - and I'd agree with Chobitsu that it could be a useful /supplemental/ tool.

>>21072 >It's exhausting to see all these bizarre literally-who languages anons have suggested HAHAHA I get that. I really do. My perspective is that what ever I learn I will have to do so from scratch so using something that is more flexible and easier to use is better. Whatever happened to the "worse is better", oh that doesn't count when it's C++...right... :) (not meant to be offensive) In the end I'm just thinking out loud. it helps sometimes to write things down and get feedback. I may have to learn some C but if it can at all be avoided I will not crack a book on C++. Most anyone who is a well respected programmer has said it's an abomination, yet they also say they use it, just because it's so widespread and has so many tools. I've been looking at interviews with programmers on Lex Freidman's youtube channel and he ask them what's the best language. They say scheme which any and all good programmers say you should learn because it will teach you good programming. Specifically from this, "Structure and Interpretation of Computer Programs" But not for actual work because it's so malleable that it can be hard to understand after you write it. They do say C and C++ for production but not because they like it. It's because they are working on large teams and they have to have something everyone understands and can use. I think Nim might be good enough and any libraries you need seem to be able to be wrapped or imported into it. >>Learning C is not the herculean task some people are making it out to be. C++ is a different story though. I've actually programmed two programs in C a long time ago illustrating Fourier transforms to make square waves from sine waves and display them. It was no worse than FORTRAN.

>>21076 If your position is to use C / [Nim] / Python, then i think we may have some common ground at least. >Most anyone who is a well respected programmer has said it's an abomination, yet they also say they use it, just because it's so widespread and has so many tools This really gets to the heart of it. Perceived 'ugliness' will *always* be secondary to momentum and availability. The Waifu project is already starting from scratch (or nearly so) in so many areas. There is so much invention/innovation that has to be done - *in tangible real-world space* - that delving into novel languages will only compound the work required. But if you have to deviate, then doing so in a way that can transpile to the lingua franca is alright I suppose.

>>21072 >>21078 Hello Anon, welcome! Thanks for your great insight, and I'm completely onboard with your 3-layer stack. We may find ourselves needing ASM as well possibly, but hopefully not. BTW, you seem like you may have a good bit of experience with C development. If so, then we'd sure appreciate that tired old man perspective within our C++ Learning class (>>19777). Cheers. >>21076 Excellent. Glad to hear you're apparently open to using C, Grommet. Looking forward to seeing how you use Nim alongside it, too. It's all gonna be gud! :^)

>>21072 >A stack consisting of C / C++ / Python i Personally I don't plan to write anything in C or C++, especially not in the latter. Anything more than a wrapper, if it needs to be fast, I'll use one either NIM or some kind of Lisp. I have no patience to read through some complex code for no reason or to write it. Therefore, if other people write the programs in C/C++ and these are then constrained inside the system, I might use them. If I can't trust them based on the access they have and don't want to read through the code, then not. > Language-of-the-month debutantes need not apply. Nim and Lisp existed for a long time.

>>21088 >If I can't trust them based on the access they have and don't want to read through the code, then not. Heh, then you'd better get your thinking-cap on Anon. :^) Because systems-level code has access to practically everything in the whole system, roughly by definition. That's what it's there for; it's the 'glue' that binds everything else together, the foundation upon which everything else stands. You can think of it vaguely like the Operating System inside your robowaifu. And it's gonna be fairly YUGE (and remarkably complex) in the end -- which is exactly why we need/use C++'s abstraction mechanisms for writing it with; to greatly-simplify the problemspace developers have to comprehend at any particular nexus into the overall robowaifu ecosystem, which in turn can significantly help them to do their work well. And for the general-use case, this massive system also has to run lightning-fast too. Probably about half of the overall systems code has to run as soft-realtime, with maybe 10-20% of it being in the hard-realtime category. And C++ affords all four types (abstract, general, soft-realtime, hard-realtime) of these needs for our robowaifu's systems core (with ASM / C making up any remainder). This central system is what the external world in general, and the Python scripting system in particular, will communicate directly (and only, for safety & security) with. And all the important lower-level systems across the robowaifu's onboard compute & signals internals -- things like microcontrollers & sensors -- will also communicate back up to it as well (these lower system's codes will be primarily written in C). >tl;dr Without robowaifu systems code, nothing works together in a coordinated way at all. >=== -prose edit

>>21088 Participate, piggyback, or pipe-dream. Sounds like you are opting for #2 or #3. I'm through with debating; do what you will.

>>21091 >systems-level code That's part of the problem in this thread here. It's not about which language for what and if something is even necessary, but all kind of mixed together. I don't know about your Robowaifu Foundations code. Why there would be one set of programs being able to access everything and need to be written in C++. Anyways, this is a project of it's own. Doesn't mean everyone will use it, or all of it. >That's what it's there for; it's the 'glue' that binds everything else together, This is exactly where slower languages are often being used, as much as I'm informed. You do the heavy lifting in code close to the machine, but other things in a high level code. >vaguely like the Operating System inside your robowaifu I will consider that if I'm ever convinced about it. >>21103 I have no idea what you're talking about. I'm participating in the board for years, I'm just not joining this idea of a board project. If this here is about a specific project or program, then this is one thing, but this here is a general thread about programming for robowaifus. So maybe discuss something you have agreed upon in a dedicated thread, where it is already clear which language is being used. >I'm through with debating Debating what exactly and when? This thread turns tense every time, there's only some preaching and ranting at the end, and we part our ways for a while. You do what you do anyways, you don't need to announce that.

I am aware that the final product usually is written in C(not C++) but we're prototyping and that is usually done in python. The final product can be written in python, it doesn't matter that much.

>>21128 >That's part of the problem in this thread here. It's not about which language for what and if something is even necessary, but all kind of mixed together. Actually, the broad topic of software of all kinds is exactly on-topic AFAICT Anon. >"In this thread, we will discuss these questions and more so those of us who aren't already settled into a language can find our way." (>>128) As to your general point regarding high-performance code (or the lack thereof), the real world is going to have a way of schooling all of us in this regard I'm quite certain. My perspective on it is that our designs are going to need several extremely-tight kernel loops, running continuously on a number of different internal boards, handling a wide array of inputs & outputs, all at the same time, without stutters or pauses... to even make effective robowaifus possible IRL. This highly stringent requirement will need a high-level, abstract language that's reasonably close to the metal to solve it (and one that doesn't also carry a yuge amount of baggage such as R*st along as well). C++ is the clear winner here (and also why I dedicated myself years ago to learning the language). But by all means; certainly you (and every other anon here) please prototype a robowaifu system using Python or w/e programming language you'd care to. Maybe you'll teach us all a thing or two that way Anon, who knows? :^) >=== -patch hotlink -prose edit

>>21142 I plan to use several internal computers, which would do their work locally and then only send some signals or short strings to other computers. I want to use whatever language seems to be right for a certain job and I'm willing to dig into. If I use someone else's code I need to be able to trust it and I will constrain it as much as I can. I don't plan to look through big piles of C/C++ code on my own, and then do this again with every upgrade. I will certainly not give something like that full control of everything. So better make it mature, no upgrades necessary for the next 30 years after certification. >Actually, the broad topic of software of all kinds is exactly on-topic Anon Arduino uses C++ anyways, for example. But then we're just using the libraries or short snippets and changing some values. Even many hobby programmers know that the speed of code makes no difference if it's only executed a few times, or occasionally. My point is, if some C++ anons want to make everything about their favorite language then they shouldn't annoy others with it. If there's a project to make everything into a C++ Robowaifu OS, then work on it and don't come over here with dismissive "real man" comments like "tired old man", "Language-of-the-month debutantes" and "bizarre literally-who languages". I think I will avoid discussion about programming language here in the future, maybe even hiding this thread, and just look in other places what they recommend for a certain job. Basically all of these >>13955 plus NIM and maybe things like Prolog are potential candidates.

>>21146 >So better make it mature, no upgrades necessary for the next 30 years after certification. Lol. >My point is, if some C++ anons want to make everything about their favorite language then they shouldn't annoy others with it. Also lol. AFAICT I'm the primary """annoyer""" here on /robowaifu/. :^) I already urged you to create a system using Python or any other language Anon, and I meant it. I honestly look forward to seeing what you manage to come up with. You already know the course I'm set upon. Godspeed to us all. Cheers.

>>21148 >Chobitsu Not being judgmental but I don't understand why you keep pushing C++. My understanding from major very, top experienced programmers is that it's somewhat of an abomination. They only use it because of it's libraries and the resources behind it. Have you even looked at Nim? You keep mentioning Python, for good reason, but Nim was made to copy the programming ease of python, use the infrastructure of C, C++ and JavaScript, speed of C, while adding the metaprograming of scheme in an easier to use, more structured (meaning easier to understand later) form. It's well known from most everyone that meta programming can give you huge productivity gains. It would seem that Nim with maybe a little scheme thrown in would move things forward much faster. Nim seems ideal for all uses and cases. I can't see learning C++. Too much detail. No one knows all this, even people who have been after it for years. Something like scheme may be really fast coding but the code becomes so specialized that each section of it, I think, appears to become it;s own language so no one can understand it.

>>21200 Lol. Hey Grommet didn't we already have this discussion before? :^) >Have you even looked at Nim? I did look into it sufficiently to confirm that yes, it was a transpiler-based design and yes, it can output both C & C++ code files. That's the extent of my research on it ATM, since I have a lot on my plate r/n. But I thought you yourself were going to investigate it for us all Anon? Regardless, as with my advice to NoidoDev, I'm all for you pursuing developing robowaifu systems in Nim or any other language you care to. Want to teach us about it? I'll be one of your best students I imagine. Godspeed. >Not being judgmental but I don't understand why you keep pushing C++. Thanks, and I don't take it that way at all from you. So, if I haven't made it all clear enough yet, then I hope it will become at least somewhat more clear to you during the course of our /robowaifu/'s C++ Learning Classroom (>>19777). While Bjarne Stroustrup's plan of discussion for his lectures is on a broad and diverse set of industry topics related to programming itself, mine are rather more narrow. Namely, robowaifus and all the pertinent systems thereto -- both within and without their physical manifestations. I think this should make the learning both more fun, and also more interesting b/c it's clearly pertinent to what we're all striving for here. In some ways, I think we have the literal best-angle for a computer programming class of anything out there. We're building robowaifus after all! :^)

>>21146 > just look in other places what they recommend for a certain job And when you get to the part about your robot needing to operate in hard-realtime, you will give c/c++ another look. Especially since your plan (as of now) hinges on passing messages between loci. >don't come over here with dismissive "real man" comments You're being just as dismissive of C by mocking those posts as 'real man' poseurs. Get real. >>21088 >Nim and Lisp existed for a long time. And have always played second fiddle to C. You strike me as a purist, and that's fine. But if you absolutely refuse to get your hands dirty you'll never get anywhere in designing control systems. Good luck, anon.

>>21203 >didn't we already have this discussion before? NApologies. No iontent to torture you. I was wondering in the vein of, "what am I missing" if Nim, seeming so much easier, is not seen as a good option while C++ is. I won't ask any more. I may talk about Nim if I find something I like but otherwise I'll leave it alone.

>>21214 Point taken. You know sometimes when you write things it comes off as aggressive when...that was not the case or intent. I'm talking about me not you. So maybe my wondering about things, are sometimes taken out of context and not really what people think they are. Generally if I'm being aggressive or contemptuous you will know it. I'll be very blunt.

>>21232 >NApologies. No iontent to torture you Haha no worries mate. I actually enjoy discussing this stuff, because it helps our newcomers realize an important part of what we're all up against here (hard-realtime), and not to just naively plod on in a fruitless direction and then leave disillusioned and discouraged. It's happened here before BTW. :/ >[Nim] is not seen as a good option while C++ is. I've tried my best to make it clear that, together with the very eminent programming language C, C++ is our best option IMO. I would be pursuing something else for our primary language choice here if I believed anything else, trust me. Rust, Go, Ada, D. All of these are reasonably good as systems language choices, but not as good as C++ is today. (Ada is disqualified primarily b/c of it's exceptionally verbose syntax, along with the lack in abundance of qualified developers. Otherwise, it would likely be our best choice here on /robowaifu/, I think.) Heck, even C++ is a good 'alternative' choice (and getting better quickly). What I mean here is that reduced variations on the ISO standard language, like Circle [1], and Cppfront [2], are being investigated as viable language-evolution pathways. But the C++ Core Guidelines [3] still far-and-away lead the pack for this C++ language research area. BTW, we'll be discussing the proper use of the CPPCG recommendations during the latter portion of the C++ programming classroom -- after our beginners have gotten up on their feet with the language's syntax. >I may talk about Nim if I find something I like Excellent! Please do so Grommet. And the same to every anon here... don't let my goals for us sway you in the least from pursuing your own interests in these affairs. That's how we all learn and teach each other together! Cheers. :^) --- 1. https://github.com/seanbaxter/circle 2. https://github.com/hsutter/cppfront 3. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines >=== -prose edit -add C++ evolution links