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.

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.

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.

That looks interesting. However, i'm not really into language-design and compilers and the first commit is from April while the project has only two contributors. Apart from the absence of a standard-library, I couldn't find anything like "attention, this is in beta". Don't get me wrong, I just would be surprised if this really was a stable language developed in under three months.

(Something I was wondering about is that it says "Contains orange standard library stuff" in https://github.com/orange-lang/orange/blob/master/lib/libor/... and "At the moment, Orange has no standard library" in https://github.com/orange-lang/orange/blob/master/README.md at the same time.)

Edit: I definitely was too fast. https://github.com/orange-lang/orange/tree/master/lib/libor doesn't contain any code.

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.

Is it memory-safe? Is it garbage-collected?

Edit: Looks like it does extern calls to `malloc`, with no matching frees. Supporting proper dynamic resource management is fundamental for a system language, as the whole point of an operating system is to manage resources for user programs.

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

Have you seen Nim and/or Crystal? Both of these languages seem to incorporate a lot of the ideas you are planning for orange, hence I must ask: what makes Orange different?

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.

Crystal looks close to Orange maybe you should contribute to it instead.

After looking more into Crystal, it seems to try to be as Ruby-like as possible. I like Ruby, but I think its more involved features are syntactically complicated. I'm also just not a fan of the "everything is an object" mantra.

On the other hand, while Orange takes some syntax as Ruby, I'm trying to keep the syntax small and simple (similarly to C), and make sure that you could write programs for target platforms like the Arduino without needing a runtime.

I think that Nim fits your description of Orange a lot (apart from the Ruby-like syntax). Please do consider contributing to it.

Please consider helping with Nim. Its really amazing.

It'd be nice to update "Why" with reasons why other recent developments in systems programming languages fail to address what you think Orange is addressing.

You are including etc/cereal/include to your -I but this does not exist, and I see no probe for cereal.

    tools/orange/main.cc:12:10: fatal error:
      'cereal/types/unordered_map.hpp' file not found
    #include <cereal/types/unordered_map.hpp>

This one: https://github.com/USCiLab/cereal ? Please add it as submodule to etc.

The apple standard cc=clang-602.0.53 is not good enough. error: no matching constructor for initialization of 'llvm::EngineBuilder' EngineBuilder builder((std::unique_ptr<Module>(m_module)))

macports clang-mp-3.{3,5,6,7} even fail before with this error: no matching constructor for initialization of 'llvm::raw_fd_ostream' raw_fd_ostream raw(loutput.c_str(), ec, llvm::sys::fs::OpenFlags::F_RW)

I only have 5 clang's on my mac.

I suggest this reading to each author before making a new language: http://www.scriptol.com/programming/languages-with-no-progra...

  for (i = 0; i < 10; i++) 

Why do so many language copy C's error prone while masquerading as a for loop? This construct is responsible for quite a bit of errors (off by 1).

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.

The for in my example (which is directly from the linked page) is a while loop written in a compact form. My complaint is that a for loop should name a definite end number without a condition. I think the WHILE portion of the ALGOL-style for loop you give is problematic (and given the example unused). Having a condition as an end condition is error prone.

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

Not to be a downer, but that's what it seems like since Rust 1.0.

> 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

Sounds like you're interested in C++.

With C ABI compatibility (without name mangling and such), and with a much more streamlined feature set...

> Sounds like you're interested in C++.

C++ is good as long as you don't have to read and debug other people's C++ code. C++ went to far with features and it didn't even fix all C core's problems. I personally like Cyclone syntax and features.

What are the pros of leaving out the type identifier when declaring a generic type? I understand that it's viable to not provide some "Type" identifier to denote a generic type, but I feel like it's better to have it for clarity. What happens when you have a function that accepts two kinds of generic types? This inconsistency doesn't seem worth it to me

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.

Is the syntax python-inspired?

It looks a lot more clean to read than Nim, so this will be interesting.

I couldn't find any more examples besides the simple "hello world", so it would be nice to see a few more in-depth examples.

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.

> variables can be defined implicitly

Oops! :-)

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.

Ah, yeah, I figured this would be an issue, which is why I thought having it be something you could disable could fix some of those potential headaches.