[jerf]

My advice to you is that you need to answer the question, "What is Orange?"

Your page right now focuses much more strongly on answering what it isn't. It isn't klunky, like C++. It is neither typed nor untyped. It doesn't "limit user's expressivity". It doesn't require you to declare variables, except that's also optional.

It almost comes across like it's nervous that some people might disagree with some design decisions. Let me put your mind at ease: If you are serious, and if you attain any success, I solemnly promise you the Internet will string up your language, dismember it publicly, douse all the pieces in gasoline, light them on fire, and dance around the flames. Why is that actually something that ought to put your mind at ease? Well, it's inevitable anyhow, so you might as well go ahead, have some fun, and make some decisions about what Orange is going to positively be. If you get to that point, remember you'll be the one in possession of a language that's gotten enough attention for that to be worthwhile, and they'll just be hecklers.

[rfratto]

You're absolutely right.

While I do strongly believe that optional typing is a feature I want to keep, I have been focusing too hard on taking a middle-of-the-road approach.

The original idea was to have a systems development language that had the same "feel" as a high level scripting language. I didn't do a lot of planning on what that meant from the technical side.

I appreciate the advice. I'll spend some time getting the answer to what Orange actually is.

[gue5t]

Given the design parameters that are stated ("systems", and C++-comparable), one can only assume that it's a typed language with aggressive (interprocedural) inference and monomorphized generics. Ensuring that the inference algorithm has good properties (performance, finding "most general types", matching programmer intent) should be a high priority.

If it wants to avoid the clunkiness of C++, Orange should have concrete answers for how it will solve the problems that those clunky features address: various sorts of inheritance, compile-time computation and value-indexing with templates and constexpr, operator overloading, data layout, etc.

[RickHull]

https://github.com/orange-lang/orange/wiki/Language-Specific...

[noonespecial]

That's great advice for any creative work. People hating on your stuff is much better than people ignoring it.

There's always a troll there to tell you how much better the thing they could have done but didn't is than the thing that you could do and did. It's not true. "I did" beats "I could have" every time.

[MichaelDickens]

Yes. I'm concerned here that if a language makes something optional, some users will want to do it one way and some will do it another way, leading to inconsistent code bases. Some languages (Ruby, Haskell) prefer to let programmers decide how they do things, while others (Python) only provide one way of doing things. A lot of people disagree about which is better, but the decision to leave design open to users is itself a design decision.

[rfratto]

Any options I had planned for the language were going to be per-project settings, so at least the coding style in any given project would be consistent.