That's one dishonest headline. Air pollution areas are commonly associated with big cities, where the crime rate tends to be higher. The website clearly turned this into something else for no reason at all other than clicks.
Ironically, your accusation of them doing this for "the clicks" prevented you from clicking the link and finding out that your criticism is not relevant to this study.
Hello. It was tested on Linux and FreeBSD. Works fine on any of those systems if you have SBCL and dmenu installed, though it might need a few tweaks on program paths of your configuration file.
I plan to migrate this to a more flexible Roswell script in a near future.
Hello. I currently use this daily to automate my workflow. I have no pretension of "selling" this as a very extensible tool that everyone should use, though I agree that I need to improve the README.
Hello, I'm the author. I just found out someone put this in HN again, I hope I can explain.
This is basically a way to create menus and submenus for recurrent utilities. You can use a rofi or dmenu frontend. Once you bind it a key shortcut, rofi/dmenu will come up asking you what to do.
Right now I can directly access my favorite websites, open my favorite programs, do web search (and also switch web engine), all without touching the browser directly. The idea is to group a lot of things in a lightweight script, and have a keyboard-only interaction with no extra extensions or programs.
I agree that the README is a little poor right now, and screenshots/gifs would also help on this regard. I'll start working on it pretty soon.
Right. With the current title my first impression was that it was like a Unix shell with Common Lisp somehow as the shell language. I mean the shell is the tool Unix power-users mostly use to automate tasks.
It might be a good idea to add screenshots or a gif or something to the README, and I see they've realized that.
From his talk on OOPSLA[1], I'd say that only Smalltalk and Common Lisp (through CLOS) were able to perform OO as Kay envisioned.
Erlang is another story: it would probably be better to call it just actor model. But again, Kay himself says[2] that there is not a lot of difference between actor model and his OOP.
Add Self to your list, which was even purer than Smalltalk since it got rid of the classes and let the objects stand by themselves.
It's not just the actor model, though. In the actor model, all the actors are contributors to the conversation. The subjects of conversation are something else. In object oriented programming, the subjects of conversation are the same category of things as the agents of conversation, and may move back and forth freely.
The simplest way to see the difference is to think about how a new contributor to the conversation is added. In the actor model, some actor forks a new actor in response to a message. If I have built up the state to describe a new actor, there is still a step to bring it to life that changes it from one thing to another.
In object oriented programming, when you build up that state, it may become a contributor to the conversation at any point in time and then go back to being a subject of conversation, or do both at once. There is no switch.
They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them.
Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.
I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.
Though I agree that complaining like this can be a problem for people with zero experience, I don't think it is a valid argument against what OP is pointing out. Most of the process seems to be rooted on automation, which encourages candidates to find a way to bypass the selection system instead of showing actual competence. This means a direct loss on the company's staff quality. If anything, IBM might be losing good people, possibly to other companies.
Part of the problem with software today is bulk of the jobs are library plumbing.
Sure you still have jobs where something of high quality like an OS patch, driver or some big algorithm work needs to be done- But those jobs are rare, and there are often ways to hire such people looking at their prior experience.
Its always hard for freshers to break into the cream software jobs that can offer you some different experience compared to others.
In general you have to take whatever comes along the way and build on that. This is unfortunate, regardless of whatever practice you might have done on leetcode, plumbing like jobs are what are common in the world today.
Not cool. This also seems to imply no support for Atom feeds as well.
I have switched my media channels entirely to RSS/Atom feeds, though I only read them through Emacs. This cannot stop stuff like fake news, but it always seemed important to me to the fact that it makes viewing discussions entirely optional (you have to visit the link for that). The lack of ads is also a plus.
I have come to use emacs for everything, and I love being in emacs. It never occurred to me that I don't have to find an RSS reader -- just an emacs package.
