Ask HN: DSL to a T1, help with the speeds - <AUTHOR> I live in a very rural area where I had to persuade Verizon to get me DSL years ago. My wife and I both work at home and pound on this connection all day every day. We also have a few servers running.
I cannot get cable internet or Fios. I get around 1.1mbps, often less, early in the morning when nobody else in my area is on yet I get like 2.8 mbps.
Verizon Enterprise agreed that they could run me a T1. They wanted to start me out at 10 mbps but that is about $764 a month and $1,200 in startup/equipment costs. I have asked them about 1.5 mbps or 3 mbps.
But, if I go with 1.5, it isn't really any faster than my DSL, correct? Except that I may get that all the time since it would only be our traffic. It would also be probably double or slightly more than my $80 DSL bill.
Am I thinking about this correctly or am I making a mistake in my thinking?
Edit: We are both geeks. We code, web site stuff too, have tool chains to update, etc, etc. <comment><USER2> The big difference technically between DSL and T1 is that a T1 has amplifiers/signal conditioners every 6000ft or so whereas DSL uses a highly complex coding scheme to extend the range. T carrier services are expensive as hell because of the need to install so many amps.

</comment><comment><USER3> What about 3G/4G cellular via tethering a phone? That's all I use when I'm away from my home interent.

\+ $764/month will buy a lot of data exceeding that allocated with a standard plan.

\+ $764/month makes multiple accounts spread across different carriers practical to provide redundant connections.

\+ Even if there's only one good carrier in your area, resellers mean one can have multiple binding contracts for data service from that single carrier without hitting that carrier's terms and conditions for their direct sale policies.

The problem that T1 is really meant to solve is providing a block of 24 dedicated voice channels for POTS [plain old telephone service]. Developed in 1962, it's not really a fat pipe by modern standards. [https://en.wikipedia.org/wiki/T-carrier](https://en.wikipedia.org/wiki/T-carrier)

Indeed, that's why DSL can offer similar speed over a single twisted pair.

Good luck.

</comment><comment><USER4> Just switched a client from a verizon t1 (really an att t1, you just can't escape them) to a verizon 10mbs dedicated line. Asked for fiber, but basically got a dedicated dsl line from the office to the co via windstream. Also has a verizon wireless link for backup.

This client has had a T1 for a number of years it was great running 5 remote desktops and voip services. The use of google maps to do some work really killed the bandwidth however.

Unless you are doing serious upstream stuff, I'd stick with the DSL and try and get a caching web proxy to reduced your bandwidth usage.

</comment><comment><USER5> Have you talked to any local competitive phone companies (Broadview Networks, Windstream Business, etc) about T1 quotes? Thy're never cheap, but you could probably get it down to the $300-$500/mo range.

I suppose one thing you could do is look into some sort of on the fly compression algorithm incorporated into a proxy to make things a little more livable. A lot of modems for satellite providers actually do this along with caching by default.

<comment><AUTHOR> I have called everyone that I can think of and nobody services this area except Verizon.

Any idea the name of some of these proxy's so I can look them up. We already run pfsense front ending everything, but I don't know if pfsense has anything built in to help with the proxy'ing. It is probably a separate box we would need to stand up.

<comment><USER4> You can run squid on pfsense. Pfsense is great.

<comment><AUTHOR> Thanks. I'll check that out.

</comment></comment></comment></comment><comment><USER6> Just a quick question, have you thought about satellite Internet services? Or is that not feasible/possible/...?

<comment><AUTHOR> We can get DISH or DirectTV internet, but they limit you to 10GB a month and my wife surpasses that alone with her work. The cost is more expensive than our DSL for that 10gb.

<comment><USER6> Well, not sure if there's other options, I've seen some that offer 25Gb for something around $130/month but that was a while ago and I don't know if they're available in your region.

As for the 1.5mbps, if that is really dedicated to you and only you then it "can" be faster than your current DSL. The question remains if it warrants the price difference for the marginal difference it might bring.

<comment><AUTHOR> 25gb for $130? I see cable internet for that speed, but not T1 for that speed.

<comment><USER6> Sorry, that was 25Gb/month in data, not speed. I'm sure there's more choice out there, I'm not very familiar with the US market on satellite Internet.</comment></comment></comment></comment></comment>


Why Kubernetes Is the New Application Server - <AUTHOR> https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/ <comment><USER2> I would say Kubernetes is becoming the new Application Server, but not for anything listed in the article. Kubernetes is more and more being sold to "enterprise" as a solution for running services much like Application servers were, and much like application servers the standard Kubernetes deployment is becoming a tangled mess of buzzwords and dreams, which work great in a demo, but won't work at all without an army of consultants.

<comment><USER3> I'm a former OpenShift (Red Hat's distribution of Kubernetes) consultant and currently I work at Red Hat in a different position and I have to disagree on the "won't work at all without an army of consultants".

While it's true that some of our customers have an army of consultants, the vast majority of our customers don't use consulting at all or that only use it very infrequently. If you don't want a lot of customization, have the right amount of people and the right people and __realistic expectations __you don 't need consulting at all.

When people want to get a highly customized experience (often, for the wrong reasons), or want to get in production after 2 months, when their people have no experience in kubernetes and didn't do adequate testing (load, fault- tolerance, etc) it will give lot of problems. But that's the case for everything, not only for kubernetes

In my opinion (mine, not Red Hat's) getting someone to deploy it with you the first time, showing how it's done and why things are done, and after that and do a workshop explaining the basic concepts has great value, saves a lot of time and isn't expensive.

<comment><USER4> > want to get in production after 2 months [...] > it will give lot of > problems. But that's the case for everything, not only for kubernetes

Are you asserting that any modern production environment that takes less than 2 months to set up is bound to cause problems? Or the whole company/startup/project?

If the former, I'd say there are many tech startups who would disagree, or at the very least, point out that it doesn't matter because they'd cease to exist during those 2 months without an MVP in production.

<comment><USER5> I think the two month phase is pretty accurate. Deployment itself is not that time intense and changing your applications to be container friendly is not either.

The time intensive phase during the first Kubernetes deployment is changing the mindset of the engineering team and everyone involved in IT.

Kubernetes IMHO is pretty much like moving from college into work life and adapting to the fact that requirements for a decent adult life are very much different from a college life.

<comment><USER4> That's as may be for Kubernetes, but the GP specifically stated "that's the case for everything, not only for kubernetes", which struck me as an extraordinarily broad claim.

One might reasonably expect "everything" to include traditional deployment methods that require no changing of mindsets (not that that's likely a factor in my nascent startup example).

<comment><USER5> Transition phases actually make sense even if you apply "everything" instead of just "Kubernetes" considering how every company transitions through stages in terms of tooling.

Think being a startup where deployments most likely will be manual and undocumented, upgrading to an initial automation using some scripting, transitioning to CI/CD, etc.

So from various experiences at companies of all sizes I would actually support such a broad claim, since companies are basically transitioning all the time through new phases to greener pastures. That of course assumes that the company values constant improvements and uses an iterative process for growth and change.

</comment></comment></comment></comment></comment></comment><comment><USER6> I feel a bit alone here. The most obvious benefit of kubernetes is that _It 's an API_. There is definitely a tooling angle, but the core disruption that kubernetes brings to the picture is, it allows to model infrastructure as an API.

Take the standard cloud application stack: Every app needs an artifact (disk image), a running service, an instance template, a group of VMs running using those templates, networking and a load balancer.

Before kubernetes, you had to automate by writing terraform scripts which mutate physical infrastructure as you apply.

With kubernetes, you POST a bunch of well-defined resources (container spec for the service, pod spec for the instance, pod as a VM, deployment as the group of VMs, services and ingress for traffic). Every physical cloud resource has a clear API mapping. Basically you save in kubernetes what you need as a first-class API resource. And then, kubernetes _responds_ to what you saved by changing infrastructure to match.

You can do the same for practically any kind of infrastructure resources. Want an S3 bucket? Duh, POST a S3 bucket resource and you can write a controller to react and fulfil that bucket.

Kubernetes comes with a built-in set of functionality that fulfils a certain core set of infrastructure using containers. But you are not restricted to that. In theory, you could POST a VM as a resource, or an Instance Group as a resource, and you can write a kubernetes controller to fulfil those resources.

Why? Because APIs are more powerful than tools. APIs allow a different axis of infrastructure evolution, even if you distribute the control to everyone. By modeling these as APIs, you can bake in a huge amount of infrastructure intelligence into the API. Want to enforce different, code-driven resource- based policies, linting, sane defaults, organizational context? Yeah, make the controller do just that. If you just provide a tool to every engineering team, you basically lose any form of cross-cutting orchestration, and you lose the ability to evolve infrastructure in a separate axis independent of the tool that each team uses.

Basically, kubernetes is "Infrastructure as an API". Thinking about it as a "new application server" kinda hides the whole point of it.

<comment><USER7> That's not a benefit to me. Is it reproducible? Keeping desired state under version control is valuable.

<comment><USER8> Yep. Super reproducible. Even more than the old ways. You can store the docker configs and store docker containers in registry. Store the yaml files, or auto generate them using build process based on other central DSL.

We could probably bootstrap our entire product from scratch in a couple of hours if it disappeared off the face of earth.

"Infrastucture as a config" is a very powerful concept. I'd say that's what the big power of k8s is.

</comment></comment></comment><comment><USER9> Here's my prediction: DevOps is dead. In 5 to 10 years developers will no longer be mentioned in articles like this.

There will be specialisation once again, because it makes absolutely no sense to make people whose main job it is to think about use cases, business logic and user interfaces to also deal with stuff like this.

<comment><USER10> Another prediction in 5 to 10 years infrastructure will be so streamlined, so that developers won't need to think it at all. I see the progress when we cam from manually maintained machines, to clumsy devops tools, to more streamlined dev tools like ansible, to kubernetes, and with each new step, maintaining a system requires less and less expertise.

<comment><USER11> No, the future is serverless applications in the major cloud providers where every server is abstracted away and things scale automatically.

The reason for this is the enormous cost benefits (its super cheap, you only pay when your code actually runs, no upfront costs, no passive server costs, no overprovision or underprovision of compute resources etc).

<comment><USER12> If you've ever used a serverless framework, you'll know this argument falls apart the second you need to run something for a long period of time, manage complex state or glue services together. There are numerous other details being glossed over.

The servless approach has its place just like everything else, it's not a panacea though.

<comment><USER13> Eventually, it should be abstracted even further into something that looks like Heroku, but deploys your code onto serverless functions or containers depending on how your service needs to run. A nice, modular, microservice backend automatically with zero config.

</comment></comment></comment></comment></comment><comment><USER14> We're in the process of migrating our (primarily) java services from straight AWS to kubernetes.

At the beginning the author poses the following questions:

* Do you use Mac, Windows, or Linux? Have you ever faced an issue related to \ versus / as the file path separator? What version of JDK do you use? Do you use Java 10 in development, but production uses JRE 8? Have you faced any bugs introduced by JVM differences?

* What version of the application server do you use? Is the production environment using the same configuration, security patches, and library versions?

* During production deployment, have you encountered a JDBC driver issue that you didn't face in your development environment due to different versions of the driver or database server?

* Have you ever asked the application server admin to create a datasource or a JMS queue and it had a typo?

I've experienced problems whose root cause are some form of all of those. Much of it could be chalked up to growing pains etcetera, but, for example, there are concrete differences between docker versions running on mac and linux that have shown up for me.

This doesn't reduce the author's argument, but they do seem liked strange examples.

Our choice to move to Docker and kubernetes came from developers, and specifically spoke to the need for consistent, reproducible test environments. We had dockerized most applications many months before the notion of using them in production was put on the table. What remains to be seen is if the switches in production reduce complexity and maintenance on the devops end of things, as well. I'm also curious how many other organizations had containers introduced 'from the bottom up' like us.

<comment><USER15> Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?

<comment><USER14> I don't have enough experience to say how common my experience (or yours) is, but I don't know how much luck is involved. I'm sure many institutions have solved these problems without containers and sicker.

But For various reasons, political, personal, technical etcetera, consistent, accessible test environments were not available. It was a huge bottleneck for developers.

This is why docker was so appealing: it allowed devs to circumvent the political and technical issues. We didn't have to justify provisioning more instances, since we could just use docker compose to run stacks on local machines.

So I'm that sense, the choice and it's benefits arose from non technical hurdles.

</comment></comment></comment><comment><USER16> Sorry but this article implies that containers can solve issues like the difference between path separators on Windows and Linux. They can't even solve issues arising from differences in kernal versions, not to mention operating systems.

<comment><USER17> Always use /

Windows can, surprisingly, handle it just fine.

<comment><USER18> On interactive uses, sure. But it's not clear cut, some code paths are lower level and bypass that.

<comment><USER17> Yea I guess most of my uses have been in things like python (e.g. open() and as.*). Got any examples of code paths that bypass that check and fail if you use /?

<comment><USER16> I think they are wrong and actually it's the opposite problem. Some applications and libraries that do their own path mangling on Windows will choke if you give them a /. The win32 file I/O API handles them correctly.

</comment></comment></comment></comment></comment><comment><USER19> It is hard not to build this impression of containers. Worse, it seems that the docker image format is massive compared to what most war files were like. This is annoying not just in terms of raw bytes to move around, but in taking stock of what is getting moved around.

My team originally pitched how docker solved much of the dependency upgrade management by having layers for each major set of dependencies. That ignored the fact that upgrading a layer is not really something you do.

So, then you can go around the path of coordinating many containers communicating with each other. That works, but in that world, things really don't seem any easier than the earlier alternatives. Harder, in many ways.

Don't get me wrong, the momentum and raw money being put into containers certainly paints it as the future. It just feels like lying to say that they have even come close to parity with what we were capable of not that long ago.

<comment><USER20> the linux world is slowly (and badly) recreating technology that has existed in FreeBSD and Solaris/Illumos for decades.

<comment><USER21> You probably never heard or used - Linux VServer. Available from the later version of the 2.4 kernel.

[https://en.wikipedia.org/wiki/Linux- VServer](https://en.wikipedia.org/wiki/Linux-VServer)

<comment><USER20> > 2008

FreeBSD jails date from 2000

Solaris zones date from 2004

[https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr...](https://us- east.manta.joyent.com/bcantrill/public/ppwl-cantrill-jails.pdf)

[https://us-east.manta.joyent.com/bcantrill/public/ppwl-cantr...](https://us- east.manta.joyent.com/bcantrill/public/ppwl-cantrill-zones.pdf)

<comment><USER21> 2003 [http://linux-vserver.org/Overview#History](http://linux- vserver.org/Overview#History)

In the Linux distribution that I used (PLD), the first vserver support took place in january 2004. [https://github.com/pld- linux/kernel/commit/5be58c1bcc5568676...](https://github.com/pld- linux/kernel/commit/5be58c1bcc5568676a75dd9f7096827bfcde08e8)

Maybe a little earlier because the util-vserver showed in Nov 2003. [https://github.com/pld-linux/util- vserver/commit/c4036d6e748...](https://github.com/pld-linux/util- vserver/commit/c4036d6e748808e07671ba402b3fe7ca027db82a)

</comment></comment></comment></comment></comment><comment><USER22> I hope that the Kubernetes Steering committee will continue its good work to keep the Core tidy and simple.

What really makes me afraid are the thousands of complex addons that are being pushed by the community (For example, Istio, Networking addons, etc etc). Those should be kept outside and it MUST be made clear they are definitely not needed for a normal installation of Kubernetes.

Istio for example, is such a political brainwash power-move by some bigger companies that benefit from it. I believe less than 5% of the use-cases really require Istio, still it is being pushed as something you should always install in your cluster. This is bad for everyone.

</comment><comment><USER23> Guys who have worked with Kubernetes and virtualization, I have a genuine personal question for you - I have been working as SysAdmin and then into virtualization (VMware / HyperV sort of things) and while natural progression in it says go for advanced VMware courses (related to Virtual machine and its concepts), do you think its better to switch lanes now to container-tech rather than some years down the line? I am totally 0 on Docker / Kubernetes / OpenStack (if thats related with containers).

<comment><USER24> At this point it is clear that this is a _thing_ that _will_ happen for a whole lot of orgs. You would be well advised to dabble at this point and see if it connects with you. At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation. That said, VMs and scripted/config-managed deployment will continue to be with us for the foreseeable future.

<comment><USER23> "At the least, you should understand what problems are and are not solved so you don't look foolish in a conversation"

Seriously, this is so embarrassing at the current point ( with me having absolutely 0 understanding of the concept)

</comment></comment></comment><comment><USER25> Well, until someone develops and releases (and strangle all naysayers) a language independent thing remotely like JEE JNDI... it's just not. Sorry, JEE was horrible but also so beautifully ahead of its time

<comment><USER26> Unfortunately, JEE was horribly behind the times. A lot of the ideas came from the COBOL middleware world. Others were a remix of CORBA.

</comment></comment><comment><USER27> I think what a lot of people forget is that this is being driven by costs. Companies don't want to pay for disaster recovery, and it's cheaper to set up a k8's platform. The platform itself performs disaster recovery, so now that's one less cost for the company.

It's all about saving money on DR. When these companies realize that developers can't handle doing ops AND complex business logic, maybe they'll rethink it. Until then I expect this trend to spread rapidly as companies look for ways to abstract away DR costs.

<comment><USER28> Can you define what you mean by disaster recovery? To me it means the ability to recover business applications from a site failure.

Assuming you have a similar definition how does Kubernetes solve that problem?

<comment><USER27> What I mean by DR is that if a data center gets nuked, you still have a replica of your k8's platform running in your other data center(s).

So k8's basically runs a replica of your whole system behind the scenes so if a physical location goes down you still have your system running.

<comment><USER28> What about all the data in DBMS, file systems, object stores? Also what about BGP routes, firewall settings, SNAT/DNAT rules and the like?

There's a lot more to replicate than just the bits in the apps.

<comment><USER29> Those are the types of things developers simply don't have experience using. And if Kubernetes tries to replace all of those it will become the new OpenStack.

</comment></comment></comment></comment></comment><comment><USER30> The software world keeps on going in circles :).

Next up - lightweight k8s server - stripped down of all the crap that can easily run and deploy a single container.

<comment><USER31> yes, this. I'm just skipping the whole Docker thing this time around, and waiting until the circle turns and the herd decides that containers create too much complexity ;)

</comment></comment><comment><USER32> As mentioned in the article, The EFK stack (Elasticsearch, Fluentd, Kibana) is great for unified logging. And its not just for OpenShift, its working wonders for our current project with Kubernetes on AWS.

<comment><USER33> Could you give more details about why Fluentd and not Beats + Logstash on the other end? I don't like the idea of running Ruby on every machine just to ship logs somewhere.

Beats are pretty lightweight and for what I used them they work.

<comment><USER34> Many people use the ELK stack which is Logstash. I imagine you can swap out Fluentd for Logstash.

</comment></comment></comment><comment><USER35> Is this a response for the Jib announcement and the inevitable comments that followed? Sounds a lot like it is...

</comment><comment><USER36> Instead of the new Application Server, Kubernetes is the new OpenStack. A conglomeration of projects that support a platform for deploying and operating software in containers or virtual machines. Just like OpenStack, some of the components deal with storage, others with networking, and others still with service discovery or proxying.

Without getting too far into semantics, I think the author is using a well overloaded terminology. When I hear Application Server, I immediately think tomcat or some other jvm.</comment>


Research in programming languages - <AUTHOR> http://tagide.com/blog/2012/03/research-in-programming-languages/ <comment><USER2> Alan Kay's observation is that any time a field grows faster than education, it becomes a pop culture. The "problem" with PL is exactly that: The use of programming languages grows faster than education about programming languages, so it's a pop culture. It's a lot like music, really. Is there research into music? Absolutely. Is there innovation in music coming out of universities? Absolutely. Does this have any effect on the top ten iTunes singles? Nope, or at least, not directly.

Music (even "classical" music) is a pop culture, just like programming. Music is also a science with a body of knowledge and well-formed theories. But it's a pop culture. Just like programming languages.

<comment><USER3> Of course it's rare that Alan Kay says something not worth revisiting, and bringing up pop music kind of gives me a different take on this quote. It's no secret that pop music (aka folk music) has long informed serious music which has long informed folk music which has long informed serious music ...

I think the current state of programming languages clearly reflects this pattern. I'm happy that the mainstream is becoming interested in something other than the strange variants of Smalltalk OOP we've been using for 30 some years.

In fact there seems to be real grassroots PL renaissance happening these days :)

<comment><USER4> I'm looking forward to Richard Gabriel's keynote at Clojure/West (<http://clojurewest.org/sessions#gabriel>). I think it will delve directly into some of this. Fortunately, it will be recorded and released.

</comment></comment></comment><comment><USER5> This is something we talk about all the time here at Mozilla Research. Languages do not become popular primarily because of technical innovation; they become popular because they were in the right place at the right time. (You might draw an analogy to startups here.) Often the designers of the popular languages didn't have much of a background in programming languages research, so they didn't break new ground. (That's not to say that the current languages aren't _good_ , though. On the contrary, Python, Ruby, Perl, etc. are all awesome languages! They just weren't particularly innovative from a PL design standpoint.)

Given that, what is the place for PL research in industry? There are two main ways that we can see for PL research to make a practical difference:

(1) Apply PL research to new features of existing popular languages, and push for those features to be standardized if they're successful. This is what we're doing with JavaScript with, for example, the PJs project (parallel extensions for JavaScript). It's always trickier to fit new research into paradigms of existing languages, but if it can be done it's very rewarding. This has been done with e.g. Java in the past; generics and the flow-sensitive initialization checking were an example of this.

(2) Create new languages designed for a specific, concrete high-value project. This is what we're doing with Rust -- Mozilla is investing in Rust specifically to be the language that we write a new parallel layout engine in. This constraint helps us focus on keeping the language usable, practical, and feature-rich. Features like the uniqueness typing and (in the future) bounded task lifetimes that allow us to avoid concurrent GC are driven by the pain points that we struggle with in Gecko.

<comment><USER2> I can't remember the exact quotation, but it goes along the lines of, " _Every successful language began as the scripting language for something popular._ " (Anyone able to provide the correct quote?)

If that's the case, "The right place at the right time" is when something new is taking off, like C for Unix, Ruby for Rails, Objective C for iOS, or recently JavaScript for Node.

<comment><USER6> JavaScript for _Node_? Isn't that a bit like saying "Java for Minecraft"? I can think of at least one popular use of JavaScrip that predates Node.

</comment></comment></comment><comment><USER7> This article starts off with some interesting albeit vague points, and then meanders into anecdote and unsubstantiated claims. To whit, there seems to be a 20 year lag between a PL idea first being explored in an academic context and it's wide spread use in "mainstream" languages. Parametric polymorphism, first class functions, these have only been integrated into languages like c# and java etc in the past half decade or so. It is normal and typical for ideas to take time to spread! (whether or not that's a good thing is a whole separate discussion) Maybe I'm missing the point of the article. But science is science because it deepens our understanding, not because it will be used by some engineers in a business next week. Arguing for the superiority of anything by dint of its ubiquity/popularity is about as reasonable and healthy as using radium/thorium infused tooth paste twice a day. (so not particularly healthy)

</comment><comment><USER8> It's also worth noting that most of PL research does not focus on simply designing new languages. For work that does propose new language features/constructs, it is typically done within the context of a small lambda-calculus/ML-style language to allow the authors to easily explain the implications of and prove properties about the feature. If the authors do take the next step, they'll often add the feature to an existing language (Java/C/Scheme) rather than design a new one from scratch. It's up to practitioners to take the most useful of these "idea-nuggets" and include them in new languages. Most academic researchers view their job as generating these new nuggets, not building and supporting tools based on them for wider consumption.

Work on new type systems is a big part of the field, however these type systems aren't always intended to be deployed as part of languages. Rather, they can often be viewed as bug-finding program analyses. Indeed, program analysis (including type inference/checking) is a much more common research topic than "a new language for X".

I think many in the field agree that more work should be done on language usability, although it is a hard topic to research. The PLATEAU workshops (on the Evaluation and Usability of Programming Languages and Tools) were efforts in this direction. The Software Engineering field is much more focused on usability and would be the most likely publication target for PL usability research. (The top PL conferences focus on theoretical concerns (POPL, ICFP) and implementation/systems (PLDI, ASPLOS)). Although usability studies are rare, the PL field has gotten tougher about requiring strong arguments about the usefulness of research: the evaluation and motivation sections of papers really need to be convincing.

</comment><comment><USER3> Some missing context, this post is by Cristina Lopes, one of the co-inventors of Aspect Oriented Programming. For thos that don't know Gregor Kiczales and others worked on the CLOS MOP culminating in their book The Art of MetaObject Protocol. I still think this is the only success story of I'm aware of where multiple incompatible programming language dialects were unified under a protocol malleable enough to express them all. This is William Cook's points about the flexibility of OOP taken to the extreme.

When Kiczales and others realized Common Lisp as a community wasn't going anywhere they took their ideas and created AspectJ.

Anyways, her blog seems like a lively read in general - I found this blog post pretty entertaining and I agree wholeheartedly - [http://tagide.com/blog/2011/05/programming-is-math- apparentl...](http://tagide.com/blog/2011/05/programming-is-math-apparently/)

</comment><comment><USER9> I think academic languages don't succeed because the incentives aren't aligned. A mass-market language has very different requirements from a research language: performance, similarity to existing languages, compatibility with existing code, good marketing. Research languages need to be novel, to have genuinely new ideas. They don't have to worry about how hard it will be to teach a million Java programers to use this thing.

Especially at big companies, we're very risk-adverse. We know you can build high-scale applications in Java and C++ because it's been done. You can probably build a high-scale Haskell application too, but would bet millions of dollars on it?

<comment><USER10> > academic lanaguages don't succeed because the incentives aren't aligned

A much harder problem is that compilers are shockingly time-consuming to fully implement and test, much less to integrate with a full set of libraries and tools that you need to use them in practice. Even if you have a new language design, implementing all of the "basic" optimizations to bring your compiler from hopeless to merely embarrasing requires person-years of heroic effort, none of which results in publications or other recognition required to keep your NSF funding coming (they're "basic").

For example, it has taken us since 2007 to get Manticore (<http://manticore.cs.uchicago.edu/> ) to a point where our sequential performance is within a factor of 2-4 of C (depending on the benchmark), and closing that last bit is probably going to take another couple of years unless we have some magical windfall of stunning undergraduate and graduate student candidates. Further, over the _entire_ lifetime of the project, I'd doubt that we will be able to put in even half the people-hours that I saw committed to improving the template error messages in Visual C++ during my first two years working at MSFT.

That said, we've been able to do some truly great things with scheduling computations on multicores, building a GC that works amazingly on NUMA computers, actually getting real speedups on > 36 core machines, etc. But I wouldn't expect to see any of the language features or implementation tricks in mainstream languages for many years. That time lag is just sort of the nature of things in PL research.

<comment><USER11> Doesn't a modular compiler framework like LLVM significantly reduce this barrier-to-entry?

<comment><USER10> Not significantly. If you check out the sources for most functional language compilers (GHC, any of the ML family, scheme, etc.), code generation and micro-optimizations make up a tiny fraction of the code and developer time investment. LLVM is a fabulous project, but many of the optimizations that it performs are already handled at a higher level of the compiler (loop unrolling, inlining, etc.) in a type-preserving functional language. Richer type information (particularly for algebraic datatypes) enables things like loop unrolling over recursive data structures, which you really can't do anymore once it's a bunch of typecasts and tagged union discriminations.

That said, we're looking to move over to it because our old code generation library (MLRISC) is beginning to show its age, and porting to LLVM is probably going to be about as much work as fixing the spill code bug we recently hit and exposing more SSE instructions. Most of the work will probably be in porting our calling convention, which does not resemble C's in any way. Like many frameworks, it's a modular compiler framework for building C compilers, not really a modular compiler framework for all types of compilers.

That's not necessarily a bad thing; many people have tried and failed to make more general ones. I'd rather have to do work to shoehorn our compiler into something that works and is widely used in industry than rely on something that's an easier fit but only likely to be around as long as the group is still publishing papers on it.

<comment><USER12> > Most of the work will probably be in porting our calling convention, which > does not resemble C's in any way. Like many frameworks, it's a modular > compiler framework for building C compilers, not really a modular compiler > framework for all types of compilers.

GHC folks succeeded in including GHC calling convention in LLVM, so there is hope.

[http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and- ll...](http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html)

<comment><USER10> Yes, we're familiar with that work. One technical bit of interest is that we don't use the C stack at all (we have heap-allocated continuation records), so we're curious how that will play out with the calling convention even beyond the issue with registers.

That said, we're still hopeful that we can make things work, though we're not optimistic that it will come about without some significant tweaking.

</comment></comment></comment></comment></comment></comment><comment><USER13> In linguistics, the study of human languages, a big deal is made about how while there are supposed rules about how languages work ("you must never end a sentence with a preposition"), the real object of study is how humans actually _use_ language, which is frequently pretty far removed from how people even self-report their behavior.

Programming languages as a subset of computer science are a purely mathematical thing, where we can use Turing's ideas from the 1930s today to inform type systems. But they're used by humans and humans are fuzzy; they choose "objectively bad" languages like PHP. That doesn't mean to say that science no longer applies -- it just means whatever metric we're using to judge PHP as bad is not the metric that causes a language to succeed. That is still an area worthy of research.

(Not a direct response to the article, sorry. Got a bit carried away.)

<comment><USER14> This is just a wider reflection of a very common pattern--success is only vaguely correlated to quality. If anything, success is heavily dependent on qualities of the environment rather than the thing in question, so there is probably no way to just look at something in a vacuum and decide if it will succeed. Really, the metrics aren't at necessarily at fault, the "market" is-- people choose an inferior product for whatever reason and then stick to it.

You can see a division like this in many other fields, particularly the arts and literature--most popular literature isn't "great" and most "great" literature isn't (as) popular. So the natural parallel is that PHP, Python...etc are like the thrillers at the top of the best-sellers list and Scheme, Haskell are like what you would read in an English class.

And really, this makes sense--whenever anybody talks about the quality of a programming language, they are talking about whether they would use it _themselves_ rather than whether the public at large would use it. So it is completely reasonable to have a "lower quality" language be more popular than a "higher quality" one.

Coincidentally, while I talk about high quality and low quality, I do not mean to denigrate popular languages. After all, sometimes a thriller is all I want on a plane ride! And it could be a perfectly fine book indeed. But that does not mean it's a better book than _Ulysses_.

</comment></comment><comment><USER15> I think the entire discussion would be helped by the simple realization that programming is not really all that glamorous nor scientific. It seems like a lot of programmers have math envy, but programming is much more like managing an office staffed with savants than it is like discovering a proof; You tell the workers in the office what to do, using very specific instructions because they can't figure out what you mean, no matter how blindingly obvious it is to you, even though any one of them can add two numbers together in a billionth of a second.

Given that, we can probably look to progress in the "science" of management to get a feel for what progress in the "science" of language design is going to look like. That is to say, we probably can't expect anything at all in the way of progress. It's funny that there's a parallel between the conclusions in William Whytes' "The Organization Man" and "progress" in language design. Whyte concludes, one, that management in the abstract doesn't actually exist and, two, "management" taken as organizational oppressiveness and intrusion is actually a parasitic load on people trying to get work done, and ought be minimized. Look at the success of weakly-typed scripting languages like perl, js, ruby, python, and so on: the fewer strictures they impose on the data, the more work you can get done!

Researchers are just going to have to get over math and physics envy. The "truths" they discover are very unlikely to be anything like nearly as universal as physical truths. Structured programming, OOP, AOP, functional programming, or whatever else aren't ever going to fit into a proposition like "If we adopt ____, we find that blah," where blah is any kind of contingent claim relating to bugs or productivity. All we'll ever get are notions that whatever paradigm worked well in one context and poorly in another. Again, this is parallel to management. You can't manage programmers like auto workers like farm workers like service workers. Outside of algorithmic analysis, computer "science" has as little to say about programmer efficiency as management science has to say about how many weeks of parental leave you should give your employees.

</comment><comment><USER16> An aside, Python doesn't really fit in with the Ruby, PHP, and Javascript. Although Python was not created for the purposes of research (it was more of a server glue), it was influenced by Guido's experience working on ABC; a research language designed for teaching children. So, python is much more of a result of research than the others.

That being said, the ironic part is the relevant research was not type theory, but rather "How can we teach programming to children?"

</comment><comment><USER17> It would seem that, even though these languages weren't made from soup to nuts in academia, they mostly incorporated ideas therefrom; for instance, Ruby and (eventually) Python got closures that had been pioneered by Scheme. There's still plenty of valuable work to be done trying out ideas that will eventually be incorporated and popularized elsewhere.

And of course, there are still languages like Haskell that have carved out a nice niche, despite their recent vintage and academic roots.

<comment><USER18> Yeah, in Python design discussions I see academic papers cited with some frequency. So all's not lost -- the research is doing something. There is a lot of useless PL research but that's just the nature of exploring new ideas (though, not to ignore real problems with academia, some of which the field of PL research is particularly afflicted with).

Related (long but good) article: [http://unqualified- reservations.blogspot.com/2007/08/whats-w...](http://unqualified- reservations.blogspot.com/2007/08/whats-wrong-with-cs-research.html)

"No field has been more infested by irrelevant formalisms than that of programming languages - also known as "PL research." So when I say Guy Steele isn't a PL researcher, what I mean is that he's not a bureaucrat."

I read basically all of the Lua papers and I think they're a great model for how to do programming language research. They use a real language for a testbed of their ideas. For example, there was a great paper that went over the history of coroutines and different options for designing and implementing them. There was also a great one about PEGs and a formal treatment of the implementation of the lpeg parsing VM. Somehow I feel that this kind of research wouldn't be respected at big name American CS universities, which is a shame, because it's exceedingly valuable.

<comment><USER10> That linked article is from 2007. Interestingly, the stuff that the author mentions as useless (proof carrying code) is now basically The Way that developers handle code that has security, reliability, or robustness requirements.

\- For example, Google Native Client uses a formal verifier to prove the safety of binaries (<http://sos.cse.lehigh.edu/gonative/index.html> )

\- Microsoft has long used a formal driver verifier to prove liveness and protocol properties associated with device drivers

One amazing piece of work going on right now in compilers is by Xavier Leroy, who cares a lot about formally proving that your compiler and its optimizations respect the semantics of the language (i.e. that its execution on hardware is within the range of possible executions specified by the original input language). Without the decades of work on formalization, semantics work, theorem provers, etc. the community wouldn't have a chance of tackling those problems today.

Certainly, if you read the proceedings of POPL or even some ICFP papers, you might wonder where it's going. And even the authors might admit to the same. But until you've fully explored the issues that come up when you try to merge (shameless example from my own work) effect types, region types, concurrency, parallelism, and transactions, it's hard to know what sets of language features can be safely combined in a way that programmers can modularly reason about and a toolchain can implement efficiently and correctly.

<comment><USER18> I don't think what Native Client does is the same as "proof carrying code". From what I gather, if it used proof carrying code, then it would do some verification on the receiving side at "compile time", and no sandbox for runtime checks would be necessary.

My understanding is that Native Client works with a combination of a special compiler toolchain (on the sending side) and runtime checks on the receiving side.

[https://developers.google.com/native- client/pepper16/overvie...](https://developers.google.com/native- client/pepper16/overview#how-nacl-works)

Happy to see any corrections. Your link seems to show a project that is related to NativeClient, but is not the core technology behind NativeClient.

EDIT: Also, I would be interested in details about the Microsoft driver thing, but that doesn't seem related to proof carrying code either.

<comment><USER10> You are correct --- PCC (AFAIK) has not come about in the sense of carrying along a proof object that a formal verifier can validate is both correct and corresponds to the code payload.

As the other commenter pointed out, the SLAM tools are part of the Windows Device Driver Development Kit. The last time I talked to the kit's dev manager (~2003), they were talking about making it mandatory that you pass the formal verification in order to have your driver signed by Microsoft. Since those signatures are then verified at driver installation time, that feels very close to it!

I have to confess I'm only familiar with the publications on Native Client and not the actual product. From what I'd read, I understood that the verifier did some basic static analysis to prove that all possible executions did not validate some properties. In that case, no proof object is required, as the source code itself is the proof object. Assuming, of course, that they're actually doing the stuff talked about in the papers and in practice don't just "grep for dangerous instructions."

</comment></comment></comment></comment></comment><comment><USER14> I'm taking a programming language class right now (not very impressive credentials, I know :P) and I think its focus is telling: the primary goal is not to design and implement a general purpose compiler but rather to design and implement different _DSL_ s.

Now, this obviously involves understanding how compilers and general purpose languages work, but it also involves some other skills and ideas both in design and implementation. The biggest difference is, of course, in scope-- rather than thinking about languages good for _anything_ , we think about very narrow languages heavily optimized to do _one_ thing. These languages may stand alone or they may be embedded in bigger languages, but each language itself is distinct from other languages (including the "host" language).

These languages are also not always aimed at programmers--one of the examples (a past final project) was a language aimed at _tailors_ , of all people, to help them work with patterns. Another language we looked at was designed for musicians to combine different inputs into one output.

These sort of languages _are_ programming languages and have the same ideas, but they serve a different purpose. In a lot of ways, languages like this replace _programs_ and _GUIs_ , letting people work with text rather than pointing and clicking. I think there are very many domains where using text is preferable to a GUI--there is a reason I still use a CLI, after all--and this is exactly the sort of thing we're looking into, except not necessarily for programmers.

I've wandered a bit off topic, but I think these ideas are interesting. It's another direction for PL research--focusing on _very_ narrow fields and potentially non-programmers. Just something to think about.

</comment><comment><USER16> The author is entirely correct that evaluating the effectiveness of programming languages on programmer productivity is damned hard. This is largely because evaluating programmer productivity objectively in the first place is damned hard.

<tounge in cheek> Perhaps developing useful metrics of productivity, rather than strong AI, should have been the real Holy Grail of Computer Science.

<comment><USER19> There's a longitudinal problem as well, in that most of the interesting aspects of productivity improvements come over longer time scales, with large projects and people who have already gotten up to speed on them. Those are extremely difficult/expensive to do controlled studies with. Medicine does them, but 5-year studies in medicine are quite expensive, logistically complex, and have a lot of institutional support because it's considered so important to run them. In HCI, user studies are typically of a shorter length, like A/B-testing one UI paradigm versus another in 30-minute user sessions. Applied to PLs, it's feasible to do user studies looking at learning curves, but much less feasible to answer how Haskell compares to C++ on a large project. Instead, like in economics, the best you can do often ends up being to look for "natural experiments" where almost-comparable things happened in different languages, and try to compare them.

A few software-engineering researchers have told me that that's one major reason that recent "tools" type SE-research happens outside academia: if someone in academia had invented git, it's not clear how they would design a user study to evaluate it, especially within the constraints of, say, a PhD thesis timescale/budget. The typical/simple study design is you recruit N participants, randomly assign N/2 to your tool and N/2 to the control tool, have them perform a task, and then try to show with p<0.05 that the group using your tool did better than control. But in this case, the "perform a task" step has to be non-trivial, and it tends not to be feasible to recruit people to participate in a random study that involves them developing serious software over several years, which would be the equivalent of the kinds of randomized studies that are done with medical devices.

I don't actually find the case-study-based approach particularly bad. Start from cases that are awkward or error-prone to handle in a language (either constructed or derived from data about real-world errors), and propose a solution that captures the underlying computation more directly, or in a more checkable way, etc. There are other areas that make progress in that manner; for example, symbolic logic develops with a case-study and counter-example- driven methodology, where someone will propose a case that either can't be represented in Logic X, or at least can't easily be represented, or maybe produces incorrect inferences when encoded in the obvious way, and this will drive development of a Logic X'.

</comment></comment><comment><USER20>
        > It appears that deep thoughts, consistency, rigor
        > and all other things we value as scientists aren't
        > that important for mass adoption of programming languages.

Perhaps the premise is confused, and programming languages are at least as much about comprehension and readability to humans as they are about theoretical purity from a mathematical perspective -- I don't think it's very surprising that many of the most popular programming languages of the last ten years were designed by individual hackers. Fortunately, academia doesn't have a monopoly on "deep thoughts".

<comment><USER3>
      > Fortunately, academia doesn't have a monopoly on "deep thoughts"

Are there many examples of language features / designs where expressive power isn't derived from prior academic research?

I've used quite a few popular programming languages and they certainly feel "useful" because of syntax, libraries, easy to run on UNIX, etc. Most the "deep thoughts" in these programming languages can be easily found in prior academic literature.

Glad to hear of some examples if you have any! :)

There's plenty of evidence that good engineering can be accomplished with popular programming languages. But I think we're still a long ways off from _beautiful_ engineering. Any way forward needs to elegantly intertwingle Theory & Praxis.

<comment><USER20> Sure.

PHP's "deep thought" was that in the context of building dynamic web pages, perhaps it made sense to embed a scripting language into HTML itself -- instead of calling out to an external program. There's an example of the initial idea being responsible for much of PHP's enduring success.

And here's an anecdote that explains how it was (lack of) readability in significant indentation that led to Python getting its colon:

        > In 1978, in a design session in a mansion in Jabłonna (Poland),
        > Robert Dewar, Peter King, Jack Schwartz and Lambert were
        > comparing various alternative proposed syntaxes for B, by
        > comparing (buggy) bubble sort implementations written down in
        > each alternative. Since they couldn't agree, Robert Dewar's wife
        > was called from her room and asked for her opinion, like a
        > modern-day Paris asked to compare the beauty of Hera, Athena,
        > and Aphrodite. But after the first version was explained to her,
        > she remarked: "You mean, in the line where it says: 'FOR i ... ',
        > that it has to be done for the lines that follow; not just for
        > that line?!" And here the scientists realized that the
        > misunderstanding would have been avoided if there had been a colon
        > at the end of that line.

(from <http://python-history.blogspot.com/>)

<comment><USER3> Perhaps for me "deep thought" means something particular which ends up having wider ramifications. These just seems like anecdotes about known "deep thoughts". The first one the power of templating / macros, the second the power of good syntax.

</comment></comment></comment></comment><comment><USER21> What is needed is a programming language where you can get the same things done but by writing less code. There will obviously be diminishing returns in this. On one project I as able to use 10 lines of Python as an alternative to 400 lines of C, but it seems unlikely that those 10 lines could be replaced by much less.

I do still find that I write far too much code to handle what isn't the normal flow, instead dealing with errors, unusual values, rare interactions etc. Exceptions cover some of that (except in Java with the annoying checked exceptions model). But there is still a lot of code that falls between exceptions and what gets executed most of the time. If only I could leave that rarely executed stuff out.

There is also a massive sore spot with functionality split across multiple processes/machines. Writing synchronous code is clear but has issues, while writing asynchronous code reflects what is really happening but involves a lot of baby sitting. I do think the functional world has immutable values right as a good approach (less locking to worry about, can be transferred between processes, easier to debug etc)

I look forward to the day when my programs look like this, all of one line long:

        DWIM

(Stands for Do What I mean)

<comment><USER22> Abstraction comes at the cost of reduced specificity.

<comment><USER21> Make the normal things easy and the hard things possible. It has been a very long time since I cared how memory was allocated (eg pools, mmap versus heap). It has been even longer since I could determine how data was put on disk (choosing which sectors).

Using Python I can say a list should be sorted and have no say over the algorithm. If I use the STL I have to make a few decisions. Java appears to have 7 different list implementations that I have to pick from.

Working code that was quick to write is far more important than being very specific about every operation. In most cases it is sufficient. With profiling and real world usage you can get an idea of where more specificity is needed, but in many cases even that can be dealt with automatically (JIT, type inference, calling out to a different language). Even if you write new more specific code you can still use the existing code to test against.

</comment></comment></comment><comment><USER23> This reads as another argument about intentional systems versus emergent systems. The author wants to intentionally build a language which is provably "better". Instead we have an ecosystem where many languages (and libraries, and frameworks, and IDEs, etc.) are created, each with varying attributes, and of varying quality; some emerge as preferred for various applications, others fall by the wayside. And then the cycle begins anew. The author seems to miss the important lessons from the "market process" at work.

Perhaps languages are no longer at the right granularity to be "solved". This again echoes the market process; too many variables, and too many different preferences leads would-be problem solvers to rely on the pretense of knowledge.

Languages combine a host of disparate features, and sometimes simply combining previously known features in novel ways is sufficient iterative improvement. Clojure is one good example of this, where immutability, functional programming, and STM were all known and used to varying degrees, but combining them in a clever way allowed for something greater to emerge, particularly how the first two allowed for a new form of the third. From this in turn emerged a (new?) well thought out model of time state, and identity.

In the end, perhaps languages are now really engineering problems, not the science/math problems they used to be. Perhaps the academics should embrace this. To continue the economic parallel, if one wishes to examine the qualitative aspects of PLs, perhaps research should approach from the historical perspective, asking why certain languages emerged to solve certain problems.

</comment><comment><USER24> There is probably some good research in programming languages out there though every time someone goes looking they encounter the ACM paywall. Back to PHP I guess.

</comment><comment><USER25> So ideally, academia would do the "innovation" and the practical people would incorporate the innovative ideas into their "mashups of concepts that already existed", right? But I guess the problem is that academia is not set up to handle that kind of innovation, because it's hard to quantify the benefits.

There's obviously lots of room to improve in programming languages. It seems the only question is getting people to do it.

<comment><USER26> This. It seems like new features are developed, but it takes decades for the good ones to rise to the top and end up being implemented. And the academic model, of applications for grant funding works quite well for just these sort of advancements, at least in other fields. Somebody who has the money and time to put together a grant program targeting improvements in both programming languages and, perhaps more importantly, real world user experiments in the design of programming languages, could really make a difference. There is no inherent reason that that the decades for useful feature implementation couldn't be reduced significantly, given a moderate source of funding, a good journal community, and better research methodologies.

</comment></comment><comment><USER27> My experience in academia suggests that this desire for pseudoscience isn't confined to programming languages.

As much as the ideas of Science and Engineering are popular sacred cows in "Computer Science", I think that the essence of the software world is much closer to some sort of mathematical craftsman.

</comment><comment><USER28> I think a PL to explore novel concepts will hardly ever make it into mainstream. Those languages from the 90s reused concepts that were developed decades ago but were eventually put into a form accessible for the masses. New problems will arise since the way computers are used will change which will pose new problems. But it will take decades to filter out which approach is most suitable for practicioners and those resulting languages will have little in common with the academic PLs whose ideas they reuse. I thus find it funny to name haskell and php in the same sentence (those languages don't simply have different target domains but they are from different planets). From the point of view of an academic PL researcher/teacher, that's somehow frustrating of course.

</comment><comment><USER29> It might be true that the last 30 years brought very little new ideas in language design. But "no innovation" is something quite different than "no improvement".

In my opinion the languages of the present improve by a) skillfully combining the existing ideas and b) implementing the 95% other things that are not big ideas but are still essential to a language being good: consistent and broad standard lib, streamlined syntax, core concepts playing well with each other and so on.

Both of the above are rather engineering than science, so the author seems right in his views. Maybe when we reach the local optimum with the current set of the fundamental ideas, we will see the need for new ones more clearly and the necessity of fundamental research will reappear.

</comment><comment><USER30> A language is defined by syntax and semantics, and there is nothing intrinsically in there to make quantitative judgements. So performance is not, and cannot be, of a language but of a compiler/interpreter, together with a runtime/virtual machine.

</comment><comment><USER31> It seems useful to address the question of _why_ people create new languages - either DSLs or full languages. Would anyone know of work in such an area? The answer to the "why" is not the reasons people _say_ they make a language. I mean the question as a probe into the psychological urges to "linguate" (is that a word?).

One possible kind of answer could be that, given formal systems are powerful tools to model some interesting corner of reality, the urge to create a DSL could be related to an urge to understand a domain by creating an automaton that can be mapped to domain aspects.

</comment><comment><USER32> The second comment on that page says python owes its list comprehensions to haskell. Is that true? Did Guido (or someone from python land) look at haskell and say 'hm list comprehensions are cool, lets put them in python!' or was it more like python rediscovered list comprehensions and the design in both haskell and python is just the obvious way to do it.

<comment><USER33> from <http://wiki.python.org/moin/PythonVsHaskell>

List Comprehension Syntax:

Python's list comprehension syntax is taken (with trivial keyword/symbol modifications) directly from Haskell. The idea was just too good to pass up.

</comment></comment><comment><USER34> It took 50 years for popular programming languages to catch up to Lisp, and in some ways we're still not there yet.

So the point of programming language research is to come up with ideas for the practical programming languages of the next 50 years to steal.

<comment><USER35> ah, the old lisp argument again ;)

 _So the point of programming language research is to come up with ideas for the practical programming languages of the next 50 years to steal._

More generally, one point of research is to come up with ideas for practical technologists of the next 50 years to steal.

</comment></comment><comment><USER22> [repost from blog] – This is really spot on. I would like to refer you to a couple of things that come to mind that you might find useful for advancing this line of thinking.

(1) I saw a talk by Jonathan Edwards that was very much along the lines of what you wrote here: <http://alarmingdevelopment.org/?p=5>

(2) Second, Christopher Alexander's early work on patterns in architecture and urban design have been referenced quite a bit in computer science, but seldom is his 'magnum opus', a four-book series on the 'nature of order', referenced. These texts move far beyond the early work. You would do well to have a look at the first book, which tries to establish an objective theory of design not based on scientific principles: [http://www.amazon.com/s/ref=nb_sb_noss_1?url=search- alias%3D...](http://www.amazon.com/s/ref=nb_sb_noss_1?url=search- alias%3Daps&field-keywords=the+nature+of+order&x=0&y=0)

(3) You might be interested to read some discussion on the history of music programming languages. Max/MSP and Pd, both dataflow-oriented, offer what I would estimate to be an order of magnitude of productivity gain for certain tasks in building one-off multi-media systems. They're a bit like a UNIX for real-time multi-media + control signals. This essay reminded me a bit of the anti-academic and organic approach that Miller Puckette took in building them despite being trained as a mathematician and developing them in an academic setting. This serves as a good lesson that successful software isn't necessarily designed by having good principles, but rather the proper environment, namely, one with energy and a need.

Check out two papers in the Computer Music Journal where this is discussed:

      2002. Miller Puckette, "Max at Seventeen". Computer Music Journal, 26(4)
      2002. Eric Lyon, "Dartmouth Symposium on the Future of Computer Music Software: A Panel Discussion". Computer Music Journal, 26(4)

Generally, computer music is one of the more interesting fields to look at if you're interested in ascertaining the future of HCI, computer science and psychological research since from the beginning they have not been accorded the luxury of forgoing certain constraints, such as that everything must happen in real-time, data must be of a certain resolution (in time and 'space') and that non-tech-savvy practitioners from other fields (musicians) must be able to use the tools as experts.

\--

Oh, and I would add that if you are not familiar with Bill Buxton's career, it may prove interesting reading for you. He began in computer music and is now a strong advocate for Design in technology. One insight that he often emphasizes, which I don't claim is his originally, is that new technologies take 20-30 years to be adopted. According to this view, new ideas in software design should expect to lie dormant for at least 20 years, echoing what @Ben wrote above.</comment>


The UX Perspective - <AUTHOR> http://thehipperelement.com/post/98141670152/the-ux-perspective

<comment><USER2> My other perspective is the 'development cost perspective'. Everything takes time to build, and some really nice UX features just don't improve the experience enough to warrant making them.

<comment><AUTHOR> As long as you have asked "does this improve the experience enough to build?" I think we are in complete agreement. That is good UX thinking, in my opinion. :)</comment></comment>


Ask HN: What calculator do you use on Ubuntu? - <AUTHOR> I've recently moved away from OSX and went full linux, not a painful decision since current MBPs are a complete waste of money. I have transitioned my workflow to ubuntu pretty easily and no issue whatsoever. But, find myself missing the calculator built in Spotlight and I'm looking for a replacement.<p>TL;DR: So, question is:
What program/tool/phisical calc/website(please don't tell me gogle :/) do you use to do calculations during your workflow? <comment><USER2> This answers your question, but won't actually help you: I use the Windows 10 Calculator, which has a super handy programmer mode that does hex and binary and crud.

IMHO, I'd look for someone who's emulated/reimplemented a proper graphing calculator. I've never tried using [https://www.numworks.com/simulator/](https://www.numworks.com/simulator/) for realz, but it looks handy.</comment>


Effective Airflow Development - <AUTHOR> https://curology.com/blog/tech/posts/effective-airflow?hn <comment><USER2> Making use of airflow's plugin architecture by writing custom hooks and operators is essential for well-maintained, well-developed data pipelines (that use airflow). A little upfront investment in writing components (and the most painful part, writing tests) will go a long way to helping data engineers sleep at night.

That said, I make a point of using ETL-as-a-service whenever it's available, because there's no use solving a problem someone else has solved already.

</comment><comment><USER3> Seeing as this article is from 2019, would people still recommend airflow to ETL data from APIs to DataWarehouse/DataLakes or is there something better in the market?

<comment><USER4> Nothing is more popular yet, but there are better architected options out there. It's hit 17k GitHub stars and was used by the team I was previously at. I don't think anything will beat it unless something from the CI/CD or "cloud native" world moves in unexpectedly.

The operators and scalability are somewhat useful. I was happy with the UI compared to cron. Testing is a mess. Also, Airflow isn't CI/CD-friendly (but it's possible to get it to work).

I'd recommend a managed option unless you have a skilled ops team. It reminds me of Hadoop in terms of how exciting it is to get set up, which isn't a good thing.

<comment><USER5> Can you expand on "testing is a mess"? Do you mean testing your own DAGs and operators?

<comment><USER4> Yeah, like the other reply, I'd mostly say testing DAGs was an issue. Airflow- related configuration is easy to get wrong and it silently fails a lot.

Now that I think about it though, most of the time I spent on testing wasn't caused by Airflow. Testing data pipelines just isn't easy with the current well-known tooling.

</comment></comment></comment></comment><comment><USER6> Based on the title I clicked this thinking it was something related to OSI layer 1, for hot aisle/cold aisle separation in high density datacenters, compartmentalized-per-cabinet cooling or something.

As a side note how do you effectively google for a piece of software or product with a name as generic as "airflow"?

<comment><USER7> "airflow etl", "airflow scheduler", "airflow software"

</comment></comment><comment><USER8> Testing Pipeline in Airflow is bit pain, but great expectation makes runtime pipeline validation much easier. [https://greatexpectations.io](https://greatexpectations.io)

For unit/integration tests we ended up doing lot of Docker in Docker setup.

</comment><comment><USER9> I am using Apache Airflow since a couple of years now and the biggest improvement was the addition of the Kubernetes Operator. You basically keep a vanilla Airflow installation and the custom code is encapsulated and tested in containers. This simplifies it a lot.

<comment><USER10> This is what we do - it's great for decoupling the two. Any heavy work is run in GKE with some custom operators. It also makes on boarding non engineers much easier as they don't have to worry about connections/credentials/etc.

</comment></comment><comment><USER11> you only need two operators, the kubeoperator, the dataflow operator

and then every task is just a standalone, vertically scalable service on k8s or a giant horizontally scalable compute job</comment>


Zellio – Open Source MCommerce Built with Meteor - <AUTHOR> http://zellio.404vanity.com

<comment><AUTHOR> Hey guys, I've been working on this for a few months as I've been really interested in building mobile apps with Meteor. Through out the process of building this I had the intention of licensing the software and make some money off this project. But I've come to realize with the direction everything is going with mobile and shopping that releasing this as an open source project would have huge benefits for everyone. I plan on working on this consistently, but now hopefully have some great minds contribute as well.

The app has 2 parts:

The frontend/iOS app - [https://github.com/404vanity/zellio](https://github.com/404vanity/zellio)

The admin panel - [https://github.com/404vanity/zellioadmin](https://github.com/404vanity/zellioadmin)

I'm currently setting up a demo for people to see, but if any one needs help deploying this to their server and building the app it self, let me know as I'd be happy to help!</comment>


A History of the Erlang VM (2011) [pdf] - <AUTHOR> http://www.erlang-factory.com/upload/presentations/389/EFSF11-ErlangVM.pdf <comment><USER2>
      88-05-27 Changed name of file to erlang.pro
      First major revision started - main changes
      Complete change from process to channel based
      communication.
      here we (virtually) throw away all the
      old stuff and make a bloody great data base

      88-05-31 The above statements were incorrect much better
      to go back to the PROPER way of doing things
      long live difference lists

Big change lasted four days :)

</comment><comment><USER3> The talk - [https://vimeo.com/23509552](https://vimeo.com/23509552)

</comment><comment><USER4> Does anyone know any more of the details about why backtracking was rejected?

</comment><comment><USER5> Wow. They started writing it in 1885. What took them so damn long?

<comment><USER6> Could you please not post unsubstantive comments here?

<comment><USER7> Steam-powered brass analytical engines were very substantial. Or would have been. As it is, they were insubstantial: very virtual indeed.</comment></comment></comment>


Phone Makers Could Cut Off Drivers. So Why Don't They? - <AUTHOR> http://www.nytimes.com/2016/09/25/technology/phone-makers-could-cut-off-drivers-so-why-dont-they.html <comment><USER2> How would a phone manufacturer tell the difference between a driver and a passenger?</comment>


Inside the Philly DA's side hustle –selling seized homes to speculators and cops - <AUTHOR> http://planphilly.com/articles/2018/12/07/inside-the-philadelphia-da-s-side-hustle-selling-seized-homes-to-speculators-and-cops <comment><USER2> Key element in the article: "The new Philadelphia DA, Larry Krasner, ran for office as a critic of forfeiture. But even his office admits the practice of law enforcement taking and selling homes will never be completely over. "'We have not suspended all forfeiture, but we have aggressively narrowed the size and scope,' said Krasner spokesperson Ben Waxman. 'You actually have to be convicted and the property has to be connected to the crime or purchased with proceeds connected to the crime. There could be very small exceptions to this rule, but that's generally it.'"

Seizures were abused much more under the previous DA -- including people losing homes without being convicted. Krasner has stopped the no-conviction seizures, and is dialing the whole thing back.

It's not trivial that this article embarrassing the DA comes out less than 12 months after Krasner was sworn in. He's not loved by the Philly Police.

[https://slate.com/news-and-politics/2018/12/philadelphia- dis...](https://slate.com/news-and-politics/2018/12/philadelphia-district- attorney-larry-krasner-criminal-justice-reform.html)

<comment><USER3> His predecessor is in jail on corruption charges. He was loved by the police for his civil forfeiture pursuance. Makes sense.

<comment><USER4> Wow.

Read a little about the previous DA. Seems like a piece of work. It's surprising to me because I didn't think DA's in other states were quite as corrupt as some of the DA's we've had in Wisconsin are, but apparently Pennsylvania has the corrupt DA problem too.

</comment></comment></comment><comment><USER5> Asset seizure is a fucking blight. If a chunk of your budget comes from selling seized property, then you are going to prioritize seizing property. Especially when _property can be fucking seized without a conviction_.

<comment><USER6> It's not completely black and white though. In this modern world of ransomware, mail-order drug trade and other lucrative side jobs, invisible crime is easier and more prevalent than ever.

Basically, asset seizure enables the state to go after someone without no known source of income flaunting millions of dollars in sports cars, mansions, etc. Even if the state has no idea _what_ the suspect doing, just that they've got millions of dollars and no explanation on where it came from.

Alas, this theoretically decent idea has been completely fucked up in it's execution. But the core idea of asset seizure, namely that obvious proceeds of a crime can be seized even when the crimes were committed in private.

Historically, I believe it was used against people who magically had gained a fortune overnight, without forcing every bank to go through their vaults and count the cash. Bootleggers, too.

<comment><USER7> > Basically, asset seizure enables the state to go after someone without no > known source of income flaunting millions of dollars in sports cars, > mansions, etc. Even if the state has no idea _what_ the suspect doing, just > that they've got millions of dollars and no explanation on where it came > from.

Why should seizing assets be okay under those circumstances?

> In this modern world of ransomware, mail-order drug trade and other > lucrative side jobs, invisible crime is easier and more prevalent than ever.

In this modern world of internet-connected financial institutions and big data, following large amounts of money through the system is easier and more prevalent than ever.

<comment><USER6> >> Basically, asset seizure enables the state to go after someone without no known source of income flaunting millions of dollars in sports cars, mansions, etc. Even if the state has no idea _what_ the suspect doing, just that they've got millions of dollars and no explanation on where it came from.

> Why should seizing assets be okay under those circumstances?

That one is a value judgement, and there is no right answer. Personally, I think the system should be biased to discourage crime, even if it's very unlikely you'll get caught. I know others place the value of freedom higher than the value of, well, fairness. I prefer a nation where crime doesn't pay, or if it does, you lose the spoils.

<comment><USER8> Lower probability of conviction can be addressed by increased severity of punishment _upon conviction_.

<comment><USER9> If that were true then we should expect the US to have a significantly lower rate of crime than other Western democracies given that:

 _the United States had by far the highest reported rate of incarceration in the world. Today, adult incarceration rates of the Western European democracies average around 100 per 100,000, and in the common law countries of Australia and Canada, the rates are only slightly higher. The U.S. rate in 2012 was seven times higher, at 707 per 100,000._ [1]

For this to be possible the US must have been incarcerating more people, for longer, than other countries, which by your logic would reduce the rate of crime.

I was under the impression it was widely accepted that increased severity of punishment had only a small effect on rates of crime. The report I've referenced seems to agree.

1\. Refer page 335 here [http://johnjay.jjay.cuny.edu/nrc/NAS_report_on_incarceration...](http://johnjay.jjay.cuny.edu/nrc/NAS_report_on_incarceration.pdf)

I found that PDF here [https://www.psychologytoday.com/us/blog/ethics-in- question/2...](https://www.psychologytoday.com/us/blog/ethics-in- question/201509/harsh-justice)

</comment></comment></comment></comment></comment></comment><comment><USER10> Important context: A recent batch of city DA's in the U.S. (I know Krasner is one of them but I can't name others off the top of my head) are revolutionizing urban law enforcement. Krasner, for example, is a civil rights attorney who won the DA office on a progressive platform, which IIRC is not dissimilar to the others. It's a revolution, as I said, and of course that means that many vested interests have lost power and many other people will be uncomfortable with the change. There are targets on the DA's backs.

That doesn't mean these DA's shouldn't face scrutiny (they absolutely should), that they can't do things wrong, or that they can't be corrupt. But the context is an important part of this story.

</comment><comment><USER11> The police-acquired homes are a red herring. They represent a fraction of the properties being rebuilt by developers for new, rich, white renters. Anything that isn't nailed down in Fishtown, NoLibs, and Kensington is being bought up and developed into condos and apartments. The development is even pushing its way south down Broad Street, with multiple new complexes of apartments and shopping coming online.

Even if this seizure bs was not going on, nobody in this area of town will be able to afford to live there in 5 years. And there's no new public housing going up anywhere, because all the contractors are bidding ridiculously inflated prices to build them.

This is going to push everyone in the area into the streets, or jail, and push crime into every other corner of the city it can spread to, because nothing is being done to help the people who have to resort to drugs to survive. Philly is still very much a dangerous, desperate place to live.

<comment><USER12> Are they being rebuilt by developers for rich white renters? Are you sure they're not being built for rich renters?

<comment><USER11> They're being built for _predominately_ rich white renters, based on the people moving in to these neighborhoods for the past few years. It's a classic gentrification story. Before you would have had mostly black and latino residents, and now on many blocks it's mostly white residents [and businesses]. The marketing is basically "Can't afford Williamsburg? Move to Fishtown."

</comment></comment></comment><comment><USER13> Anyone associated with government and their families should be banned from buying seized property and any proceeds should be going into a general fund.

</comment><comment><USER3> How was this never challenged constitutionally with violation of due process, at a bare minimum?

<comment><USER14> Supreme Court has upheld civil asset forfeiture so far

Of course this is based on the arguments presented

And there are plenty of arguments remaining

All it comes down to is that nobody rich enough, and sympathizable enough, has been subject to this yet. No random police department has seized a bank's property due to suspected association with an unspecified crime.

Gamblers driving with cash and illiquid homeowners are the ones that experience this.

</comment></comment><comment><USER15> Slightly related, I was reading this[0] over the weekend and it left me incensed.

Behind a paywall, so relevant bits

> Uri Rafaeli is an 83-year-old engineer and great-grandfather. He never > expected the government to treat him like a drug dealer or gang banger. But > last year the Michigan Court of Appeals held that a county government could > use civil asset forfeiture—the same legal process used by police to > confiscate drug lords' mansions—to seize a modest rental property Mr. > Rafaeli owned because he accidentally underpaid his property taxes by $8.41.

> Mr. Rafaeli bought the house through his business for $60,000 in 2011. Later > that year he inadvertently underpaid his property's taxes by $496. When he > learned of his mistake in 2013, Mr. Rafaeli attempted to pay the debt in > full but failed to account for the interest that had accumulated since he > received the bill. He came up $8.41 short.

> Unaware of his error, Mr. Rafaeli went on to pay his taxes in a timely > manner in subsequent years. Nevertheless, in February 2014 Oakland County > foreclosed on the property to collect the tiny debt, along with $277 in > penalties, additional interest and fees. Six months later the county sold > the property at auction for $24,500 and refused to refund Mr. Rafaeli any of > the profits.

> ....

> The elderly, sick or economically distressed are most at risk of losing > property over tax debts. Henderson Hodgens lost his childhood home and farm > in Geneva Township, Mich., in 2014 when a hospitalization left him > unexpectedly unable to pay his $5,900 debt. Benjamin Coleman—who suffers > from dementia—lost his Washington, D.C., home when he forgot to pay a $134 > tax bill. Public outrage over his story prompted District of Columbia > officials to change a confiscatory law to protect property rights.

> The Michigan Supreme Court agreed last month to hear Mr. Rafaeli's case and > will decide whether the Court of Appeals erred in its ruling that Oakland > County had violated neither the Takings Clause nor the Michigan > Constitution's "just compensation" requirement. Mr. Rafaeli is prepared to > take his case all the way to the U.S. Supreme Court, if need be, to stop > bureaucrats from turning property tax collection into an instrument of > government theft.

Absolutely fucking appalling stuff.

[0] [https://www.wsj.com/articles/for-8-41-in-unpaid-taxes-the- go...](https://www.wsj.com/articles/for-8-41-in-unpaid-taxes-the-government- took-uri-rafaelis-house-1544227055)

</comment><comment><USER16> This was discussed earlier today on the r/Philadelphia subreddit and this was the top comment: [https://reddit.com/r/philadelphia/comments/a4xseb/_/ebigt2b/...](https://reddit.com/r/philadelphia/comments/a4xseb/_/ebigt2b/?context=1)</comment>


Setting up a second keyboard for more shortcuts in Emacs - <AUTHOR> http://jordekang.tk/posts/rus-kbd.html <comment><USER2> A little more complicated, but a lot more versatile.

I had a similar issue, where I wanted a large amount of extra keys for macros/hotkeys. I bought a planck kit from olkb ([https://olkb.com/planck/](https://olkb.com/planck/)) (which is just one of many keyboard kits that will run the QMK firmware ([https://github.com/qmk/qmk_firmware)](https://github.com/qmk/qmk_firmware\))) built it and rewrote the keymap to output my special keys.

Later I went on to wire up a couple simple industrial style footswitches to a cheapo arduino pro micro clone and put qmk on there.

A few other interesting and smaller keyboard kits can be found from vendors like [https://www.1upkeyboards.com/](https://www.1upkeyboards.com/) (the sweet16 macropad/keypad) and [https://keeb.io](https://keeb.io) (the chocopad or just half of any of their "ortholinear" split keyboard pcbs.

</comment><comment><USER3> Reminds me of this [https://www.jwz.org/blog/2016/09/searching-for-finally- got-m...](https://www.jwz.org/blog/2016/09/searching-for-finally-got-my-emacs- setup-just-how-i-like-it-yields-excellent-results/)

<comment><USER4> Since jwz dislikes HN, most users will want to use this link instead:

[http://archive.is/z8VCZ](http://archive.is/z8VCZ)

</comment></comment><comment><USER5> There's also the emacs pedal:

[https://www.emacswiki.org/emacs/FootSwitches](https://www.emacswiki.org/emacs/FootSwitches)

</comment><comment><USER6> Something I've been wondering and casually looking into: besides another whole keyboard, what other keypad-like layouts/devices are there? What I _think_ I want is another row of F-keys above the ones that are there (I use these to switch between windows). Of course I now use a TKL, but never warmed up to the idea of using the numpad for this. I think part of me just doesn't like the idea of repurposing keys with strong meanings.

I've pondered getting one of those pads used to drive music software. The Elgato Stream Deck mentioned elsewhere in this thread seems quite interesting (to look into when I have more time). Any other pointers?

Also related: I'd really like to try a wireless chorded keyboard for mobile use.

<comment><USER7> X-Keys makes a variety of USB key pads in various shapes, including single rows of 4, 8, or 16 keys.

[http://xkeys.com/XkeysKeyboards/index.php](http://xkeys.com/XkeysKeyboards/index.php)

<comment><USER8> Also see Genovation

[https://www.genovation.com](https://www.genovation.com)

</comment></comment></comment><comment><USER9> A second keyboard is also good for playing split-screen multiplayer DOS games. No more incessant beeping in Mortal Kombat when both of you try to perform a combo at the same time!

<comment><USER10> Actually, a sane keyboard with sufficient rollover suffices for that task. Just don't but a <20$ model to get this.

</comment></comment><comment><USER11> I mean, if a piano (or something closer to a Tonnetz[0] layout) is okay, why not a full organ with >1 keyboard and pedals? :)

[0]: [https://en.wikipedia.org/wiki/Tonnetz](https://en.wikipedia.org/wiki/Tonnetz)

<comment><USER12> I've seriously considered getting some sort of foot pedal arrangement, albeit mostly for FPS games - I'd love to be able to use one foot to melee attack, and another to activate/deactivate the mic.

<comment><USER13> I've tried repurposing a three-button guitar footpedal for FPS games before.

The connection for the pedal is TRS, with one button being ring, another sleeve, and the last both—so it ended up being useful for only two commands as the last button would be ghosted by pushing the other two simultaneously.

I used the pedal for left and right leaning and with melee in the center, but with the ghosting, I ended up dropping melee and just stuck with using it for only leaning.

I used an Arduino Pro Micro which supports acting as a keyboard and just soldered a TRS socket so I could just use a regular TRS cable to hook up the footpedal.

It's a bit satisfying once you get it working and the project didn't cost too much—maybe about $20 (found a cheap used footpedal) and enough games use "q" and "e" binds that I get to use it a bit.

</comment></comment></comment><comment><USER14> If you need a second keyboard to use your text editor, maybe the problem is not the keyboard, but the text editor.

yes emacs is more than that, but with f1-f12, ctrl,shift,alt and their various combinations to the alphanumeric keys, it seems a bit overkill to me.

If you still need more keys, you can also get a JP keyboard with extra modifiers conveniently located next to the spacebar.

</comment><comment><USER15> Is it possible to do this on Mac? Have a second, external keyboard mapped to a different language than the primary keyboard?

<comment><USER16> With lua + autohotkey scripts in windows this is definitely possible the last time I checked. You run a luascript on another keyboard mapped to a generic key, luascript inputs that as the proper text-based language

There's a tomscott video on it

[https://www.youtube.com/watch?v=lIFE7h3m40U](https://www.youtube.com/watch?v=lIFE7h3m40U)

Checkout Teran van Hemert (linustechtips editor) for some potential ideas too. He's got crazy macro schemas, I've used a couple of his and there great. All windows based as well though. [https://www.youtube.com/playlist?list=PLH1gH0v9E3ruYrNyRbHhD...](https://www.youtube.com/playlist?list=PLH1gH0v9E3ruYrNyRbHhDe6XDfw4sZdZr)

Mac, I can only assume its something you would write in applescript. But maybe you find some interesting ideas there. I found something called "[http://www.orderedbytes.com/controllermate/"](http://www.orderedbytes.com/controllermate/") that might be of interest to you

<comment><USER17> [https://autohotkey.com/boards/viewtopic.php?t=45307](https://autohotkey.com/boards/viewtopic.php?t=45307)

[http://www.oblita.com/interception](http://www.oblita.com/interception)

</comment></comment></comment><comment><USER18> Heh, his feels like what happens when an Emacs user gets mocked by the vi crowd and decides to just own it. Good for him.

</comment><comment><USER19> I though emacs/vi users _don 't_ want to take their fingers off the home row?

<comment><USER20> That's definitely true for vi; but only after you properly remap your ESC key to something else (usually jj or caps lock).

Emacs is a differenet story... By default it uses a lot of alt and ctrl key combinations and also makes heavy usage of the arrow and home/end keys. Of course, there is a vi mode for emacs (evil; this is what Spacemacs uses) to take advantage of vi keys in emacs. But I believe that most emacs users just stick to the alt/ctrl shortcuts.

<comment><USER21> Ctrl and alt only take the little fingers. I'm actually used to not typing with them, but instead reserve them for shift, ctrl and alt. All the other fingers stay at their place.

After seeing the article I've thought about doing something similar, but dismissed it exactly because it would take my hands out of the keyboard.

</comment></comment></comment><comment><USER22> Double bucky, an additional keyboard or two...

(see: [http://www.art.net/~hopkins/Don/text/double- bucky.html](http://www.art.net/~hopkins/Don/text/double-bucky.html))

</comment><comment><USER23> Three modifiers are enough: Command, option, control. Easy on macOS, possible on Linux:

        (setq mac-control-modifier 'super)
        (setq mac-option-modifier 'meta)
        (setq mac-command-modifier 'control)

I never have to resort to using two modifiers at the same time (e.g. Command + Option), as said 3 individual modifiers are plenty.

I also never use C-c or C-u prefixes, or other emacs-isms. Everything is a single combination, which is fundamentally simpler and more ergonomic.

For rarely-used commands, I just `M-x the-command`. Better than assigning complicated or easy-to-forget shortcuts.

<comment><USER24> so you rebind lots of key chords?

<comment><USER23> These are (almost) all of them, I'd say it's a bearable amount:

[https://github.com/vemv/.emacs.d/blob/master/lib/non- submodu...](https://github.com/vemv/.emacs.d/blob/master/lib/non- submodules/vemv.shortcuts.global.el)

(also some are redundantly rebound, like left-key to left-char. I do it for... reasons)

</comment></comment></comment><comment><USER25> Does Emacs distinguish between "left" and "right" modifiers? If so, you could (ab)use those to effectively create 4 extra prefix layers.

</comment><comment><USER26> Another idea to consider, something like the Elgato Stream Deck (LCD keyboard where you can configure the image and behavior of every key).

<comment><USER27> Wow, those LCD keys are fancy, but it's hard to imagine that's worth the premium over a usb or BT 10-key. Not sure about other platforms, but on macOS with something like Karabiner-elements[1] or Controllermate[2] you could assign all sorts of things to those keys.

1: [https://github.com/tekezo/Karabiner- Elements](https://github.com/tekezo/Karabiner-Elements)

2: [https://www.orderedbytes.com/controllermate/](https://www.orderedbytes.com/controllermate/)

<comment><USER26> I find them useful in a slightly different use case. For things where you don't use them often enough to learn the shortcut by heart (i.e. you don't need the visual help) but often enough that it is worth having a button for it. For instance something you will be doing intensely for a short period of the time in the year.

</comment></comment></comment><comment><USER28> Is it possible to have the 2 keyboards plugged in with different layouts in windows?

</comment><comment><USER29> Haha, gloriously hacky.

</comment><comment><USER24> very nerdy.

</comment><comment><USER30> soon emacs-organ

<comment><USER31> Hmmm, with pull-stops to activate various minor modes...

</comment></comment><comment><USER32> Jokes write themselves /s</comment>