Re: Release date of IntelliJ IDEA 5

Marcus,
I really understand your point here, but I think that what you call a new
"wow" factor is more a matter of marketing work.
Previewing the 5.0 release, can you name an IDE that provides the level of
support we do for JSP/JSPX?
Does any IDE provide completion/resolve, even partial for (dynamically
typed) javascript?
What level of support is provided by existing IDEs to help edit html/css?
Speaking about refactorings, NetBeans provides only the basics for java
(probably more will be added in the near future)
We are going to provide those basics inter-language (i.e. rename, safe
delete and move). For example moving an image file with automatic references
correction from html.

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 classic
development tools depends greatly on the progress in programming languages.
There is of course the inverse idea of making the language specific for
particular domain, but that is just another story (and I really don't know
any news on MPS:)

Eugene.

"Marcus Brito" <mbrito@gmail.com> wrote in message
news:2376322.1115041408888.JavaMail.itn@is.intellij.net...

<rant-mode>
The IDE arena is surprisingly active since the release of IDEA 4.5

(Pallada).

When Pallada was released, IDEA was on a very comfortable position as the

best

IDE out there, hands down. There were some contenders, of course, but none

would

get close to the greater user experience provided by IDEA.

>

Has this changed? In my opinion, yeah, significantly. The latest releases

of

Eclipse, including the Web Tools Platform brings Eclipse to a level of
functionality only achieved by commercial plugins before. This means there

will

be one less reason to buy a commercial product, unfortunately. The new

releases

for NetBeans are also much more polished and incorporates a great deal of
functionality. OmniCore released their new cross platform IDE, which still
has a long way to go but already shows a promising product. Even Microsoft

is

raising the bar, previewing the new refactoring functionality in Visual

Studio.
>

At the same time, what happened to IDEA, really? If some cosmic force

fixed all

critical bugs on Irida and it was ready for release tomorrow, what do we

have?

Primitive support for javascript (but still better than what most other

tools

have to offer), a couple of new XML features (schema validation) and a few

new

inspections. Maybe a new refactoring or two.

>

What do I want to say with all this nonsense? Just think about the

context: we'

re talking about release dates. So, closing this wrecked train of thought,

I

really hope Irida is not released any time soon. I'd love to see

Irida

feature chart reworked to better fit the new IDE arena. We need a release

with

a "wow" factor again... just don't ask me what this could be.
</rant-mode>



58 comments
Comment actions Permalink

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


0
Comment actions Permalink

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.


0
Comment actions Permalink


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

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

Tom

0
Comment actions Permalink

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.

0
Comment actions Permalink

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


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

0
Comment actions Permalink

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

Tom

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.
>
>


0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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




0
Comment actions Permalink


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

0
Comment actions Permalink

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



0
Comment actions Permalink

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

0
Comment actions Permalink

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



0
Comment actions Permalink

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


Same with me :(

Tom

0
Comment actions Permalink

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


0
Comment actions Permalink

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




0
Comment actions Permalink

+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

0
Comment actions Permalink

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 ;)


0
Comment actions Permalink

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


Any details? Observations? CPU snapshots?

-


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


0
Comment actions Permalink

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




0
Comment actions Permalink

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

0
Comment actions Permalink


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.


0
Comment actions Permalink

+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

0

Please sign in to leave a comment.