Wikipedia:Reference desk/Archives/Computing/2018 February 3

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

February 3

What's the point of the "All Files" option for "Save link as..." in Chrome?

I'm using Chrome in Windows 7. When I right-lick on a link I'm given the usual options (starting with "Open link in new tab"). If I pick "Save link as..." Windows Explorer opens and I'm given the choice of saving the link either as a "Chrome HTML Document" or as "All Files". What is that "All Files" thing for? When I try it I sometime get a file with no file type. Now when I open it with Chrome then the result is the same as if I had saved it as a "Chrome HTML Document". So it is saved as an HTML Document no matter what. So what exactly is the point? Thanks. Basemetal 15:03, 3 February 2018 (UTC)

It allows you to choose file extension. Ruslik_Zero 20:21, 3 February 2018 (UTC)

You should be able to partially choose extension without it. If you give the file a name like 'save file.txt' or 'save file.com' or 'save file.jpeg' or something with a recognised extension (I think recognised in Windows Explorer), it will not add an extension. If you give the file a name like 'save file.meow' it will probably add the extension, so the final file name is 'save file.meow.html'. If you choose the 'All files' option, it should never add an extension. The all files option will also show all files (except those hidden due to Explorer settings) in the target location. Otherwise you will only see those with the .html extension unless you put the * wildcard into the file name box and hit enter. Nil Einne (talk) 04:28, 5 February 2018 (UTC)

Thanks guys. I have another question: When you're displaying a page in Chrome and you right-click on it then the options you are given for saving (that is when choosing "Save as...") are "Webpage, complete" and "Webpage, HTML only". On the other hand when you right-click on a link in a page you get (when choosing "Save link as...") what I said above (namely "Chrome HTML Document" and "All files"). So my question is: Why the difference? Why not behave the same when right-clicking on a page and when right-clicking on a link in a page? Thanks. Basemetal 19:03, 5 February 2018 (UTC)

The laziness of Chrome's programmers. 78.0.213.2 (talk) 04:32, 6 February 2018 (UTC)

Not necessarily. The are obvious implications for changing the behaviour. 'Save link as' just saves the link whatever it is (e.g. a 7zip, PDF, txt, aac, jpg) with minimal processing or interpretation. I believe it follows stuff like HTTP 303 but not much more. When you use 'save as' with a loaded page, and choose the 'complete' option, it saves the extra loaded files that are necessary to display the page, generally including images, css, fonts and possibly even some scripts in a directory with the same name and modifies the HTML file to refer to these local copies. It's able to do this because the page has already been interpreted (and rendered). It would be possible to do this without displaying the result, but I'm not sure whether that's something which really already coded for i.e. it may be more than just a few lines of code. Further while I wouldn't recommend you actually do it with any untrustworthy page, simply saving a link should generally be fairly safe with fairly limited risk from browser vulnerabilities. By adding the 'Complete' option to the save link and interpreting the page, you are increasing the security risk whenever that is used whether by accident or on purpose. Note although AFAIK it would be possible to 'save complete' without properly rendering the page (e.g. interpreting the images and fonts), I wouldn't be surprised if this is simply something Chrome, as with any browsers, does not do. There are plenty of spidering type programs which can do this if it's desired. While it may seem weird considering how much people encounter what they consider feature bloat, I'm fairly sure developers do actually consider whether they should bother to add a feature for reasons besides laziness or time, such as the risks of adding more complexity to the code. Nil Einne (talk) 05:12, 7 February 2018 (UTC)

When to use what programming paradigm

Besides [1] I am having trouble finding more precise examples about when to use what programming paradigm. --Hofhof (talk) 19:34, 3 February 2018 (UTC)

You can look at Comparison_of_programming_paradigms. Ruslik_Zero 20:25, 3 February 2018 (UTC)

I already took a look at it. I was hoping for something more specific — a concrete example about a project that decided for this or that paradigm. --Hofhof (talk) 20:43, 3 February 2018 (UTC)

Often it will be guided by the system on which the end program will run. eg interactive systems Microsoft Windows, iOS will be event driven as the user does things, eg types, clicks, touches, turns the phone. A program on a mainframe to pay workers may be procedural, ie print out the check, move money, update account. But this may also be time driven- once a fortnight. A building automation system might be declarative, eg keep the tempeerature between 22 and 25°C, have lights on when there are people in the office. Graeme Bartlett (talk) 22:21, 3 February 2018 (UTC)

Here is my iron-clad rule. Break it at your own risk. If you have complex algorithms and performance is not that critical, use the functional paradigm with OCaml or Haskell or Racket. If you need portability and performance, use C (which is nominally imperative), but keep OO and functional paradigms in mind. And if performance of your code does not matter (because the problem is simple or the heavy lifting is done by external libraries), use OO with Python (and lambdas! ;-). If you can't make up your mind, use C. C will still be around to control reversion of the polarity of a tachyon beam when all the other languages are left in the dust of history. --Stephan Schulz (talk) 21:29, 11 February 2018 (UTC)

Modern desktop applications, and the operating systems that run them, are invariably object-oriented. This includes Windows, Linux, MS Office, Firefox, etc., and is because these programs all use large portions of existing code: the object-oriented paradigm is the only way to do this at scale. As such, it's really more of a super-paradigm, in that the other paradigms listed will also be object-oriented. That said, the only real difference I see today is between functional languages such as Python and Scala, and imperative languages like C++, Java, C#, etc. Even then, other than a few esoteric languages like Haskell, programming languages are a blend of paradigms, because programs have to do multiple things, and this gives the language (and the programmer) flexibility to choose the paradigm best suited to the task at hand.OldTimeNESter (talk) 14:45, 4 February 2018 (UTC)

In 40 years of programming, I've never had the choice of a paradigm (or even a language) unless it was something I was doing on my own. Professionally, management chooses everything. The programmer is just a code monkey. So, how does management choose? They invest in a paradigm or a language. Once invested, they need to show return on the investment. To show return, the programmers must use the paradigms and languages (and packages and tools, etc...) provided. It is a choice of what is best. 71.85.51.150 (talk) 19:36, 4 February 2018 (UTC)