151–160 of 185 posts
Earlier quoted context omitted.
The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
Earlier quoted context omitted.
I'm afraid I found it confused. For the tests the check types of values, that's just a dumb test that you shouldn't write regardless of the language. Then for rest of the post, he talks about having nicely-defined tests which is orthogonal to whether or not your types are static.
> For the tests the check types of values, that's just a dumb test that you shouldn't write regardless of the language. The thing is, almost all the tests you'd write in a dynamic language end up being something you can encode into the types of values.
Can you actually give an example of a test that would be realistically written in a dynamic language that would be something encoded into the types of values?
Earlier quoted context omitted.
> For the tests the check types of values, that's just a dumb test that you shouldn't write regardless of the language. The thing is, almost all the tests you'd write in a dynamic language end up being something you can encode into the types of values.
Almost all? That just sounds plain ridiculous. Can you actually give an example of a test that would be realistically written in a dynamic language that would be something encoded into the types of values?
Earlier quoted context omitted.
Almost all? That just sounds plain ridiculous. Can you actually give an example of a test that would be realistically written in a dynamic language that would be something encoded into the types of values?
You give me an example of a test that would realistically be written in a dynamic language then. I've been out of dynamic languages for so long that I've forgotten how to produce working code in them (seriously, I tried to write some Django because I used to be quite good at it and it seemed like a good fit for a specific problem, and I just wrote code that had stupid bugs everywhere).
There is a definition for the schema to a fruit table.
Fruit: {
list_id: 32
}
The actual options are populated from a list:
const LIST_OPTIONS = [
[32, "Blueberry", 1],
[32, "Apple", 2],
[32, "Orange", 45],
[45, "Nope", 1]
]
And for the actual test:
This actual sends the request to be processed.
let response = await processRequest({
type: 'QUERY',
table: 'Fruit',
})
deepStrictEqual(response, {
status: 'OK',
records: [{
id: "Blueberry",
name: "Blueberry",
position: 1
}, {
id: "Apple",
name: "Apple",
position: 2
}, {
id: "Orange",
name: "Orange",
position: 45
}]
Earlier quoted context omitted.
It still is. Kotlin advocates are just very loud, while Scala devs are busy shipping real-world software projects.
If Brainfuck had the marketing dollars that Typesafe spent then you would see real-world shipping Brainfuck projects. It wouldn't make Brainfuck a good language.
Earlier quoted context omitted.
You give me an example of a test that would realistically be written in a dynamic language then. I've been out of dynamic languages for so long that I've forgotten how to produce working code in them (seriously, I tried to write some Django because I used to be quite good at it and it seemed like a good fit for a specific problem, and I just wrote code that had stupid bugs everywhere).
Here's a test I wrote recently. The code in question is part of a nodejs service that talks to a database and produces json objects to be used by a web client application. There is a definition for the schema to a fruit table. Fruit: { list_id: 32 } The list_id indicates that this isn't a real table, but is actually stored in the list_options table. So my code has to generate a different query then for a normal table…
That aside, what pieces could actually go wrong in a statically typed language? You can't typo field names or the like. You could typo the names, but I don't believe typing them into the computer twice adds value - better to check them once in code review. People aren't going to be editing this code in a way that could lead to getting the names wrong.
You couldn't go down the wrong code path and end up with the "normal table" query, because having list_id instead of something else is part of the type. You couldn't pass some other number as the list id, because list ID is a typed thing that is different from all other IDs, and in any case where would an outside number come from? And you're definitely going to return a response that's formatted with a record list, because that's part of the type of the method. (You might need to test the JSON String piece, but that's generic, so you only need an O(1) test for that, you don't have to test every JSON endpoint. In practice you're likely using an existing well-tested library. Similar reasoning applies to the database querying part). Assuming you have warn-for-unused-parameters enabled, you couldn't forget to apply the criterion and just return everything in the list.
So yeah, assuming this was for part of an existing system where I'd already tested generic facilities like database access and JSON serialization, I wouldn't feel the need to write this test at all.
Earlier quoted context omitted.
Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.
Or Spring Boot, which is fantastic.
Earlier quoted context omitted.
Because the VM on Android devices runs only Java 6 compatible bytecode.
Alright, so basically using Kotlin for PCs could possibly expose one to known critical security vulnerabilitys in Java 6? EDIT: On the other hand Java 6 byte code might run just fine under I.E JRE 8?
Earlier quoted context omitted.
And you don't need tests to make sure the assertions are there?
Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)
I've switched from Scala to Kotlin after 8y of Scala. There are some things I miss (e.g. Options and Futures) but Kotlin feels much more focused on real world problems. And Gradle is so much easier than the monster that is SBT.
Totally is, but I've had better luck using Maven than Gradle. Having multiple mutually compatible options is great.