Slower execution is indicative of waste. When it comes to interpreted languages, even those that are very well implemented, any slowness is directly related to energy loss. This is very problematic when it comes to mobile devices, even modern ones, as this energy is generally coming from a rather limited source (the device's battery).

While this may not be a problem if one or two apps are written using a wasteful interpreted language, it can become a much bigger issue when the entire ecosystem is implemented in such a manner. It'd be irresponsible to unnecessarily reduce the battery life of the devices of thousands or even millions of people.

And while many mobile devices today probably are more powerful than desktops from a decade ago, I don't think it's correct to say that those desktops "ran interpreted apps just fine". They didn't. There's a reason why Java has a bad reputation for performance problems, even today: many desktop apps written in Java performed horribly on computers of that era. And Java was perhaps the best-performing of the interpreted or quasi-interpreted languages.

As long as your Obj-Next doesn't come with superb C++ compatibility you won't get the serious players on board.

See also more thoughts on the essay: http://nearthespeedoflight.com/article/2014_03_20_assorted_f...

Bluntly: there is a class of programmers and programs that cannot be written without:

* C linkage

* Calling of and calling from C

And a further class of programs where:

* Garbage collection

* Significant runtime

* Safe code

Make acceptable performance impossible. This class of programs includes .NET itself which is entirely written on top of the Win32 C APIs.

If you want a runtime on top of Objective-C, you're welcome to write one yourself. It could offer everything you're requesting without needing to change anything about Objective-C.

Oh wait, there are literally dozens of runtimes on top of Objective-C. Not to mention official bindings to Python and other languages. Sure, none of them are very popular but if you want to write in something else: go ahead.

    @interface MyClass
    - (NSDictionary *)createSimpleDictionary;
    @end

    @implementation MyClass
    - (NSDictionary *)createSimpleDictionary
    {
        return @{
           @"keyForNumber": @1,
           @"keyForBool": @YES,
           @"keyForArrayOfStrings: @[@"one", @"two", @"three"]
        };
    }
    @end

    class MyClass
    - (NSDictionary)createSimpleDictionary
    {
        return {
           "keyForNumber": 1,
           "keyForBool": YES,
           "keyForArrayOfStrings: ["one", "two", "three"]
        }
    }
    end

There may be some perfect, completely new idea for a programming language out there, but Apple would never go for it. Developer experience is a distant third to the User experience and the Apple experience, and the only thing they will go for is an evolutionary, backward compatibile change such as this.

When will people learn this is an implementation issue?!

The end result of visual design tools doesn't seem to match the hype. At some point you DO need programmers to make some of the magic happen. I think so far game development has probably done the most to merge the graphic designer, game designer, and programmer workflows into something that is productive for lots of people on the same project.

I really think Apple is the last place you'll see much programming language innovation compared to what you already see in languages compiling to JS or the JVM or even LLVM.

The iOS dev environment is the nicest I've ever worked in., in big part to obj-c and all that comes with it.

Seems to be change is being requested for changes sake , rather than trying to address any actual pain points.

The complexity is reality, not something that can be swept under the rug so that naive implementors can use general purpose tools. Isn't that why we have DSLs, anyway?

So, for example, I have a Customer type and a Customer varibable. Not only can I see that one is a type and the other is not, I can apply a global "tag" to all the Customer instances to mark it as "Client-Side" and see visually the difference between a Customer class server side and client side.

Or have a style to mark when a function have side-effect, or if it trhow a exception. Make it part of the syntax:

[CAN-KILL]openFile:(customer:[CLIENT]Customer)

But the coder just write: openFile:(customer:Customer)

How could be to use code as a word document?

>We think we know what we want from an Objective C replacement. We want Garbage Collection, we want better concurrency, we don’t want pointers. We want better networking, better data base, better syncing functionality. We want a better, real runtime. We don’t want header files or import statements.

We don't want Garbage Collection to the contrary we want reference counting. Reference counting is the best compromise between handling memory manually and using GC ala Java. I would argue that the mental strain for the programmer is equal for reference counting(at least with ARC) to that of GC. However Reference Counting is extremely lightweight.

Regarding concurrency it should be mentioned that I don't have a huge amount of experience with different languages. I've done concurrency in Erlang, Java/JR, C++ and Objective-C. I'd say that GDC from Objective-C and possibly Erlang were the easiest to use.

Why wouldn't we want pointers? Most modern languages use pointers under the surface, there are significant benefits in not obscuring and hiding this as is done in Java.

We do want header files and imports because they provide a bunch of benefits namely separation of interface and implementation, distribution of compiled implementations with interfaces in header files. With the @import option compile time is significantly faster as well.

I'll deliberately skip the last points, suffice to say I don't feel strongly about them. I do agree on the data base point though.

My own revised list of things that Objective-C needs are. Proper static typing(no id), templates and namespaces.

EDIT: The point about requiring a programer to change a color is interesting, all though I would argue that the same holds true for web. I have rarely worked with designers who are proficient enough in git and css to make such changes. In the case that the designer is proficient enough to handle git, a css like json file can be used to specify the look of the app and thus changing colour would only involve editing a json file which is comparable to editing a css file

"What do we want? We don't know! When do we want it? Now!"

I used to think that, until I started to spend more time on modern GC platforms like Java and .NET. It's impressive how performant a good generational garbage collector can be. For many business applications (i.e., not the kinds of workloads you'll see being simulated by popular benchmarks) a good generational GC can even improve performance thanks to improved locality of reference. I think a lot of us don't fully appreciate the cost of a cache miss.

Speaking of, I'm not sure a lot of us fully appreciate the cost of synchronization, either. It's one big reason why I'm not convinced that reference counting is particularly well-suited to concurrent programming, since it turns a really commonplace operation (retaining a reference to an object) into a synchronization point in the program. There's a non-trivial cost associated with that. You could avoid repeatedly stalling the CPU by being very careful about not sharing objects among threads, but I don't think most developers can reasonably be expected to make a habit of that in practice.