Good to know about ed! Since noone else has mentioned this, emacs' keyboard macros seem much easier to me especially since more than the basic editing stuff off awk/ed/sed i can leverage all the editor extensions and modifications i have accumulated over the years. That is unless its tens of thousands of files and the edit is exceptionally simple. I would write a script in that case too.
Since discovering them, I use Emacs keyboard macros all the time.
Let's say I have:
key value
salt pepper
fish chips
vodka orange
rum cola
and I want the second column in uppercase.
<F3> to start recording a macro. Alt →, → to position the cursor at "v" (or just →→→→→→ if this is a fixed width column), then Alt U to uppercase the next word. → to move the cursor one forward, to the start of the next line. <F4> to finish recording the macro.
Then press <F4> five times to run the macro five times.
(Explanation intended for users who've never used Emacs before. Of course, there are optimizations.)
But in this example I would have probably used ex command:
:%normal wgUaw
(for every line do as if I had typed wgUaw) or visualy selected the second column as a block and just pressed U.
I'm genuinely interested in someone showing how to do this kind of trasformation in popular modern editors such as Atom and VSCode. Is there such a flexible way as in the classic editors?
You can do it using multiple cursors. On Sublime, you place the cursor on beginning of “value”, then press Ctrl+Shift+Down until the end - there will be a cursor on every line. Then you press Ctrl+Right to select all values on the second column. Then press Ctrl+P and choose “Convert to Upper Case”, or just Ctrl+KU.
The main reason i am not moving to something more trendy are kbd macros and the fact that emacs is designed to be equal parts runtime and editor. I think that for most purposes emacs and vim are equivalent but virtually all modern editors are lacking compared to a well good emacs/vim configuration.
Microoptimizing a couple of things, I'd do this from the top of the buffer:
<F3> M-f M-u C-n C-a C-0 <F4>
I particularly like combining the "finish recording" and "running the macro" steps into a single <F4>. Plus, using a numeric argument of 0 seems better than counting lines.
Typeclasses and parametric types are there to leverage the typesystem. It's hard to see how you can benefit from these abstractions if all you have is ducktyping.
Javascript doesn't support duck typing. It doesn't support any typing actually: it's dynamically typed.
If Javascript can inspire respect for type systems, it's by making you realize that not having type annotations leads to terrible, unmaintainable code.
> Javascript doesn't support duck typing. It doesn't support any typing actually: it's dynamically typed.
Dynamically typed doesn't mean untyped; you still have types in JavaScript. Most dynamic languages are strongly typed, not untyped. You're conflating a few unrelated things. JavaScript is duck typed, as virtually all dynamic languages are.
Dynamic typing is a typing. Also, duck typing is used more in the dynamic sense than the static sense, where in the latter it is instead called structural typing.
AFAIK most compiler will do tail-recursion optimization if the method ends in a tail call to the current function (obviously) or to a "sibling" function (i.e. if a() calls b() which calls a() again and so on) and is sufficiently short to be suitable for inlining.
It's important to remember local objects with destructors will make this impossible, since destructors are run at the end of the function scope and thus after what's seemingly a perfect tail call.
I don't think the author claims they found something groundbreakingly new. In fact just the references contain all the points Liam makes.
Patches-vector seems to be different to ottypes for example in that ottypes have predicted what types you would want to synchronize and provides you a correspondig OT type for each of them. What if I want to synchronize binary data or javascript objects or some other weird thing? If equality is defined for my object the library shouldn't need to make any other assumptions.
Besides this practicality though, I think the whole point of the article is that one can mathematically reason about patches-vector.
I assumed that `Int` was the sequence index of the Edit, not the line number. The line position, which is not necessarily the line number, it might be contextual, is encoded in `a`. In fact the way I read the article was that `a` was a file, so you can have operations:
- Insert Int File == "create file"
- Delete Int File == "delete file"
- Replace Int File == "patch file"
Removing and Inserting a file each time it changes, while technically correct is probably not what you want.
The nice thing about what Liam proposes (and type classes in general) is that it doesn't matter what we each interpret `a` to be.
Well, a patch is defined as Patch [Edit a], so I presume the sequence of the edit is implicit in the list position. The article says that an edit is the modification of an element of a Vector. I think the parameter a is the type of the elements of the Vector. In your example, a Patch File would be something to apply to a Vector File, and the Int in the edit should be the index of the file in the vector.
I see your point about the larger fonts but I have used the sunburn theme for a while in my editor (not anymore thought in favor of slightly customized naquadah[1] ) and I feel quite a bit more comfortable reading code in familiar coloring.
I chose this color scheme because sunburn dark is quite popular.
Perhaps your color vision is now at the point where you should consider loading an accessibility stylesheet into your browser. I don't look forward to the day when I am required to do this, but I do know that it will inevitably arrive.
