timclark

Also, don't edit your bash profile when drunk! In my youth I did this and it took 3 weeks to return to normality - I didn't know about source code control in those days.

There is no major difference between a nullable type and a maybe - the big difference is between non-nullable types and maybe. If you have a maybe I in my ignorance can assign a null to it, if you have a non-nullable type the compiler will prevent me from assigning a null to it.

Some of the smaller decisions the Ceylon team has made also seem nicer than the Kotlin equivalent. For example I prefer the Ceylon "if(exists x) {}" to the Kotlin "if(x != null)" - even though the Ceylon is further from the Java syntax.

Kotlin is a very nice replacement for Java but I really like the ambition and thought being shown by the Ceylon development team. I sure do hope that they get an IntelliJ plugin completed sometime in the future.

Would that be clojure?

To incompletely quote Rob Pike: "If crypto is so hard that only one implementation is allowed to exist, it's crypto that needs to be rethought"

https://groups.google.com/d/msg/golang-nuts/0za-R3wVaeQ/M8_B...

Why do crypto people only want there to be a single C implementation of everything?

Me too! May be they want it to look that way?

And surely it would be better to have many implementations than a couple?

Unless you need to go to the toilet it is probably more comfortable to stay in your car.

Not being able to get out of your car in an emergency would be a bigger problem.

See here: http://ceylon-lang.org/documentation/1.0/roadmap/

I hate to say it because I like JetBrains and have given them lots of money over the years but I prefer Ceylon to Kotlin. They are very similar languages but I just like the Ceylon syntax more.

If you like Kotlin also look at Ceylon from RedHat. In some ways very similar to Kotlin with null-safety and improved generics.

What is it with all these web pages stealing my back button lately? This site adds three pages to my browser history for one click.

Also, in my totally non-objective opinion, the font used on that page feels really shouty to me.

Doesn't go just implement Hoare's communicating sequential processes, as does Erlang? They share the same inspiration.

You don't need to share state data between your goroutines if you don't want to either just like you don't have to use mnesia to share state between erlang processes if you don't want to.

I don't think you can really accuse go of being a cargo cult language either, Rob Pike has implemented CSP multiple times (http://swtch.com/~rsc/thread/).

go does have file organisation. You can create packages in directories and nest them and the tooling will handle it easily.

Me too!

The go command will install third party packages from source code repositories if you know about them. There is a dashboard of packages on the go web site but I believe further work is needed for discovery on the command line.

Interesting, but worth remembering, as Rich Hickey says, every bug has got past both your unit tests and your type checking.

They keep going with the same level of quality until the very end. Even the three draft chapters of the unfinished 21st volume left me wanting more.

Or as in my experience as an EE, learn how to use Laplace transforms, find a table for the 2nd order differential equations, use Laplace transforms, forget how to solve differential equations.

Things I like about Go:

The compilation speed is super fast which makes it feel like you are developing with a scripting language as opposed to a statically typed language. I typically edit code, run the tests and correct my errors without any noticeable time lost waiting.

The Go parser and pretty printer are exposed as a libraries in the Go distribution which allows for interesting meta-programming.

Plain old Java compiles way faster than Scala I don't believe the JVM is the main contributor to the slowdown.

Scala compilation is complex, partly due to its extremely sophisticated type system, it is also quite resource intensive - I have got the type checker to run out of memory on multiple occasions I have never seen a Java compilation fail due to lack of memory. fsc and incremental compilation do speed things up but it is still slower than compiling an equivalent amount of Java.

If it compiles faster than Scala I will use it!

From reading the language specs it seems much more pragmatic than Scala (as does ceylon http://www.ceylon-lang.org/ or fantom http://fantom.org/).

I think if JetBrains thought that Scala was a better Java they would be using it instead of creating their own language.

Netbeans is less compelling now that we have IntelliJ CE but given a choice between Eclipse and Netbeans, I would choose Netbeans every time!

Eclipse has always seemed to me to be baroque and over complicated, for example why do I need to change to a specific perspective to perform a specific task?

DeMarco wrote Peopleware with Timothy Lister, Fred Brooks wrote The Mythical Man Month.

You can use undefined, the nearest equivalent to null in Haskell, anywhere you like and it is just as bad as using null! However, typically you don't because as you point out Maybe is a better alternative.

Congratulations on releasing the code! I am looking forward to using the algebraic types when you get them finished.

Most of the expensive CMS products have edit in place, so a user can just click and edit. This does come with quite a large overhead in pageweight in my experience.

Lots of Java development is carried out for internal business applications and like it or not they would typically be integrated with third parties using something like SOAP or a shared database. So in this type of application the choice of a concrete class over an interface probably has little impact on the known or unknown clients of your code.

However, as you point out, if you are presenting a Java API to your known and unknown clients you had better think carefully about which abstractions you are going to expose and interfaces are probably going to be very helpful.

But you understand interfaces, you have just given an explanation. The candidates I interviewed didn't explain themselves at all, I think if a language has a feature you should be able to explain when and when not to use it.

I think that all Java IDEs make it trivial to introduce an interface when it is required, so unless you are producing an API for consumption by a third party you should only introduce an interface when you have multiple implementations, or a third party can legitimately produce their own implementation, and not because you think you may have multiple implementations at sometime in the future.

Also if you have a single implementation naming it InterfaceImpl is just lazy, you almost always have more information that you can use to name it, it might be a InterfaceUsingJdbc or an InterfaceFileBased for example.

You don't have to create an interface! One of my favourite interview questions is why do you use interfaces in Java? The majority of people I interviewed said that it a good design used interfaces and had nothing more to say. In code review if you have an interface and only one implementation I'd make you remove the interface - I call this the unnecessary Impl pattern since the class is traditionally called NameOfInterfaceImpl.

Also you don't have to name property accessors getX() and setX() if you don't want to.