rkido
That's why Nihon-shiki is and will likely always remain the best system for serious students of Japanese - if you even need it at all. But then again, if you're just starting out, the best place to start is usually to immediately start learning kana.
That said, buying certain games can lock you into using Windows. So there's that. But it's far better than buying games on modern consoles, which force you to use some special-snowflake hardware just to access the game you bought.
It's impossible to completely prevent all classes of lock-in, but it can be minimized. I would argue that my personal lock-in is minimized, across the axes I care about, by buying everything from Steam and GOG. No hard Windows dependency, no silly hardware dependency, and I'll almost certainly still have access to my games in 40 years.
Valve uses its 30% cut extremely effectively by continuing to invest in the happiness and convenience of its customers and, just as importantly, its developers. For instance the profits of smaller developers dramatically increased after the new discovery/search features landed, enabling exactly the kind of people who would love your game to find it easily. Contrast that with every other store where it's basically impossible to find anything but the most mainstream top sellers.
Maybe Epic could afford to actually make the Epic Games Store a useful product if they took a higher cut of sales?
As Steve explained in the video, the Steam Deck's input-to-photon latency is lower than the Aya Neo's simply because it has a much more powerful GPU.
The only real way to test if there's any extra input-to-photon latency would be to compare the exact same game on a Steam Deck running SteamOS to a Steam Deck running Windows.
The only one I can think of off the top of my head is HDR support, but that wouldn't affect these benchmark results.
You can try to prevent it with project structure, but even something really unified like FreeBSD ended up having derivatives like GhostBSD as well as full-blown divergent forks like DragonFly BSD that are not necessarily compatible anymore with upstream.
As for Valve hardware, the only clear flop was Steam Machines -- which weren't Valve hardware at all.
I think it's odd to focus purely on the mass market success of Valve's actual hardware (Link, Controller, Index) since these can all be considered experiments by a company that can afford to fail, and since these have all been widely praised as the best-in-category. Clearly they know how to make great hardware; they just haven't done anything mass market yet. Who knows, maybe the disappointment with Nintendo will fuel sales for the Steam Deck.
Steam Deck at least stands a chance, although I'm worried about the weight and the battery life.
What?
> Which language should be used in a CS1? There isn’t very much research to suggest conclusively what makes the biggest difference in a classroom, and it doesn’t seem like the language debate will ever end.
But now you're saying there's a massive amount of research for Java and Python — so I think we must be talking about two different things.
> I'm not clear that that's more than a theory.
It is less than a theory — it's my opinion based on my experience going through the edX How to Code series (closely based on HtDP and the design recipes). For example, sum types are taught as "Enumerations" [0], and the design recipe for enumerations looks suspiciously like "pattern matching in a language without pattern matching", as if to prime the student for a language that supports this more conveniently.
Yet, if the student learns Java immediately after HtDP, they will have no use for this knowledge (and probably forget it), as it seems you need some convoluted boilerplate like the visitor pattern to emulate a sum type [1].
> Even if it's true, is that necessarily the major goal in CS1? Perhaps, but you'll have to convince a few of my colleagues of that.
Given that the follow-up material to HtDP was called "How to Design Classes" and used Java [2], no I don't think this is a goal of (PbD's) CS1. I'm saying I think it should be to make the curriculum cohesive, and that HtDP is a wasted investment of the student's patience without related follow-up material. I really loved HtDP so I wish I could find such material.
[0]: https://htdp.org/2019-02-24/part_one.html#%28part._sec~3aenu...
[1]: https://stackoverflow.com/questions/48143268/java-tagged-uni...
[2]: https://programbydesign.org/materials (You can see it mentioned but it doesn't seem to exist anymore when you follow the links)
The design recipes give you an excellent foundation for transitioning to a statically-typed programming language with algebraic datatypes. If students are just going to learn Java or Python immediately afterwards, I think it's a waste.
It does have serious limitations though. Many times I have needed to tell clients: "you can't do that because it's not (yet?) supported in Webflow". For example, you can't have "lists of lists" (i.e. nested maps or loops in JavaScript), which makes a huge number of designs virtually impossible. There are also random CSS properties, like vertical text alignment, missing from the Webflow interface, requiring custom coding, and they have arbitrary maximum file sizes for a number of assets. With Webflow, you either stay within their limitations, or you have to do a lot of things in custom code embeds.
Despite this, I've found that, even with Webflow's brutal price structures, working around those limitations in order to stay on Webflow's infrastructure has generally been worth the pain compared to spending a whole lot more time/money on doing things by hand, especially because my clients have a tendency to completely change their mind several times during the process. I'm not yet aware of anything with a shorter iteration time — there's CodePen, but its hosting features are even more limited than Webflow's...
This is misinformation. SBIR funding is the #1 source of early-stage funding for certain industries. Any startup developing a life-saving medicine or medical device is using SBIR for things like clinical trials. "The preferred vendor has already been chosen" is utter nonsense; it's like saying the government has already decided which drug is going to work.
To be effective at applying for SBIR grants you do need a good program officer. They will let you know whether it's worth spending the time to apply.
Aside from that, there are entire industries that VCs don't touch until after SBIR, such as life sciences startups, where you're looking at 10 years of R&D and regulatory approval processes before you can launch on the market. That's way too long for VCs.
I empathize with your general sentiment, but non-profits and governments exist to fill in gaps that the free market cannot.
Free software is not about licenses; they're a very limited means to an end. If we didn't have copyright, some other means would be needed.
For freedom to spread, free software has to become faster, prettier, more convenient, and more intuitive than proprietary software. I would go further than this and say that the distinction between developers and users has to become fuzzier, so that anyone can edit software without needing to be a "developer".
Sadly, developers love their arcane tools because it makes them feel elite. And the FSF / GNU project participates in this elitism by continuing to promote such arcane tools. Software like GNU Emacs only meets the absolute bare minimum of "free software"; it empowers hackers but it doesn't empower the general public.
The next movement, whatever it will be called, needs to embrace open source licensing, and open process, and end user empowerment.
Why does modern web development have to be so convoluted? Here is a wishlist of what I want from ONE language:
- A package manager like nix so that each project folder doesn't have to be hundreds of megabytes
- Static typing with minimally expressive (i.e. ADTs) type system, type inference
- Built in immutable data by default, so you don't have to pile on 3 different immutable data libraries
- A better alternative to HTML+CSS like Elm UI [0]
- One very high quality backend framework (exactly like Phoenix)
- One very high quality frontend framework like Elm but with better component reusability, that makes fewer allocations, and that compiles to efficient WASM
The benefits of a "one language to rule them all approach" should be extremely obvious to JavaScript developers who are following this approach with Node.js, React, etc. This huge mess of tools that they use now is a hairball of workarounds for JavaScript's many deficiencies. We essentially just need a better JavaScript.
It normally isn't just 0.1% of sales when developers do get everything right, although whether or not the usual 1-5% of sales is worth it depends on the particular game, budget, and sales numbers. Linux support clearly wasn't worth it for Planetary Annihilation due to its low sales numbers, but a game with (1) high sales and (2) easy porting process would be leaving money on the table not to support Linux.
> He points out that a very large percentage of the crashes were graphics driver related
This was still largely related to the Coherent UI middleware and the strange way it was being used, as other posts have noted.
They selected a middleware, Coherent UI, that didn't work properly on anything but Windows. They also didn't make proper use of the Steam runtime, a mistake that continues to cause issues. Most games don't make these mistakes, so this isn't really representative of the larger state of Linux gaming.
It's worth pointing out that the devs did make a legitimately good attempt at making Linux/Mac support first class, by making a purely OpenGL engine for the game. But it seems they weren't aware of some other best practices.
What it's sorely missing right now is higher quality documentation output. Currently, it's hard to navigate the generated documentation (e.g., no search bar), it's not held in a centralized online location, and it doesn't do a great job dealing with complex module/functor hierarchies (especially in the presence of destructive substitution).
Unfortunately, much of what I described above doesn't come out of the box. To fix this, the OCaml community is seeking to emulate Rust's cargo tool via the development of the ocaml-platform: http://ocamllabs.io/doc/platform.html
An aside: I didn't know Java had good tooling. I know it recently gained a good REPL. But what is the official package manager, and where is the centralized repository for packages?
OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic.
Also, I like OCaml's extremely simple and direct syntax. I'm fine with F#'s implicit `in`, though it requires whitespace-sensitivity. I think ReasonML went in the wrong direction, cluttering it up with curly braces and ubiquitous tuple-like syntax for function arguments.
OCaml actually has excellent tooling — among the best — and some (but not many) great libraries. What it lacks most is great documentation...