
Objective Next - ImOssir
http://nearthespeedoflight.com/article/2014_03_17_objective_next
======
Pacabel
The arguments in favor of considering an interpreted language as a suitable
alternative are not very convincing.

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.

~~~
rapala
Most of the time it's not the CPU that is using most of the energy. It's the
mobile or wireless connection, the GPS and the screen.

~~~
Pacabel
I think that hardware factors like those are generally irrelevant when it
comes to purely software issues, like we're discussing here. In this case,
we're talking about an energy consumption penalty imposed solely at the
software layer.

Aside from arguments about the screen perhaps not needing to be used as long
when the software completes its operations faster, I think it's probably safe
to say that such hardware-specific energy consumption due to the factors you
mention would be constant in both the case of compiled applications and the
case of interpreted applications.

~~~
hueving
>In this case, we're talking about an energy consumption penalty imposed
solely at the software layer.

The point is that we may be wasting time talking about a negligible amount of
the total battery assumption.

------
kybernetyk
ObjC's dirty little secret is its capability of playing nice with C++. There
are huge C++ code bases with only Obj-C UI frontends both in the OS X and the
iOS market.

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

------
jbrennan
Author here. Please try not to get too caught up on the interpreted part. It’s
far less important to what I’m trying to get across here in the essay. Yes,
implementation matters, but what we’re implementing matters more. And don’t
ignore the benefits of being interpreted, like having a more dynamic runtime.
Being able to modify a system without needing a recompile cycle is a huge win.

See also more thoughts on the essay:
[http://nearthespeedoflight.com/article/2014_03_20_assorted_f...](http://nearthespeedoflight.com/article/2014_03_20_assorted_followup__explanation__and_afterthoughts_regarding____objective_next___)

~~~
nightski
I think instead of presenting the problems it is important to provide
solutions. Do not presume a large portion of your audience has not already
thought these same things. Instead, take Brett Victor's approach and offer
slightly more tangible advice.

Instead of hating on the way things are currently done, show a better way. It
will mean a lot more in the end.

Don't mean to be harsh, just saying that there are plenty of us who have
questioned all these things and still do not have the answer.

------
gilgoomesh
Dear OP: why do you think the Win32 C APIs still exist? Microsoft have offered
.NET for Windows since 2001. It does everything you're requesting but it
hasn't replaced the completely hideous Win32 C APIs.

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.

~~~
pjmlp
I would like to add all of that is possible without C and has been achieved
multiple times back when C was UNIX only.

It is just the historical legacy fact that the majority of modern OS ABI == C
ABI that keeps us have to link with it.

~~~
bunderbunder
Well, that and C is a nice lowest common denominator; virtually any language
can manage a fairly decent foreign function interface with C code without too
terribly much friction.

------
ZitchDog
To me, it's easy to see what needs to be done with objective-c when you write
a tiny class that creates a dictionary:

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

How much cleaner could this be if we dropped C backwards compatibility! We
could remove the header file, and get rid of all the *'s and @'s:

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

This new language would get rid of many warts of Objective-C, bringing it up
to speed with modern languages, while keeping performance and interoperability
with the Cocoa toolchain.

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.

~~~
K0nserv
Why would we want to get rid of the .h/.m separation? It's a nice feature,
Java's single file format is far worse in comparison.

~~~
necubi
I, and basically every language designer since the 80s has disagreed with
this. It's needless repetition: all of the information contained in the .h
file is duplicated in the .m file. If you really want a nice listing of the
exported methods, it's easy to generate that from the .m file.

~~~
frou_dh
Stockholm syndrome from too many years in the company of archaic compilation
models: it's real and it's scary!

~~~
pjmlp
It is incredible how C based compilation models become so widespread, that
younger programmers are completely unaware of sane module systems in other
languages with ahead of time compilation toolchains.

------
abijlani
The author is right that we need to think outside the box but I think his
argument is misleading. Historically, programming languages evolve and not
leapfrog. I don't see why Objective-C cannot keep evolving while some other
company is bold enough to research a new visual programming language that will
result in a paradigm shift. The two are not mutually exclusive.

~~~
jbrennan
Author here. Good point, they are not mutually exclusive. I do think however
it's not in Apple's culture to significantly move away from C/ObjC any time
soon. For the time being, they are getting by well enough as is today. I think
they'll continue to slowly evolve the language, but I'm not so keen to wait
for major changes, and I'm hoping to get others onboard with me.

~~~
abijlani
Are you saying you want to take a crack at creating this new paradigm shift?
Couldn't you argue that a project like RubyMotion is already doing some of
what you are proposing.

~~~
jbrennan
No not really. Ruby is a fine text language but it offers no benefits or
advantages like what I described in the article, safe maybe a REPL. But we can
have that already with the Super Debugger, for example.

------
pjmlp
> Why do we assume we need a compiled language? Why not an interpreted
> language?

When will people learn this is an implementation issue?!

~~~
Pacabel
I'm not convinced that it's purely an implementation issue. While maybe that's
true in a theoretical sense, I don't think it holds true in practice.

There are various characteristics of programming languages that can make it
much easier to implement them as interpreted languages rather than compiled
languages, and vice versa.

Maybe any difficulties could be overcome given enough resources, but this
usually isn't the case. I think this is why the efforts to make compilers for
a language like Python have never really been that successful. And the same
goes for the attempts to create interpreters for languages like C and C++.

Perhaps the most success has been with the various compilers that compile Java
source or bytecode to native code. But even in that case, the end result
usually isn't very good. It's usually somewhere in the undesirable middle,
giving the worst of both compilation and interpretation.

~~~
pjmlp
> There are various characteristics of programming languages that can make it
> much easier to implement them as interpreted languages rather than compiled
> languages, and vice versa.

It is all about convenience and effort one is willing to invest versus return
on investment. As any good CS compiler design course will show to their
students.

Back in the 70-80's most languages had multiple implementations offering both
compilers and interpreters as part of their toolchains.

Only on the early 2000's I started to see this phenomenon of mixing languages
with their canonical implementation.

------
programminggeek
The closest thing I've seen to this notion of what the OP seems to want is
Adobe Flex and MXML. Microsoft has kind of the same thing going on with
Silverlight and XAML (or whatever they are calling those things now).
Microsoft put a lot of time and effort into the design tools and everything
else to make that a good experience for designer and developer from what I can
tell.

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.

~~~
programminggeek
Also, if there is going to be a visual software development revolution, I
think it will look something like a visual data flow language. Something along
the lines of yahoo pipes meets rails or django.

How it would work is you would have something like ActiveRecord that can pull
data into the first step, then visual steps for mapping, calculating, etc..
and spitting that data into a HTML view or whatever in the last step. You
could design the HTML in a WYSIWYG kind of thing or just as a tempting system.
Doesn't matter.

All it would be doing would be replacing a lot of the computation that
programmers do with some functional lego block able logic in the middle. Once
you had the mechanisms in place for this kind of system, I think you could
swap out the data sources from a CSV file to a database to a restful service,
and your design bits from HTML to iOS or whatever pretty easily, giving you
the ability to work in a pretty general purpose way.

A tool like that could be very interesting, but it's quite a different
approach.

------
supercoder
The interesting thing is why are people actually calling for a replacement.

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.

------
spacemanmatt
Idiomatic code, formatting and all, is a visual language I've gotten quite
used to. If I "zoom in," it's regular code, but one must also be able to
cruise one's project artifacts at a higher level than lines of code to
function as a developer.

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?

------
jes5199
It's really surreal to me that we're having this conversation without
discussing the reality that outside of the Apple-controlled iOS sandbox, the
world is replete with hundreds and hundreds of languages. You don't have to
navel-gaze to theorize what's it's like to work in another language: just try
writing some code that runs your laptop instead of your phone.

~~~
mantrax
Many of those hundreds of languages do actually run on iOS. Many games on the
App Store are written in Unity (a C# platform).

Heck, many are written in Flash too. Yes, Flash.

I actually consider it a very healthy sign that the people complaining about
Objective C are a vocal minority whining about such silly, unfocused, vague
things.

It means Objective C is doing quite fine, thank you very much.

------
S_A_P
Anyone here tried xamarin? It's a 1:1 map of the iOS /Mac API. I love c# and
wish I could use it to write native code. C++ is just too clunky to me to use
daily. The one thing about iOS and Mac dev that I hate is the interface
builder. Worst. ui. designer. ever.

~~~
pjmlp
> I could use it to write native code

mono -aot

------
mamcx
The only thing that could be usefull, IMHO (because a visual language per-se
is a niche tool) is perhaps use code no as "plain" text but as RTF/HTML/Word,
ie, the developer _write_ "text" but the code is stored in html/rtf or
similar, meaning, that exist "bold", "italics", "center", etc commands that
apply to the text.

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?

~~~
mamcx
What is the problem with this comment?

------
protomyth
So, why not use F-Script or work to make it what you need?

~~~
jbrennan
Author here: Funnily enough, I have! I wrote the Super Debugger which uses
F-Script
([http://shopify.github.io/superdb/](http://shopify.github.io/superdb/))

Please note though this is not at all what I’m describing in my essay. A REPL
is hardly a graphical, direct manipulation drawing tool for creating software.

But it was fun to dip my toes in more dynamic waters.

------
lucian1900
It sounds like you're describing a modern Smalltalk. I would love something
like that, especially if it was cross-platform and perhaps syntax like Nu.

------
K0nserv
While I agree with the OP in that there are certainly improvements that could
be made to Objective-C I find myself disagreeing with a lot of the ideas in
the post, especially this paragraph:

>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

~~~
bunderbunder
> 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.

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.

~~~
stormbrew
> 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.

This is actually a problem for both. Simple implementations of AGC have to
stop the world to scan at least the roots, and probably even a bit more than
that, because there are significant ABA problems. There are ways around this,
but as far as I know the only environment to use any of the really good ones
is the JVM, because it's hellishly complex. I don't know that there is
anything that doesn't stop the world for at least a couple of ns, though.

There are also solutions to it for reference counting. They involve using
thread local reference counts and briefly stopping the world to reconcile the
counts. I believe [1] describes this algorithm.

And once you get there, and start dealing with cycle detection, the difference
between the two approaches starts to look a lot smaller. There's a paper on
this too. [2]

[1]
[http://www.cs.technion.ac.il/~erez/Papers/refcount.pdf](http://www.cs.technion.ac.il/~erez/Papers/refcount.pdf)

[2] [http://www.cs.virginia.edu/~cs415/reading/bacon-
garbage.pdf](http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf)

------
LeoNatan25
Please "god", no interpreted language.

------
phaed
Visual Studio for the mac then?

------
mantrax
I can sum up this article & its predecessors like so:

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

