jackcviers3

Not to mention not researching your problem space seems to be an afterthought for these types of people. It's not a novel problem or solution.

Haxe already exists [1] to unify everything, similar to beads' claims. It doesn't.

Unifying has been done better before with it, C (it does run almost everywhere!), Java, Flash/Flex, and JS+HTML. Many have entered. Few win for a little while, and eventually everything loses.

1. https://haxe.org/

Also, the organization is ceding control to an other when they don't use their own stuff. That doesn't sit well when the needs of the other gets in the way of profits.

This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale.

In the initial meetings where you talk about making new component libraries, someone who worked on the old one says, "We reinvented the wheel last time, then standards changed, and we couldn't keep up. We need to take current standards into account before doing anything new, including accessibility."

And the new boss says, "That's a good call-out, but accessibility isn't a problem if nobody can even load the component list and scroll to the thing they want, and with the current ux and stats, we're getting close to using most of the available memory on devices just to scroll our content. We don't want to change the content we can scroll, we just want to make scrolling more efficient. Everyone agrees the current design is at its limits. We need to start over at the beginning. Accessibility is step 3. We're at step 0. Let's focus and move forward." And while they are right, they need to demo an map to an abled-person boss, so accessibility gets pushed farther back as technical things take priority.

Often, this leads to teams over time producing lots of things without accessibility, and you build new things from old things, and it just snowballs.

Suddenly a user appears, and they aren't served, and now a whole new bunch of juniors are scrambling to add accessibility to old things without breaking current usage.

So, like nice[1], except the developer sets the level of importance ahead of time? Makes sense, as long as I can reprioritize if needed.

1. https://en.wikipedia.org/wiki/Nice_(Unix)

I think it will be abstracted kubernetes - something a little like ec2, but where the cpu, memory, and disk are multi-tenant, overprovisioned, and your code and aps run on the os provided, but are suspended during non use and unsuspended by the supervisor service on demand. Common architectures are available (elk, ssh/scp, tls load balancer with lamp/tomcat-postgres/etc.) Out of the box with automating, overprovisioned, multi tenant bandwidth, storage, etc.

Virtual private servers, but suspended/resumed/scaled for you without you needing to worry about the underlying method of deployment. AWS lambda + aurora but running actual operating systems. You want more threads or memory - they're there for you. Every user process is metered and monitored. Charged by cpuops + memoryops + iops + hdstorage bytes by the second. You never need to worry about how much disk you need, it's there, unlimited except by your pocket book. You never need to worry about how much compute you need - it's there, unlimited by your pocketbook. You never need to worry about how much memory you need. Backups of your drives are automatic.

All data is encrypted to allow it to live amongst all the other tenants' data. All wire traffic is encrypted.

It works exactly like ec2, except it's on-demand usage and overprovisioned and multi-tenant. Alarms and user-set limits for price and scale are respected. The only thing that will leak about the abstraction is that you'll have to mark processes as suspendable and dependent. You don't need to run your metrics collector if your app isn't running. Cron jobs should wake up the server, etc. Ssh/scp just works. You get service discovery out of the box, and your point of entry is the app lb dashboard. A real, on-demand, virtual private cloud.

Yes. You should know one layer of abstraction below the one you are using. Always. Because everything leaks, and eventually you have to fix it.

6 and 2 on hard mode. The failure of the model to connect ideas in long paragraphs (or to make a succinct claim) is what gives it away. It introduces far too many terms with far too little repetition and far too much specificity in such a short span.

Suggested tweak - train it against papers written by people with an Erdos number < 3 (or Feynman contributors, etc.), so that the topics and fake topics are more closely related in style and content. Maybe even feed it some of their professional letters as well. That would produce some very hard to decipher fakes.

Another great corpus for complex writing is public law books. Have it compare real laws from the training set with fake laws. I bet it would be very difficult to figure out the fake laws.

Training one of these on an entire corpus of one author (Roger Ebert, Justice Ginsberg, Joyce, anyone with a large enough body of work), and having people spot the fake paragraphs from the real ones would be very, very difficult. An entire text, however, would likely be discernible.

It is getting really, really close to being able to fool any layman, though. Impressive work!

The major problem I have with electron apps is that they eat memory for breakfast, lunch, and dinner.

This happens with jvm applications as well, but you can limit the max heap size and force the garbage collector to work more, trading off speed for the ability to run more apps side by side.

AFAIK, you can't limit the memory used in electron apps, and they don't respond by sharing heap with their child processes. With enough extensions to make it usable, vscode easily eats GB of memory.

I like lsp. But I don't need vscode to do the rendering.

Maybe we should make electron more efficient?

But they are a good thing, from a type perspective, they encode the idea that a side-effect is going to happen at the type level, and then force you as the caller to handle that fact or pass the buck to your caller.

Effect types are a signal for all programmers that "Here be dragons". They outline parts of your code which may not be safe to reorder during refactoring. And they can cover so much more than just asynchronous I/O. [1]

1. https://en.wikipedia.org/wiki/Effect_system

We ran a DoubleClick ad engine on the Clear Channel websites right around that time period. The front-end was a Java Web Start application, ugly, slow, but very intuitive to use for ad-targeting. I wrote several extensions for it using their plugin-api and the ad engine worked really, really well. Had several calls with the DART team and they were all smart people delivering a necessary service to keep websites free to use. Hard to believe that something so simple and useful could become the tool for evil that it has.

I don't know if this is so surprising. It took a little longer, but Google is basically becoming what Yahoo! became. A gameified search engine with a decent email and chat client for the era it was dominant within. As their search results get worse, people will migrate somewhere else, (like DDG), and the cycle will continue.

Converting any non boolean type into a boolean is always a lossy compression that will often need to be reversed later. If/else was invented so that you don't need to perform this compression at the variable level.

I also don't like nullable fields in my databases. Anything nullable is representable as some form of coproduct - and can therefore be represented as a relationship to an entity with a property that can be joined to for terms of definition.

All of that works on my System 76 Ubuntu 20.04. The real reason corporations use Windows is so that they can lock down the desktop to prevent users from installing tools without corporate approval. They could do it on Linux as well, but it's more difficult.

Kotlin could he better, but doesn't go all the way. Without HKTs and implicit injection, Java is going to eat its lunch. Java already has records, type inference, parametric null safety with Optional, Loom provides coroutines, vavr and streaming apis have given us theabilitytodo FP... what's left as a unique feature?

Kotlin will survive because it was picked for Android to avoid copyright issues. But the difference between the two languages is vanishing small.

It was used in Killer Game Programming in Java by Andrew Davidson published in 1995. That used a Webcam and a color coded bracelet you made yourself as an input device for one of the code examples. Microsoft had Surface touchscreen 2.0 pre 2011 that tracked real world objects [1].

1. https://youtu.be/57k2iJbotV4

Dynamicland feels to me like The Mother of all Demos. Ahead of its time, groundbreaking practical applications of interactivity research.

Dozens of companies and projects will spring from this. Just give it time.

We'll be back to using real objects instead of keyboards at some point in the near-future. Brett's right that a lot of the difficulty in actually using computers to produce things is in the translation of human interactions into a medium the computer can understand, and translating the data a computer outputs into a medium humans understand. We aren't two-dimensional creatures. The state of the art cannot remain in pictures and text forever.

I'm not sold that everything will be done this way - some things will always need the precision of automated, textual input (see tool assisted speed runs in video-gaming if you think human beings can match pre-programmed precision inputs).

I had a Linux IdeaPad p400 for like 12 years with Ubuntu. 0 issues. I now have a system 76 gazelle. No problems.

Ubuntu 20.04 is really easy to use.

I can't stand the mbp. Hoops to jump through for everything with a cli. Extra permissions to make build tools work. Extra additions to file permissions that are incompatible with docker. Special gui with extra settings to make docker work. vpns that have to run inside the top bar and freeze up with no way to get them to shut down. Weirdness with .net core compilations. User admin only with a gui. Difficulty finding files because the finder window doesn't follow path. Extra steps to launch apps from the cli. Weird ppi so text settings that are legible everywhere else aren't in Mac. Slow keyboard repeat rates that are hard to change.

That's how it is successful. HN said my post was too long, but here's my rebuttal to the op and it pretty much goes along with what you said: https://gist.github.com/jackcviers/a7e74a3ad0a57f6ab97afd25c...

If you are in the databricks Spark ecosystem -- stick to using the Databricks style and Spark libraries. Don't bring in anything that isn't in that ecosystem, because it runs way behind standard scala -- it's on a 6 year old version at this point.

If you don't want java to eat the features you use, use either the typelevel ecosystem or the ZIO scala ecosystem of libraries, use their respective preferred built-in DI methods (tagless final and ZIO environments, respectively).

If you don't mind eventually having java eat your features, go ahead and use the Lightbend ecosystem and buy the support license. If you don't want to buy support, the twitter/finagle ecosystem is basically the same without a support possibility. But within those there's definitely room for creative license.

All in all, the functional and typelevel subset works best as it's a tiny footprint of features and libraries, it doesn't leave any gray area for personal expression, and treats the language as its own language rather than clone - you - a - c++ - java - javascript - ruby.

Would I rather everything move to Mill? Yes. Is that ever going to happen, nope.

Vimium for gui in two secs: f - show keys to press to click something and open the link in the current window F - same except opens in a new window /<chars> <enter> - search, n for next and p for previous V - visual cursor selection, y copies esc - get out of anything

There's a lot more, but you can go a long way just with that.

This is so backwards. If they want electric cars to dominate, they need interchangeable, standardized batteries that can be swapped out by machines at gas stations just like stopping for gas. You'll never have batteries that charge quickly enough for a cross-country trip and have range.

Just switched to a Gazelle from an old IdeaPad p400 touch. Full keyboard, beautiful screen, removable battery, extensive power management options, large trackpad, multiple color adjustable brightness back-lit keyboard so I can change it to red to avoid hurting my eyes, a real gpu, and powerful as all heck. I love it.

Rainbow delimiters mode kind of does this, but doesn't maintain the scope color of referenced variables.

As long as the list of symbols is small then yes, because the symbols are a subset of the entire character list. I imagine some implementations basex encode the bytestring first then indicate the original and basex encoding instead of sending the symbol list.

Yes, that is what I was asserting. I chose Spinks because he defeated Ali in a split decision in the biggest upset of the sport. However, their overall careers were so different. Ali is considered to be the greatest of all time by many.

When Spinks beat Ali, he was the quickest to win the title in history. He also was the only man to take a title from Ali. He was younger, faster, in better shape and had a longer reach than Ali.

However, despite the physical attributes favoring Spinks in every way, and the previous victory, in the rematch Spinks was completely destroyed by Ali, who trained hard for the fight this time.

These two are perfect examples of elite athletes with excellent physical similarities that put their careers on similar trajectories when you compare their early careers. However, Ali's mental talents and training skill so far surpassed Spinks that Ali only lost 5 times and won the title 3 times, while Spinks lost 17 and only held the title once.

Physical prowess matters, but not as much as training at the elite level.

Or, programming is simply easier than painting or boxing, and boring and tedious for most people.

Physical and psychological traits matter when you undertake certain tasks - how many fast twitch muscle fibers you have, how big and string your lu game and heart is, the angle of your jaw in relation to your brainstem, the distribution of your weight on your body, your personal nerve conduction velocity, your natural aggressiveness and your pain tolerance levels for boxing.

Your natural intelligence, hand-eye coordination, tolerance for failure, and curiosity level for learning programming.

Your hand-eye coordination, imagination, and depth of color vision for painting.

The thing is, while everyone starts with more or less of some physical or mental fitness for a particular task, with enough proper training the difference between two trained professionals is very, very small. Yet o e is Mohammed Ali, and one is Leon Spinks. That difference is not in proportion to the difference in their physical or mental capabilities at the start, and is largely explained in studies by coaching and practice technique.

The ability to follow a trainings regime until you reach success is largely a mental tolerance for failure and determination. If you have lots of success, you tend to continue. But if you were to continue despite failure, you would eventually reach the success you were after if the training regime was correct.

No. I'm suggesting that as part of a 2 decades long development process at a multi-billion dollar company that is science based, there should be enough documentation for someone to pick this up and run with it.

What everyone else seems to be saying is that Covid-19 has a bus factor of like 5 or 6 people, who if they died,would lead to any breakdown in the process becoming an irrecoverable incident.

That single point of favor needs to be distributed, not just for production capacity, but for the future safety of the human race.

Call me skeptical. I think it's much more likely that this falls under trade secrets.

Can't you do this with expectations of failure, especially if your functions under test aren't total functions?

I really like encoding failure types into the type signature of my code (assuming types).

    defa(x: str) -> Union[str, AnErrorType]:

That way, it is clear that your code may fail, and so you must test the unhappy path as well. Limits the places you might be able to throw and read/write input, and requires an effect type, but keeping functions total allows for fewer bugs and fewer places to test horrible things happening.

If you document the design and process, somebody else can copy it.

Yeah, mine is like 500 lines with use-package and lsp-mode. And it works on Mac osx, windows, and Linux, works with Java, scala, typescript/Javascript, python, yaml,c#, xml, html, haskell, ruby, c, and c++. Haven't done any Android or ios work, but I'm sure it would work with that as well.