2 ms·

> "And I'll take your challenge. Here's something I can do in Emacs: I can take a spreadsheet received from a client, full of intended configuration settings fo

> "And I'll take your challenge. Here's something I can do in Emacs: I can take a spreadsheet received from a client, full of intended configuration settings for a custom internal application. I can export it as CSV, load it in Emacs as such, and extract the relevant sections of the content into tables in a plaintext Org-mode document. I can then add a function to that document, in whatever language I choose, which will receive the contents of those tables as structured data in the language's own idiom, and generate the collection of complex SQL statements necessary to implement the desired configuration. From there I can decide whether I want this SQL script inserted into the document I'm writing, or written out to a file that I can copy to a remote host and feed to the SQL monitor. Or I can instead have Emacs itself connect to the target RDBMS and apply the configuration directly. Or any combination of those. And once the document's written, I can do all this with a single keystroke. Another single keystroke exports the document to HTML, so I can share it with the client to demonstrate exactly how their intent has been translated to reality, and with colleagues so they can see what's been done." Okay, so let's look at this. If I've understood correctly, you want to be able to generate data migration code based on a CSV file, and export that code so that it's ready to be inserted into documentation, is that a fair assessment? So for Visual Studio, one way to do this would be to write a custom runner for Fluent Migrator: https://github.com/schambers/fluentmigrator https://github.com/schambers/fluentmigrator https://www.nuget.org/packages/FluentMigrator/ https://www.nuget.org/packages/FluentMigrator/ https://www.nuget.org/packages/FluentMigrator.Tools/ https://www.nuget.org/packages/FluentMigrator.Tools/

throwanem 11y ago
Nope. This isn't a migration; it's one-off data population. Fluent Migrator can do that, from its documentation, but it wouldn't be required, and since this isn't a migration, Fluent Migrator doesn't really bring anything to the table that I can see. So you're building a custom software project in your language of choice, with all the overhead that implies. In the workflow I described, you create a file and activate Org-mode. (Or just create a file whose name ends with ".org".) There's also the documentation task, which has to include the source data and resulting SQL script, as well as the transformation code. I'm not seeing anything here that would simplify that in the slightest; you'd have to either write the HTML document by hand, or write code to generate HTML. In the workflow I described, all that code is already written, and you can invoke it with a single keystroke. And beyond that, there's the matter of data ingestion. You're starting from CSVs, so you have to read those and parse them just to have the data you need to work with in a form which you can use. Any serious language has a CSV parsing library, of course, so that's not a difficult task in its own right, but it's still more code you have to write, and more effort you have to put in - selecting a CSV parser, adding it to the project, learning its API, et cetera. In the workflow I described, it's a copy-paste operation. Don't get me wrong - I didn't say, or assume, that anything I described couldn't be done in Visual Studio. But at this point we're talking about, what, a few hours at least? And you're spending a fair chunk of that time on overhead, especially in document generation. You have to find, vet, and install libraries, write or modify a bunch of code, and so forth. By the time you're done, you've probably had to spend the better part of a day on this one task. In the workflow I described, the only code I needed to write was that in which I expressed the actual transformation from tabular data to SQL statements. Everything else, Emacs and Org-mode took care of for me; all I needed to know was how to invoke capabilities already present. And I had the job done and dusted in less than an hour, with plenty of time left in my day for other work. That's what I mean when I say Emacs and Vim give you superpowers - not that there's anything you can do in one of those editors that (with enough effort) you can't do in another environment, but that those editors are better than anything else (at least anything else I or anyone I know has ever encountered) at helping you get more done, faster, without having to spend time on ancillaries that distract you from the meat of the task at hand.
- ZenoArrow 11y ago
  > "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke." The thing is, if that's the case, what you're describing isn't a custom plugin, it's an existing plugin someone else has taken time to write that you're making use of. If that's the argument you're making then you could say Emacs has a better ecosystem of plugins, and that it's easier to tie them together, is that what you're trying to state?
  - throwanem 11y ago
    It's a subset, and the Blub paradox applies. For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up. For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself. You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up. As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.
    - 11y ago

throwanem 11y ago

Nope. This isn't a migration; it's one-off data population. Fluent Migrator can do that, from its documentation, but it wouldn't be required, and since this isn't a migration, Fluent Migrator doesn't really bring anything to the table that I can see. So you're building a custom software project in your language of choice, with all the overhead that implies. In the workflow I described, you create a file and activate Org-mode. (Or just create a file whose name ends with ".org".) There's also the documentation task, which has to include the source data and resulting SQL script, as well as the transformation code. I'm not seeing anything here that would simplify that in the slightest; you'd have to either write the HTML document by hand, or write code to generate HTML. In the workflow I described, all that code is already written, and you can invoke it with a single keystroke. And beyond that, there's the matter of data ingestion. You're starting from CSVs, so you have to read those and parse them just to have the data you need to work with in a form which you can use. Any serious language has a CSV parsing library, of course, so that's not a difficult task in its own right, but it's still more code you have to write, and more effort you have to put in - selecting a CSV parser, adding it to the project, learning its API, et cetera. In the workflow I described, it's a copy-paste operation. Don't get me wrong - I didn't say, or assume, that anything I described couldn't be done in Visual Studio. But at this point we're talking about, what, a few hours at least? And you're spending a fair chunk of that time on overhead, especially in document generation. You have to find, vet, and install libraries, write or modify a bunch of code, and so forth. By the time you're done, you've probably had to spend the better part of a day on this one task. In the workflow I described, the only code I needed to write was that in which I expressed the actual transformation from tabular data to SQL statements. Everything else, Emacs and Org-mode took care of for me; all I needed to know was how to invoke capabilities already present. And I had the job done and dusted in less than an hour, with plenty of time left in my day for other work. That's what I mean when I say Emacs and Vim give you superpowers - not that there's anything you can do in one of those editors that (with enough effort) you can't do in another environment, but that those editors are better than anything else (at least anything else I or anyone I know has ever encountered) at helping you get more done, faster, without having to spend time on ancillaries that distract you from the meat of the task at hand.

ZenoArrow 11y ago
> "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke." The thing is, if that's the case, what you're describing isn't a custom plugin, it's an existing plugin someone else has taken time to write that you're making use of. If that's the argument you're making then you could say Emacs has a better ecosystem of plugins, and that it's easier to tie them together, is that what you're trying to state?
- throwanem 11y ago
  It's a subset, and the Blub paradox applies. For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up. For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself. You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up. As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.
  - 11y ago