• (nodebb)

    No, the person responsible for this stored procedure also installed GNU Core Utils on Windows, just so they could have mv and cp to invoke from this stored procedure.

    Never mind that the sadster who was irresponsible for this misbegottery could have spelled them move and copy without having to install anything special.

  • Officer Johnny Holzkopf (unregistered) in reply to Steve_The_Cynic

    Even worse, COPY /Y for cp -f, and MOVE /Y for mv -f. Things people have done in DOS (not that one, the other one) with the NDOS CLI aliases decades ago...

  • (nodebb)

    Probably a case of the old "I know how to do this with SQL and can't be bothered to learn how to configure the task" scenario

  • (nodebb) in reply to Officer Johnny Holzkopf

    DOS (not that one, the other one)

    I can think of several candidates for "the other one". The earliest of these, which I've never, to my knowledge, used, was built by IBM for the original System/360 series, before the arrival of the first S/370s. But there's also TRSDOS, DOSPlus, CBM DOS(1), MS-DOS(2), PC-DOS(2), and so on.

    (1) It lived in the Commodore disk drive series, of which the most widely distributed were the 1540, 1541, and 157X series.

    (2) These were kindasorta similar, and definitely had 99% the same syscall API, but did have certain subtle differences. Notable among these was that BASICA differed from GW-BASIC in that GW-BASIC had to include a complete BASIC interpreter, while BASICA installed extra hooks and then ran the built-in ROM BASIC interpreter (that was present only on actual IBM PCs).

  • (nodebb)

    Yeah, in the old days DOS was pretty much an universal term the described some sort of OS light. With Unix begin considered a full OS. After MS-DOS gained more mainstream penetration with v3, people just used it in a more specific context - plus by this time full OS where already the norm because slimmed down versions died out with the 8-bit era except on the worst architecture back then, the x86 platform :-)

  • AzureDiamond (unregistered)

    most of the basic unix commands like mv/cp/ls are defined in powershell so if this code was made today it would be one less wtf

  • (nodebb)

    rm -rf /

    rm -rf --no-preserve-root /

  • (nodebb) in reply to MaxiTB

    Ah yes, memories of someone at a computer show walking up to a Mac (I think) and asking "does this thing run DOS?".

    Which was at least partly valid, given that 99% of personal-computer business software at the time needed DOS.

  • Kotarak (unregistered)

    or doing what most people seem to need: migrating data into Excel spreadsheets.

    Ok. I will commit heresy. I will back up Excel. There I said it.

    So, why do people want everything in Excel? The answer is quite simple: Because it solves their problems. Now. I'm walking the fence. I do a bit of user work and I do a bit of developer work. I'm developer enough to understand how powerful Excel actually is (and that it's implementation sucks). I did things in Excel 20 years ago without macros, which will blow your socks off today. I'm also developer enough to understand that you should not use that power because it results in a total and complete mess.

    I'm user enough to understand why people do it anyway: Because their boss wants results till noon. Of course, a dedicated tool would be the better approach. But then you have to spent meeting over meeting talking to the boss to get the money (you don't), then with the dev guys so that they understand what you neeed (they don't). Then you wait for your shiny tool to be delivered (it isn't). When it is, it doesn't do what was promised before. You can imagine that noon passed a long time ago.

    So people say: "Screw it". They use Excel. They are done by noon. Their boss is happy. They curse their lives. The developers still try to kybernate TensorFlow on docker in a dapr environment talking to rabbitmqs. Hint: Excel did the job.

    And of course the average user has no clue himself, what he needs, which doesn't exactly help.

    So whenever we mock Excel, we should also remember that we are part of the problem.

  • (author) in reply to Kotarak

    Remy's Law of Requirements Gathering: no matter what the requirements document says, what your users really wanted was Excel.

  • Zutroy (unregistered)

    It's "SQL Server Integration Services"

  • Brad Wood (unregistered)

    As I always say; all rows flow through Excel.

  • LZ79LRU (unregistered)

    Honestly, I think everyone who dislikes Excel is frankly missing the point of our profession.

    Excel is not just a tool. It is the best tool for most jobs. Why? Because it is fast, easy to use and most importantly good enough.

    It's easy for us developers to cite all the ways that a custom piece of software might be better for one particular use case or another. But a custom tool comes with extra cost development time, learning time and a whole lot of other downsides. And at the end of the day all you achieved is accomplish one of the users daily tasks marginally better. And he has a lot of other tasks to do other than that one. So the cost benefit just does not work out.

    We are not artists, we are not philosophers. We are engineers. The job of an engineer is not to chase after perfection and beauty but to provide practical and cost effective solutions to real world problems. And for that, the fist and most important rule is and shall always be "Good enough IS in fact good enough."

Leave a comment on “The File Transfer”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article