The problem with Vim (and Emacs) is that they do not support anything modern, not even ctrl-z/x/c/v.
VIM has the "VIM Easy" mode, which when used on MSWindows would do Ctrl-Z/X/C/V out of box. And even select text when holding Shift and moving around with cursor keys.
Shortcut to VIM Easy is preinstalled. If you complain about it, then you probably never really used the VIM. Or are you complaining about the *NIX "vi"?
For programming Eclipse or NetBeans or Visual Studio is just miles away what of vi/emacs can do, especially out of the box.
The problem for the professionals is not what the IDE can do out of box, but what can it be made to do. Eclipse or NetBeans or Visual Studio - all suck horribly at everything for what there is no button premade. And when there is a button for everything - they suck at finding this right button.
But I'm not planning to contest the point that VIM is not IDE. No, it is not "VIM is bad IDE" - it is "VIM is not IDE". (This is different for Emacs, though: it is an IDE and then some more. One needs to learn it. And lack of good in-depth tutorials is actually what turned me off from the Emacs.)
The thing about VIM is that it integrates nicely with the system, instead of reinventing it. And it also provides great automation facilities with macros, mappings or scripts. They are fairly simple and can be learned in 1-2 weeks, which is a small price to pay for the ability to control 100% of your text editor. That is the capability no other editor offers.
To get vi/emacs to work nearly as good as good IDE is just too big a job.
(Please do not say "vi" when you really mean "VIM".)
In the project Neovim the work going on to make the Lua the built-in scripting language and improve VIM's plug-in framework. All that to specifically allow to create IDE based the VIM. (Though in my opinion, the direction of the Neovim effort is misguided. They should have went in direction of allowing VIM to be easily embeddable into other applications.)
So in the future, there might be an IDE based on VIM. But not right now.
For example NetBeans ctrl-b (go to declaration). Sure, you can install ctags, configure it, run it, tinker with it, tinker some more, add custom rules, search net, rinse-and-repeat and eventually you'll get something resembling ctrl-b, but not quite the same.
This is probably the most unjustified complain you throw. The tags support in VIM is very good - if you bothered to RTFM. Literally every book and tutorial describe these highly sophisticated and inexplicable 3 steps involved: install the exuberant ctags, put into the.vimrc the line ":set tags=tags;/", and finally run "ctags -R." in the root of the project.
If you use plugins like YouCompleteMe, they would do it for you automagically.
In the end, if you can't bother to read the VIM's help (which is by far the best help for a text editor there is out there) then VIM is definitely not for you.
They should have tested interactivity of the editors. Though in synthetic test environment that would have been probably an impossible task.
I'm still using the VIM (terminal version, occasionally the GUI gvim-athena) because this is the only combination which doesn't have the delays.
Few years back I have tried the Kate/Kdevelop, Gedit and Eclipse, and they still had the same thing in common: occasionally GUI would freeze for couple hundred milliseconds, typed text at first goes nowhere and then suddenly pops in the editor window.(*)
It's probably not a big deal for a mouse person. But for a keyboard person (or a touch-typist), when there is no visible indication of something happening, the delays are simply too irritating.
VIM (in xterm) still remain my champion of text editing. Yes, xterm, because the "modern" terminals, especially with tabs open, not only prone to the same GUI delays, but they also prone to losing the focus (like in: you switch back to the terminal, start typing but nothing happens, click with the mouse inside the terminal window and start typing again - and lo and behold it finally works).
(*) Disabling the "composing" window managers helps greatly, but doesn't eliminate the delays completely.
What the hell is ACM and why would it benefit me to join them?
If you were a halfway competent software developer, you'd already know, and if you were an elite software developer, you'd already have joined...
I'm no elite, but as a competent software developer, all I know about ACM is that they are a paywalled website.
Why would I chose to spend time investigating one particular paywalled site over the dozen others? They all look the same to me.
Most of computer science research is published publicly on Internet anyway. On several occasions, when my friends from universities were getting paywalled articles printed for me, I was finding out that I have seen the article already freely before on the internet.
Usefull/non-useful ratio on the paywalled articles IME isn't sufficiently different from the plain web search to justify the price. I still have to waste my time grepping through all the junk.
I might pay for somebody to actually select the founding and important articles. But I'm yet to hear about an organization which offers such service. (And the academia where being published still bears the highly exaggerated value, and 90% of articles are nothing but the quoting of the quoted, almost guarantees that the service wouldn't be affordable.)
How about the fact that Chrome has an up to date implementation of Flash that continues to get security updates... And don't tell me I don't need flash, you'll be just moving the goalposts with your argument.
That is somewhat ironic, since I find video quality of Google's own YouTube to be the worst with the Google's own Chrome. Either way - HTML5 or Flash - in Chrome sometimes HD videos are shown highly pixelated. Works fine - everyt time - in Fx and IE.
Anyway, FlashBlock (which can also be simulated with the AdBlock), side-steps most of the Flash-related security problems.
Lots of people *need* resistive touch-screen, because capacitive ones can't be used in gloves.
But all that doesn't mean that it is going to happen. Production/etc moved to Asia - distance between customer and manufacturer is as great as it ever was.
Man, I haven't even mentioned the numerical computing. It is an exception, because that's where programming serves the math, not the other way around.
In numerical computing, ironically, there is very little overlap between the math methods used in the development and math methods used for the goal of the development. Programs there often look more like a math formula. Developers simply skip the "computer science" as a whole and use the computers (with help of specialized libraries) as almost pure calculators.
As an exception, it is simply obscures the subject of the discussion.
The talk here is about what precisely from the math is used in general software development. (IOW, math serves the programming.) My personal experience, having majored in the applied math 15 years ago, is that by studying math one learns the methods to approach the real world problems. "Learns" is a weak word. The methods are implanted, grafted (or even brandmarked) onto the brain. Normal person's brain go into freeze when faced with thousands pages of specification. Person with math background, already switched into "divide and conquer" mode, and probably has already dismissed the >90% of it as trivial, incremental and derivative. (Some people learn it one their own. But studying math is definitely a nice shortcut to get there faster and earlier.) But the math in itself, either discrete/algebra or analysis or numerical, is very very rarely needed.
Then it is fine. I would expect programmers to struggle with classical math geared toward physics. That's perfectly logical: it is easier for people who come from physics because they understand the applications. And vice versa: physicists have huge problems with discrete math, where you can't round or generalize everything to hell.
Otherwise, it was repeated many times before. The math in itself is not as useful as studying math is. Math doesn't relate to software development directly - but mathematical methods and approaches translate often one to one.
Studying math is fitness for the brains and method to the fitness.
P.S. But it doesn't mean that people who are good at math are good at programming too. Theoretical math != applied math. I have seen profs who could invent a new proof for theorem on a whim (forgotten notes), but struggled to implement something as trivial as a quick sort.
I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here
OK. You completely miss the point.
Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.
Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.
I dunno about the rest, but for filesystem browsing you can use vim:e on a directory which vim will then let you navigate
Well, you really have to try it first to understand the difference.
Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.
And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.
Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)
Can you describe something that Xiki can do that cannot be done with `:r!`?
I can't. Because I do not use Xiki. I use something much simpler coded in VIM.
But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)
Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.
I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.
The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.
The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.
OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.
Re:Yes, Perl is indeed dead and rotting
on
Perl Is Undead
·
· Score: 0
More telling is how utterly fast Perl is compared to the other languages.
The test is ridiculous.
In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.
All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)
I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there [...]
That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.
Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.
In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.
With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).
No. Remote display is used everyday. Network transparency is not.
Remote display is used only if you are locked into the Windows. And comes with bunch of little problems, of which stuck keys and broken clipboard (until server restart) are though most annoying, the least. Recently admins where I work had to reboot PDC simply because a disconnected remote session got stuck and server didn't allow new sessions because RDP supports only one session.
But that's on Windows, where people have no choice. On *NIX, there is no good reason to choose RDP/VNC over X+ssh. But if you wish, you can RDP/VNC too.
Funny enough remote display is a feature possible on Wayland too.
Do you even know what you are talking about? Wayland's official statement is that network support is out of scope. Because Wayland is an interface to *local* graphical subsystem.
As network support goes, Wayland has only recently gained support for the X protocol (aka X Server can use Wayland as a display driver).
Vast majority of the later bugs were actually caused by the major internal redesigns starting with the version 4: new JS engine (which changed 3 or 4 times) and reworked layout engine. And IIRC there was even one UI security bug, where web-site could trick new FireFox into displaying green verified label for a compromised site.
I'm not saying that 3.6 is perfectly secure. But with AdBlock, FlashBlock and NoScript, it is probably more secure than the recent FireFox out of box. The add-ons cut off the major exploit vectors at the root.
Can one place the close button on the right side in the tab bar? So that I do not have to look at the specific tab in the tab bar while closing tabs in a bulk?
Comparing recent Chrome and FireFox versions, the only real difference is that Chrome still doesn't have a properly functional AdBlock.
But some animations used by web sites are smoother in Chrome, while still jerky in FireFox.
If you do not use AdBlock, or want smoother graphics at cost of ads, keep the Chrome.
If you want AdBlock, then use FireFox.
If you want just a reliable browser, and you are on up-to-date Windows, then better use IE. Ironic as it is, YouTube works better in IE (and FireFox) than in Chrome.
I'm not sure about the whole scope of the lay off, but many of the departed were translators and testers. Definitely not "paper pushers".
(My office is near. Some people stopped showing up for the lunch breaks. Asked few other neighbors and learned that Nintendo in the location laid off 160 out of 600.)
Slashdot Mirror
The problem with Vim (and Emacs) is that they do not support anything modern, not even ctrl-z/x/c/v.
VIM has the "VIM Easy" mode, which when used on MSWindows would do Ctrl-Z/X/C/V out of box. And even select text when holding Shift and moving around with cursor keys.
Shortcut to VIM Easy is preinstalled. If you complain about it, then you probably never really used the VIM. Or are you complaining about the *NIX "vi"?
For programming Eclipse or NetBeans or Visual Studio is just miles away what of vi/emacs can do, especially out of the box.
The problem for the professionals is not what the IDE can do out of box, but what can it be made to do. Eclipse or NetBeans or Visual Studio - all suck horribly at everything for what there is no button premade. And when there is a button for everything - they suck at finding this right button.
But I'm not planning to contest the point that VIM is not IDE. No, it is not "VIM is bad IDE" - it is "VIM is not IDE". (This is different for Emacs, though: it is an IDE and then some more. One needs to learn it. And lack of good in-depth tutorials is actually what turned me off from the Emacs.)
The thing about VIM is that it integrates nicely with the system, instead of reinventing it. And it also provides great automation facilities with macros, mappings or scripts. They are fairly simple and can be learned in 1-2 weeks, which is a small price to pay for the ability to control 100% of your text editor. That is the capability no other editor offers.
To get vi/emacs to work nearly as good as good IDE is just too big a job.
(Please do not say "vi" when you really mean "VIM".)
In the project Neovim the work going on to make the Lua the built-in scripting language and improve VIM's plug-in framework. All that to specifically allow to create IDE based the VIM. (Though in my opinion, the direction of the Neovim effort is misguided. They should have went in direction of allowing VIM to be easily embeddable into other applications.)
So in the future, there might be an IDE based on VIM. But not right now.
For example NetBeans ctrl-b (go to declaration). Sure, you can install ctags, configure it, run it, tinker with it, tinker some more, add custom rules, search net, rinse-and-repeat and eventually you'll get something resembling ctrl-b, but not quite the same.
This is probably the most unjustified complain you throw. The tags support in VIM is very good - if you bothered to RTFM. Literally every book and tutorial describe these highly sophisticated and inexplicable 3 steps involved: install the exuberant ctags, put into the .vimrc the line ":set tags=tags;/", and finally run "ctags -R ." in the root of the project.
If you use plugins like YouCompleteMe, they would do it for you automagically.
In the end, if you can't bother to read the VIM's help (which is by far the best help for a text editor there is out there) then VIM is definitely not for you.
They should have tested interactivity of the editors. Though in synthetic test environment that would have been probably an impossible task.
I'm still using the VIM (terminal version, occasionally the GUI gvim-athena) because this is the only combination which doesn't have the delays.
Few years back I have tried the Kate/Kdevelop, Gedit and Eclipse, and they still had the same thing in common: occasionally GUI would freeze for couple hundred milliseconds, typed text at first goes nowhere and then suddenly pops in the editor window.(*)
It's probably not a big deal for a mouse person. But for a keyboard person (or a touch-typist), when there is no visible indication of something happening, the delays are simply too irritating.
VIM (in xterm) still remain my champion of text editing. Yes, xterm, because the "modern" terminals, especially with tabs open, not only prone to the same GUI delays, but they also prone to losing the focus (like in: you switch back to the terminal, start typing but nothing happens, click with the mouse inside the terminal window and start typing again - and lo and behold it finally works).
(*) Disabling the "composing" window managers helps greatly, but doesn't eliminate the delays completely.
What the hell is ACM and why would it benefit me to join them?
If you were a halfway competent software developer, you'd already know, and if you were an elite software developer, you'd already have joined...
I'm no elite, but as a competent software developer, all I know about ACM is that they are a paywalled website.
Why would I chose to spend time investigating one particular paywalled site over the dozen others? They all look the same to me.
Most of computer science research is published publicly on Internet anyway. On several occasions, when my friends from universities were getting paywalled articles printed for me, I was finding out that I have seen the article already freely before on the internet.
Usefull/non-useful ratio on the paywalled articles IME isn't sufficiently different from the plain web search to justify the price. I still have to waste my time grepping through all the junk.
I might pay for somebody to actually select the founding and important articles. But I'm yet to hear about an organization which offers such service. (And the academia where being published still bears the highly exaggerated value, and 90% of articles are nothing but the quoting of the quoted, almost guarantees that the service wouldn't be affordable.)
Amazon 30% is taking the piss
When Amazon takes 30%, everybody's up in arms.
When publishers take 95% or more, it's fine, the business is as usual.
We probably should start calling that "American logic". Because even "women logic" is above the level.
How about the fact that Chrome has an up to date implementation of Flash that continues to get security updates... And don't tell me I don't need flash, you'll be just moving the goalposts with your argument.
That is somewhat ironic, since I find video quality of Google's own YouTube to be the worst with the Google's own Chrome. Either way - HTML5 or Flash - in Chrome sometimes HD videos are shown highly pixelated. Works fine - everyt time - in Fx and IE.
Anyway, FlashBlock (which can also be simulated with the AdBlock), side-steps most of the Flash-related security problems.
Lots of people want physical home/back buttons.
Lots of people also want non-glossy screen.
Lots of people *need* resistive touch-screen, because capacitive ones can't be used in gloves.
But all that doesn't mean that it is going to happen. Production/etc moved to Asia - distance between customer and manufacturer is as great as it ever was.
I personally do not expect thing to get better.
Man, I haven't even mentioned the numerical computing. It is an exception, because that's where programming serves the math, not the other way around.
In numerical computing, ironically, there is very little overlap between the math methods used in the development and math methods used for the goal of the development. Programs there often look more like a math formula. Developers simply skip the "computer science" as a whole and use the computers (with help of specialized libraries) as almost pure calculators.
As an exception, it is simply obscures the subject of the discussion.
The talk here is about what precisely from the math is used in general software development. (IOW, math serves the programming.) My personal experience, having majored in the applied math 15 years ago, is that by studying math one learns the methods to approach the real world problems. "Learns" is a weak word. The methods are implanted, grafted (or even brandmarked) onto the brain. Normal person's brain go into freeze when faced with thousands pages of specification. Person with math background, already switched into "divide and conquer" mode, and probably has already dismissed the >90% of it as trivial, incremental and derivative. (Some people learn it one their own. But studying math is definitely a nice shortcut to get there faster and earlier.) But the math in itself, either discrete/algebra or analysis or numerical, is very very rarely needed.
discrete math
Algebra?
Then it is fine. I would expect programmers to struggle with classical math geared toward physics. That's perfectly logical: it is easier for people who come from physics because they understand the applications. And vice versa: physicists have huge problems with discrete math, where you can't round or generalize everything to hell.
Otherwise, it was repeated many times before. The math in itself is not as useful as studying math is. Math doesn't relate to software development directly - but mathematical methods and approaches translate often one to one.
Studying math is fitness for the brains and method to the fitness.
P.S. But it doesn't mean that people who are good at math are good at programming too. Theoretical math != applied math. I have seen profs who could invent a new proof for theorem on a whim (forgotten notes), but struggled to implement something as trivial as a quick sort.
InoReader did the trick for me. Using it for over the year now. So far - no problems whatsoever.
I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here
OK. You completely miss the point.
Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.
Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.
I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate
Well, you really have to try it first to understand the difference.
Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.
And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.
Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)
Can you describe something that Xiki can do that cannot be done with `:r!`?
I can't. Because I do not use Xiki. I use something much simpler coded in VIM.
But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)
Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.
For those already on VIM: [...]
I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.
The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.
The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.
OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.
More telling is how utterly fast Perl is compared to the other languages.
The test is ridiculous.
In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.
All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)
I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there [...]
That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.
Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.
In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.
With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).
No. Remote display is used everyday. Network transparency is not.
Remote display is used only if you are locked into the Windows. And comes with bunch of little problems, of which stuck keys and broken clipboard (until server restart) are though most annoying, the least. Recently admins where I work had to reboot PDC simply because a disconnected remote session got stuck and server didn't allow new sessions because RDP supports only one session.
But that's on Windows, where people have no choice. On *NIX, there is no good reason to choose RDP/VNC over X+ssh. But if you wish, you can RDP/VNC too.
Funny enough remote display is a feature possible on Wayland too.
Do you even know what you are talking about? Wayland's official statement is that network support is out of scope. Because Wayland is an interface to *local* graphical subsystem.
As network support goes, Wayland has only recently gained support for the X protocol (aka X Server can use Wayland as a display driver).
That's a heck of a lot of data, and certainly more than most folks will write in the lifetimes of their drives.
Continued write cycling [...]
That's just ridiculous. Since when the reliability is measured in how many petabytes can be written?
Spinning disks can be forced into inefficient patterns, speeding up the wear on mechanics.
SSDs can be easily forced to do a whole erase/write cycle just by writing single bytes into the wrong sector.
There is no need to waste bus bandwidth with a petabyte of data.
The problem was never the amount of the information.
The problem was always the IO pattern which might accelerate the wear of the the media.
You linked to the list of bugs *fixed* in 3.6
Vast majority of the later bugs were actually caused by the major internal redesigns starting with the version 4: new JS engine (which changed 3 or 4 times) and reworked layout engine. And IIRC there was even one UI security bug, where web-site could trick new FireFox into displaying green verified label for a compromised site.
I'm not saying that 3.6 is perfectly secure. But with AdBlock, FlashBlock and NoScript, it is probably more secure than the recent FireFox out of box. The add-ons cut off the major exploit vectors at the root.
Just where it is in 3.6.
In 29+ the option simply isn't available.
That sounds interesting. Tell me more.
Can one place the close button on the right side in the tab bar? So that I do not have to look at the specific tab in the tab bar while closing tabs in a bulk?
Comparing recent Chrome and FireFox versions, the only real difference is that Chrome still doesn't have a properly functional AdBlock.
But some animations used by web sites are smoother in Chrome, while still jerky in FireFox.
If you do not use AdBlock, or want smoother graphics at cost of ads, keep the Chrome.
If you want AdBlock, then use FireFox.
If you want just a reliable browser, and you are on up-to-date Windows, then better use IE. Ironic as it is, YouTube works better in IE (and FireFox) than in Chrome.
Brrrr.... Close button is still on each tab... The annoying "+" new tab button irrationally placed in the tab bar... Brrr....
Unpredictable and unreliable UI is as unpredictable and unreliable as always.
even if you like Australis, because of all the nice customisation options it gives.
Care to elaborate what are those customization options?
I have the 29 on my Ubuntu VM, and I see much much less options than, e.g. my desktop's 3.6.
Or just install the 3.6. Works too.
I'm not sure about the whole scope of the lay off, but many of the departed were translators and testers. Definitely not "paper pushers".
(My office is near. Some people stopped showing up for the lunch breaks. Asked few other neighbors and learned that Nintendo in the location laid off 160 out of 600.)
That's possibly why in Nintendo's Frankfrut am Main office, about 20% of employees were laid off.
Oh the flip side of financial news.