6 ms·
Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor
by skocznymroczny 7y ago
Personally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until build time).
Most people will tell you, "oh just use auto, it makes the code more generic". That's sweet, except as soon as I want to pass it to another function, I need to have the concrete type. Like you, I usually just copy-paste the full type from the error message and move on.
- stcredzero 7y agoPersonally I dislike var/auto in languages because I like having types explicitly written. But in case of languages like Java or Kotlin you can move the cursor over the variable name and you will see the type, also you can right-click and select "replace with explicit type" and it will work. In D, IDEs struggle with templates and can rarely index templated code (no wonder, because most of the code doesn't exist until build time). It's 2020. Why couldn't things work like this, where one can open a window for a concrete type using templates, and it shows the code?
- kevin_thibedeau 7y agoA well designed language should be usable from a text editor. Even in 2020.
- qqssccfftt 7y agoA good dev uses an IDE. In 2020.
- snazz 7y agoThis is a really tired argument that we don't need to get into right now. Different things appeal to different people.
- qqssccfftt 7y agoAnd text editor users are wrong.
- entropicdrifter 7y agoTwo things can be true. You shouldn't need an IDE to grok the code.
- petee 7y agoA good dev shouldn't require crutches
- Dylan16807 7y agoInteractivity is not a crutch.
- petee 7y agoInteractivity is a base attribute of an ide, and not the first reason people use it; the context here is that using an ide doesn't define a good programmer. So being able to clicky click is what makes good programmers to you?
- Dylan16807 7y agoThey said that good devs use IDEs, not that IDE use makes you a good dev. Those are very different statements.
- petee 7y agoThey said "A" good dev uses an ide, and a snappy 'in 2020' retort. It's plainly clear their intention is to imply only good devs use ide's in the modern era.
- Dylan16807 7y agoNo, that's not how simple if statements work. I don't know what else I can say. If I say "A good CPU has more than two cores in 2020." then I'm just saying it's a requirement, not sufficient all by itself. I'm not calling a twelve-year-old phenom X3 a good CPU. The "in 2020" is just to emphasize that anyone failing this standard is falling behind the times.
- deleted 7y ago[deleted]
- harikb 7y agoI agree. I will paraphrase this as - a well designed language should be usable, at minimum, from a pure text editor, and should not put unreasonable burden on an IDE.
- shrimpx 7y agoThe cynic in me wants to say that such a language doesn’t lend itself to static analysis. As soon as you can do great things with static analysis you can build those features into an IDE, therefore causing the “pure text editor” to feel crippled giving rise to the idea that this language is “unusable from a pure text editor”.
- skocznymroczny 7y agoTemplates don't exist until compile time, until you build the code, the IDE plugin doesn't have the full data on what types exactly are there. Java/C# generics are more limited in functionality, but it's a tradeoff in exchange for better ahead of time knowledge of types.
- pjmlp 7y agoVisual Studio can do that, you just provide an example type and the IDE shows what the result would be. https://devblogs.microsoft.com/cppblog/template-intellisense/ https://devblogs.microsoft.com/cppblog/template-intellisense... Now try that on vim.
- hiq 7y agovar/auto is a trade-off which requires good tooling support, as you said. Once you're able to see the types as you see fit in your IDE, I feel that you're mostly better off, for all the reasons already mentioned in the thread. Of course good tooling is still a big requirement, but I still think it's the best decision in the long-term: it's way easier to improve and change tools like IDEs (especially with LSP?), rather than the language itself. Regarding explicit types in functions, you also don't always need them in languages such as OCaml. I feel that the answer to your criticism could be to just have "auto" also for function arguments, especially when you're just prototyping.
- johannes1234321 7y agoIn places where you need to know the exact type auto probably isn't the right choice. There are many cases where the type is clear however or irrelevant or in generic code is hard to express (thus depending on documentation/comments unless obvious) which would also be hard to read.
- hibbelig 7y agoIn Java, `var` comes in useful at times. For example: for (Map.Entry<SomeLongType, AnotherLongType> x : someMap) { final SomeLongType key = x.getKey(); final AnotherLongType value = x.getValue(); ... } In the above code snippet, `var x` would have been very useful because the actual type just repeats information that can be found in the next two lines. Also, usually, I'll use more speaking names instead of `key` and `value`. But if the body of the loop just refers to `x.getKey()` and `x.getValue()`, without extracting them into local variables, then it makes sense to put the exact `Map.Entry` type into the loop header.
- enitihas 7y agoYou can just use map.forEach and avoid the types in the next two lines too.
- jerven 7y agoIn java 10+ for (Map.Entry<SomeLongType, AnotherLongType> x : someMap) { final var key = x.getKey(); final var value = x.getValue(); ... } Is valid.
- hibbelig 7y agoI prefer to put "var" into the loop header because the combination of two types is hard to read. It's easier to read (for me!) when the type of the key and the type of the value are separated, like they are on the first two lines of the loop body. for (var x : someMap) { final SomeLongType key = x.getKey(); final AnotherLongType value = x.getValue(); ... }
- Pxtl 7y agoHard disagree. MyClass myVar = new MyClass() is not DRY. It also makes it practical to use complicated structures out of generics/templates without killing the developer With<Deeply<Nested,Template>, Declarations>.
- choward 7y agoHard disagree. If you are assigning a value that's the result of an expression you might have somewhat complicated logic. Being able to say what you expect returned is very useful. MyClass myVar = something ? SomeFunction() || somethingThatMightBeASubClassOfMyClass
- Koshkin 7y agoAnything wrong with var myClass = ... (or some other descriptive name of the variable)?
- Pxtl 7y agoPersonally I prefer this, since it also carries on to every following line. Like, in C# List<Account> accountsToDelete = accountService.GetAccountsToDelete(); repository.Delete(accountsToDelete); becomes var accountsToDelete = accountService.GetAccountsToDelete(); deleterService.Delete(accountsToDelete); So as much type information is already encoded into names so that all references to this object are clear in what we're handling, and so the type declarations at the point where the variable is declared is just redundant noise. If your variables aren't informative when I'm reading the code, I'll be confused 5 lines later anyways. So make them informative at the start. And given that, doesn't that mean the List<Account> is a bit redundant?
- enhray 7y agoBeware the m_pszSlipperySlope [0]. [0] https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation
- 7y ago