Funny that all of these, minus the first one, have next to nothing to do with the language itself, and everything to do with its standard library and external tooling.

Yes, first point, and datatypes as well. And to be fair, the author does state clearly that some of the features & benefits he lists can come from a mix of language/standard libraries, OS, runtime or third-party. At the end of the day, you just have to be able to be productive with the language.

If you’re coming up with a brand new language, you have to do a damn good job of compensating for it by piggybacking on existing VM/Libraries/third-party tools (which Swift largely does), building it in your language and standard lib (e.g. Ruby), or doing a good job at attracting a new community to build that for you.

I guess that's what attracted people to Python some ten years ago, as opposed to Perl. One can be sure that CPAN has a Perl library fit for your needs, but having such features in the standard library makes a big difference for a newcomer.

The same could be said in the devops context with Ansible vs Chef/Puppet. Ansible joined the game pretty late, but it's attracting a lot of users because of its "batteries included" philosophy. But this battle is still ongoing and only history will tell us the winner.

> having such features in the standard library makes a big difference for a newcomer.

And not just for the newcomer. The biggest benefit is that your dependencies and your dependencies dependencies can all compose better when they're all using the same standard implementation of feature X.

The extreme case of this problem was c++ in the bad old days when lots of organizations were writing their own String libraries. Inevitably, you'd add a dependency that pulled in yet another incompatible string implementation.

Notice that there is no difference to the programmer. Whether the problem lies in the library or language itself is irrelevant.

It sounds like what he wants is more "wolfram language" than an actual programming language. So there are efforts in that direction.

(Personally, I'm working on large systems, programming rather than plumbing. What matters is not what datatypes are built in but how easy it is to add new ones in library fashion. So I'm very happy with Scala; look at what Spray does with HTTP to show how a really powerful, flexible language can express domain constructs).

"mostly due to all the Objective-C/Foundation heritage".

Huh?

Objective-Smalltalk (http://objective.st) is also based on Objective-C/Foundation:

1. Hello World

    stdout println:'Hello World'.

in fact since it's an expression language, you can also just write

     'Hello World'.

(Might change the quotes to double quotes at some point).

2. Sending e-mail

Have to admit I haven't implemented the mailto scheme yet, but will be 1 line or close to it once it's in. Can probably get there

3. GET/POST

   page := http://objective.st

Save page to disk:

   file:objet-home.html := http://object.st

PUT

   http://objective.st/index.html := file:newHomePage.html

I haven't implemented POST yet, it interacts with a bunch of other features that are in the works.

4. Days between dates

Whatever you did with NSDate ...

5. JSON

The http and file URL scheme handlers have cooked versions that will figure out the MIME type and translate for you, but I haven't full figured out complex literal syntax yet.

6. Modern Datatypes

Actually, Swift has a big fail here for the single numeric type. Objective-Smalltalk currently just inherits to Objective-C stuff (so fail), but a real numeric tower is in other Smalltalks and both a goal and achievable in ObjST.

Why they didn't do this in Swift is puzzling.

7. Package distribution

ObjST has always been heavily framework based, for example 'framework:' is one of the supported URL schemes. Now that we have frameworks for iOS, it's time to start thinking about a "cooked" framework scheme that can do name mapping to URIs for the source of that framework etc.

8. HTTP server

This serves the directory passed as an argument:

   #!/usr/local/bin/stsh
   #-<void>fileserver:<ref>dir
   framework:ObjectiveHTTPD load.
   httpserver := (MPWSchemeHttpServer serverOnPort:8081).

   server := dir ⇨ (MPWCopyOnWriteScheme memoryCache) ⇨ httpserver.
   server start.

This will serve "Hello World" from an in-memory scheme-handler:

   #!/usr/local/bin/stsh
   framework:ObjectiveHTTPD load.
   scheme:site := MPWSiteMap scheme.
   server ← MPWSchemeHttpServer serverOnPort:8081
   site:/hi := 'Hello World!'.
   server start.

Ooh, I'm seeing some non-ASCII characters here. How are you handling that? Can I use => instead of ⇨ and <- instead of ←? How do you usually type those? Is there a way of ASCII-ifying or de-ASCII-ifying source files?

Yep, the non-ASCII chars have ASCII equivalents.

They aren't finalized yet, as the whole "architecture connection/configuration" part of the language has barely been begun.

In fact, the non-ASCII chars are a recent experiment, but so far I like it a lot. Now that even shells and vi know about Unicode/UTF8, maybe it's time to take advantage of the rich typography we have.

I am typing those characters using a keyboard map I created in Ukelele.app (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=...).

The left arrows are mapped to Alt-[ and Alt-{ , the right arrows to Alt-] and Alt-}.