Re: Release date of IntelliJ IDEA 5

Having said that, my personal opinion is that we (and not only=) are
on the
wrong track when trying to add support to some really old
technologies,
that in spite of being popular now, were not designed bearing in mind
the
possible support from the tools.
Indeed it is impossible to make IDEA as smart when editing say
Javascript,
as it is for Java, because statically typing is essentially the spices
of what we are doing. So what I want to say is that the progress of

I am NOT starting a language war. But many people I know would say that dynamically
typed languages are the current highest progress in programming languages.
You say "impossible" and maybe it's true, maybe it is impossible to make
IDEA as smart with JS as with Java, but it can still be smart. In many
cases, data flow analysis can determine the (possible) type(s) of any value,
even if it takes some more processing power than just searching backwards
for a declaration like in Java. So, I don't see dynamically typed languages
as such a large limitation as you appear to.

I wonder what you think about this. Maybe I'm wrong about everything, you
probably know better. Does IDEA have plans for heavy data flow analysis for
determing types? It seems like the next logical step, what about in Irida
though?

classic
development tools depends greatly on the progress in programming
languages.

-Keith

You say "impossible" and maybe it's true, maybe it is impossible to make
IDEA as smart with JS as with Java, but it can still be smart.

Plus, JB has already shown us that they could do things that they had
qualified as 'impossible' in the past. They just need to be challenged ;)

Vince.

Smalltalk refactoring browsers predate Java refactoring browsers by at least a couple of years. They used both data flow analysis and dynamic "what type was this varible bound to in the last N runs" analysis to do the necessary reference resolution. They also pretty much required the user to preview and individually validate the changes, to avoid mistakes. Refactoring to the level of current IDEA functionality in the presence of dynamic types is a solved problem, albeit a very difficult one.

At levels of automated refactoring beyond what IDEA currently supports (automated duplicate detection with parameterized removal strategies, coupling/cohesion optimization over portions of the dependency graph, automated suggestions for type, parameter and method extractions, refactoring to aspects, and all the other toys my child will someday get to play with) the jury is still out, but I bet strong typing is still in the "extremely helpful, but not actually necessary" bucket.

--Dave Griffith

Vincent Mallet wrote:

>Plus, JB has already shown us that they could do things that they had
>qualified as 'impossible' in the past.
>
Like ... releasing Fabrique?
:(

Sorry. Couldn't resist.

Alain

I was about to mention this, but Dave took the words from the tip of my tongue: Smalltalk provided a productive, refactoring environment for a dynamically typed language 10 years ago. This is not impossible, and has been done before.

Marcus Brito wrote:

Smalltalk provided a productive, refactoring environment for a dynamically typed language 10 years ago.
This is not impossible, and has been done before.

Well, than JetBrains could experiment on the Javascript plug-in :).

Ahmed.

But ask yourself, is it useful? IIRC, Smalltalk never became publicly
accepted.

Tom

But ask yourself, is it useful? IIRC, Smalltalk never became publicly
accepted.

Yes it is. No one wants a Smaltalk plug-in now, but javascript is the
only widly used solution in browsers.

Ahmed.

But ask yourself, is it useful? IIRC, Smalltalk
never became publicly
accepted.

One of those things that were ahead of it's time...

Sorry, I thought you were talking about dynamically typed languages like
Groovy & Co.

Tom

PS: I never needed to write one line in Javascript.

Note that nothing in my response should be thought to mean that I think investing development resources in advanced Javascript refactorings would be a good idea. I have no personal Javascript interest, so my only concern along those lines is "would it have net positive ROI for JetBrains", a question which I couldn't begin to guess at.

--Dave Griffith

It would be a very difficult task, expecially for Javascript, because Javascript is even more dynamically as Smalltalk (in js you add methodes and attributes at runtime).

Also Smalltalk is a 'closed world' system, and the type-inferencer could be certain, that he won't missing something to worry about. In Javascript you have not only to analyse js-files but also all possible import paths via html-files, external files on some web server etc.

So if its possible to calculate types in Javascript (you have to use some optimistic assumtions though, because its proveable impossible to generally infer types exactly in a language like Javascript) it would be a nice thing and could open new options with other dynamic languages like Groovy, Phython, Ruby etc.

Thank you Karsten,
I was just about starting to write the same, when I read your post.

Eugene.

"Karsten Wagner" <no_mail@jetbrains.com> wrote in message
news:25125826.1115126895193.JavaMail.itn@is.intellij.net...

It would be a very difficult task, expecially for Javascript, because

Javascript is even more dynamically as Smalltalk (in js you add methodes and
attributes at runtime).
>

Also Smalltalk is a 'closed world' system, and the type-inferencer could

be certain, that he won't missing something to worry about. In Javascript
you have not only to analyse js-files but also all possible import paths via
html-files, external files on some web server etc.
>

So if its possible to calculate types in Javascript (you have to use some

optimistic assumtions though, because its proveable impossible to generally
infer types exactly in a language like Javascript) it would be a nice thing
and could open new options with other dynamic languages like Groovy,
Phython, Ruby etc.
>
>

PS: I never needed to write one line in Javascript.

Sure, why would you if you can choose - you have your own company, right?
On webapplications (real webapplications - what customers want) however
there's no way way without it (no practical one I mean).

Ahmed.

Something I have to add to my previous post:

In Javascript every-Browser has it's own runtime-model. So even if you're able to infer every type of your program you still don't know exactly what attributes and methods i.e. 'document' has. And since most js-programs 'bootstrap' from these system defined objects you're in a mess.

What could be possible is to assume, that there are certain thing true (like certain attributes of 'document' for example) and reason from this on. But you'll never have the same possibilities as in Java or even in Smalltalk.

OTOH: Limited support for well known objects like 'document', 'window' etc should be possible (assuming, that no one messed with them somewhere) and would be nice. Also simple type-propagation like

var el = document.getElementById("element")
... // nothing changes el here
el.| // here IDEA nows that el is a 'Element'

should be possible - even if it could fail and give you the wrong options somehow.

So don't expect the impossible. Anyhow, there're some limited opportunities also.

I think the kind of work that would be done on JS would benefit many other
languages, anyway, so I think even if you don't use JS, you will see benefits.

Note that nothing in my response should be thought to mean that I
think investing development resources in advanced Javascript
refactorings would be a good idea. I have no personal Javascript
interest, so my only concern along those lines is "would it have net
positive ROI for JetBrains", a question which I couldn't begin to
guess at.

--Dave Griffith

I'm afraid I'm that most unfashionable of beasts nowadays: a static typing purist. I'm in this business to build cathedrals, not duct-tape together science projects. The only language I use that doesn't have a static type system is SQL, and I don't use anything complicated enough in it to merit refactoring support. If the cool kids want Ruby/Python/what-have-you refactoring support enough to pay for it, I'm fine with that. Just so long as I can pull the jar out of my idea/lib directory if it gets in my way.

--Dave Griffith

Just out of curiousity, Dave, and what are those statically-typed languages
you use? Apart from java of course?

Eugene.

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:24555821.1115134887803.JavaMail.itn@is.intellij.net...
>

I'm afraid I'm that most unfashionable of beasts nowadays: a static typing

purist. I'm in this business to build cathedrals, not duct-tape together
science projects. The only language I use that doesn't have a static type
system is SQL, and I don't use anything complicated enough in it to merit
refactoring support. If the cool kids want Ruby/Python/what-have-you
refactoring support enough to pay for it, I'm fine with that. Just so long
as I can pull the jar out of my idea/lib directory if it gets in my way.
>

--Dave Griffith

Lately it's been all Java, XML, and SQL. Back in the day it was C++ and C. There was a year there where I did a bunch of Javascript (including coding up a drag-and-drop pivot table implementation in it!) but I've blocked most of that out.

--Dave Griffith

Thank you!

Eugene.

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:3383976.1115136564985.JavaMail.itn@is.intellij.net...

Lately it's been all Java, XML, and SQL. Back in the day it was C++ and

C. There was a year there where I did a bunch of Javascript (including
coding up a drag-and-drop pivot table implementation in it!) but I've
blocked most of that out.
>

--Dave Griffith

I'm afraid I'm that most unfashionable of beasts nowadays: a static typing purist.

Same with me :(

Tom

With a little reiforcement, even JavaScript can be more manageable and
refactorable.

With some IDE definitions of class packages and dependencies our project
here could be very refactorable and many errors would become obvious and
trackable.

Even some type smart could be injected, especially with OO JavaScript usage.

Amnon

Eugene Vigdorchik (JetBrains) wrote:

Thank you!

Eugene.

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:3383976.1115136564985.JavaMail.itn@is.intellij.net...

>>Lately it's been all Java, XML, and SQL. Back in the day it was C++ and

C. There was a year there where I did a bunch of Javascript (including
coding up a drag-and-drop pivot table implementation in it!) but I've
blocked most of that out.

>>--Dave Griffith

I thought I was a static typing purist for a long time, but I've been talking
to my friend who is a Ruby and Javascript fan lately, and I've come to realize
that we all want the same things. You and I may claim to be static typing
fans, but when it comes down to it, as an IDEA user, I am really not a static
typing fan, I just have a tool which helps make static typed languages more
like dynamically typed languages.

Every time you use Create Local Variable or Introduce Variable, you are using
(smart) code generation to help you do what Ruby or Javascript developers
have done for them automatically without any syntax. So, I think you may
think you're a fan of static typing, but maybe without tools that make static
typed languages more like dynamic typed languages, it might be different.
Static typing has its places, such as (public) parameters and return values,
but in many cases it is unnecessary, and I think IDEA's code generation tools
(Introduce xxx) prove that.

>> I'm afraid I'm that most unfashionable of beasts nowadays: a static
>> typing purist.
>>

Same with me :(

Tom

+I just have a tool which helps make static typed languages more like dynamically typed languages. +

I'd prefer to say that it makes statically-typed languages as easy to use as dynamically-typed languages without sacraficing any of the advantages of static typing. While there is the much talked-about "safety" advantage of static typing, in my old age I'm beginning to realize that the real advantage is in that statically-typed languages enforce a discipline of documentation onto a code base, and machine-checkable documentation at that. The benefit of JDK1.5 generics isn't that you can do fancy metaprogramming (although you can to some extent). The benefit is that it gives your coworker a painless way of telling you what he thought he was putting in this HashMap field. This communication path can be misused, but if used properly it's extremely valuable.

(That's why I have such trouble understanding the point of Haskell-like type inferencing. You get all the rigidity of static typing and none of the communication. The math is pretty, but it truly does look like the worst of both worlds.)

+
Every time you use Create Local Variable or Introduce Variable, you are using
(smart) code generation to help you do what Ruby or Javascript developers
have done for them automatically without any syntax.
+

Naw, those guys just pull variables out of their ass. "Introduce variable" not only creates the variable, but also creates documentation so that six months later I'll know what that variable holds, and whether it is mutable or write-once. It also helps ensure that the variable you're creating won't be misassigned later. All for the low, low price of one Ctrl-Alt-V.

--Dave Griffith

Exactly. And the bigger the team and the codebase, the more valuable strong
static typing becomes. Generics are a real gem in that sense: more
documentation in the code that the compiler can help check and maintain.

I don't care much about how long it takes me to write a few classes. I care
much more about how less likely it will be for me to mess things up six
months later, or how easy it is for everyone else to understand precisely
what I've just written. Good tool or not, static typing helps me in that
way; IDEA helps making it quick (*) and easy.

Vince.

(*) quick: not in 3316. That build is just too slow ;)

(*) quick: not in 3316. That build is just too slow ;)

Any details? Observations? CPU snapshots?

-

Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

Dave I agree with you about many things here. Typing is only documentation,
nothing more. Ruby duck typing is equivalent to Java interfaces but without
the benefit of well-defined behavior.

However, I think a smart IDE could make specifying types unnecessary in many
cases (mainly local variables). You say declaring the type creates documentation,
but imagine a Java-like language which IDEA supported and inferred types
from use. Then you could simply hold Ctrl and run your mouse over the variable
and you would immediately see the type in the tooltip. I think this is, in
most ways, just as valuable as a type declared for the variable, don't you?

+I just have a tool which helps make static typed languages more
like dynamically typed languages. +

I'd prefer to say that it makes statically-typed languages as easy to
use as dynamically-typed languages without sacraficing any of the
advantages of static typing. While there is the much talked-about
"safety" advantage of static typing, in my old age I'm beginning to
realize that the real advantage is in that statically-typed languages
enforce a discipline of documentation onto a code base, and
machine-checkable documentation at that. The benefit of JDK1.5
generics isn't that you can do fancy metaprogramming (although you can
to some extent). The benefit is that it gives your coworker a
painless way of telling you what he thought he was putting in this
HashMap field. This communication path can be misused, but if used
properly it's extremely valuable.

(That's why I have such trouble understanding the point of
Haskell-like type inferencing. You get all the rigidity of static
typing and none of the communication. The math is pretty, but it
truly does look like the worst of both worlds.)

+
Every time you use Create Local Variable or Introduce Variable, you
are using
(smart) code generation to help you do what Ruby or Javascript
developers
have done for them automatically without any syntax.
+
Naw, those guys just pull variables out of their ass. "Introduce
variable" not only creates the variable, but also creates
documentation so that six months later I'll know what that variable
holds, and whether it is mutable or write-once. It also helps ensure
that the variable you're creating won't be misassigned later. All for
the low, low price of one Ctrl-Alt-V.

--Dave Griffith

What I like with Java is, that the compiler catches a lot of errors, so I
don't need that often the debugger. Quite always I prefer type-safe
solutions over fast solution. It might be a little bit more effort at the
beginning, but once developped, the maintainance costs are very low.

Tom

I've uploaded a CPU snapshot to ftp.intellij.net/.uploads. I spent 30
seconds adding two lines of code to an existing class. IDEA reacts to
everything I type with a serious lag so I always have to pause for a few
seconds for IDEA to catch up -- especially if I want to use an intention.

Things have never been that bad with the editor (for me). 4.5 and not too
recent EAPs worked just fine and snappy with the same projects. Note that
I'm working with plain java (no j2ee, no jsp) and I'm not seeing any
suspicious exception anywhere (console, logs, error reporting tool).

Vince.

+Then you could simply hold Ctrl and run your mouse over the variable
and you would immediately see the type in the tooltip. I think this is, in
most ways, just as valuable as a type declared for the variable, don't you?+

IIRC, that was one of the many very odd things one could do with the Camoflauge plugin. Couldn't stand it myself as I am very used to seeing the types, but I'm willing to believe that might be trainable behaviour. OTOH, I'm pretty sure that the best you could get out of the system you describe is one as valuable as a static typed system, not one more valuable than static typing.

I put essentially no value on terseness for the sake of terseness, particularly if my tools are doing most of the typing for me. I put an enormous value on clarity (what a surprise), and the way that humans are wired clarity actually implies a certain amount of redundancy. Seeing the types of variables seems to be a good way of putting just the right redundancy in for ease of understanding, without undue clutter.

Overall, the JDK1.5 level of redundancy feels just about right to me. There's enough documentation points in the code that it is possible to make your code tell the story of your design, but not so much that the actual execution paths get lost in the chatter. Before 1.5, there were design stories you couldn't easily tell (What's in this collection? This type has ten values. A barely explored plethora of metadata-ish questions), and places where coding details obscured the flow (old for-loops, boxing/unboxing, enum hacks). We're down to relatively few places where Java code has to be obscure (mostly designs relying on inner class peculiarities), and we're closing in on being able to clearly tell most of the stories of OO designs in Java. A design-by-contract system and nullity specifications are the only big gaps that I feel. Dynamically typed (or inferred static type) systems just don't let me tell the stories I need to tell, even if I can build the functionality I need quickly.

--Dave Griffith