8 ms·

I think, in these days, it is not too much to ask for the intelligent completion, e.g. when you type dot or arrow, to get corresponding members of class/struct

by exim 14y ago

I think, in these days, it is not too much to ask for the intelligent completion, e.g. when you type dot or arrow, to get corresponding members of class/struct - the information is just there and the editor has enough power to parse it... Same goes for a very simple word completion - when the editor already encountered the word in the previous line. These are just _very_ basic things.

clintjhill 14y ago
But it's not. In fact intelligent completion is incredibly hard for dynamically typed languages. Those IDE that do perform intellisense or autocomplete with dynamic languages do it with very basic ability. In a real world dynamically written code file the editor simply has no way of knowing the members of a class. Or if it is even a "class".
- lyime 14y ago
  Sometimes the simples things are hardest to implement. Visual voice mail - No brainer, but took a decade.
- jamesaguilar 14y ago
  No one's saying it's easy, but enough IDEs have done it that some of us have come to expect it.
  - snprbob86 14y ago
    I started programming on VB3 and spent many years doing Visual C++ and C# as well as quite a bit of Java with IntelliJ. I depended deeply on IntelliSense/autocomplete. Years later, I don't remember how I ever got anything done with that stupid distracting drop down box. It's just so easy to arrow up/down through that list and hope to stumble upon the correct method to call. On the rare occasion that I type that member accessor dot and don't know what I want, I much prefer full-sized documentation in a browser that I can cmd+f on.
    - pbz 14y ago
      Using it as an alternative to documentation is a small part. First of all you get a confirmation that what you have up to that point is somewhat correct. If the dropdown doesn't show then something's wrong - sometimes that's ok and expected. You also get a type confirmation and actual completion as in type one or two characters and have the rest filled out for you.
      - snprbob86 14y ago
        It's just a different style of working, but I almost never type long symbols. I go to their definition site, yank them into a buffer, and paste them into place. Or, I work with a REPL. So I write the code there and run it before putting it into my code base, so I know it's correct.
  - bronson 14y ago
    Only for old and static languages.
    - jamesaguilar 14y ago
      Actually, Eclipse's Python support is decent. You can infer a lot about what a type is by what methods and properties are accessed. It's not perfect, but it can do a decent job of it in a lot of cases.
    - recursive 14y ago
      How old is old?
- chrisbuc 14y ago
  Unless that dynamic language is Google Dart. The Dart Editor's intellisense works just fine.
- astral303 14y ago
  IntelliJ does really impressive type inference in Groovy. I can write all sorts of dynamic code and it autocompletes surprisingly well. Not as great as Java, obviously, but impressive nonetheless.
- chokma 14y ago
  I am still looking for a Perl IDE which offers autocomplete - or at least the option to jump to where the currently selected method is defined. Something like the Groovy/Grails-support in IntelliJ - but of course, Groovy is somewhat easier to autocomplete because of the underlying Java class system.
rapind 14y ago
It all depends on your average typing / coding speed. Autocompletion doesn't offer a lot to someone who knows the language framework really well and type 90+ wpm. You may even find it's annoying more than helpful most of the time. I'm not that fast and to be honest I really don't miss code completion at all.
- jules 14y ago
  It's not so much about typing less as it is about interactively learning to use an API or codebase. Suppose you have a comment object and you want to get the body text of that comment. With autocompletion you can just type `comment.` and you'll immediately see whether it's called "body" or "text" or something else, instead of having to browse around the codebase (which incidentally is also easier in an IDE that understands your code, because you can put your cursor on the class name and press a "go to definition" key instead of having to find it manually). Another invaluable feature related to this is documentation as you type. I can never remember the order of the arguments to the fold function. Fortunately Visual Studio helps out: https://dl.dropbox.com/u/388822/intellisense.gif https://dl.dropbox.com/u/388822/intellisense.gif (somehow my mouse pointer shows up in white, which makes it hard to see, but if you hover over the variables you get type information & documentation).
  - rapind 14y ago
    To me what you're describing are imagined problems. They aren't real problems for someone who eschews autocompletion tools. No offence intended. I would argue that the autocompletion training wheels for learning a new API are really only useful if you're rarely going to use that API again. If you're going to be using it a lot, there's actual value in spending the extra effort to learn it's functions. It'll stick more. Unless you have a photographic memory your brain will tend to discard information it had to expend no effort on, and autocompletion basically becomes background noise. I theorize that a fast typist will gain the edge after using the API 10+ times, even if they have to look it up the first couple of times, because the additional effort and focus they had to give to the task will commit it to memory (and they will potentially learn more about what the API is doing). The focus is often on typing the fewest characters, but I think that's the wrong thing to focus on most of the time when choosing an editor.
no_more_death 14y ago
Dynamic languages are not ideal for huge code bases. But huge code bases are not ideal, period. Dynamic languages grant huge power to small programs. Greater power through less code is surely the future.
- spooneybarger 14y ago
  The work that http://www.vpri.org/ http://www.vpri.org/ has been doing around OMeta, Nile etc is really exciting. It is detailed in the later part of this Alan Kay presentation: https://www.tele-task.de/archive/video/flash/14029/ https://www.tele-task.de/archive/video/flash/14029/ ( around minute 45 or so up, perhaps earlier for more background )
- kamaal 14y ago
  Only if we consider future of problem solving involves writing code. Tool generated code, might be a big thing in the future. Eclipse + Java is already 80% tool generated code.
  - damncabbage 14y ago
    Steve Yegge has some interesting points to make about generated code: http://steve-yegge.blogspot.com.au/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.com.au/2007/12/codes-worst-enemy...

by exim 14y ago

clintjhill 14y ago

But it's not. In fact intelligent completion is incredibly hard for dynamically typed languages. Those IDE that do perform intellisense or autocomplete with dynamic languages do it with very basic ability. In a real world dynamically written code file the editor simply has no way of knowing the members of a class. Or if it is even a "class".

lyime 14y ago
Sometimes the simples things are hardest to implement. Visual voice mail - No brainer, but took a decade.
jamesaguilar 14y ago
No one's saying it's easy, but enough IDEs have done it that some of us have come to expect it.
- snprbob86 14y ago
  I started programming on VB3 and spent many years doing Visual C++ and C# as well as quite a bit of Java with IntelliJ. I depended deeply on IntelliSense/autocomplete. Years later, I don't remember how I ever got anything done with that stupid distracting drop down box. It's just so easy to arrow up/down through that list and hope to stumble upon the correct method to call. On the rare occasion that I type that member accessor dot and don't know what I want, I much prefer full-sized documentation in a browser that I can cmd+f on.
  - pbz 14y ago
    Using it as an alternative to documentation is a small part. First of all you get a confirmation that what you have up to that point is somewhat correct. If the dropdown doesn't show then something's wrong - sometimes that's ok and expected. You also get a type confirmation and actual completion as in type one or two characters and have the rest filled out for you.
    - snprbob86 14y ago
      It's just a different style of working, but I almost never type long symbols. I go to their definition site, yank them into a buffer, and paste them into place. Or, I work with a REPL. So I write the code there and run it before putting it into my code base, so I know it's correct.
- bronson 14y ago
  Only for old and static languages.
  - jamesaguilar 14y ago
    Actually, Eclipse's Python support is decent. You can infer a lot about what a type is by what methods and properties are accessed. It's not perfect, but it can do a decent job of it in a lot of cases.
  - recursive 14y ago
    How old is old?
chrisbuc 14y ago
Unless that dynamic language is Google Dart. The Dart Editor's intellisense works just fine.
astral303 14y ago
IntelliJ does really impressive type inference in Groovy. I can write all sorts of dynamic code and it autocompletes surprisingly well. Not as great as Java, obviously, but impressive nonetheless.
chokma 14y ago
I am still looking for a Perl IDE which offers autocomplete - or at least the option to jump to where the currently selected method is defined. Something like the Groovy/Grails-support in IntelliJ - but of course, Groovy is somewhat easier to autocomplete because of the underlying Java class system.

rapind 14y ago

It all depends on your average typing / coding speed. Autocompletion doesn't offer a lot to someone who knows the language framework really well and type 90+ wpm. You may even find it's annoying more than helpful most of the time. I'm not that fast and to be honest I really don't miss code completion at all.

jules 14y ago
It's not so much about typing less as it is about interactively learning to use an API or codebase. Suppose you have a comment object and you want to get the body text of that comment. With autocompletion you can just type `comment.` and you'll immediately see whether it's called "body" or "text" or something else, instead of having to browse around the codebase (which incidentally is also easier in an IDE that understands your code, because you can put your cursor on the class name and press a "go to definition" key instead of having to find it manually). Another invaluable feature related to this is documentation as you type. I can never remember the order of the arguments to the fold function. Fortunately Visual Studio helps out: https://dl.dropbox.com/u/388822/intellisense.gif https://dl.dropbox.com/u/388822/intellisense.gif (somehow my mouse pointer shows up in white, which makes it hard to see, but if you hover over the variables you get type information & documentation).
- rapind 14y ago
  To me what you're describing are imagined problems. They aren't real problems for someone who eschews autocompletion tools. No offence intended. I would argue that the autocompletion training wheels for learning a new API are really only useful if you're rarely going to use that API again. If you're going to be using it a lot, there's actual value in spending the extra effort to learn it's functions. It'll stick more. Unless you have a photographic memory your brain will tend to discard information it had to expend no effort on, and autocompletion basically becomes background noise. I theorize that a fast typist will gain the edge after using the API 10+ times, even if they have to look it up the first couple of times, because the additional effort and focus they had to give to the task will commit it to memory (and they will potentially learn more about what the API is doing). The focus is often on typing the fewest characters, but I think that's the wrong thing to focus on most of the time when choosing an editor.

no_more_death 14y ago

Dynamic languages are not ideal for huge code bases. But huge code bases are not ideal, period. Dynamic languages grant huge power to small programs. Greater power through less code is surely the future.

spooneybarger 14y ago
The work that http://www.vpri.org/ http://www.vpri.org/ has been doing around OMeta, Nile etc is really exciting. It is detailed in the later part of this Alan Kay presentation: https://www.tele-task.de/archive/video/flash/14029/ https://www.tele-task.de/archive/video/flash/14029/ ( around minute 45 or so up, perhaps earlier for more background )
kamaal 14y ago
Only if we consider future of problem solving involves writing code. Tool generated code, might be a big thing in the future. Eclipse + Java is already 80% tool generated code.
- damncabbage 14y ago
  Steve Yegge has some interesting points to make about generated code: http://steve-yegge.blogspot.com.au/2007/12/codes-worst-enemy.html http://steve-yegge.blogspot.com.au/2007/12/codes-worst-enemy...