Nim

ira) about this issue [2]. Nothing changed. They don't care at all, since 2012, when the Red project started. I know NirSoft [3] products suffer from that plague; network utilities (Wireshark, nmap) get hit, so as various packers (WinRar, also see [4]); re-reading the thread after the original post, I'm not even surprised that demoscene experiences problems with anti-virus software; but seeing this issue pertaining mainstream language such as D is, well, terrifying, to say the least ⁂. It can be easily brushed off as an anomaly in such mature, widely adopted code bases, but with non-mainstream, yet-in-development languages it's a scourge that hinders the adoption and serves as a constant source of headache both for developers and users. And, honestly, I can't see how this can be resolved without raising public awareness and engaging other developers in a debate. -- [1]: https://github.com/red/red/issues?utf8=%E2%9C%93&q=label%3At... [2]: https://twitter.com/red_lang/status/887970289618829312 [3]: https://www.nirsoft.net/ [4]: https://news.ycombinator.com/item?id=4152539 (apparently, original post is deleted, but still can be retrieved via Archive) -- † We can only guess what causes the trigger, as vendors never give any feedback. One guess is that toolchain generates a file layout different from VisualStudio or GCC linkers, and uses a custom compression of DATA segment. ‡ I think this happens after each update of heuristic DBs or AV engines which vendors share. IIRC Windows started to use machine learning for malware detection some time ago. Total bonanza. ⁂ Ever wondered what the very first issue in Nim repository was? (https://github.com/nim-lang/Nim/issues/1)

a bunch of type signatures or whatever and you can enforce it how you like it. But when writing code for other people to interact with, the implicit return type initialization creates weird ways of coding around it that are not clear or common sense for other people, and then mixing void and the use of discard makes it super unclear when or why it’s useful to ignore the return type in some context, instead of it having been actually designed as a void function (and for this to have a proper type). This comment on this Nim issue gives a good example of what I mean, < https://github.com/nim-lang/Nim/issues/7370#issuecomment-376... >. But generally, I think it just speaks badly of discard-style thinking. Write void functions to communicate side-effectfulness. Don’t mix concerns about a side effect and an optional return value and assume people will get your meaning and know when to use discard. That is more like coding for the function author’s benefit instead of coding for readers, users or other contributors.

facilities for DSL's or rewriting where opportunistic. Then, where that doesn't work out, you at least have general-purpose language to fall back on. http://www.vpri.org (Use Control-F to go to anything that says "STEPS" to find the reports. Work from the bottom up since it's chronological series.) On your other point, your Racket example is one way it could work. I was also advocating in this thread just using Python itself to build tooling for its own benefits and ecosystem. A lot is already built. Use C for low-level software that strictly needs it if nothing else is available with HLL's like Python for stuff that doesn't need it. The language I've been telling C programmers to check out for scripting-like use is Nim. It looks like Python, has real macros, can call C, and compiles to C. Here's a comparison I just dug up: https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers I also doubt it will be harder to find C developers if tooling is written in HLL's. For one, they just have to use the tooling rather than write it. I doubt most C# developers extend Visual Studio, most Java developers extend NetBeans, and so on. If they do have to learn, using a language like Python or Nim should make low barrier to entry since even folks with no experience pick Python up quickly. A C-like subset of Nim or something similar will be just a lot like C with easier syntax and less stuff to worry about. If anything, productivity will go up over C like shown in about every language study ever done. I have encouraged people to do C-like languages with safe defaults, cleaner semantics, a REPL, better macros, easy integration of C, and outputting C. That way, one can program in a cleaner language avoiding most headaches and accidents that come with C being designed for 1970's hardware. Aside from Wirth's languages with C syntax, a good picture of what this might look like is Julia language which was femtolisp on the inside. Especially its seemless interoperation with C and Python. https://julialang.org