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.

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.

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.

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.

That's a good point; I updated the README to note that the language is still under development.

And yeah, as for https://github.com/orange-lang/orange/tree/master/lib/libor, it only contains bootstrap code for the linker at the moment.

When a standard library is introduced, Orange will be garbage-collected.

I've seen both, but I haven't spent a lot of time looking at their documentation to start making comparisons.

At the moment, I only have a vague idea of what I want Orange to be. The development has mostly been driven with what I thought at the time. It's been a bad approach, and I plan to fix it before I continue developing.

I'm going to work on figuring out Orange's specific goals and points where it differs from new languages like these. Saying I'll have this ready by the end of the weekend might be a stretch, but I will get back to you soon.

What do you consider a for loop to be? The loop constructs called "for" that existed prior to C all just iterated through a numeric sequence with an optional step parameter. This was present in BASIC, ALGOL68 and Pascal.

The C for loop was designed by looking at an ALGOL-style for loop:

    FOR i FROM 1 BY 2 TO 3 WHILE i≠4 DO ~ OD

and trying to make the construct not tied to integer sequences (because such a specific construct would be out of place in C). The typical for loop, like the one in your comment, has a begin, end and increment parameter, just like the ALGOL example.

I assume you mean that you'd prefer some kind of for-each kind of loop, but in order to support that, a language needs a formalized concept of iterators, which may be out of scope for the project.

> Is the simple--easy-to-learn--without-the-mistakes-of-C systems language becoming a hype now?

being easy to learn is not enough.

I think "scripters" like me definitely want a language that compiles to a binary (no VM) like C(so easy to deploy on a server or to distribute to third parties), with good a concurrency model(because concurrency is one of the most important thing in web apps today) but expressive yet statically typed. The language that can pull this off will be the next big thing, no question.

Go isn't(the next big thing). it could have been great, but its type system is just horrible once one digs a little bit. No co-variance or contra-variance so extremely limited polymorphism, devs having to do compiler's job with type assertions everywhere, a clunky error system(that could have at least benefited from some syntactic sugar to make it less verbose...). However Go concurrency model is excellent and set a standard

It started long before Rust 1.0, and not a moment too soon in my opinion.

It really started with the rise of llvm, which gave way to julia, rust, and many other languages. Nim and D seem to be two big exceptions.

I'd personally would like to see a C ABI compatible language, that

- keeps 90% of C, - adds a string type - adds Go like "classes" (e.g. making more concrete the classic C idiom of passing a struct to the "object" to manipulate a la Glib) - adds a foreach - adds a builtin, multi-purpose map, vector and set type (e.g. based on Glib) for quick work - adds closures a la Obj-C / Apple's C - adds a small, but handy standard library (all C classic stuff + all Glib style stuff). - compiles to C-ABI compatible static binaries

Each parameter in a function without a type identifier is a unique generic type. This means any function with two typeless parameters already accepts two different kinds of generic types.

I was more inspired by Ruby's syntax, which I always thought was very clean to read.

I struggled coming up with a lot of examples since I don't have a standard library to work with (yet), but the most diverse group of existing programs would probably be at https://github.com/orange-lang/orange/tree/master/test.

To expand a bit, implicit declaration works great for small programs. But it doesn't scale to larger source code bases, as misspelled names become hard to spot.