The original D compiler was written in C++ and used bits of the C++ compiler (like its optimizer and code generator), and was eventually converted to 100% D. It still kinda looks like C++.
It's like my early Fortran code looked like Basic, my early C code looked like Fortran, my C++ code looked like C, and my D code looked like C++.
It takes a while to write code idiomatic to the language your using.
Man...all I wish, after this illness goes away, is to finally meet you in person (in the near future that is) and have food and drinks while having a geeky chat about programming languages and the like.
I like how down to earth human being you are; that's the type of people I want to be around as much as possible.
There are so many things I could be taught from you.
Yeah, I had a bumpy transition from C to Forth. Now I can write idiomatic C, Forth, Erlang, OCaml, and Ada/SPARK, but C -> Forth was the most difficult one, I would say.
As for C++: I have zero clue about it. Occasionally a student who learns C++ comes to me for help and I end up being useful and help her (by RTFM), but other than that, nothing much really.
Just think of Ada as "boomer Rust". It's great for when you have a well-specified project that can be coded in a top-down fashion, and correctness is a paramount concern. It enforces correctness through a very strong type system and a pointer model that forbids aliasing by default (pointers must be declared as 'aliased' to alias them), and the SPARK extensions provide even more guarantees, allowing you to formally specify contracts which the compiler will ensure are fulfilled.
My language learning progression is usually to write everything like a mix between C and simple C++, then I start using all kinds of new features and after a while it goes back to simple C/C++ with a few fancy stuff left.
Either the title is incorrect or the OP has linked the incorrect github page on this user's account. [0] seems to be written by the same person, and generally covers what the current title claims.
Thank you for posting, OP! I have a tangential question about your programming style. I've noticed you define quite simple structs, that nevertheless have constructors and are not POD (e.g. they include a deque<>), and define the methods that work on them inside a namespace. [0]
The two main styles I've seen are (1) the classic full-fledged OOP-y C++ classes with methods, and (2) POD structs with functions that work on them defined in namespaces, in a more C-like style.
Your style seems to be a mix. You don't seem to get the big downsides of OOP, as you're grouping functions per namespace instead of having to make everything a class and ending up with a contrived architecture. At the same time, you're still going to be using many C++-isms due to your use of non-POD structs, which some people may appreciate (for uniform initialisation and memory management), and some people may enjoy less (due to the limitations and complexities of constructors, being forced to use exceptions etc.).
I apologise for my extremely superficial description, but I think it's enough background for my question, namely: could you speak a bit about this programming style, what led you to choose it, and what you enjoy/don't enjoy about it? Thank you! :)
You're welcome, the isolation is not without upsides :)
That's correct, I tend to drift towards the same style when the language allows it.
This is the result of 35 years of trial and error, not so much careful planning. I've found that structuring my code like this makes it more enjoyable to deal with.
C++ being C++, simplifying and cutting it down to its core is essential from my experience. But I like constructors and destructors, and the standard library is pretty nice these days.
I like this programming style, personally. The pattern of having helper funcs as well as class/struct methods, which is most appropriate, is a pattern I seem to see quite frequently with Go code.
When did HN start showing the GitHub username in the URL? It’s a great improvement given how many such links there are. Never noticed it till now though.
If you want to implement an interpreter for a small language, in my experience, it is better to compile it to create an Abstract Syntax Tree with an eval function. I have tried this approach in my Crystal Edit MySample clone with extended functionality. The build in script can be used to manipulate images. The scripting language has no functions and procedures, but for image manipulation scripts, this is usually no big deal. See more details, source code and example script (in the entries of my blog): http://www.iwriteiam.nl/MySample.html
Show HN: Build your own programming language in your own language.
Why on earth would someone seriously want to use C++ for the compiler, when you created a much better language? Bootstrap it once and your problems are gone. Memory safety, tree management, proper matching, high level. All extremely important for a compiler.
One reason could be that most real-world compiler/runtime codebases are in C++ (gcc, llvm/clang, v8, most of Java JITs) and C++ has just enough high-level features to make a large code base somewhat manageable. So, if one wants to work on a industrial-strength compiler at some point, it might be not the most expressive and helpful choice, but it makes sense.
I don't know why you'd post a Show HN and then being so dismissive of someone chiming in asking if it's possible to use your project to do something they'd be interested in!
The constructive answer to the original question is - yes both this system and Java bytecode are fundamentally stack-based languages, so they should match up well.
It's like my early Fortran code looked like Basic, my early C code looked like Fortran, my C++ code looked like C, and my D code looked like C++.
It takes a while to write code idiomatic to the language your using.