After developing software for 20 years, hearing the argument of ‘X language is better than Y’ gets a bit boring. At the end of the day, you can write shit code or good code in either language in the same way that you can build a shit house or a good house out of brick or stone.
No language will prevent a team of developers from building an un-maintainable mess no matter how good it is (and I have seen a few). Proper design skills and knowledge of ‘good’ software architecture will make or break a project every time. Stop getting hung up on languages.
Unless you’re being asked to develop in C (then I applaud you), then agree on a language that will still exist in 6 months time and then on with the difficult part...writing decent code.
I've seen thoughtful, well-crafted ColdFusion and PL/SQL applications and I've seen Swift code that was incomprehensible and unmanageable. I've seen beautiful PHP and ridiculous Python. The amount that the language matters is way out of whack with how much we talk about how much it matters.
Maybe. But that’s also a race to the bottom. And it’s not like you need many developers to get stuff done. The right team and autonomy to choose their tools can be way more productive that a big team
Only if you assume popularity is static. "Innovators", and then "early adopters" keep trying things to move it forward. Popularity is fickle and disloyal - i.e. dynamic.
To play devil's advocate, a software craftsperson would ideally use the right tools for the job. You could fire up Groovy and Spring for a REST API that essentially takes JSON from a source/sources, transforms, and returns... but there are easier languages and frameworks and much more performant ones.
The developers I've met with this argument have usually been doing one stack for many years and don't want to do anything new or uncomfortable. It's like watching someone try to cut brush with a butter knife.
I agree with you that being comfortable with a stack is not a good reason to use it. Developers need to keep up with emerging languages. Team leads also need to be doing this and provide direction. But as I said, there is more to the success of a project that the language and I think people get hung up on this. Yes look at all the options, but agree on a language/stack and move on. Also, give just a tiny thought as to whether you will be able to hire any developers to support the thing in 3 years. Boring yes, but kind of useful.
I agree with most of this but each language is different and each language encourages different things. I think the most important thing to do as a software developer is to research the problem domain before writing a single line of code and pick the language which fits the project most. I happen to use Kotlin because out of the languages I have experience with this is the one I'm most comfortable with and the one which fits my problem domains best.
Agreed, but do you think that a language that reduces lines of code considerably (lets say clojure vs java) is bike shedding or is part of using "good design" ?
No it's not bike shedding. The team should certainly choose the most appropriate language. Even if not all of them have experience in it. If they decide on clojure then go for it. But agree on something and move on.
Also, saving lines of code isn't necessarily the end goal for me in a language choice to be honest. Get rid of boiler plate code yes, but what I'd like to aim for is code that is easy for the next developer to understand and support as quickly as possible, whether thats 10 lines or 20 lines.
Reading the first article I was left with the impression that the author's team switched to Kotlin just for the sake of switching to Kotlin, tried their darndest to write it like it was Java, and then was just upset that it wasn't Java.
I read it as: the author was a Kotlin skeptic whose team wanted to use Kotlin, so was trying to find out whether they could use Kotlin for the sake of their team while still writing Java-like code themselves. Given how Kotlin pushers have been marketing it as close to Java with easier Java interop than other JVM languages (falsely if you ask me), that seems like a reasonable approach on the original author's part.
Doing the thing the marketing tells you you can do is only "setting yourself up for failure" if you know the marketing is bollocks. (And even in that case, it might be the easiest way to expose the fact).
You hit the nail head on. I don't think it makes sense to write code like language X in language Y. If you try to do so you'll just get upset and quit.
I find debates over "is language X good or is it bad" to be a particularly subjective topic in programming. Not that there's nothing objective you can say about them, but opinion pieces like these are always rife with personal preferences, and often (like in these two) interspersed with pettiness.
There are still legitimate tradeoffs that can be discussed.
For long, Kotlin has meant way longer compilation times. That's no longer the case (or at least way harder to determine, kotlinc is even faster than javac in some projects) but that was a legitimate bullet to bite 2 years ago.
Sadly I agree with the author of the second article, all the reasons given are very petty and I wonder how much of these 6 months were really spent writing kotlin.
I would say the "shouting at eachother" vibe comes more from the snarkiness of this post's content. I enjoyed it, but I understand that might not be everyone's cup of tea.
Both are speaking to an audience, and the point/retort approach is how most reasoned discussions occur, and how we move forward. Some see them as confrontational, and thus unsavory, which is unfortunate.
We can also have reasoned discussions directly with each other (as you and I are here). Here we may have an audience of other forum members, but the same audience can see the same back and forth (and contribute).
In my opinion, the 'speaking to an audience' via indirect blog posts doesn't really help us move forward as much as direct discussions do. Since we already had thorough discussions about this topic both here and on reddit, I don't see the value in this post.
I will admit that this type of indirect conversation isn't without its uses though. For one, I don't think the original blog author participated in the discussions here or on reddit. So our discussion boards were also indirectly attacking that post, without much room for the author to respond. Similarly, it's impossible to have a discussion with everyone you disagree with. Sometimes the best you can do is state your opinions, and let people consider them as they will.
I guess a better statement I could have said earlier is that we already have a forum (right here) for discussion of articles, and we don't need the disconnected responses-via-blogposts, because we can just discuss things normally here.
I'll try not to spam too much and just reply to this one comment to address the feedback around here about the technical aspects of the site.
- Yes, it's a completely pointless web app in the place of what could be a very simple, quick, and well functioning static HTML site. I'm using it as a hobby project to test drive a framework I'm working on. I do desparately need feedback on it, so thank you for everyone who's reporting issues!
- Yes, I didn't have time to do any compatibility testing, so right now I only know that it works alright in Chrome. There are probably things that are very easy to fix (e.g. not using those couple functions that are missing in Edge), I'll have to look into these later.
- I don't know if I can solve the port issue yet, I understand that random ports besides 80 and 443 are often blocked, I've actually ran into this just trying to access my own site already too. I only have this one domain and one server for it so far, and I need separate ports to serve the app and to expose the API it talks to. I'll have to think about how I can solve this later.
From your answer I guess you have a static web server on port 80 and another one on port 8443. The URL of the JSON starts with /public so I guess it's completely static.
If you can setup the second web server then you're probably in control of the server. How about reverse proxying an /api URL to localhost:8443?
If you can only run another web server on 8443 and can't modify the configuration of the main one on port 80... You simply serve the static JSON file from port 80. This is too easy so you probably can't do that. Do you have an application serving those files on 8443? Maybe run it once to create a file and store it where the web server at port 80 can serve it. Some small script with curl should be enough.
You know what the world really needs? A way to share text & optionally images with users across the net, without requiring them to execute untrusted & possibly-broken code.
FIrst article was an opinion and second article response is also an opinion in Kotlin defense. Opinion here is very subjective with problem at hand. Switching from one language to another should happen after you fall in love with what that language was offering not just for the sake of trying. Not a good idea to waste time trying without loving it.
> Various small sample surveys have been done to ascertain if arranged marriages or autonomous marriages have a more satisfying married life. The results are mixed - some state marriage satisfaction is higher in autonomous marriages, others find no significant differences.
"And it's about 7 extra characters in a line of this length."
(regarding the example from "Class literals" sections)
Well, the Kotlin line is still shorter overall, despite the ".java" bit, because it allows to get rid of "new" keyword (two of them), and to replace the first occurence of "GsonBuilder" with "val".
Could just be me but the site appears to have been Slashdotted (sorry -- inspired to use a throwback term based on the other HN story about WebDav).
Assuming this is a story about Android development, there will be the sequel: "From Java to Kotlin and Back to Java -- before surrendering to Dart and Flutter." :-)
No language will prevent a team of developers from building an un-maintainable mess no matter how good it is (and I have seen a few). Proper design skills and knowledge of ‘good’ software architecture will make or break a project every time. Stop getting hung up on languages.
Unless you’re being asked to develop in C (then I applaud you), then agree on a language that will still exist in 6 months time and then on with the difficult part...writing decent code.