It's an interesting award. Walter Duranty won a Pulitzer for denying the holodomor, and he was awarded a Pulitzer for his work, a Pulitzer that the Times has yet to address.
The reality that Duranty denied was comparable to the holocaust. Hundreds of thousands, maybe millions, of people died and the Times apologized for it.
I've been thinking about striking out on my own, having both run a contract software business and worked for a startup recently.
I'm inclined to think that the best way to find fit is to make sure people are willing to _overpay_ you for services. For instance, I have a great deal of expertise when it comes to graphics, and I could probably insist on being overpaid in this realm.
If I could automate what I am overpaid for at scale I might have a business.
I'm an evangelizing convert to Prettier. I was hesitant about it until I tried it, but... I am sold on it now. Prettier has costs- there are cases where I'd like to format things based on semantics not syntax, to show intent, and Prettier can't read my mind (feature request: make Prettier read my mind.)
But the costs are more than offset by the benefits. I didn't realize how much of a cognitive burden thinking about formatting was until I stopped thinking about it, and it turns out that using formatting to signal intent is perilous when people don't agree on how formatting signals intent.
I'm pushing to have Prettier used across all our JS code- there is some resistance to the idea of running it across a several hundred k line non-prettified codebase and some resistance to the idea of using it at all. And this causes problems. Prettier is best when you use it for everything.
But I'm pretty sure we'll eventually just move to prettification. It seems like the right thing to me, and I'm generally right ;). Anyway, thanks for Prettier- I am not actually a huge JS fan despite mostly writing it professionally, but Prettier does away with some of my complaints about JS, and just generally makes my life easier.
I keep hearing good things about VSCode. If I weren't essentially married to emacs I'd definitely try it out. I'm not sure I'd recommend emacs to everyone at this point, though I think it remains a really solid choice of editor/OS for people willing to get over the learning curve and put up with a bit of clunkiness.
Re the git stuff though- one place that I'm pretty sure emacs is the uncontested champ is in git integration via magit. I'd be inclined to recommend using emacs as their git interface even to people who want to use a different interface for everything else. It is that good, and IMHO the only git porcelain that is strictly better than the standard git porcelain.
I started playing with emacs 24 years ago, then spent 20 years as a devoted vim user with a two year work-enforced gap in Eclipse. I tried spacemacs in evil mode about four years back and stayed for magit. I tried VSCode a few weeks ago to see what the fuss was about and had my Eclipse PTSD triggered. Magit, mu4e, elfeed, eww, multiterm, restclient.el, tramp, [edit]org-mode![/edit], the list of replacements for bloated "native"- and surveilling web-apps keeps growing. I mentor an up-and-coming developer who has learned more– about git, the filesystem, shells –in four weeks of using spacemacs than the 23 months of using Atom and VSCode. I know emacs in evil mode makes me smarter and more productive, and I'm seeing anecdotal corroborating evidence in my community.
There's an old joke: "Emacs is a great OS, but it lacks a decent text editor." Only vi users are allowed to tell that joke with a straight face, IMHO.
Evil-mode solves that, and just as magit is better than git evil-mode seems, to me, better than vi. Emacs is better than ever (though you do need to use auto-formatting for languages like JS that change a lot- there is no emacs mode that has kept up with ES whatever. Luckily emacs makes it easy to use formatters like prettier on a per-buffer basis.)
I am using vim for years now, and I haven't written more than 50 lines of vimscript apart from the bundles. Most of the thing that I have written is just maps, some configuration for other bundles, and some copied better defaults. I still don't get it when people say they heavily use elisp. Can anyone give example of a highly custom thing that you do in emacs/vim/any other editor, for which there is no famous bundle available.
The question is not elisp v. vimscript but rather the power of not having to switch contexts. To write code for a locally-hosted RESTful API I used Chrome to read the API docs, Postman to make the calls, iTerm2 to start/restart the server and read the logs, and a text editor to make changes. I replaced that flow with eww, restclient.el (amazing!), multiterm, and an editor buffer. No changing of context, conserve about ~1GB RAM in Chrome instances, full-screen if I want it, and everything is text (I'm looking at you, Postman).
On the "highly custom" level, I have a work-in-progress script that takes a URL, sends it to a Splash server, and returns the rendered HTML to eww for viewing. This is great for annoying SPAs like the article that spawned this conversation.
My current goal is to swap out my development MBP with an eInk tablet and bluetooth keyboard. Success will be measured as a function of productivity and weather-/water-/environment-proofing of the device; the goal is productivity in full sunlight and/or under water. Emacs will have a central role in that. Just need to find an eInk device with adequate screen refresh rate and Bluetooth support....
I'm using Org Mode to write my thesis and, although most of the functionality I use comes from vanilla org mode, I do need to write some Elisp to get the LaTeX export working properly, and to knit different projects together into a single one.
As another example, it took me less than 30 lines of Elisp to get Apple Music incremental searching from within Emacs. A highly custom thing that I don't get elsewhere.
I think you've assumed the wrong premise. At least for me. It's not the highly customised things, it's the accumulation of the small things that are either missing, inconvenient, slightly annoying or somewhat different to your needs.
Every package developer makes choices about how their package works (and built-in behaviour too), but sometimes that clashes with what you want, or is somehow inadequate.
It's those small conveniences that have a disproportionate impact.
I'm not saying you can't do similar in vim or there aren't other ways to achieve the same goal, I'm saying that over time, those minor improvements have a huge impact.
Here's 2 examples:
1) Splitting a window horizontally by default splits 50:50 but on a 16:9 monitor I usually want the new buffer (right) to be smaller than my current buffer (left). So I override the defaults.
2) I use paredit for lisp based languages, but (as far as I'm aware) there's no built in-command to copy (or paste) the s-expression surrounding the cursor's current position.
I often find myself wanting to do exactly that e.g. in a let or a cond form in Racket. So I wrote a couple of small functions to do just that, bound them to keyboard shortcuts and I've now made a minor extension that fits exactly what I want to do. Since lisp is based on s-expressions it turns out this extension to someone else's package is incredibly versatile and useful.... TO ME!
(let [<CURSOR>(x (some-function with args)]
I press my chosen key-combination and it becomes
(let [(x (some-function with args)]
[<CURSOR>(x (some-function with args)]
In vim, when you're in visual selection mode, you can type `ib` (inner block) to select the innermost parenthesized block's interior or `ab` to include the parentheses. If you type these commands multiple times, the selection widens to the next, next, next ... enclosure.
There are other similar commands in the category, like a" for selecting the interior of a double-quoted literal and such.
They are documented under ":help visual-operators".
I wholeheartedly agree: Magit is that good, really. The way I see it, it reduces the burden associated with carrying the required git mental model in your mind, by giving you easier points of entry into its complexity. I owe all the slightly more advanced things I now routinely do with git (which would probably be seen as pretty basic by a lot of people though) to Magit, without question.
Yep- I was reminded of how much I like magit by this thread so I just made a $100.00 donation to its development. I hope it inspires other people to at least give magit a try (if I'll donate that much it must be good, right?)
Yep- I'm actually a pretty old hand when it comes to git, and I know most of what git can do, but... I'm lazy, so when I use git at the command line I do caveman git. Magit lets me remain lazy and do subtle git things,
I'd say it's uncontested if you like using emacs. Because - for me - it's awful. Mostly because I find using vim or emacs awful and only use either of them when I absolutely can't avoid it.
But that said - it does it's job very well and magit is certainly excellent software for those that are interested in that interface.
No... I mean I hear you about not liking emacs/vim/evil-emacs. I happen to like evil-emacs, but I can see why other people would prefer VSCode. That's a matter of taste, and I won't tell people to switch.
But when it comes to magit I'm not so sure. I'm inclined to think that magit is _strictly_ better than any other git interface, so much so that even if you don't like emacs you should suck it up and use magit as your git porcelain, even if you use a different editor for everything else. Magit is that good- I just gave $100.00 to the project, and I never donate to open source stuff. It is that good.
Again - having used Magit because I heard the same effusive praise - it’s goddamn awful if you don’t like using emacs.
I don’t mean “it’s not my preferred git client”. I mean “I’d rather use almost anything else”.
Why? Because it requires emacs interface, concepts, and controls. And unless you’re ok with those it’s not better at all. In fact it’s _strictly_ worse.
That said: if you like emacs I think you’re correct, it’s almost certainly the best there is.
I think it's genetic. Whatever allele is responsible for emacs affinity, some people have it. It never ceases to amaze me how early in their studies they latch onto emacs and start doing increasing amounts of their computing through it.
Others, such as myself, suffer it only when compelled by an instructor.
IMO it certainly takes some learning curve to get up to speed with the keybindings and concepts. In the beginning anybody would struggle but after the learning efforts you'd find it to be much more productive than the other editors.
Interesting. I prefer to write in high-level strongly dynamically typed garbage-collected languages when I can.
But of course I can't always do so and get the performance I want. My approach is generally to prototype in languages like Python, but implement in C89. See: https://www.youtube.com/watch?v=WNTOpl30MIQ . That's 10s of thousands of times faster than our initial prototype and...
We profiled all sorts of things in order to make it that fast. Right down to cache misses, branch mis-prediction, etc, how concurrency on the CPU interacts with I/O.
I think it's pretty clear at this point that citing Chomsky in cases like this is like citing Velikovsky when discussing celestial mechanics. Wrong and inapposite.
you're probably right - somebody start teaching this girl english, she'll be fine! what's the father of cognitive science and modern linguistics know about anything?
> what's the father of cognitive science and modern linguistics know about anything?
If he hasn't observed at least a dozen such children trying to learn language for a dozen years then he doesn't even know what are the things he doesn't know.
And guess what, I watched your video and even Chomsky admits that he only heard about few cases of feral children of which the one he talked about in detail means little because the girl was severely mistreated by parents in addition to growing up in isolation. And then he talked some more about other people inventing their own languages, but not living in complete social isolation.
Hmm- gonna get flamed here, no matter what I say, so... I'll try to be a bit delicate, but not going to put too much effort into delicacy.
I understand loving CL. CL was, I think, the first programming language I really loved passionately, for itself I loved programming in C passionately before that, but in retrospect it was more a matter of having gazed from afar at the machine for so long, and suddenly realizing that C would bring me much closer to her than BASIC had. C was just an intermediary, though I did not understand that at the time. We have good relations to this day, but I'm afraid I do not love her, and never really did. I just used her to get close to the machine.
I still love the machine, but, as they say, familiarity breeds contempt, and it eventually became apparent that we would be better off at some remove from each other. No judgment- it's just that I happen to be fairly abstract, and the machine likes to pretend to be concrete (on some level I suppose she is, but I'm pretty sure we never dug that deep in our relationship.) I suppose that that was, perhaps not so co-incidentally, right around the time I met CL again.
I'd flirted with CL in University AI classes, even worked with her a bit in a computer vision lab, and I'd always thought she was attractive, if a little off-beat. But then I fell for her, obsessively, and for a while she was all I could think about.
I cherish our time together. I was such a bumpkin when we met, and she challenged me at every turn. "Why," she'd ask, "must a byte have eight bits?" And I'd be forced to admit that she was right-a truly inclusive computing culture ought to accept bytes of all different sizes. I won't get into our discussions of filesystems here.
And I was introduced to her friends. What a lively bunch they were, and what a smart bunch. I remember I once asked her friend Erik for the time and... well, actually he suggested that I might want to start carrying a watch or just go home and kill myself, but then he explained some things about time that I carry with me to this day. He was the most provocative of CL's friends, but many of her other friends were not only brilliant, but perhaps monotonically increasingly old and disappearing.
The great thing about CL is that it has a standard that is hard to change. The worst thing about CL is that it has a standard that is hard to change. For many years the former overcame the latter. I'm inclined to think that that is no longer the case.
CL allows us to write code the way we think about a problem--and then bring life to that way of framing the problem. We can come up with an ideal way of describing a solution and then make a language work that way. I say a language because the target of our code might be C or JavaScript (these days that is more often the case for me than targeting CL itself, cf. 4500 recent lines of Lisp that turns into 8000 lines of terse JavaScript).
Our ability to reason correctly about systems directly corresponds to how complex they are. And I posit that complexity in code is best measured in number of symbols (because lines can be arbitrarily long, and longer symbol names can actually be helpful). So a system that reduces the number of symbols necessary to express a solution increases the size of a solution about which we can successfully reason. Just as computers are a "bicycle for the mind", homoiconicity+macros (of which I posit CL is still the best practical implementation) is a "bicycle for the programmer's mind".
Lisp provides an optimal solution for thinking of programs as nested sequences of arbitrary symbols. Sequences that can be transformed (and must be, for a computer to evaluate them, unless we hand-write machine code!). Common Lisp provides an optimal set of built-in operators for composing operations and transformations on its fundamental data types (atoms/cells/lists/trees). Other languages might provide better implementations of particular paradigms or whatever, but CL is the best language for implementing macros. Other Lisps make macros "safer" and miss the point.
As Vladimir Sedach wrote earlier on Hacker News[1]:
"The entire point of programming is automation. The question that immediately comes to mind after you learn this fact is - why not program a computer to program itself? Macros are a simple mechanism for generating code, in other words, automating programming. Unless your system includes a better mechanism for automating programming (so far, I have not seen any such mechanisms), _not_ having macros means that you basically don't understand _why_ you are writing code.
This is why it is not surprising that most software sucks - a lot of programmers only have a very shallow understanding of why they are programming. Even many hackers just hack because it's fun. So is masturbation.
This is also the reason why functional programming languages ignore macros. The people behind them are not interested in programming automation. Wadler created ML to help automate proofs. The Haskell gang is primarily interested in advancing applied type theory.
Which brings me to my last point: as you probably know, the reputation of the functional programming people as intelligent is not baseless. You don't need macros if you know what you are doing (your domain), and your system is already targeted at your domain. Adding macros to ML will have no impact on its usefulness for building theorem provers. You can't make APL or Matlab better languages for working with arrays by adding macros. But as soon as you need to express new domain concepts in a language that does not natively support them, macros become essential to maintaining good, concise code. This IMO is the largest missing piece in most projects based around domain-driven design."
Unfortunately, those people that only treat programming as a way to pay the bills - with a six figure salary - which would be the vast majority of professional programmers working today, do not want to understand _why_ they are writing code. The commoditization of software engineering that companies like Google [1] enthusiastically support and promote is also directly responsible for the obliteration of the entire field.
In a world where geniuses like Alan Kay are almost unheard of and
Tim Berners-Lee ends up receiving the Turing award (next: Stroustrup/Rob Pike) there really isn't a lot of hope for languages like Common Lisp to proliferate. They're simply too meta and require a lot more from you than just settling for whatever makes one feel good about him/herself in an immediate-rewards sense.
I think you're massively overstating your case when you say "optimal." There is no evidence anything CL provides is optimal according to any rigorous metric. I could very easily claim Scheme is "more optimal" since it's a much more minimal implementation with the same capabilities. Also I think you are mistaken to equate fewer symbols with easier to reason about symbols, e.g. I find it much easier to reason about complex programs when they are written in a strong static type system, which CL lacks. The type system lets me leverage the computer to help me reason about the program, by type checking.
Then the computer is doing the reasoning, not (just) you. Static typing will certainly help you reason about a larger system, I do not dispute that. I am talking about increasing the capability of the largest symbol system you operate on in your mind without relying on the computer. If the meaning-density of the symbols is higher, your effective intelligence goes up.
Some people are just very much drawn to ML and/or lisp. For some people it just maps in a very nice way to how you imagine a solution to a problem.
I don't think it is much more than in other languages, it is just that there is a culture within those communities that promotes: "hey wow, I just did something cool. Look".
As a lisp guy I stare in envy at the cool things people do in ML.
You don't build a network at a company. You build a network in an area, perhaps more than one. You can be a complete idiot and still be well-known among local programmers (some of whom might not realize that you're dumb, and might hire you.) Imagine how far you might go if you're not dumb.
