Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Swift take another step up the programming language ladder

medium.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Go and Swift take another step up the programming language ladder

#51

Post by bjz_ »

Animats wrote: post #50
bjz_ wrote: post #46

Earlier quoted context omitted.

The semicolon as a statement separator is such a lovely thing that it would be hard to imagine Rust without it. It's sad to see that Swift and Go have gone with a statement based approach as opposed to emphasizing the composition of expressions. They feel very clunky in comparison.

The semicolon as a statement separator is such a lovely thing... That particular convention goes back to ALGOL-58. In ALGOL-58, semicolon is a statement separator. See page 14 of the ALGOL-58 report: http://www.softwarepreservation.org/projects/ALGOL/report/Al... C goes the other way, with semicolon as a statement terminator. 56 years after ALGOL-58, we still don't have convergence on this. Wikipedia has a table: htt…

Oh interesting, I didn't know that ALGOL had that. Looking through the Wikipedia pages, it seems that Rust most likely gained it via the ALGOL->ISWIM->ML->Ocaml->Rust route. I hope it catches on in more imperative languages in the future. After using it for a while, statement terminated syntax feels so clunky in comparison. I love being able to break out into a block like:

    let foo = {
        /* do stuff */;
        some_expression
    };

Re: Go and Swift take another step up the programming language ladder

#52

Post by sanderjd »

bjz_ wrote: post #45
sanderjd wrote: post #11

Earlier quoted context omitted.

I think Swift is a great language, and that creating something new that incorporates some very good ideas into a package that works well with their existing and extensive runtime made a lot of sense, but that tying it to their platform is a damn shame (though not unsurprising). I don't think the languages you list would have been a great fit, but D would have been a really good and interesting choice. Were it more ma…

One of the big things for Apple was Objective-C compatibility, which is surprisingly hard to get right. I know because I have been trying to wrap the APIs for Rust. Don't get me wrong: I still would prefer to use Rust on iOS, but Apple has too much invested in their Objective-C APIs to force a subpar experience and migration path onto their developers.

You certainly know more about this than me. Do you think Rust would have been fundamentally more difficult to make compatible with Objective-C than Swift was, assuming Apple had invested the same amount of time and effort? My sense is "no", but I really don't have any clue, and I'm genuinely curious.

Re: Go and Swift take another step up the programming language ladder

#53

Post by Someone »

Animats wrote: post #49
Someone wrote: post #42

Earlier quoted context omitted.

"It seems that the one scripting language feature programmers really wanted type inference for local variables." Other features that I would put in that category: - string interpolation - a repl-like environment (fast startup, interactive, not requiring one to define a function or class to get some output) - convenient syntax for initializing arrays and hashes - generics as a most-of-the-time substitute for weak typi…

There is convergence on hashed dictionaries as a basic type, and syntax for subarrays. Generics are still up in the air. Templates got so complex in C++ that they ate the language. Go avoids generics, but that leads to over-use of the any type ("interface{}" in Go) and reflection. Rust is somewhere in between. A REPL environment is more of a tool chain issue than a language design issue.

"A REPL environment is more of a tool chain issue than a language design issue."

Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world".

Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type

   P = "Hello, world";
but I would call that doing language redesign.

Re: Go and Swift take another step up the programming language ladder

#54

Post by putterson »

Someone wrote: post #53
Animats wrote: post #49

Earlier quoted context omitted.

There is convergence on hashed dictionaries as a basic type, and syntax for subarrays. Generics are still up in the air. Templates got so complex in C++ that they ate the language. Go avoids generics, but that leads to over-use of the any type ("interface{}" in Go) and reflection. Rust is somewhere in between. A REPL environment is more of a tool chain issue than a language design issue.

"A REPL environment is more of a tool chain issue than a language design issue." Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world". Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type P = "Hello, world"; but I would call th…

Actually, I really enjoy using Groovy as a Java REPL, when having to use Java. Your code is run in a Script class

Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV

Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groovy Console)

  > P = "Hello world!"
  Hello world!
  > sub = P.substring(5)
  world!
  > sub ==~ / wo.+/ ? println("World") : {}()
  World

Re: Go and Swift take another step up the programming language ladder

#55

Post by vorg »

putterson wrote: post #54
Someone wrote: post #53

Earlier quoted context omitted.

"A REPL environment is more of a tool chain issue than a language design issue." Moreof, maybe, but it is language design, too. If you had a Java REPL, you still would have to type quite a bit of stuff (a class and a function) before you would have your "Hello, world". Yes, you could add an implicit class named GLOBAL that magically gets a property named 'P' the moment you type P = "Hello, world"; but I would call th…

Actually, I really enjoy using Groovy as a Java REPL, when having to use Java. Your code is run in a Script class Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groo…

> Most java code is valid Groovy code

Up to Java 7 you could say "most" but why not "all"? Was it too difficult to test full compatibility? Why is the == slightly different between Java and Groovy, and the rest of the little differences which only confuse? And as for your example it doesn't look in the slightest like Java...

    P = "Hello world!"
    sub = P.substring(5)
    sub ==~ / wo.+/ ? println("World") : {}()
Why wasn't Groovy updated so most java 8 code is also valid Groovy code? And why didn't you actually post some code to do something useful like "configure a transformation from XML -> CSV" instead of creating a HN login to post a meaningless syntax sample?
Post reply on HN