- 0 Posts
- 80 Comments
From the article:
A quick Microsoft demo video shows the Copilot key in between the cluster of arrow keys and the right Alt button, a place where many keyboards usually put a menu button, a right Ctrl key, another Windows key, or something similar. The exact positioning, and the key being replaced, may vary depending on the size and layout of the keyboard.
I would start by learning rust at a user level via the rust book to get you familiar with the language without the extra layers that embedded systems tend to add on top of things. Keep in mind that the embedded space in rust is still maturing, though it is maturing quite quickly. However one of the biggest limitations ATM is the amount of architectures available - if you need to target one not supported then you cannot use rust ATM (though there is quite a few different projects bringing in support for more architectures).
If you only need to use architectures that rust supports than once you have the basics of rust down take a look at the embedded book, the Discovery book and the Embedonomicon. Then there are various crates for different boards such as ruduino for the arduino uno, or the rp-pico for the raspberry pi pico, or various other crates for specific boards. There are also higher and lower level crates for things - like ones specific to a dev board and ones that are specific to a chipset.
Lastly, there are embedded frameworks like Embassy that are helpful for more complex applications.
I’m still forgetting things I learned 3 or even 4 times like how to do a for each loop.
I have been programming for decades now and still have to look up how an if statement works in bash - or other similar things, especially when switching between languages. It takes 5 seconds to look up and remember so I would not bother worrying about it. Far better to know when you need to use an if or for loop and quickly look up the syntax then to know the syntax but not when to use it.
I see tutorials say to make a tic tac toe game or a calculator or to contribute to open source code. Which is good I suppose but all of it feels too advanced and I get lost on how to begin.
Break problems down into simpler problems, then break those down into simpler problems until you have a trivial problem you can solve. Then build up from there. Like take a tic tac toe game - lots of things to consider that can all be dealt with in isolation. Like rendering the game to the screen, that is one problem you can start with, and can be broken down even further to maybe how to draw a grid to the screen, which again can be broken down to how to draw a box or line.
You might even want to look at the book " Think Like a Programmer: An Introduction to Creative Problem Solving by V. Anton Spraul" which goes into this way of thinking in more detail.
Rust, it is a pleasure to work with and far more flexible in where/what it can run then a lot of languages. Good oneverything from embedded systems to running on the web. Only really C and C++ can beat it on that, but those are farlesss pleasant to work with. Even if it is not as mature in some area quite yet, it just gets more support for things as time goes on.
UI for non trivial conflict resolution? Definitely.
I dont know about that… Never found they help that much in conflict resolution. They give you some nice buttons for accept their or accept our changes but really I find more often than not those are what breaks code as you often want a mash-up of both sides - which needs to be manually done even in UIs.
Otherwise it is just find the marked sections in the file, and make it look like what you want it to after the merge/rebase. And that is the hardest part - figuring out what it should look like. Which is made easier if you only ever have small commits and merge back to master frequently minimizing the amount your branches drift from each other.
IMO trying to write everything out in psudo code first is way slower. You are writing things out twice and you are not able to run things quickly. You just have to hope you got things right on the first pass and cannot quickly adjust things when you don’t.
I prefer constant feedback from my editor, compiler and test framework to write things quickly and make sure I am not doing something that is fundamentally flawed. There is nothing worst than writing a whole program without running it only to run it and realise nothing is working how you thought it should.
8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.
This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.
If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.
There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.
And TBH I don’t really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner… Which defeats the whole argument that typing is not the bottleneck? I really don’t follow his logic here.
Apparently, it has to be explicitly stated: Programmer productivity has nothing to do with typing speed.
I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.
My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.
I don’t see how? This is targeting people already using ad blockers. People not already using them should not see any difference in service so why would they change their behaviour? At most a mild rise of awareness, though I bet most people following these news stories are also already running ad blockers. It is all the other aggressive shit they are doing with ads that will turn people towards ad blockers/premium.
Or like that time gitlab found out that none of its 5 backup/replications worked and lost 6 hours of data.
One of my project managers once described scrum as agile with training wheels. Which I think is a good description. It is useful for teams new to agile but once you get going you can start to throw out the parts that you don’t need or that don’t work for your team. But still useful to get you going initially.
A new diffraction-gated real-time ultra-speed mapping technology threatens to undercut cameras costing $100,000 with off-the-shelf parts.
The threatens to undercut part. Rather than talking about how it is going to make things more affordable, it talks about how it is going to ruin the exiting markets pricing. At least that is how that reads to me. Note, I am not talking about the whole article - just that one abstract, which is what is shown here and leads a completely different tone to how the article is actually worded.
then sticking with the coding guidelines of the whole project is more important for maintainability
This can also be a sticky point. When they make sense sure, but sticking to them no matter what can cause more problems. Far too often I have seen some people try to stick with they style/way something was written before because they want to respect the code that was there before or don’t understand why it was done that way. Only to squeeze their solution into it in an awkward way and bend over backwards to get it working right. But if they were to ask the original developer why it was done that way the answer is often just could not think of a better way at the time or I cannot remember any more or seemed like a good idea at the time, but it has not aged well.
Large projects are often layers of changes layered on other changes in additive ways that eventually lead to some very weird and convoluted structures. In those situations I do actually find undoing the layers of abstraction and just inlining all the function calls lets you make some massive simplifications and lets you better see new more robust abstractions you can then apply - things that would never be obvious from the original overly abstract code.
It is worth asking other devs though. Occasionally there is a legitimate reason for some jank in the code that cannot be gotten rid of some external reasons (ideally if you find these you should add a comment to explain this though).
That being said, the code on the right is easier to maintain
That depends if you guessed how it is going to change correctly. All too often you don’t and some weird requirement comes in that your abstraction does not account for and makes the whole thing really awkward. Which tends to lead to spaghetti abstractions that are just as bad to maintain as spaghetti code.
For the context of the code he has given the code on the left is easier to maintain. At least at the start. Once it becomes more complex and more requirements are added and start to make it less maintainable that is the point abstractions should be added. Linear code is far easier to find and add abstractions to that already highly abstracted code.
The problem most of these examples and counter examples make is only showing simple code and assuming that you always want to apply the patterns of abstracting things or not. In both cases the code becomes a mess over time as too many abstractions are equally as bad as not enough abstractions. And where those lines are depends on the code you have in front of you. There are no good rules out there ATM for all cases. Just some that sometimes work, and others that work in different situations. Better to learn all of them and when they are most useful to apply. And don’t be afraid to rip out some bad abstraction (that may have once made sense).
Personally I would do something in the middle of both those solutions. Why is the oven preheat not a method on the oven object? Makes the overall method simpler and still linear. No need to abstract every part of the function into methods, but some do many good candidates for that.
So? It is basically always as efficient as resistive heating at its worst, and the vast majority of the time it is massively more efficient. And even then they can remain more efficient even as low as -25C and might need resistive heating backup at places that get below that. But even in places that can dip below that they are often not that cold all year round. So overall throughout the year they are way more efficient on the majority of days even if you need a less efficient backup system.
We really need to think of the whole situation rather than just focus on the but sometimes part of the problem. Yes, sometimes they dont work as well. But overall through a year for the vast majority of places a heat pump can be all you need and is a lot more efficient than other heating systems.
Heat pumps dont replace gas ovens. They replace central heating systems. They are not that much more complex then a central heating system and come with a lot fewer safety concerns. And heat pumps are not new technology - they are just AC units that can run in reverse to heat instead of cool. We already know how well they work and how often they fail and a lot of the world is already reliant on them just as much as others are reliant on gas central heating.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
Though one thing I do like about bracers is I can be lazy with formatting and let my formatter sort it out for me on save. With a white space sensitive language you need to get it correct from the start or else the program just does the wrong thing.
Gitflow is far more complex and unnessaray for most places. You do not need a dev, main, and release branches. Github flow is far closer to trunk based dev - create a branch of master, PR back into master when done. If you keep your PRs small it gives you most of the benefits of trunk based dev with a CI check before you merge to the mainline.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
I don’t find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.
Why do you need time to refactor? It is just part of the work you need to do and should be accounted for when doing any other work. IMO a big mistake people make is thinking refactoring is some separate thing they need permission to do. You don’t, if you need to make a change in some area refactor it first to make it easier to accept your change, then add your change then refactor to clean up. This is not three separate tasks, just three steps in one task. You should be given enough time to do the whole task, not just part of it.
The only other choice would be to break backwards compatibility, which is obviously not a good thing to do.
There are other options. A version on html/css/js would be good IMO. Then you can remove things you should not use in newer versions or make other breaking changes and better evolve the standard. Yes the browsers need to implement and understand each version. Much like how rust works with its editions.
The social aspect of going into a dark room to watch a screen in silence? Vs talking a joking around on voice chat?