We started using Swift on new projects. I don't hate it per-se, but as with most new languages like Rust, or Kotlin, they have some neat, modern ideas, but mostly they help solving none of the problems you have on a day-to-day basis, and instead make common coding tasks harder.
Using Swift feels like i'm back in college writing C++ code while following all the newest design patterns, and best practices, thinking about whether i should make two classes friends or not, instead of solving actual problems.
Articles by fedora-tipping allies gracing us with their superior moral values while providing biting commentary on current pop-culture events is exactly why i visit Hacker News.
It’s sexual assault, not rape, and „1 in 5” studies like these have consistently failed to stand up to scrutiny, mainly due to unclear definition of what constitutes sexual assault. This whole article was written from the perspective of an „ally”, so it’s hardly a surprise to see things like that cited.
I'd ask what constitutes "same level", and what's the overtime gap between genders, if there is one, but why do that when we can have a good ol' laugh at how Google made their own bed, and now we can watch them use the same "it's more complicated than that" arguments used by people who Google think are "propagating sexist stereotypes".
Immediate mode is simply a way of designing your API so that there's no creation, destruction, callbacks, etc. It's a convenience to the programmer, because they can explicitly express what they want to happen at a given moment, and the application state is known at any given time. It's a general concept that can be applied to any code you write, and it most certainly doesn't forbid you from keeping track of dirty regions between frames, that would be ridiculous.
The rate at which you have to update, and what you have to update doesn't change between retained and immediate mode. The only difference is that, with retained mode, the library you're using has, by design, all the knowledge it needs, so it can manage all of that for you. The whole point of using immediate mode is to get rid of this black box from your program, so that you can explicitly state what you want to happen, when, and in what order. It's only "a ton of code" if you write everything from scratch, so i fail to see how that's an argument.
I'd be interested in learning more about how a blind person does software development. I already do most of my coding work in the terminal with keyboard only where possible, and it'd be an interesting exercise to try and get rid of the monitor altogether.
It's worrying how sometimes the most basic programming concepts can appear revolutionary to web developers. So much so, they've recently stumbled across the concept of a read input-update-render loop, and are now trying, with frameworks like React, to contort the DOM tree, just to get back to how UI was programmed since decades.
There's a fairly old concept called "immediate mode UI", which even gets rid of the tree structure, and keeps the whole state on the user side, giving you full control over when elements are updated and where they are placed. These days it's used mostly in video games, since they already rely on a 60 FPS loop, and the UI complexity tends to be low.
If not for the necessity to use standard platform form elements due to their various quirks and interactions with the system, I'd be doing UI programming only in immediate mode with custom controls, simply because how convenient, and simple it is.
An interesting read. Though, for me, VC in general is not the kind of job that favors people who are nice. When people are rude to you, or try to use you, there's a multitude of ways you can interpret that. For Ellen, it's sexism. What baffled me was that in the opening paragraphs she felt the need to point out that the powerful men were white. For me, it set the tone for the whole article, and painted a clear picture of her attitude towards the case and people involved. Given the current political climate in SV, it's a poor attempt at manipulation, and doesn't help her come off as reasonable.
Xamarin is given as an example of a better alternative why exactly? You develop a single layout in React Native, while in Xamarin you just share the C# code, so separate platforms need separate UI code (unless you want to rely on their weak Xamarin.Forms API), and at that point you can just write common code in C or C++ and not rely on any third party. It's hardly comparable.
All i got from the memo, besides the echo chamber part, which google, and others managed to prove almost immediately, was that the author thinks there are biological differences between men and women, which lead to women being less interested in the field, thus being under-represented, and that google's sexist practices won't change that, only make people resent the diversity hires.
Was i reading the wrong memo? Because everybody, including the 3 interviewees, no matter if they seem calm and collected, keep attributing malice, and talking about how the author said women are less suited to being good engineers, and that women shouldn't be encouraged to get interested in STEM. Where was that stated?
Not getting into "guilty until proven innocent"; all this is going to accomplish is attach a huge risk factor to women who are seeking investors making their life harder than it already is. Hell is paved with good intentions.
Yes, it does afford you healthcare the way US works right now, if it doesn't, that's a failing of Obamacare. Also, you want to be able to afford a car and a home by working at McDonald's? What are you talking about? And your solution is to not even have people work, just be given money. That's borderline insane. What cozy life do you have to be living to think that you're entitled to these things.
>Everyone working 40 hours per week deserves a living wage (...)
You can earn a living wage for 40 hours a week doing anything in the US. You just can't afford a new iPhone. All the minimum wage does is makes it impossible to employ low-skill workers. So while before the minimum wage you could make a living, now you either can't make a living or you're effectively in the lower middle class.
Ask your dad or granddad what they had to go through to get you to a position where you think 15$ an hour is merely a "living wage".
I'd say this is an Orwellian statement, but at this point i got so used to Twitter silencing voices they disagree with i'm shocked they didn't just ban Trump long ago, since they banned people for pettier reasons multiple times.
Hillary got more support on Twitter than Trump. The reason places like Twitter helped Trump in any signifficant fashion was that they let Trump reach people directly, and not through the media which are still lying, and slandering the president, and trying to paint a false picture of what's going on in the country.
It's just Java with a few Swift features. The only thing Kotlin does is help you to be more efficient at writing terrible OO code.
This is even less of a reason to to be excited than when C++ came out, and solved none of the issues C had, just introduced a weak inheritance system, and search-and-replace level of meta-programming.
This post is an example of armchair programming, so your armchair experience is more than enough.
On a more serious note, it's software architecture done on paper. Any experienced programmer will tell you it's close to worthless. You don't have to be a graphics expert. Abstraction of passes and pipelines isn't anything new, it even bled into the modern APIs like Vulkan. This post is just some inexperienced programmer's vague description of how he or she would like things to work in theory. It's not worth a discussion.
Languages like Java and JavaScript don't let you lay data out in memory directly, nor do they give you much on control over how memory is accessed, so any performance benchmark involving C is entirely superficial.
I can write 2 programs in C, both which iterate over some amount of elements and perform the same calculations on the same amount of data, and have one take 500ms and the other take 8s. It's all a matter of how you lay things out in memory.
It's not that people aren't willing to put in the effort to optimize games for Linux, it's the reality of graphics drivers being effectively a massive collection of bugs and special cases for specific titles or common programmer errors. If you have a direct line to the manufacturers like Valve does, you can ask for bugs to be fixed, for specific optimizations, or even for engineers to fly over and tune your shaders. For regular developers, you're happy if your game just works.
I remember Valve articles from that period when the Windows 8 Store was being introduced, and Valve started pushing Linux. I remember reading a similar article from them on the subject, but that one mentioned DirectX 9 Source Engine on Windows performance versus OpenGL 3 on Linux, which is a shady comparison to say the least. Just mentioning it, since such details got curiously ommited in the referenced article.
If Rust solves the kinds of problems you have, then by all means use it. I don't think there exists a language that's in all aspects better than any other. For me personally, C is the language that gets in my way the least without forcing me to write ASM, and that happens to be highest on my list. If there was a language with the same idea of minimalism behind it as C, but with all the quirks and bad syntax choices out, i'd switch in a heartbeat.
I agree that having to remember is a problem, it's one of the many shortcomings of C that it doesn't let you differentiate between types at compile time.
Pointing into subsections works fine. You just have to create a type for it. This solution doesn't have the same problems as strings because you don't rely on a terminating entry, and it's what languages like Rust or Java do as well.
You can allocate dynamic arrays on the stack in C just fine with alloca(). The only performance cost is when checking bounds, but since it's a dynamic array, it's the same cost you'd pay in Rust.
No, you just allocate enough space to store an extra int at the start for the length, and return a typed pointer to the actual data. Then you need an accessor that checks bounds, if you want safe access. Both of these problems are solved by simple macros.
Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up when trying to work with memory in Rust.