how to not impress a c developer

Marcus Brito wrote:

Not really. Java has proved that a mix of JIT compiling and dynamic interpreting can be even faster than static compiling.

> Sure, this wasn't true when Java first came to the world,
> but today the JVM can execute code as fast (if not
> faster) as a static compiled application.
I didn't say Java applications are slow :) I meant every time you launch
Java application, you launch a byte->native code compiler , in such a
comparison it is skipped. IMHO it's not fair.

Sergiy

Just because there is a Java bug doesn't mean that
IntelliJ doesn't need to find a way to work around it.

I agree. The bug relates to modal dialogs. So the question I have is why must these dialogs be modal? It makes no sense to me why modifying project settings (and other dialogs) cannot be done non-modal. This would solve all the problems.

Sergiy Dubovik wrote:

Alexey Efimov wrote:

>> Hello, Michael!
>> You wrote on Thu, 27 May 2004 15:34:06 +0400 (MSD):
>>
>> Just one big advance of IDEA over VisualStudio - Refactoring. I thing it
>> cover all performance restrictions...

I'm working with C++ (Visual Studio) and Java at the same time. And I
can't say that I'm missing refactoring doing my work in C++. Even though
I'm renaming, extracting, changing signatures in Java constantly.
Why is that? I don't really know the answer. May be I do my job more
carefully when I code in C++ because I know that I won't be able to
change it as easy as I would do in IDEA? I have noticed several times
that after applying refactoring (IDEA) few times in a row I don't
understand what is going on with the application anymore.

In the other life I have been a C++ developer. I refactored constantly... by
hand.

In yet another life which still goes on, although no as actively, I am an
Objective Caml programmer. I refactor a lot there too.

Refactoring is not a technology. It is something you just do all the time to
make your code catch up with the changing life.

Cheers,
Dmitry
--
Dmitry Lomov
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

So the question I have is why must these dialogs be modal? It makes no sense to me why modifying project settings (and other dialogs) cannot be done non-modal.

Have you ever created a decent sized modal dialog with perfectly working
OK/Cancel behaviour? Then you would know, that it is a non-trivial task.

If you would like to create a OK/Cancel dialog without modality, it will
get a real nightmare.

This would solve all the problems.

This one is good. It would create 10 times more problems.

Tom

seems like the "modal dialog" problem can be blamed
to JDK ;)

I still would like to know why exactly IDEA cannot
start 2 instances?
Because it would require extremely complicated cache
file lockings or sth. like that?

I know it is a very ignorant way of looking at it,
but:
as we all know, IDEA is an extremely high tuned product
- but it fails for such a simple task like truly support two open projects !!

I still would like to know why exactly IDEA cannot
start 2 instances?

I guess, because two instances would read/write the same files (e.g.
settings), which might cause a lot of "strange" i/o-bugs.

Tom

The two instances could coordinate (IPC) to ensure that the same project is
not open in both instances. They could also let each other know when a file
(e.g. settings) has changed.

It would require a little effort, but certainly nothing beyond the
capabilities of the JetBrains crew.

Tim


"Thomas Singer (MoTJ)" <nomail@nodomain.com> wrote in message
news:c979m6$rfd$1@is.intellij.net...

I still would like to know why exactly IDEA cannot
start 2 instances?

>

I guess, because two instances would read/write the same files (e.g.
settings), which might cause a lot of "strange" i/o-bugs.

>

Tom

As VC does. :)

>However, how often do you have two projects open >simultaneously?

Um, pretty much all the time. I'm tasked on two separate work projects right now, plus assigned to technical oversight on three more (which means opening IDEA to download changes from CVS and do code reads) and usually have at least one for-fun project open as well. None of these have anything to do with one another, so making them modules would be pretty silly. Over the course of the day, I've usually got two and occasionally up to four projects open. That said, the modal thing is only intermittently an issue, as there are only a few really long-running modal activities left in IDEA (code inspection and really large CVS activities are the only ones that comes to mind).

--Dave Griffith

I hope that you have at least two monitors, maybe four. I would have a hard
time keeping track of all those open projects on my desktop simultaneously.

I primarily work on one project at a time, but I do shift gears occasionally
to support one or two other ones. I find that the time it takes to close
one project and open another one is just about right for switching gears in
my head as well. I guess that's why you make the big bucks. ;)

Tim

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

>However, how often do you have two projects open >simultaneously?

>

Um, pretty much all the time. I'm tasked on two separate work projects

right now, plus assigned to technical oversight on three more (which means
opening IDEA to download changes from CVS and do code reads) and usually
have at least one for-fun project open as well. None of these have anything
to do with one another, so making them modules would be pretty silly. Over
the course of the day, I've usually got two and occasionally up to four
projects open. That said, the modal thing is only intermittently an issue,
as there are only a few really long-running modal activities left in IDEA
(code inspection and really large CVS activities are the only ones that
comes to mind).
>

--Dave Griffith

Tim, do you know how exactly does it works? I would need the information
for our own applications as well. Thanks in advance.

Tom

This problem also happens with Microsoft Word. For example, if you have 2 documents open (in separate windows) and bring up a modal dialog (e.g. Open, Tools | Options) from one of the windows, it will block both windows.

If you're writing an email from Outlook, and your email editor is Word, and you do try to attach a file (Insert | File), then any other Word documents will be blocked. So you're writing an email, and this can block Word.

So, while Sun haven't been particularly useful in fixing this bug, this problem isn't restricted to Java.

Unfortunately, opening IDEA can be a bit slow because it's a Java app.

However, I can live with the delay in opening a project, because IDEA is doing a pile of work (indexing etc.) which will vastly speed up my development - providing refactoring, searches etc.

So I can live with a slow start, because subsequent productivity is boosted so much.

Good to know such an example :).

Tom

I don't have any existing examples to refer to. However, off the top of my
head, I would probably open up a socket connection between the two
processes.

Instead you could use JMS to communicate if a JMS server is available, but I
wouldn't add one to IDEA just for this.

The actual protocol between the processes would be implementation specific.

You could also use file locking (not my first choice), and/or the processes
could monitor for changes of the configuration files like IDEA does now for
the source code.

Tim

"Thomas Singer (MoTJ)" <nomail@nodomain.com> wrote in message
news:c97f87$vtm$1@is.intellij.net...

Tim, do you know how exactly does it works? I would need the information
for our own applications as well. Thanks in advance.

>

Tom

Have you ever created a decent sized modal dialog with
perfectly working OK/Cancel behaviour? Then you would
know, that it is a non-trivial task.

Yes, I've done this quite often, actually. Can you explain to me a use-case that would be problematic? How does modality simplify OK/Cancel behavior? How does preventing access to the rest of the app while looking at the dialog make it easier to code an OK/Cancel dialog?

This one is good. It would create 10 times more
problems.

Like what?

Hi Kirk,

Imagine a OK/Cancel dialog which has a list of antennas. For each of
them you can edit it's location (x, y, z) and the vendors, which use the
antenna to send. The vendors are stored in a separate list somewhere
else in the system. Of course also you can add new antennas or remove
old ones.

First, when the (modal) dialog is opened, you need to create a backup of
the antennas-list and operate on this copy. If you press OK, the copied
list needs to be "synchronized" with the original list (note, that other
objects might have references to antennas!). If Cancel is pressed you
can give the list copy into nirvana (also known as GC).

If you would take a non-modal dialog, it would be possible to edit the
list of vendors, which makes it necessary, that the antennas-dialog
needs to update for each change in the vendors-list.


This is just a simple use case, we already had much more complicated
situations which would be much more difficult to describe.

Cheers,
Tom

Hi Tom,

To summarize what I think you are saying : a modal OK/Cancel dialog
helps to express a transaction at a user level. It's modality serves to
both enforce atomicity of the transaction and to also define it's scope.

N.

Thomas Singer (MoTJ) wrote:

Hi Kirk,

Imagine a OK/Cancel dialog which has a list of antennas. For each of
them you can edit it's location (x, y, z) and the vendors, which use the
antenna to send. The vendors are stored in a separate list somewhere
else in the system. Of course also you can add new antennas or remove
old ones.

First, when the (modal) dialog is opened, you need to create a backup of
the antennas-list and operate on this copy. If you press OK, the copied
list needs to be "synchronized" with the original list (note, that other
objects might have references to antennas!). If Cancel is pressed you
can give the list copy into nirvana (also known as GC).

If you would take a non-modal dialog, it would be possible to edit the
list of vendors, which makes it necessary, that the antennas-dialog
needs to update for each change in the vendors-list.


This is just a simple use case, we already had much more complicated
situations which would be much more difficult to describe.

Cheers,
Tom