Is that better than the one-liner:
tell application "System Events" to do shell script "kill " & unix id of process PromptName
?
Yes, because you have to do the do shell script anyway, which you can’t get by, System Events, you can do without, and the System Event call necessitates an Apple Event (costly), and besides that, the construct, creates a “silent” error number -10004, because it is a privilege violation to use do shell script from System Events. Now, that could be altered, with a Use AppleScript version “2.3” clause, followed by a use Standard Additions clause, (which also would speed up the call of “do shell script”), however, you are still having the call to System Events.
The choice is yours, if readable weighs heavier, use your proposition, if a clean “system wise aspect” weighs more, use the do shell script. 
I don’t mind but the definition of deprecation will perfectly explain why backticks are deprecated for command substitution. $() can execute commands which backticks can’t, $() is just a newer and improved version of command substitution. Because backticks are “buggy” the POSIX standard suggests not to use backticks at all and recommend never using them for “new” commands. Then Apple’s manual about command substitution is explicitly tells it’s deprecated as well. POSIX implies that the actual reason why backticks are still working is for backward compatibility with old shells. When I sum it all up it sounds pretty deprecated to me.
It’s like saying that the list folder command is not deprecated because it still works. By deprecation people starts to think it will stop working, deprecation doesn’t mean that. The backticks can be supported forever, just like deprecated osax commands in the standard addition. It does simply mean that the developer of the API suggests not to use it.
I see I have put something different in the term “deprecated”, as have the guys at StackExchange. (I read deprecated as something that may stop working sometime in the future.) And when it isn’t deprecated, then, I am not going to stop using backticks, because I know for sure that they will work as a last resort. I am in fact going to use them, until Apple decides to use bash as the standard shell for the do shell script, per today, I believe there is an actual legacy shell residing somewhere in there as a “last resort”. Having said that, I realize now, that maybe I have used some features of bash, that goes beyond the posix specification when I ended up with the problems that some features didn’t work.
I also wonder in what way command substitution can execute commands that backticks can: I believe they both create a subshell and returns the result as stdout, which the parent shell grabs and passes as a parameter to the next process it creates.
I take it, by Apples Manual you are referring to the bash manual that can be found through developer.apple.com?
Thanks.
I’m sorry, I was to answer you earlier. The unix id, is the process number of a process. In the end, everything that is running in OS X is a unix process, unless it is a subroutine in the kernel. So, an Application, though launched through the Launchservices, and set up with the goodies of Cocoa, is still a unix process, and does still possess this number. That number resides in a table, called the processess table in the kernel, by which the kernel uses to track its resources, and give it resources as it needs them. (In broard terms here, to give you the perspective).
From the unix side of things (The Terminal window, we use the ps utility, to see what processes there are, those processess (name and numbers) can also be seen in the Activity Monitor. You can also use lsofen to see what files a process have open. We use the kill utility to kill a process, and nice, to lower the priority of a process, (you can install a renice utility from third parties to increase the priority.)
You should read the man page of ps, and kill, because those commands are kind of fundamental when dealing with processes. (You can also use the kill command to signal interrupts to a process that you can install with the trap command.)
If this is stuff that interestes you, then I also recommend that you get hold of a copy of “The Unix Programming Environment” by B.W. Kernighan and R. Pike. (“man bash” is of course also a good read.)
Edit
I do believe you would enjoy to read a book about operating systems as well then “Operating Systems, its internals and design principles” by Stallings, comes to mind as the least bad alternative. There is one very thin one, that is written by an English proffessor, but I have forgotten the title and the name of the Author, it has a grey cover, is very thin, and covers the principles well. 
Unless you choose not to:
use framework "Foundation"
use framework "AppKit"
(current application's NSRunningApplication's runningApplicationsWithBundleIdentifier:"com.whatever")'s firstObject()'s forceTerminate()
FWIW, use scripting additions doesn’t seem to eliminate the -10004 error for do shell script.
I see, it makes it go faster with a silent error. I was sure they removed the silent error, if they made the errant code run faster. I was wrong.
Now that is a superior way, that I wasn’t aware of, because the approach is a lot simpler, and it should work one way or another from Snow Leopard onwards. I’d check out if it generates a crash report though, but I did provide a link to how to disable Crash Reporter, and enable it back again, higher up in the thread.
Thanks Shane.
ASObjC needs at least Mavericks, though.
I don’t believe it does. (I use it quite a bit.)
In that list the book “Operating Systems: Design and Implementation” a.k.a “The MINIX Book” written by Tanenbaum and Woodhull about Minix (the same book used by Linus Torvald when he wrote Linux) gives an very good insight on how the underlying BSD of Mac OS X works.
I see, sometimes it is good to be without Crash Reports. Thanks again.
Not that I am caring much for going back to Snow Leopard, but I’ll figure out where my assumptions went wrong on that one.
AppleScriptObjC available in Xcode → Snow Leopard
AppleScriptObjC available in AppleScript Editor → Mavericks
Right – and NSRunningApplication also introduced in Snow Leopard.
Hello.
And I also thought you had to use AppleScriptObjC from an applet, and not a script in Snow Leopard.
Late reply, but something I have overlooked. You do know that sh is actually bash running in POSIX mode? So it’s not some old shell that do shell script uses but it’s bash that will mimic an sh POSIX shell. So you can start using $() from today on
Hello.
I didn’t overlook that , hence why I wrote “last resort”; say if something is wrong with the way the shell is set up by launchservices, then in theory, something other than bash invoked as sh in posix compatible mode kicks in.
I have deducted that from some error messages I have managed to get at some times, which I swear didn’t look like the regular ones from bash. Regrettfully, I am more considered with getting stuff working, as to recording exactly what has gone wrong at all times, and what sideffects that had, so, I don’t really have any reproducible proofs of concepts.
I have to state that I believe that the do shell script has a version of sh of its own, if it can’t find a shell to work with from launchservices, and that that sh shell doesn’t work in posix mode, and that is why I wrote earlier that backticks was a last resort that would work, since the do shell scripts “last resort” shell, isn’t a posix compatible one.
But right here and now, we are kind of debating the function of a rubber duck, unless we had the source code for Standard Additons. I see no point in continuing it, since we are really discussing beliefs.
Edit
It may be wrong about this, because it all depends on the “system” c-function call, that should really use /usr/bin/sh as its parser. This is linked to the bash shell, and the manual for bash states:
It may be, as I also wrote earlier, that I may have tried to use functionality of bash that extends the posix standard, and there has gone wrong. But I am happy with using back ticks anyway, unless I have to nest them, I have never found a bug with them.
I really could have been going on, with how I think the system call works, when the shell interpreter goes awry, and maybe written about the same about it, as I just did above about beliefs on the do shell script call, that inside the system call there is a ancient version of sh. 
I really don’t believe it is.
++
I have been over at opesource.apple.com to clarify for myself once and for all, how this works. As far as it goes, the system() is a normal one, without any “magic” “ancient” sh, kicking into place. So I’ll simply await and see until next time, if a next time is to come regarding sh, and posix compatiblity, whether it is a real compatibility issue or not. Then I’ll hopefully remember to look deeper into it.
I meant I missed your post
Not really a belief to me, Apple is clear about this: “If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.”. Do shell script invokes sh, but as Apple clearly says, it is actually bash that mimics sh. That’s why getting the version from sh used by do shell script simply returns “GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13). Copyright (C) 2007 Free Software Foundation, Inc.”. When debugging script editor I found once more that script editor is forking itself using execv() function into a new process and execute the command “/bin/sh”. So it’s not something I believe, it’s just what the documentation and the machine tells me. There is no special shell for do shell script, period.
How embarrassing… How can I compile this?
I get errors whether it’s inside or outside a handler.
I agree to that.
I’ll have to wait and see, until next time I perceive any troubles, first and foremost if it is caused by lack of Posix compatibility.