141–150 of 185 posts
I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problem…
Earlier quoted context omitted.
What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.
Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
Earlier quoted context omitted.
The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
And you don't need tests to make sure the assertions are there?
Earlier quoted context omitted.
What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.
You might find https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... enlightening (note that in modern typed languages there's a lot less overhead to using type technique than there is in Java - but even in Java you can do some of this stuff)
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.
Earlier quoted context omitted.
The Kotlin reference is not supposed to be used for finding methods. The way to go is to use auto completion in an IDE. If you type `myArray.sort `, you get all one needs, including `sort`, `sorted`, `sortBy` (which you needed). Alternatively you could search the reference page for Array or MutableList or MutableMap, not sure what you wanted: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinl…
I had something like this: var heights: Array > = ... //populating the array heights.sortBy { it.second }; It was not obvious at all that I had to use curly braces. The documentation says: inline fun > MutableList .sortBy( crossinline selector: (T) -> R?) (source) This is after I figured out that I'm not supposed to use sortWith (I never figured out how to use this one)
The docs are arranged in a way that one reads them in the order they are written (at least the first half). I supposed that would take more than half an hour given at the competition.
I don't think Kotlin is the best choice for programming challenges like codeforces - they really don't let him shine (although I use it whenever I can). But if this is a valid case, we can collaborate and write a short tutorial for C/C++ to Kotlin programmers.
I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problem…
There are other articles like that, of course.
Earlier quoted context omitted.
You might find https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... enlightening (note that in modern typed languages there's a lot less overhead to using type technique than there is in Java - but even in Java you can do some of this stuff)
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.
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.
Earlier quoted context omitted.
The line about "Kotlin comes from industry, not academia. It solves problems faced by working programmers today." is pretty naked anti-intellectualism IMO.
You have a lower standard for anti-intellectualism than I do, I guess. From wiki: > Anti-intellectualism is hostility towards and mistrust of intellect, intellectuals, and intellectual pursuits, usually expressed as the derision of education, philosophy, literature, art, and science, as impractical and contemptible. ... In public discourse, anti-intellectuals are usually perceived and publicly present themselves as c…
Earlier quoted context omitted.
Sometimes I think I should change that paragraph because it too often gets interpreted as generically anti-academia, which then triggers people who think I'm anti-intellectual. Note the very important part of that statement: It solves problems faced by working programmers today . Academic PL research can have that property. Pizza went on to be the foundation of Java generics, there's a ton of excellent compiler and G…
> And of course a few of the ideas in Haskell A few? Don't you feel like you're underselling the impact Haskell had had on other languages? > he only language that came out of academia in recent times which has serious production usage is Scala, What are your qualifications for serious production usage? Would ocaml count by your standards? Haskell also has increasing production usage, though I'm sure you don't count…
What are the key ideas that make Haskell unique? I'd say they are pure functional by default, lazyness by default, an extremely terse syntax that relies heavily on symbols, effects in the type system, type classes, and a few other smaller things. As a non-Haskell expert at least, these are the ideas I associate with the language.
Writing code in a more functional style is steadily becoming more popular, but functional by default does not seem to be the choice of any modern language targeted at the mainstream. Swift, Rust, Kotlin, Ceylon, Go are all examples of industrial languages developed outside of academia that do not follow this design choice, and their functional programming support primarily consists of map/filter/fold/etc type methods on collections and sometimes (as with Kotlin/Java) a lazy sequences library. Meanwhilst, whilst often convenient and intuitively helpful, the evidence that fully pure functional code is of much higher quality than mixed or mostly imperative code is ... lacking. Certainly it's difficult to get clear evidence without controlling for other factors like experience of the programmers.
Lazyness by default is an equally un-influential choice. It seems Idris is the newest cutting edge academic pure FP language and it's strict by default. Lazyness by default creates an entirely new class of bugs that developers didn't have to think about before, for little obvious benefit (it lets you write in a certain style more easily, but does that style really give better software? again, it's difficult to get robust data on this).
The extremely terse syntax that relies heavily on symbolic operators is widely regarded as a bad choice. Modern industrial languages like the ones I named have all shunned this type of design and Kotlin, for instance, doesn't let you define arbitrary new operators. Haskell code is often rendered much harder to read than necessary due to its abuse of symbolic operators.
Effects in the type system do feel nice, but the impact of this idea has likewise been limited. You could argue that Rust's borrow checker is perhaps somehow inspired by this, although it's sufficiently different that I'd describe it as original work rather than idea that comes from Haskell. Other languages haven't focused on it so much.
I suspect the next idea to cross over from Haskell will be type classes, or a variant of them. But probably as an obscure feature not many people use, rather than a fundamental building block as in Haskell.
All in all, given the level of attention Haskell has received for many years, I feel its ideas have had surprisingly little impact.
With respect to "serious production usage", that was obviously a lax description. As far as I know there's much more usage of Scala in the non-academic world than O'Caml or Haskell, but it's still quite a small amount relative to languages like Python or Java. I don't have any specific thresholds, it was an intuitive description.
> In an existing language that uses null pervasively, it would be hard to get a critical mass of legacy code which uses optional.
Exactly, but that's what Kotlin is trying to do through its auto-convert from Java to Kotlin, the backwards compatible type system, support for nullity annotations and so on. It's got the closest yet.
Earlier quoted context omitted.
The Kotlin reference is not supposed to be used for finding methods. The way to go is to use auto completion in an IDE. If you type `myArray.sort `, you get all one needs, including `sort`, `sorted`, `sortBy` (which you needed). Alternatively you could search the reference page for Array or MutableList or MutableMap, not sure what you wanted: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinl…
I had something like this: var heights: Array > = ... //populating the array heights.sortBy { it.second }; It was not obvious at all that I had to use curly braces. The documentation says: inline fun > MutableList .sortBy( crossinline selector: (T) -> R?) (source) This is after I figured out that I'm not supposed to use sortWith (I never figured out how to use this one)
inline fun > Array.sortBy(
crossinline selector: (T) -> R?) (source)