I think you misunderstand what I’m saying. My claim isn’t that Qt would solve every problem that people are looking to electron to solve if only it were more popular. My claim is merely that of the cross-platform native toolkits, Qt seems to be both the furthest along in terms of capability, and also seems to be one of the less recognized tools in that space (compared to Wx, GTK, Mono, Unity, heck I’ve seen seen more about TK and FLTK than Qt lately). I suspect that Qt could grow and support more of what people want if it got more attention, but for whatever reason of the cross-platform native toolkits it seems to be less discussed.

without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today.

I don’t really remember having a problem finding desktop applications before Electron. There seems to be relatively little evidence for this statement.

I’m not sure sure that it’s necessarily true that the existence of these apps is necessarily better than the alternative. For a technical audience, sure. I can choose to, grudgingly, use some bloated application that I know is going to affect my performance, and I’m technical enough to know the tradeoffs and how to mitigate the costs (close all electron apps when I’m running on battery, or doing something that will benefit from more available memory). The problem is for a non-technical audience who doesn’t understand these costs, or how to manage their resources, the net result is a degraded computing experience- and it affects the entire computing ecosystem. Resource hog applications are essentially replaying the tragedy of the commons on every single device they are running on, and even as the year-over-year gains in performance are slowing the underlying problem seems to be getting worse.

And when I say “we” should do better, I’m acknowledging that the onus to fix this mess is going to be in large part on those of us who have started to realize there’s a problem. I’m not sure we’ll succeed as javascript continues to eat the world, but I’ll take at least partial ownership over the lack of any viable contenders from the native application world.

“and without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today. “

What that’s actually saying is that people who envision and build cross-platform apps for their own satisfaction, fame, or fortune would stop doing that if Electron didnt exist. I think the evidence we have is they’d build one or more of a non-portable app (maybe your claim), cross-platform app natively, or a web app. That’s what most were doing before Electron when they had the motivations above. Usually web, too, instead of non-portable.

We didnt need Electron for these apps. Quite a few would even be portable either immediately or later with more use/funds. The developers just wanted to use it for whatever reasons which might vary considerably among them. Clearly, it’s something many from a web background find approachable, though. That’s plus development time savings is my theory.

I think the big caveat to this is that for a great many of the applications I see that have electron-based desktop apps, they are frontends for SAAS applications. They could make money off a GPL application just as easily as a proprietary one, especially since a lot of these services publish most of the APIs anyway.

Granted, I’d love to see a world where software moved away from unnecessary rent-seeking and back to actually selling deliverable applications, but as long as we’re in a SAAS-first world the decision to release a decent GPL-ed frontend doesn’t seem like it should be that hard.

I have been responsible for third party IP at a company that did exactly that with Qt; it’s fine.

I never claimed that it doesn’t make life easier for some developers, or even that every electron app would have been written with some other cross-platform toolkit. Clearly for anyone who uses Javascript as their primary (or, in many cases, only) language, and works with web technology day in and day out, something like electron is going to be the nearest to hand and the fastest thing for them to get started with.

The problem I see is that what’s near to hand for developers, and good for the individual applications, ends up polluting the ecosystem by proliferating grossly, irresponsibly inefficient applications. The problem of inefficiency and the subsequent negative affect it has on the entire computing ecosystem is compounded by the fact that most users aren’t savvy enough to understand the implications of the developers technology choices, or even capable of looking at the impact that a given application is having on their system. Additionally, software as an industry is woefully prone to adopting local maxima solutions- even if something better did come along, we’re starting to hit an inflection point of critical mass where electron will continue to gain popularity. Competitors might stand a chance if developers seemed to value efficiency, and respect the resources of their users devices, but if they did we wouldn’t be in this situation in the first place.

“But that is not Electron’s fault.”

It happens by default with a lot of Electron apps. It doesnt so much with native ones. That might mean it’s a side effect of Electron’s design. Of course, Id like to see more data on different use-cases in case it happens dor some things but not others. In your case, did you have to really work hard at keeping the memory down?

Edit: The Github link has some good info. Thanks.

Which parts are the problem?

Thanks for your thoughts as well. A few follow-on thoughts to your notes:

I would suggest that that status, and the dogwhistle effect you mentioned earlier, is perhaps due just as much to repeated memes about coded messaging and hostility as any of the actual behavior in those communities. At some point, repeated public shaming starts to create pathological behavior on its own.

I think there’s probably some truth to this, especially the problems with public shaming. There is an unfortunate tendency to shame people in a way that I think makes them double-down on problematic behaviors. That aside, I don’t think we can ignore the effects of something, dog whistling in this case, regardless of it’s original cause.

The issue is that, if you expect fair enforcement of rules, you need to use language as clearly as possible. I understand your viewpoint (of CoC as values and not as rules documents) doesn’t take that approach, but for a great many folks a Code of Conduct is taken at face value to be a “Hey, if you do , then happens, so please consider instead.”

Writing clear rules intended to be taken literally that cover all forms of potentially allowed and disallowed behavior is essentially a fools errand. Ultimately there must be some human arbiters of behavior that will have to interpret the intention of the rules, look at the behavior, and decide if a violation occurred. You’re basically talking about a miniature domains-specific legal problem here, and if you look at the complexity of most modern legal systems it’s clear that you can’t really have a clearly written exact set of rules that will apply without human interpretation.

I do agree with your suggestion that having a separate rules and values document can help. In the communities that I help moderate we do exactly that- we have a set of rules that are more specific, and have specific consequences, along with a broader values document that outlines the types of behavior we want to see, and how people should behave. The rules document still requires some level of human judgement.

Secondarily, I’d argue that the great benefit of technology is that it works regardless of the value and belief systems of the folks using it. Both a Marxist and a libertarian can sit down at, say, a numerical methods conference on optimization and expect to find something useful for planning out resource expenditure. Neonazis and Antifa both benefit from a good lightning talk on OPSEC. Both Republican and Democrat workers benefit from sharing knowledge about how to use AWS properly. Using a CoC to try and shoo away folks who have ideological differences runs directly counter to the free exchange of ideas, and serves to limit the utility of those communities by ostracizing others. If we lived in a world where, say, you could point to somebody and say that “This person is a Nazi” with 99.999% accuracy, maybe I’d feel differently–but abuse of terms and the public square by overzealous if well-meaning people (some of whom are even users on this site!) has caused me to severely doubt the reliability of our mechanisms.

This is one set of values, but I think it’s not the only one. There’s a place for venues that are focused on allowing all people regardless of ideology or background, but it’s perfectly reasonable to want to run or participate in other types of communities.

In communities that I moderate, I am unapologetically uninterested in excluding some ideologies. Ultimately, there are some ideologies that simply cannot coexist, and focusing on equalizing them just favors the more aggressive of the ideologies. I’m okay with excluding Nazis, because the alternative is to exclude people who are targeted by Nazis. This is one of the ways a CoC can help signal values- by being explicit about the values of the community it is quite quickly clear on which side of this particular chasm an organizations values fall.

Im ok with a higher false positive rate for ‘Is this person a Nazi’ test if it means fewer false negatives. The beauty of technology is not that it’s value less, but that it’s an expression of human value. Technology is anything people make and which things people make is a huge signal of what they value. While some technology are useful tools regardless of value (i can use the butt of a gun to hammer a nail) we can make a pretty good statement about what that society values based on their technology.

The CoC provisions on offensive speech are usually interpreted broadly benefiting certain groups over others. In other words, it works the opposite of the general rule where these give enforcers lots of leverage over large groups of people. The wiggle room is theirs.

Apart from that concern, which I totally agree with, I also try to stay clear of projects that boast a CoC because it shows me that their priorities lie in politics, rather than in technical matters. It’s a waste of my time to spend any effort on endeavors like that.

It’s my experience that the only people who whine about this are better left excluded, because somehow, white dudes are still abundantly present and everyone has a nice time.

Nearly every CoC I encounter is a variant of or asserts to be inspired by the same geek feminism-based CoC

If you are a geek and not a feminist, what are you? I’m a male, geek, and a feminist.

I’m surprised anyone working in high technology would choose to not be a feminist and prefer to live in the last century. Fortunately I don’t meet many of those people. They seem to only exist on the internet.

If it’s public, I’m curious to hear more words or links about your alternative model for a CoC. What do you see as key differences do you see in problems to be addressed, approach to solving them, enforcement, administration, education, etc.?

There is something wrong with the same type of article being submitted every few weeks with zero new information.

Complaining about Electron is just whinging and nothing more. It would be much more interesting to talk about how Electron could be improved since it’s clearly here to stay.

Did writing C++ become insane in the past few years? All those GUI programs written before HTMLNative5.js still seem to work pretty well, and fast, too.

It’s always been insane, you can tell by the fact that those programs “crashing” is regarded as normal.

In answer to your question, Python and most of the other big scripting languages have bindings for gtk/qt/etc, Java has its own Swing and others, and it’s not uncommon for less mainstream languages (ex. Smalltalk, Racket, Factor) to have their own UI tools.

Shipping a cross-platform native app written in Python with PyQt or similar is a royal pain. Possibly no real technical work would be required to make it as easy as electron, just someone putting in the legwork to connect up all the pieces and make it a one-liner that you put in your build definition. Nevertheless, that legwork hasn’t been done. I would lay money that the situation with Smalltalk/Racket/Factor is the same.

Java Swing has just always looked awful and performed terribly. In principle it ought to be possible to write good native-like apps in Java, but I’ve never seen it happen. Every GUI app I’ve seen in Java came with a splash screen to cover its loading time, even when it was doing something very simple (e.g. Azureus/Vuze).

C++ the language becomes better and better every few years– but the developer tooling around it is still painful.

Maybe that’s just my personal bias against cmake / automake.

I had never in my life been part of a team where I understood less of the code or infrastructure

I had the same exact experience. Watching other people code is not how I learn.

Pair switched 8 times a day??

Madness.

There are others, sure - but as a method of spreading knowledge through a small group , 1:1 tutelage is pretty effective.

I’ve had the experience you’re describing but the issue with “two friends trying to crack a puzzle” is that it actually requires a puzzle for the description to be applicable. For most professional, relatively experienced, developers, even if they are working on very interesting problems in the large, sitting at a keyboard isn’t really puzzle solving time.

If I have some problem that’s conceptually difficult I might talk to a colleague about it, but I don’t need them to spell out the solution or watch me do the same in implementation. Imagining pair programming as joint puzzle solving is a bit like considering a lawyer to spell checking a document for spelling mistakes the same thing as legal advice.

I’d also add that sometimes it is a way to get past a hurdle when you are banging your head against a wall. Not to be done every time, just when you are stuck and need extra input and a sanity check.

In fact, I don’t think I’ve ever met anyone credible who has claimed something so rigid, so I wonder if the OP is engaged in a straw man.

Certainly the following Martin Fowler quote proclaiming that Ep > Es makes my argument not a straw man.

I worked for about 9 months on a team of 8 that paired 100% of the time, I’ve also paired with a few other people here and there for workshops or because someone wanted some help learning something. In general the people that I’ve paired with have spent a lot of time pairing, and I believe that they know how to do it well, I just found it awful.

The end of my 9 month run with the team that paired left me so burned out I seriously considered completely leaving tech and going into academia or something. I’ve given it what I believe is about the best possible chance for me to get on board with it, and I just abjectly loath it.

Edit for clarity: The team of 8 pair-switched between 2 and 8 times per day. There was a run of 1-hour pair switching, but for the most part it was a mandatory morning and after lunch pair switch, along with a pair switch whenever the team transitioned from development to deployment, so I regularly paired with every one else on that team.

My comparison is Erlang vs Elixir, though. Not Elixir vs Ruby. Being less insane than Ruby is not a challenge, but Elixir is still more complicated than Erlang.

It does all this while acting as a strong selling point for new adopters.

This is exactly my point, though. The Erlang syntax is weird and that seems to be enough to dissuade adopters, despite it being quite utilitarian.

It certainly doesn’t seem to be making anything harder to learn.

In a world where Python and Ruby are considered easy, I do not believe this is a powerful statement.

I had the same “always pairing” situation and found it drained my skill and energy to the point that I was barely able to accomplish anything. I’ve recovered… but get out while you can.

My last job had us pairing 7-8 hours per day with a pair switch every every 1-4 hours. There were other issues there as well, but the pairing was enough after 9 months to make me seriously consider leaving software alltogether.

It isn’t really feasible unless your company has huge resources.

Many people have a job already and “normal circumstances” need a ramp-up time. Their performance will be influenced by that. Some developers are not good under stress (some excel under stress!). Some feel like this is an exam situation which a non-trivial part people have an unreasonable fear of. Also, Interviews conducted by untrained engineers tend to be biased towards their knowledge and interests, not the companies.

All this is incredibly hard to set up for small to medium companies, as it needs a dedicated hiring process, someone caring for it and trained interviewers.

I do enjoy having some technical part in an interview situation, but let’s not pretend it comes any close to the performance they will have on the desk later.

The problem, I think, is that it’s very difficult to create a work sample that fits any of the criteria you’ve listed: normal job, normal circumstances, and fairly evaluated.

The normal job criteria fails because every job is going to be a bit different, and in most cases a job is going to involve working with peers in an environment that you’ve had a hand in building and been able to spin up on. Because you’re in an interview situation the people you’re working with are evaluators, not peers, which changes the power dynamic. The environment is also going to be unfamiliar, and you won’t have been in a position where you’ve been able to spin up on the tech or culture being used. For more senior people this may present less of a problem because they should have a large enough breadth of experience and enough adaptability to be able to navigate unfamiliar environments and languages, but for junior and mid-level people and interview-length project (even on the order of a 1-2 week take-home project) isn’t going to be enough time.

The circumstances are also going to be different. The power differential noted above aside, there’s the problem that most people are already working a job when they go looking. The extra hours and severe context switch of going from day-job to interview-project are going to be a pretty significant deviation from the way a person would normally work.

Finally, the fair evaluation. I’m assuming when you say “evaluated” you are meaning some sort of fair and as-objective-as-possible evaluation. This is going to be hard because it’s going to strongly favor candidates who are most like the existing team. Leaving aside personal implicit bias regarding race, gender, age, etc. and assuming we’re talking about a black-box project, because of the factors above related to the timeframe, availability of peers, lack of contextual background, etc. you’re going to be strongly bias toward people who are already working in environments like yours, and with your technology stack. This can be a good thing if you need to scale up your team quickly, but at a rather severe cost to diversity of experience with different tech stacks, languages, backgrounds, etc. In the long-term you’ll be hobbling your team’s effectiveness by tending toward a monoculture of people who passed the interview thanks to a predisposition to thinking the way your team already things.

It’s also pretty reasonable to expect a 3-6 month “settling in” period for development work. You might know $TECHSTACK cold, but you don’t know our implementation at all, our idiom, and our quirks. Just chucking a real-ish problem at someone and expecting them to solve it probably isn’t going to be a good sample.

Honestly, the best approach is to do a few short interviews to establish: 1) they’re not a con artist, 2) they’re not a lunatic, then bring them on as contract-to-hire to see if they work out.

I happen to prefer ML to Haskell, and agree that the importance of category theory in everyday programming has been oversold. However, to be fair, there are some virtues to thinking denotationally (monads) rather than operationally (continuations). For example, the virtues of call-by-push-value, were immediately clear to me when I saw its categorical semantics: An adjunction between the categories of value and computation types, where the former admits nice universal constructions (direct sums, tensor products) and the latter admits nice couniversal constructions (direct products). The adjunction itself gives you function types. Considering just the category of value types (and the monad on it) gives you (a denotational semantics for) call-by-value. Dually, considering just the category of computation types (and the comonad on it) gives you (a denotational semantics for) call-by-name. I have no idea how I would have even begun to understand this from a purely operational point of view.

I’m not referring to category theory per-se, although the sort of category-ish language is part of it, along with the type theory. More than those specific things though I’m really referring to the general approach to thinking and communicating, and the sort of math-adjacent pseudo-formalism that the Haskell community is really fond of, and the mathematical leaning theoretical cs that people often run across in papers that still form most of the documentation for some libraries.

For me personally, the language used around Haskell motivated me to study the mathematics, and in turn to realize that a lot of the things in Haskell are named by analogy to those concepts than strict formal adherence to them. The useful bit I think came from the way of thinking I started to develop and how I got a better intuition about going between math and code. Still, I don’t think making that leap is necessary to use the language and is turning a lot of people away.

I think that there is a mode of thinking that’s more of an analogy to category theory than actually being category theory, and it can be helpful in providing a mental framework for gaining an intuition of certain types of abstractions. Beyond that I agree its usefulness has been overstated.

That said, I think there are a lot of benefits to thinking of api design algebraicly and Haskell has done a lot to facilitate that.

I think the 99% figure might be underestimating the importance of category.theory, though maybe not by much- but in my own experience it’s always served more as a framework for brainstorming and I move on to other techniques to actually get stuff done.

Yeah, Haskegorical theory is a thing of its own. I learned category theory too in math school, but the real interesting applications for me were completely different from Haskell’s, like the Galois functor or homological algebra. I seldom see familiar stuff like universal mapping properties or snake lemmas in Haskegorical theory.

I’m actually in the early stages of writing a book about this; I’ll try to distill my thoughts down to something makes a little more sense here. For a bit of perspective, the languages I’ve worked with most in my career are: C, Haskell, and Ruby. Much of my thinking has evolved out of comparing the general approaches that I’ve used in those three languages, and trying to generalize them to the wider practice of programming.

To start at a very high level, I think of the Curry-Howard Isomorphism, which basically says that a type signature for a program is a formula that is proved by it’s implementation. In that sense, when we’re working with a strongly typed language, our entire program is a composition of many tiny proofs that we develop with the help of our theorem prover (in our case, the type checker). If take a category theoretical approach to program analysis we can see that each of these proofs can have several different implementations that may or may not be equivalent for our purposes. For example (*) and (+) both prove (Int -> Int -> Int) but we can’t use them interchangeably in our application.

When we start looking at developing applications this way, it leads us to consider an approach where we start with some set of formulae that we want to implement as programs, which are themselves pure functions. Our tests then are acting much more like function-level acceptance tests than unit tests, and our focus is not on the proof of our formula but rather on demonstrating that we have selected the correct morphism.

Moving back into the “Not about preventing errors” part of this though, taking a category-theoretical approach to software design also means that, beyond the area of proofs for our applications, we have an entirely new toolbox to use when we’re thinking about how we design our applications. I typically use the language of algebra instead of category theory because it’s often sufficient and less intimidating. If we start to look at our application as a type level formula then the process of proving it with our program becomes one of defining an algebraic structure that’s appropriate for our data domain, and then building up the set of morphisms we have over the objects in that structure, and finally using the algebra we’ve defined to prove our formula.

I believe that the benefits of this approach extend beyond making our code less error prone, and improve the overall quality of our code under refactoring, the addition of new features, or changes to requirements. While traditional approaches to unit testing will give you the confidence to make changes without introducing regressions, the type-driving algebraic approach gives you a coherent language to work with and I think makes it much easier to write applications that are structured such that they facilitate modularity and refactoring. When you’re building an algebra it’s difficult NOT to build small orthogonal components that can be composed into different programs as your business requirements grow and change.