-
I don’t know if language choice has anything to do with it, but the fact remains: the service is now dead. ;)
I agree in 2012 the state of Python3 support was a valid concern, and I have to admit actively discouraging people from learning it at the time, but luckily that part hasn’t aged well. I still want better FP support in Python of course.
My biggest problem with Common Lisp is that it’s a Lisp-2. Why would anyone want different namespaces for functions and other bindings in an ostensibly functional language?
-
Why would anyone want different namespaces for functions and other bindings in an ostensibly functional language?
According to this site, one of the arguments was “backwards compatibility”:
Common Lisp was the result of a compromise between a number of dialects of Lisp, most of which had separate namespaces.. [transitioning to a single namespace] would introduce a considerable amount of incompatibility..” There are really more than two namespaces, reducing either the benefit of collapsing these two or the cost of collapsing them all
which I don’t find that convincing, since there were plenty of lisps using dynamic scoping, despite CL using lexical scopes. But I agree, things like these together with, frankly wierd function names always annoy me. I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.
-
I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.
There’s a page which I can’t find now which makes the case that the term “functional programming language” evolves over time to mean “the most functional programming language which currently exists”, so different features rotate in and out of defining what it effectively means to be a functional programming language.
(I’d add that each generation has a different boogeyman idea, an idea which the Average Programmer regards as being “too complex” and which others write blog posts or the local equivalent to explain.)
The first generation was when Algol introduced recursion. Recursion is also the boogeyman idea of this era.
The second generation begins with “mature” Lisp (that is, Lisp implementations like MACLISP and Lisp Machine Lisps, not LISP 1.5) and, later, Scheme, where the defining feature is first-class functions and closures, and the boogeyman idea is Scheme’s continuations. Common features are strong dynamic typing and a universal feature is garbage collection. The new-school scripting languages (Perl, Python, Ruby) are languages of this type with object systems bolted on, and Java’s getting there, slowly.
(Some pre-Common Lisp Lisps didn’t have closures. They had the upwards funarg problem, instead.)
The third generation is ML and everything after, including OCaml and Haskell. Now, functional programming includes strong, static type systems with algebraic types, Hindley-Milner type inference, and, at a syntactic level, pattern-matching as flow control. The boogeyman idea is monads, and, more specifically, requiring the use of monads to mark out side-effecting code, as Haskell does.
The underlying point is that “Functional programming is whatever your language of choice doesn’t have yet”: Recursion is now universal. It wasn’t when FORTRAN IV was “your language of choice” for a lot of programmers. Strong dynamic typing and garbage collection aren’t universal, but they’re not weird and wacky ideas only long-haired MIT AI Lab types can make sense of. Marking your side-effecting code in a machine-readable way is still weird and wacky… for now.
-
-
-
-
It might be slightly easier to write tooling when you know what’s a function and what’s a variable.
On the other hand, if you use a Lisp-2 in functional style (which poorly suits Common Lisp), you still have the problem of full analysis between the boundary of namespaces + awkward syntax. It looks like Common Lisp is meant to be used in imperative style, without juggling functions as values.
-
-
-
-
Sounds like a good time to finally set up my bouncer. If only there were one that had good Emacs compatibility.
-
I just run weechat on a server and connect to the weechat relay with weechat.el. There’s a few bugs in weechat.el (e.g. nicks go out of sync) and some things missing (e.g. nick list), but that’s a small price to pay for replacing another standalone app with emacs :)
-
I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).
-
-
-
I’ve been trying to set this configuration up for half a year now, but I never get anything I’m satisfied with. The ZNC documentation is quite bad and confused, imo. And when I manage to set it up, even using ZNC.el it won’t work with IRCnet. Switching between multiple servers is another annoyance.
But maybe I’ve just messed up somewhere.
-
-
I used to use znc, seemed to work just fine with ERC.
Now I use weechat (a bit more features, nice Android app), again with ERC. There is weechat.el, but I prefer ERC (connecting to what weechat calls an “irc relay”, instead of using the weechat protocol). I use https://gist.github.com/unhammer/dc7d31a51dc1782fd1f5f93da12484fb as helpers to connect to multiple servers.
-
-
-
In case it’s useful - I used to use ERC, and I switched to Circe long enough ago that I can’t exactly remember, but I think the issue was that I wanted to connect to both freenode and an internal IRC server at the same time, and ERC made that awkward or impossible to do. It may well have improved in the last 5 years though.
-
-
-
-
-
Nice. Where should I contact to make a translation? I wanna make a Vietnamese translation for this. Just like the German one.
-
I’m guessing the contact address at the bottom of the site: info@adfreeblog.org
-
-
Studying X11, Xlib, xcb, xgb, XRender. Need to load all the concepts into my head.
-
-
Sources are all over the place. xcb/xgb is notably poorly documented, but most of Xlib applies with slight modifications. Yet Xlib docs aren’t necessarily practical. It took me a good while yesterday to understand visuals and how to create an ARGB window (eventually StackOverflow helped me get past BadMatch by analyzing X.org sources) and paint a gradient on it with direct ARGB values, while knowing what I’m doing. X11 also has its deal of history. Right now I’m reading a random paper from 1994 http://www.rahul.net/kenton/perf.html as I’ve been trying to understand GraphicsExpose events.
I don’t know. I really hope I can find something readable on XRender. So far I have like:
- https://keithp.com/~keithp/talks/usenix2001/xrender/
- https://www.x.org/releases/current/doc/renderproto/renderproto.txt
- https://www.x.org/releases/current/doc/libXrender/libXrender.txt
- edit: https://github.com/golang/exp/blob/master/shiny/driver/x11driver/
- edit: https://web.archive.org/web/20090317092553/http://ktown.kde.org/~fredrik/composite_howto.html
- edit: https://github.com/ereslibre/x11/blob/master/xrender/xrhello.c
and none of that is very instructional. Though it seems to have Cairo-level capabilities.
-
GLFW source code.
-
-
-
Quote from Wikipedia:
An enumeration is a complete, ordered listing of all the items in a collection.
Could someone enlight me on this? What the Article describes doesn’t seem like “complete listing”.
-
-
When I was in University, I remember our server room in the CS department had those massive/think books on X11 programming.
It’d be interesting to see a minimal X11 window manager vs a minimal Wayland composer. Although the compose is a lot more, correct? It’s not only the wm, but drawing/buffering to the screen right?
-
One out of many problems is that you can’t abstract away the window management details to a comparable set of mechanisms in the way shown in the article - coarse window management policies are encoded into the protocol (that’s the “shell”) and just the high level semantics of popup windows alone span reach into hundreds of lines of code.
-
Someone reposted the link on HN, and there seems to have been a conversations just exactly about wayland/X11: https://news.ycombinator.com/item?id=17765851
-
-
The author goes into more detain here: https://tromey.com/blog/?p=982
-
Good talk.
I recently used systemd “in anger” for the first time on a raspi device to orchestrate several scripts and services, and I was pleasantly surprised (but also not surprised, because the FUD crowd is becoming more and more fingerprintable to me). systemd gives me lifecycle, logging, error handling, and structure, declaratively. It turns out structure and constraints are really useful, this is also why go has fast dependency resolution.
It violates unix philosohpy
That accusation was also made against neovim. The people muttering this stuff are slashdot markov chains, they don’t have any idea what they’re talking about.
-
The declarative units are definitely a plus. No question.
I was anti-systemd when it started gaining popularity, because of the approach (basically kitchen-sinking a lot of *NIX stuff into a single project) and the way the project leader(s) respond to criticism.
I’ve used it since it was default in Debian, and the technical benefits are very measurable.
That doesnt mean the complaints against it are irrelevant though - it does break the Unix philosophy I think most people are referring to:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
-
If you believe composability (one program’s output is another program’s input) is an important part of The Unix Philosophy, then
lsviolates it all day long, always has, likely always will.lsalso violates it by providing multiple ways to sort its output, whensortis right there, already doing that job. Arguably,lsformatting its output is a violation of Do One Thing, becauseawkandprintfexist, all ready to turn neat columns into human-friendly text. My point is, The Unix Philosophy isn’t set in stone, and never has been.-
-
nobody said it’s set in stone; it’s a set of principles to be applied based on practicality. like any design principle, it can be applied beyond usefulness. some remarks:
- i don’t see where ls violates composability. the -l format was specifically designed to be easy to grep.
- the sorting options are an example of practicality. they don’t require a lot of code, and would be much more clumsy to implement as a script (specifically when you don’t output the fields you’re sorting on)
- about formatting, i assume you’re referring to columniation, which to my knowledge was not in any version of ls released by Bell Labs. checking whether stdout is a terminal is indeed an ugly violation.
-
i don’t see where ls violates composability. the -l format was specifically designed to be easy to grep.
People have written web pages on why parsing the output of
lsis a bad idea. Usingls -ldoesn’t solve any of these problems.As a matter of fact, the
coreutilspeople have this to say about parsing the output ofls:However ls is really a tool for direct consumption by a human, and in that case further processing is less useful. For futher processing,
find(1)is more suited.Moving on…
the sorting options are an example of practicality. they don’t require a lot of code, and would be much more clumsy to implement as a script (specifically when you don’t output the fields you’re sorting on)
This cuts closer to the point of what we’re saying, but here I also have to defend my half-baked design for a True Unix-y
lsProgram: It would always output all the data, one line per file, with filenames quoted and otherwise prepared such that they always stick to one column of one line, with things like tab characters replaced by\tand newline characters replaced by\nand so on. Therefore, the formatting and sorting programs always have all the information.But, as I said, always piping the output of my
lsinto some other script would be clumsier; it would ultimately result in some “human-friendlyls” which has multiple possible pipelines prepared for you, selectable with command-line options, so the end result looks a lot like modernls.about formatting, i assume you’re referring to columniation, which to my knowledge was not in any version of ls released by Bell Labs. checking whether stdout is a terminal is indeed an ugly violation.
I agree that
lsshouldn’t check for atty, but I’m not entirely convinced no program should.-
just because some people discourage composing ls with other programs doesn’t mean it’s not the unix way. some people value the unix philosophy and some don’t, and it’s not surprising that those who write GNU software and maintain wikis for GNU software are in the latter camp.
your proposal for a decomposed ls sounds more unixy in some ways. but there are still practical reasons not to do it, such as performance and not cluttering the standard command lexicon with ls variants (plan 9 has ls and lc; maybe adding lt, lr, lu, etc. would be too many names just for listing files). it’s a subtle point in unix philosophy to know when departing from one principle is better for the overall simplicity of the system.
-
-
-
With all due respect[1], did your own comment hit your fingerprint detector? Because it should. It’s extrapolating wildly from one personal anecdote[2], and insulting a broad category of people without showing any actual examples[3]. Calling people “markov chains” is fun in the instant you write it, but contributes to the general sludge of ad hominem dehumanization. All your upvoters should be ashamed.
[1] SystemD arouses strong passions, and I don’t want this thread to devolve. I’m pointing out that you’re starting it off on the wrong foot. But I’m done here and won’t be responding to any more name-calling.
[2] Because God knows, there’s tons of badly designed software out there that has given people great experiences in the short term. Design usually matters in the long term. Using something for the first time is unlikely to tell you anything beyond that somebody peephole-optimized the UX. UX is certainly important, rare and useful in its own right. But it’s a distinct activity.
[3] I’d particularly appreciate a link to NeoVim criticism for being anti-Unix. Were they similarly criticizing Vim?
-
[3] I’d particularly appreciate a link to NeoVim criticism for being anti-Unix. Were they similarly criticizing Vim?
Yes, when VIM incorporated a terminal. Which is explicitly against its design goals. From the VIM 7.4
:help design-notVIM IS... NOT *design-not* - Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"Neo-VIM appears to acknowledge their departure from VIM’s initial design as their
:help design-nothas been trimmed and only reads:NVIM IS... NOT design-not Nvim is not an operating system; instead it should be composed with other tools or hosted as a component. Marvim once said: "Unlike Emacs, Nvim does not include the kitchen sink... but it's good for plumbing."Now as a primarily Emacs user I see nothing wrong with not following the UNIX philosophy, but at it is clear that NeoVIM has pushed away from that direction. And because that direction was an against their initial design it is reasonable for users that liked the initial design to criticism NeoVIM because moving further away from the UNIX philosophy.
Not that VIM hadn’t already become something more than ‘just edit text’, take quickfix for example. A better example of how an editor can solve the same problem by adhering to the Unix Philosophy of composition through text processing would be Acme. Check out Acme’s alternative to quickfix https://youtu.be/dP1xVpMPn8M?t=551
-
akkartik, which part of my comment did you identify with? :) FWIW, I’m fond of you personally.
I’d particularly appreciate a link to NeoVim criticism for being anti-Unix
Every single Hacker News thread about Neovim.
Were they similarly criticizing Vim?
Not until I reply as such–and the response is hem-and-haw.
-
To be fair I don’t think the hacker news hive mind is a good judge of anything besides what is currently flavour of the week.
Just yesterday I had a comment not just downvoted but flagged and hidden-by-default, because I suggested Electron is a worse option than a web app.
HN is basically twitter on Opposite Day: far too happy to remove any idea even vaguely outside what the group considers “acceptable”.
-
Indeed, I appreciate your comments as well in general. I wasn’t personally insulted, FWIW. But this is precisely the sort of thing I’m talking about, the assumption that someone pushing back must have their identity wrapped up in the subject. Does our community a disservice.
-
-
-
https://news.ycombinator.com/item?id=7289935
The old Unix ways are dying… … Vim is, in the spirit of Unix, a single purpose tool: it edits text.
https://news.ycombinator.com/item?id=10412860
thinks that anything that is too old clearly has some damage and its no longer good technology, like the neovim crowd
Also just search for “vim unix philosophy” you’ll invariably find tons of imaginary nonsense:
Please don’t make me search /r/vim :D
-
thinks that anything that is too old clearly has some damage and its no longer good technology, like the neovim crowd
That’s not saying that neovim is ‘anti-Unix philosophy’, it’s saying that neovim is an example of a general pattern of people rewriting and redesigning old things that work perfectly well on the basis that there must be something wrong with anything that’s old.
Which is indeed a general pattern.
-
That’s not saying that neovim is ‘anti-Unix philosophy’
It’s an example of (unfounded) fear, uncertainty, and doubt.
rewriting and redesigning old things that work perfectly well on the basis that there must be something wrong with anything that’s old.
That’s a problem that exists, but attaching it to project X out of habit, without justification, is the pattern I’m complaining about. In Neovim’s case it’s completely unfounded and doesn’t even make sense.
-
It’s not unfounded. It’s pretty obvious that many of the people advocating neovim are doing so precisely because they think ‘new’ and ‘modern’ are things that precisely measure the quality of software. They’re the same people that change which Javascript framework they’re using every 6 weeks. They’re not a stereotype, they’re actual human beings that actually hold these views.
-
-
-
-
Thanks :) My attitude is to skip past crap drive-by comments as beneath notice (or linking). But I interpreted you to be saying FUD (about SystemD) that you ended up taking seriously? Any of those would be interesting to see if you happen to have them handy, but no worries if not.
Glad to have you back in the pro-Neovim (which is not necessarily anti-Vim) camp!
-
-
-
-
-
-
-
What is FUD is this sort of comment: the classic combination of comparing systemd to the worst possible alternative instead of the best actual alternative with basically claiming everyone that disagrees with you is a ‘slashdot markov chain’ or similar idiotic crap.
On the first point, there are lots of alternatives to sysvinit that aren’t systemd. Lots and lots and lots. Some of them are crap, some are great. systemd doesn’t have a right to be compared only to what it replaced, but also all the other things that could have replaced sysvinit.
On the second point, it’s just bloody rude. But it also shows you don’t really understand what people are saying. ‘I think [xyz] violates the unix philosophy’ is not meaningless. People aren’t saying it for fun. They’re saying it because they think it’s true, and that it’s a bad thing. If you don’t have a good argument for the Unix philosophy not matter, or you think systemd doesn’t actually violate it, please go ahead and explain that. But I’ve never actually seen either of those arguments. The response to ‘it violates the Unix philosophy’ is always just ‘shut up slashdotter’. Same kind of comment you get when you say anything that goes against the proggit/hn hivemind that has now decided amongst other things that: microsoft is amazing, google is horrible, MIT-style licenses are perfect, GPL-style licenses are the devil-incarnate, statically typed languages are perfect, dynamically typed languages are evil, wayland is wonderful, x11 is terrible, etc.
-
claiming everyone that disagrees with you is a ‘slashdot markov chain’ or similar idiotic crap
My claim is about the thoughtless shoveling of groundless rumors. Also I don’t think my quip was idiotic.
there are lots of alternatives to sysvinit that aren’t systemd
That’s fine, I never disparaged alternatives. I said: systemd is good and I’m annoyed that the grumblers said it wasn’t.
-
-
-
-
Have you watched the video this thread is about? Because you really sound like the kind of dogmatist the presenter is talking about.
If you like systemd, use it and shut up about it
Also, isn’t this a double-standard, since when it comes to complaining about systemd, this attitude doesn’t seem that prevalent.
-
-
I see this kind of vague criticism when it comes to systemd alot. What ecosystem is it really breaking? It’s all still open source, there aren’t any proprietary protocols or corporate patents that prevent people from modifying the software to not have to rely on systemd. This “threat”, thr way I see it, has turned out to be at most a “ minor inconvenience “.
I suppose you’re thinking about examples like GNOME, but on the one hand, GNOME isn’t a unix-dogmatist project, but instead they aim to create a integrated desktop experience, consciously trading this in for ideal modularity – and on the other, projects like OpenBSD have managed to strip out what required systemd and have a working desktop environment. Most other examples, of which I know, have a similar pattern.
-
-
-
-
-
-
-
-
I think that the problem is fanboyism, echo chambers and ideologies.
I might be wrong, so please don’t consider this an accusation. But you writing this sounds like someone hearing that systemd is bad, therefore never looking at it, yet copying it. Then one tries it and finding out that baseless prejudices were in fact baseless.
After that the assumption is that everyone else must have been doing the same and one is enlightened now to see it’s actually really cool.
I think that this group behavior and blindly copying opinions is one of the worst things in IT these days, even though of course it’s not limited to this field.
A lot of people criticizing systemd actually looked at systemd, really deep, maybe even built stuff on it, or at least worked with it in production as sysadmin/devop/sre/…
Yes, I have used systemd, yes I understand why decisions we’re taken, where authors if the software were going, read specs of the various parts (journald for example), etc.
I think I have a pretty good understanding compared to at least most people that only saw it from a users perspective (considering writing unit files to be users perspective as well).
So I could write about that in my CV and be happy that I can answer a lot of questions regarding systemd, advocate its usage to create more demand and be happy.
To sum it up: I still consider systemd to be bad on multiple layers, both implementation and some ideas that I considered great but then through using it seeing that it was a wrong assumption. By the way that’s the thing I would not blame anyone for. It’s good that stuff gets tried, that’s how research works. It’s not the first and not the last project that will come out sounding good, to only find out a lot of things either doesn’t make a difference or make it worse.
I am a critic of systemd but I agree that there’s a lot of FUD as well. Especially when there’s people that blame everything, including own incompetence on systemd. Nobody should ever expect a new project to be a magic bullet. That’s just dumb and I would never blame systemd for trying a different approach or for not being perfect. However I think it has problems on many levels. While I think the implementation isn’t really good that’s something that can be fixed. However I think some parts of the concept level are either pretty bad or have turned out to be bad decisions.
I was very aware that especially in the beginning the implementation was bad. A lot got better. That’s to be expected. However next to various design decisions I consider bad I think many more were based on ideas that I think to most people in IT sound good and reasonable but in the specific scenarios that systemd is used it at least in my experience do not work out at all or only work well in very basic cases.
In other words the cases where other solutions are working maybe not optimal, but that aren’t considered a problem worth fixing because the added complexity isn’t worth it systemd really shines. However when something is more complex I think using systemd frequently turns out to be an even worse solution.
While I don’t wanna go into detail because I don’t think this is the right format for an actual analysis I think systemd in this field a lot in common with both configuration management and JavaScript frameworks. They tend to be amazing for use cases that are simple (todo applications for example), but together with various other complexities often make stuff unnecessarily complicated.
And just like with JavaScript frameworks and configuration management there’s a lot of FUD, ideologies, echochambers, following the opinion of some thought leaders, and very little building your own solid opinion.
Long story short. If you criticize something without knowing what it is about then yes that’s dumb and likely FUD. However assuming that’s the only possible reason for someone criticizing software is similarly dumb and often FUD regarding this opinion.
This by the way also works the reverse. I frequently see people liking software and echoing favorable statements for the same reasons. Not understanding what they say, just copying sentences of opinion leaders, etc.
It’s the same pattern, just the reversal, positive instead of negative.
The problem isn’t someone disliking or liking something, but that opinions and thoughts are repeated without understanding which makes it hard to have discussions and arguments that give both sides any valuable insides or learnings
Then things also get personal. People hate on Poetteing and think he is dumb and Poetteing thinks every critic is dumb. Just because that’s a lot of what you see when every statement is blindly echoed.
-
That’s nice, but the implication of the anti-systemd chorus was that sys v init was good enough. Not all of these other “reasonable objections” that people are breathless to mention.
The timbre reminded me of people who say autotools is preferrable to cmake. People making a lot of noise about irrelevant details and ignoring the net gain.
But you writing this sounds like someone hearing that systemd is bad, therefore never looking at it, yet copying it.
No, I’m reacting to the idea that the systemd controversy took up any space in my mind at all. It’s good software. It doesn’t matter if X or Y is technically better, the popular narrative was that systemd is a negative thing, a net-loss.
-
In your opinion it’s good software and you summed up the “anti-systemd camp” with “sys v init was good enough” even though people from said “anti-systemd camp” on this very thread disagreed that that was their point.
To give you an entirely different point of view, I’m surprised you don’t want to know anything about a key piece of a flagship server operating systems (taking that one distro is technically an OS) affecting the entire eco system and unrelated OS’ (BSDs etc.) that majorly affects administration and development on Linux-based systems. Especially when people have said there are clear technical reasons for disliking the major change and forced compliance with “the new way”.
-
you summed up the “anti-systemd camp” with “sys v init was good enough” even though people from said “anti-systemd camp” on this very thread disagreed that that was their point.
Even in this very thread no one has actually named a preferred alternative. I suspect they don’t want to be dragged into a discussion of details :)
affecting the entire eco system and unrelated OS’ (BSDs etc.)
BSDs would be a great forum for demonstrating the alternatives to systemd.
-
-
-
-
-
It violates unix philosohpy
That accusation was also made against neovim. The people muttering this stuff are slashdot markov chains, they don’t have any idea what they’re talking about.
i don’t follow your reasoning. why is it relevant that people also think neovim violates the unix philosophy? are you saying that neovim conforms to the unix philosophy, and therefore people who say it doesn’t must not know what they’re talking about?
-
are you saying that neovim conforms to the unix philosophy, and therefore people who say it doesn’t must not know what they’re talking about?
When the implication is that Vim better aligns with the unix philosophy, yes, anyone who avers that doesn’t know what they’re talking about. “Unix philosophy” was never a goal of Vim (”:help design-not” was strongly worded to that effect until last year, but it was never true anyways) and shows a deep lack of familiarity with Vim’s features.
Some people likewise speak of a mythical “Vim way” which again means basically nothing. But that’s a different topic.
-
-
-
-
-
The follow links don’t work, but it’s a cool idea!
-
-
Over the last year I’ve made a transformation from being reluctantly acceptive of systemd, to strongly opposing it, to accepting it more fully. Interestingly this didn’t come from systemd itself, but a greater immersion in emacs that made me question the so-called “unix philosophy” – the fact that systemd wasn’t that relevant seems to me to reflect the issue and attitudes in general.
Nevertheless, or maybe even precisely because of it, I understand the problems people have with it. Special formats that doesn’t directly cooperate with the userland, isolated and non-trivially replaceable components and unexpected behaviours (something I do think *nix generally gets right) all are one the one hand an attempt to shed of legacy constraints, but at the same time make the appearance that systemd isn’t a component or something that is added, but something one has to submit to: just think about all the software that depends on a specific init system! (albeit, it can usually be circumvent).
To simply blame all of this on systemd seems to me an incomplete criticism, since systemd didn’t just pop up out of nowhere with the intention to provoke the greatest amount of graybeards. Real design issues, real legacy problems and real limitations which are to be found with a set of ideoms that resulted from quite a different environment, all had their influence. No solution is pretty or clean when the issue to begin with isn’t pretty of clean either.
-
As far as Tech-newsletters go, I can really recommended the Nixers newsletter. If one reads sites like lobste.rs regularly, it may contain a few things one might have already seen, but especially if you were a bit more busy over the week, it’s a nice summary.
-
-
nice. I wonder if there’s a way to make one account that I can use on all of them.
-
Ehh, as far as I understand, that’s not the point. All these apps are the source code between instances, and instances federate + offering per-instance identities. Accounts can then use the instance federation to talk between one-another.
And in the same way as you don’t have a mastodon account that’s valid on all instances, so you can’t have a “fediverse account” that’s valid over all “fediverse apps”.
-
-
btw there’s an app that I don’t see on this list: How might I go about finding a community of people that want to work together building a federated version?
-
-
Non-Fiction: I’ve just started A Field Guide to Genetic Programming, and I can at least say that the first part is understandable enough for a person with minimal experience. Additionally, I’m currently continuing The Rust Programming Language after having have taken a brake for a while.
Fiction: Karl May’s “Durchs Wilde Kurdistan” and Kafka’s “Das Schloss”, both in german, both with longer breaks in between.
-
The Plugin API
I’d much rather use vimscript than Python for scripting vim. Vimscript is no stranger a language than many other domain-specific languages out there. And I’d definitely rather configure using vimscript than Python or elisp. Hmm, what’s a better way of swapping
;and::(define-key evil-normal-state-map (kbd ";") 'evil-ex) (define-key evil-normal-state-map (kbd ":") 'evil-repeat-find-char))nnoremap : ; nnoremap ; :And while it was true at the time that vim was purely synchronous, it’s not true anymore. Can’t really hold that against the author, of course, because he wrote it in 2015, but certainly can hold that against the person that posted an outdated article.
The Codebase
Really doesn’t matter to anyone that isn’t developing it, and Vim doesn’t really need a lot of new development in my opinion, so I don’t care how slow it is to develop. It has async. Its development resources are being wasted on crap like terminal support within vim, which is not the right way to use the terminal from vim (use
ctrl-z [do some terminal stuff] fg) anyway, so getting useless features added faster doesn’t seem important.In fact, out of all the developer communities I’ve encountered, Vim’s is the most hostile to change. Anything that isn’t a bug fix is frowned upon. Patches are often criticized for ridiculous reasons. After we posted our patch to the Vim-dev mailing list, the first reply was:
Most developers of free software don’t particularly like it when people turn up with big unannounced patches they want merged, with no previous history of contribution. I don’t know if the latter is true, but it probably is. It usually is. Who wants a bunch of code foisted upon them, in a different style from what they’re used to and what the project has, that they then have to maintain?
Does Neovim clean stuff up? Sure. But it cleans stuff up by removing support for the clipboard and incompletely reimplementing half of it.
NOTE: Don’t use ANSI style function declarations. A few people still have to use a compiler that doesn’t support it.
Regardless of whether this is a reasonable comment to make (and I personally think that without some evidence that it’s untrue, you shouldn’t really criticise it, as vim’s developers probably know its userbase better than you), I’m sure this has probably been mentioned elsewhere or should be obvious from the fact that that’s how the rest of the codebase does it! The number one rule of coding style is to maintain similarity with nearby code. If a codebase uses a particular style, even if it’s not the style you like, just go with it.
And for what it’s worth, often the pre-ANSI style function definitions are much nicer to read.
float foo(x, y, z) float x, y, z; { ... }rather thanfloat foo(float x, float y, float z) { ... }- why should you have to writefloatthrice?The rest of that thread is me being as civil as possible, despite discouragement at every turn. The replies might as well be a paint-by-numbers guide on how to alienate new contributors.
What you call ‘async’ isn’t even proper async, it’s just ‘delay actually doing this action that still blocks the UI for an amount of time’. Could you in theory use that to implement something to poll an external process? Sure. Is that a good way to implement asynchronous communication with external processes in a text editor? I really don’t think so. That is brought up in the thread and then it looks like the person that posted the original patch basically never says anything in the rest of the thread.
Skimming the thread, it sounds like there were a lot of issues with the original patch, and they were pointed out, and you changed things in response to them. But you definitely can’t claim as you do in this article that you were strung along making changes then finally told it wouldn’t do. He said from the start that he was very retiscent about making those changes because they were error-prone and likely to cause lots of issues in the future. That’s pretty clear signalling that it’s unlikely that your changes will make it in.
-
Really doesn’t matter to anyone that isn’t developing it, and Vim doesn’t really need a lot of new development in my opinion, so I don’t care how slow it is to develop.
It’s funny when people admit this kind of stuff because it means (1) they haven’t (deeply) followed vim_dev for much time, and (2) their opinion doesn’t matter to anyone who actually isn’t happy with the status quo.
often the pre-ANSI style function definitions are much nicer to read
Vim switched to ANSI later, anyways. Bram very well knows the importance of keeping developers happy.
Personally, my main complaint about Vim’s development is that Bram doesn’t trust his own “core” developers (there are about two or three–or zero if you’re looking for anyone besides Bram with a deep understanding of the eval, input, or event-loop subsystems).
-
Bram very well knows the importance of keeping developers happy.
is that Bram doesn’t trust his own “core” developers
These points disagree with each other I feel.
Sounds like it “doesn’t matter” until it does. That is, when everybody else but Bram needs Bram out of the way.
-
-
And I’d definitely rather configure using vimscript than Python or elisp. Hmm, what’s a better way of swapping
;and::(define-key evil-normal-state-map (kbd ";") 'evil-ex) (define-key evil-normal-state-map (kbd ":") 'evil-repeat-find-char))nnoremap : ; nnoremap ; :Things like
nnoremapalways deterred me from doing any serious vim configuration, and is in my eyes a quite good example for why I don’t like vim script.From a programmers perspective, it’s at the very least confusing. What I read is “ rebind
:to;(or the other way around?), then do the same with they keys;and:…” but wait, shouldn’t that make both keys do the same thing, since I just redefined:(or;)? Or is this just some rerouting mechanism, a sort of compatibility layer between my vim and the real vim?And as a frivolous emacs apologist, I’d like to give a practical example why I consider elisp to be better, while keeping in mind that I’m not remotly a elisp expert:
(defun swap-keys (kb1 kb2 &optional map) "Swap the functions behind KB1 and KB2 in MAP" (interactive "kFirst key: \nkSecond key: ") (let* ((m (or map (current-global-map)) (f1 (lookup-key m kb1)) (f2 (lookup-key m kb2))) (define-key m kb1 f2) (define-key m kb2 f1)))Now I have a function for swapping key bindings, which I think is useful if there is a real need to swap keybindings all the time. And not only can anyone with any lisp experience get what’s going on here, it’s also interactively usable via
M-x swap-keys. When I include the time it took to find the functionlookup-keyand theinteractiveformatting, it all took me about 5 minutes. And again, I really don’t do much elisp, but IMO much more elegant.(Your pervious example would then become
(swap-keys ":" ";" 'evil-normal-state-map))
-
-
huh?
-
In case there are problems with the rendering of the page, this is a “Dweb” example: a distributed version of the the Internet Archive (I used the title auto-generator, so “in the browser” might have not been the best title…).
As far as I see, issues can be reported here: https://docs.google.com/forms/d/e/1FAIpQLSe7pXiSLrmeLoKvlDi2wODcL3ro7D6LegPksb86jr5bCJa7Ig/viewform
-
-
Premature optimization is the root of all evil
- C.A.R. Hoare
Wasn’t that Knuth?
-
Trying to finish an update for my regular expression game, since people have been mentioning that it’s too easy.
Already got rid of 1000 (out of 1900) lines of code over the last few days.
-
-
“It is difficult to get a [web developer] to understand something, when [their] salary depends on [them] not understanding it.”
― Upton Sinclair
-
My back looks like a pin cushion from all the arrows I received over the years fighting for web that would be more ethical and void of mostly useless crap. Some battles won, too many lost. I lost one just yesterday, but it didn’t occur to me that it was because of my money-induced blindness.
I actually like this quote and have used it myself before, but while I met many web developers over the years who didn’t care about bullshit described in the article, almost all of them didn’t simply because they were either ignorant of available technologies, didn’t care much about quality of anything they did and most often both.
-
-
Example of a small recent one would be Klevio website (as it currently exists, less so after today). I am not linking to it because I don’t want referrals from Lobsters to show up in website’s logs, but is trivial to find.
Almost everything on this website works with Javascript turned off. It uses Javascript to augment experience, but does not needlessly rely on external libraries. Should work reasonably well even on poor connections. Does not track you and still has a privacy policy handling that tries to be closer to the spirit of GDPR then to what you may get away with.
It would certainly be easier for me and faster to develop (cheaper for company) if I just leaned on existing tools, build yet another SPA and have not spent more than a week arguing with lawyers about what is required.
Alas, because unsurprisingly most people do not opt-in to analytics, I am now working on a different confirmation dialog, more in line with what others are doing. It will still be better than most, but certainly more coercive than current.
And this is in a company that is, based on my experience, far more conscientious about people’s privacy than others I worked for.
-
It would certainly be easier for me and faster to develop (cheaper for company) if I just leaned on existing tools, build yet another SPA and have not spent more than a week arguing with lawyers about what is required.
Is this really true? Not to downplay your craft but I always thought tinkering with HTML/CSS until things look right would be way easier than learning a separate library.
I checked out that website and it’s pretty refreshing that stuff actually works. If you want a little constructive feedback, the information density is very low especially on a desktop computer with a widescreen monitor. I have to scroll down 7 screens to get all the information, which could have fit on a single screen. Same with the “about us” page. I notice the site is responsive, giving a hamburger when you narrow your window, so maybe the “non-mobile” interface could be more optimized for desktop use.
-
I don’t think it is in every case, but in this one I think it would be since everything was handwritten without picking up existing solutions for things like galleries. If you mean the SPA part, then I guess it becomes more moot. It would probably be about the same doing the first implementation, but this one, which is basically a bunch of static files, certainly has a higher cost of maintenance because we (I) didn’t get around to finishing it so page “components” still have to be manually copied to new files and updated everywhere when their content changes. The plan was to automate most of this, but we haven’t spent the time on it yet.
I agree with everything in the second paragraph. Regretfully that is one of those battles lost.
-
-
-
-
-
-
-
You’re on week three of your new job at a big city ad and design firm. Getting that first paycheck was nice, but the credit card bill from the moving expenses is coming up, that first month of big city rent wiped out your savings, and you don’t really have a local personal network to find new jobs. The customer wants a fourth “tag” for analytics tracking. Do you:
- Put it in
- Engage in a debate about engineering ethics with your boss and his boss (who drives a white Range Rover and always seems to have the sniffles after lunch) culminating with someone screaming and you storming out, never to return?
-
-
-
Over the last few months, I’ve been working and rewriting my own Emacs configuration, and most my sources, that weren’t from Emacs’s own documentation, came from reading configurations like these listed here (other sources would probably be blogs, those on Planet Emacsen). It’s actually not that boring as it might sound to some, and a great way to procrastinate.
If anyone is interested in furthering their own configuration, or even trying to start using Emacs, I can really recommend doing something like this, but one only adapts code that one understands. This prevents you from having a “dumped” configuration, that quickly becomes unmaintainable and cumbersome, and at the same time gives a great opportunity to understand Emacs and Elisp – which is crucial for “proper” usage, beyond a mere text editor with peculiar keybindings.