It costs more or less the same amount of money to send one email as it does to send hundreds of thousands of emails. So spammers send hundreds of thousands of emails and they only need to fool one person to make it worthwhile financially. Is anyone doing work around "proof of work" email sending? Could a blockchain be used to make the cost of bulk email sending proportional to the volume?
I think it would be really cool if all your sellers had to do was maintain their inventory in a google sheet, and "share" access to your marketplace thing. Maybe you require columns to be named a certain way etc, but much lower barrier to entry.
Whatever the cause, I think what happened had a positive outcome. Being able to choose from a huge selection of window managers (or none at all) is something I really like about Linux. Thanks for all the hard work that people have put into WMs!
I agree. As a dev in a pretty large organization, I have seen the knowledge of business logic dissapate as the org grew, with some churn. To the point now where very few people actually know how the current system works, let alone how it is supposed to work. This means the only concrete definition of "this is what the system is supposed to do" is only in the code. The organization is disorganized, and the code is only as good as the level of organization outside the code - so very poor. All this gotme thinking about what does it mean exactly to be organized? We call companies "organizations" because they are groups of people getting together and organizing. If the organization is not organized the code (or any other artifact it produces) will also be poorly organized. Organizing is sorting, classifying, grouping, communicating etc.
Plus exceptions don't return to the call location - control jumps down to the catching block. Exceptions are not goto, but they are not like regular function returns either. Some weird thing in between.
It does assume we will be capable of popping these bubbles if we need to. We can not guarantee we will retain the capability to go into space. It would be better perhaps to engineer it so it naturally falls out of its location after some X years.
There is a definition of "unreadable" missing from the bullet point list at the top. This is code that is known to be correctly functioning, but the implementation of that functionality is objectively obscure (this is not equivilant to the second bullet point). In my experience you see it most in code that is old and has had many programmers work on it. For example, your reading a function trying to figure out how it could ever return a correct value - and yet good tests show it does every time. You realize 100 lines can be replaced by a hash lookup such-n-such, so you make the change expecting the tests to fail because you didn't understand something, but nope, you were right - simple lookup was all it needed. How does code like this come to be? It grows organically. The latest minor tweak is a tiny blip in the long twisted history of the functions existence.
This might seem like a minor addition to the list, but I think it's an important one. And it has a deeper philosophical implication: if you end up with a "Rube Goldberg machine" chunk of code it is not simply stylistic preference, even if the code functions correctly. In other words: you should not make the claim that just because it functions correctly that it is "correctly written". You certainly can make that claim (and I have seen many do, and I have done so myself).
There is code that is complex because it needs to be. There is code that is complex even though it doesn't need to be. If you don't actively prune the second type, it will grow all by itself and take over your garden.
Only 80% of my db inserts make it to disk, the remaining 20% randomly dissapear into the void. But this is OK because Pareto Principle. It's just savvy business.
Totally agree. It's interesting to ponder where the ditest for spreadsheets comes from. You can make a mess in any programming language after all.
With conventional imperative programming languages there is a kind of "culture" of sorts, collectively owned by programmers. It presents a fairly difficult barrier to entry, and has been built up over time as people learn from mistakes. But it's interesting that this culture doesn't really "live" anywhere centralized - there is no actual guild of programmers with a book of rules, even if we feel like there is (or is that feeling all that is needed for it to exist?)
But spreadsheets don't really have this. This is a blessing and and a curse. When you build something in a spreadsheet it's not going to be critiqued by anyone. But also no one is going to teach you the "right way". There is no "sheethub" to host your little project and get stars and merge requests, and get good and bad feels.
I spend a lot of time thinking about spreadsheets, but I never actually use them. I also spend a lot of time imagining what programming will look like in 100 years time. I don't have anything to show from that process. Maybe I would sketch my thoughts in a spreadsheet so no one would critique them. But then I would never learn anything I guess.
I would like to see spreadsheets and regular programming languages reconcile some how. I think both have a lot to learn from each other. Regular programming language culture has a lot of baggage that doesn't get questioned often. It's easy for programmers to look down on spreadsheeters, and yet the sheets keep coming.
Teaching anything when the student doesn't want to learn is a bit futile. I was taught physics at school. I am actually interested in physics now, and I am finding the historical progression, the story behind the move from an older model to a newer one to be very enlightening. I was taught this way at school but I just didn't understand it and wasn't interested enough to pay full attention. I think there is value in telling the historical story of physics, just only to interested students.
Hasn't some information been passed? You flip one bit, and if your observing the other bit you know the first one was flipped? So you know when something was done to the first bit...
Or just dynamic link to libc and static link the rest as much as you can. If a binary dynamically links to libc, but is otherwise statically linked, all good no?
I use Firefox because I believe its important for there to be more than one browser implementation (rendering engine) in the world. If you believe the same, go and download and use Firefox, even if it inconveniences you to do so. Now, about Skia...
Most (useful) libraries are managing state. This means the user of the library should have a pretty good idea of how the state is managed or they will call functions in the wrong order.
I am a professional software developer for over 16 years, and learned C in the last 3 or so years for interests sake. I would most likely fall into the category of C developers that think they know enough tricks to get by, but probably write terrible code without realizing it.
> Yes, you can write things in C and C++ that are very fast, but statistically, it is unlikely that you have the skill and discipline to do so consistently and at the same time deliver quality and robustness.
I would love to know how to get to this level. C is such an elegant language, and I really enjoy programming in it. Seems like there must be a way to get really good at C... But how?
I think it's important to note that these rights are there regardless of who you are or what you have done. And that differs from "natural" human tendencies to strip wrongdoers of their rights. We have collectively agreed that a wrongdoer can have some rights revoked (prison) and yet continue to preserve more fundamental rights. Yet many people today still feel that someone that commits a terrible crime should be stripped of all their rights, including in some cases their most fundamental right to be alive.
I am possibly alone in thinking the biggest thing to happen in computing in the 80s/90s was the spreadsheet. Having an immeasurable affect on the productivity of organizations large and small, to this day. So what does the 21st century version of the spreadsheet look like?
With pipes between threads, the OS is able to suspend the reading thread when the buffer is empty, or suspend the writing thread when the buffer is full, because the OS "owns" the buffer and the threads. With distributed systems connected via Kafka for example, there is no "process" overseeing both ends that can suspend or resume hollistically, so its difficult for producers to know and respond to back pressure.
Not just build internal models of the code, but also an internal model of the execution of the code. For example, a mental model of the scoping rules. As a developer you have to read a function and build a model of when variables are assigned values - you have to execute the code in your head to understand what the state will be at a particular point in time. I think a big part of complexity is having to imagine what the current in-flight state is - the larger the current in-flight state, the harder to reason about how the code will interact with it.
It illustrates that often as programmers we put code into functions purely for readability or organizing stuff. How often have you written a function that is only called from one place (or in a loop in one place)? You could really just inline that function, but that make your code a bit less readable. Recursive functions are different of course, and do need the stack (unless tail call recursion??). What is a function anyway, right? They don't really "exist" in machine code. They are a higher level language abstraction, and a compiler is free-ish to translate that into machine code however it sees fit (except calling between pre compiled objects).
The question is: what investment options are there for a savings-rich population in an environment of high inflation? Get ripped off gambling in the rigged casino that is the stock market? Buy bitcoin? It's no surprise housing is going crazy. Does anyone expect there to be a new, stable investment opportunity come into existence in the next 10 years? I wish it were different.
Been looking at ECS architecture for game engines. As opposed to a scene graph you have big in memory tables of "things". This let's you say render all the leaves on all the trees in one OpenGL draw call. As opposed to traversing a scene graph and constantly switching contexts of what is being drawn.
What we need is a good separation between computer science, and computer engineering - as there is is a separation between physics as a science and mechanical or civil engineering. What this article laments is students coming out of CS with little practical know-how. But practicality/application is not a requirement from a pure science. Let the scientists do science, and the engineers do engineering. And stop making a CS degree a requirement for a software engineering job.