One very simple reason why - even though your code is very smart - I dont want it as a custom function is that I work over many small companies. For me to carry code between companies is bad news, I try to use my own IDE where I go - but that is not even always possible. Long story short - this way I have to define it in 20 places, 20 different namespaces… 19 more places for confusion… many more people to explain it to… for something that is as obvious to other languages (that I work with) as doing 1 + 1…
Considering that it went through 3 iterations while a Kotlin array operator would be standard… And then you have to remember to include, name it… or start having multiple copies… call me greedy - but I prefer it to just be there whether I gradle something or not.
FYI… this code executes 2.666 times slower than Kotlin native methods. This is substantial in high looping situations. But till there is a better construct I am at least going to use it in the annotations bit… those get parsed and proxied once (normally)… so I am considering using it. Thanks.
An annotation parameter must be a compile time constant… (Homer) doh! So it is not working for annotations.
In other words… back to my point - smart workarounds are still, workarounds; Kotlin gods - hear my song. Thanks and cheers. Don’t be offended if I don’t follow this thread any longer - I started it… now it ends for me.
You need to learn that people that reply to you are not attacking you and you do not need to get defensive. All I was saying in my reply was that IF there were special syntax that { } would not be a good choice since there could be ambiguity with lambdas.
Thanks @dalewking and apologies if I upset you. On internet threads - I make my tone slightly more aggressive to avoid thoughtless comments/opinion. And unfortunately - where a cosmetic want is concerned - there isn’t too much fact involved as the language implements it already (we believe in OOP; I will show you best paid devs that still use structured Cobol which you in a million years cannot convince otherwise →
I find that you get less stupid comments by the tone; and people that don’t really care but still like to give an opinion avoids the conversation; and people who do care - is willing to debate even if more heated - which - win or lose you take it. All considered - I think the points and code raised by the thread to be of decent quality, even pointing out a thing or 2.
If there is something that western culture (I am western cultured myself) has instilled is that everybody has an opinion; sadly everybody thinks its relevant, good, or factual and believe in it. I heard James Blunt say it best - an opinion is like an arse - everybody’s got one.
On your bullet 1:
I do not add the operator. Kotlin adds it… so they obiously have to choose it with their bigger view in mind. I merely fight the case - and like said many times over… I am not too fussed about the actual symbols (that will be a natural process I think) as long as it is balanced. Can even go the F# route for all I care… By visually balanced I mean, { } ( ) < > or / combinational (there are a few in there that will never work - but it is just to make the point)
On your bullet 2:
The parser need to parse array like structures all over the show. In all fairness, it has to parse the arrayOf… that is 8 characters in width, a symbolic operator, 1 or 2 characters! So no, the guys at JetBrains - the complexity in implementing this is light years below what they have done till now already; and if you count 8 characters of parsing vs 1, it should be quicker both for parsing and typing. + throw in there the fact that while typing an “a” your IDE may give you a 1000 type suggestions, make the case for a symbol even stronger
On bullet 1 and 2… for me it is very much about readability of the code. My eyes, in my line of coding, catches operators, string constants, numeric constants quickest and my eyes pan out from that. The longer the construct, the shorter it forces me to make my variables - and the more function like it becomes the longer it takes for me to focus to them… here is a Java 6 example:
what happens is that people either start to break the line, or alternatively … start to shorten the variable name… neither of which have happy consequences toward the flow and readability of the code.
So Kotlin (and most modern/revamped compilers) infer the type from the declaration/expression and hence make the code shorter. So why, for the love of a primitive array… make the code - Longer (or perceived functional for that matter)?
I think a general construct for List/Array creation is overrated. The only place where such features excel is in example code. Oh great I can write ["oranges", "apples", "bananas"], but in my real life application collections come from user input, config files, datastores and other dynamic sources. I simply don’t have that much static collections. A method or constructor will do just fine for those cases.
There is however the exception of annotations, as pointed out in this thread and a lot of other threads and discussions. But I don’t look at this as a need for a special construct for array creation, rather I look at this as way to see al the arrays in annotations as varargs. I wonder if the grammer allows or can be extended to understand things like:
@MyAnnotation( foo = 1, 3, 5; bar = "1")
fun baz()
Good for you Mr @mplatvoet . As I said before to another threader - is that if you don’t use it - then what is the point having a quarrel about it?
To counter your point - I however regularly work with various constructs that have great value in this type of const array definition. One good example - that is not an annotation, is defining the array of fields necessary for CSV/TSV parsing. I also regularly work with custom hash algorithms and replacement values.
I agree - I find this to be very good for example code, but at this very moment in time I am sitting with about 18 different formats for text process parsing… and arrays are working sweetly for these - also partly due to the fact that it plays nicely to varargs with the * operator.
And why is it good for example code I ask you? Are you half alluding to the fact (in my mind anyway) that it reads better than arrayOf… or should I not probe that hard?
The point of quarrelling about it is that every language feature that is added is a potential extra layer of complexity to the language. So I think that every feature added should be well considered and not just blindly added because some people prefer the aesthetics.
What I meant by “example code” is that it’s usually a showcase for how concise you are able to write things while they usually hardly occur in production code thus rendering the construct rather obsolete.
In all honesty - don’t you think the fact that Kotlin went against the grain of other (like mentioned above) leading commercial languages that follow a symbol pattern -already added complexity to the language - and that for newcombers (which is pretty much most people at this stage for Kotlin) - that having the construct similar to Java, or C# may have been advantageous and added less complexity in switching?
I am not asking here that generics gets reified (I would like it to be… but understand that that is a mammoth undertaking)- I am asking for something that is very very small - aesthetically pleasing and closer to Kotlin aims of shorter code, current - and more productive code especially where annotations are concerned.
I have already presented to you that there are various good reasons for doing arrays apart from exercise/demo code - so I rest that one.
@mplatvoet
I don’t know why I am trying to convince you…? the ball is already in motion on YouTrack. Many people voted already… Now it is just a waiting game to see what the guys at JetBrains do with it if anything. So lets wait and see… if having an array symbol is the downfall of Kotlin then you can blame me.
You should really learn to use a different tone of voice. Your way of communicating doesn’t avoid thoughtless opinions, it simply avoids you.
Voting is just a way to get some attention to the issue. It doesn’t have any decisive meaning. Arguments are needed for language features, both opposing and proposing. And that’s what people in this thread trying to do: getting the arguments out there for why this is both a good and a bad proposal. Maybe there are some arguments that the guys and girls at Jetbrains have overlooked. So don’t be offended if someone doesn’t blindly accepts your position, it doesn’t even mean that someone disagrees with you. So it’s not at all about convincing people.
So about the topic of arguments you make a fair point that other mainstream languages have this feature, so I most certainly agree that it can help adaptation of Kotlin as it will be a familiar construct for developers. However familiarity is not something that may be a decisive argument. There was a time when every language had a goto statement and was considered a necessary construct. Now we can do without.
Every opposing view i have answered with good examples and questions into what you think is suggested. I am a working man - working for myself - for every minute wasted I PAY FOR MYSELF - so my time is precious - I don’t get into the threads for the sake of having an opinion - I go in there to get something. So answering and debating something to this extent is not easy for me.
The fact that there is no counter argument coming back on most of these issues is not due to the tone of voice - it is due to the fact that the line of reasoning is killed off.
So if you lose an argument - don’t be offended - simple as that. Cheers.
Also… please state one place where I offended you personally - instead of giving alternative reasoning to your argument?
On the contrary - I gave you a compliment about your reified example - which sadly does not work with annotations - which to me yields that you are the one becoming personal.
Like I said about 15 posts ago. I was willing to rest it.
You did not offend me. It’s just that your tone of voice makes it harder to react to the actual arguments in your posts, yet it makes it far easier to just interpret them as none constructive. You seem to think of all this in terms trying to win arguments. It’s no competition, we’re not looking for the best debater. Like I said it’s just about getting as much arguments out there, both proposing and opposing.
So what we’ve got right now is: proposing
familiar syntax
better interoperability with annotations
readability
opposing
new syntax, parser/language complexity
harder to type in other keyboard layouts
other remarks
is this Array only?
is this mainly an issue for annotations?
should special syntax be available to every collection type?
what syntax should be used?
A probably missed some arguments or remarks so feel free to add.
Ok. Then I probably need a bit of education on the pace of this type of thread. The usual threads you have to make your point thick and fast while teaching somebody to declare an array while still having to defend your argument from the same person; who has had a smarter idea
You summed it up nicely.
Proposing… 100% agreed
Opposing… The thread has lifted out these issues nicely. You kind of never can be good for everybody on the keyboard layout however.
Other Remarks:
Array only - yes in my mind - opening this conversation towards other types will make this discussion exponentially more difficult. (Maybe another thread needed)
Annotation - best value there quickest - BUT the implementation may lead to array inconsistencies. Hence the reason why I tackled it from an array point of view rather than an annotation pov. This is the case for Java. There is inconsistency between declaring an array and setting an array annotation parameter. This Java “smartness” is also one of the big complaints and reasons why many newcomers struggle to adopt Kotlin (as they never knew it was an array to start off with). For me it is not about that - even though I can understand the frustration.
