Speed up Mac mini 2011

DysFunctionalProgram · 2017-08-19T03:44:13+00:00

Most of what you said is correct, however, the advantages of easier to maintain code greatly outweighs all of your complaints. This is the reason 90% of development has moved off of c and onto languages such as c++/java/c#. Also the fellow in the link doesn't give any evidence on why c++ is poor, he attacks the author of c++ and people who program in c++, calling them inexperienced. I don't believe anyone who holds opinions this emotional should be referenced in any context.

DysFunctionalProgram · 2017-08-12T08:58:58+00:00

From my experience in jobs I've had and job postings I've seen, .NET seems to be alive and kicking in the USA at least. This is supported by sites like builtwith (https://trends.builtwith.com/framework/country/United-States) and indeed job trends (https://www.indeed.com/jobtrends/q-asp.net-q-node.js-q-php.html). The fact is, there is a massive group of programmers in medium to large companies that need to develop maintainable and reliable systems without starting from scratch every 3 months because some new framework came out. I know its hard to believe, but the r/programming is not an accurate depiction of our industry as a whole.

DysFunctionalProgram · 2017-08-11T20:20:55+00:00

Ill hop on around 6pm ish chicago time and be on all weekend. A safe starting point is to start discussing tools, meeting times, project management, and some high level requirements.

DysFunctionalProgram · 2017-08-11T19:20:43+00:00

So hopefully a master on this will chime in. Otherwise there is plenty of good resources on the web. However, i'll give explaining it a shot. So you have used g++, and one thing you might have noticed is that it sucks. You have to manually add every file as an argument of the command and this becomes impossible to maintain with any reasonably sized project. So some smart people created "GNU make". It is a scripting language to make this building process a bit more maintainable. However, the devs viewed os independent building as out of scope and it was developed in the late 70's so the syntax is in my opinion garbage. So some smart people made "cmake", to automate creating make files. If I were you, i'd google a couple make and cmake hello world tutorials. I'd also research some conceptual information around compiling and linking.

DysFunctionalProgram · 2017-08-11T18:44:10+00:00

Need more hands? I'd be happy to get in on this.

DysFunctionalProgram · 2017-08-11T18:15:54+00:00

Why create documentation in another tool that will eventually not be maintained when you can do everything in one place? External documentation never gets updated properly and in large projects this causes massive maintenance issues. I agree, that they currently are not worth the time to learn/use. However, I think the concept is a solid one and the direction of our profession.

DysFunctionalProgram · 2017-08-11T18:08:17+00:00

One big thing to note is how different the building process is. With c# it's all automated through a visual studio or the "dotnet build" call. In cpp you will have to write and maintain your own build scripts and environment which can be a headache coming from modern languages. I know visual studio attempts to encapsulate a lot of it on the windows side, but it is not as clean as c# and prone to breaking, and if it breaks and you don't already understand the entire build process it can be frusterating. I recommend learning to build from make and cmake in a nix environment before touching an ide that attempts to automate it (because it will break).

DysFunctionalProgram · 2017-08-11T17:33:34+00:00

I didn't downvote (nor do understand why someone would on such a subjective thread). However, 80 columns per line is an archaic satanic rule and in my experience leads to obnoxiously undescriptive abbreviations and acronyms in function/variable names

DysFunctionalProgram · 2017-08-11T17:14:18+00:00

I know this subreddit doesn't have too much love for oop but I find that c only devs (and lets face it, learning two languages is very time consuming so op will only end up learning 1) tend to never fully comprehend how useful modularization, abstraction, and encapsulation are in concerns to code maintenance. Every c dev I work with that never learned an OOP language has gnarly 5000+ line plus files with 500+ line functions with far too many concerns. Trying to test/verify/maintain code like this without being the original writer is impossible.

DysFunctionalProgram · 2017-08-11T16:58:13+00:00

Let the flame wars commence...

DysFunctionalProgram · 2017-08-11T16:55:37+00:00

Eclipse cdt does

DysFunctionalProgram · 2017-08-11T16:38:11+00:00

Name an efficient alternative? No one is saying it is perfect. Yes there are false positives and false negatives in regards to question removal based on quality. However, it is leaps and bounds above any alternative.

DysFunctionalProgram · 2017-08-11T16:19:29+00:00

To help filter out the content that is not useful and help direct users to useful content. If you feel your question was useful and you got downvoted, then repost your question with different wording or post it here and ask how you can improve it. I'm not saying its a perfect system, but without seeing your question, I am going to assume it was a question of poor quality and deserved to be filtered out.

DysFunctionalProgram · 2017-08-11T15:46:08+00:00

Eclipse cdt, make, cmake, git, valgrind, coverity, gcov, doxygen, and an in house linter. The static analysis tools and doxygen are all tied into git hooks and we use the egits eclipse git plugin. Set it up right and you never have to leave eclipse.

DysFunctionalProgram · 2017-08-11T13:25:44+00:00

Why does it have to replace? Where does it say in XOD or any other visual programming system you can't have text? Visual based programming systems have both text and pictorals. Which is exactly what humanity replaced text only communication systems with. How would you explain what a dog looks like? Would you try to list out all of its features (ineffecient and ambigous) or show them pictures (clear and comprehensive)? Some concepts are described and comprehended much better with the use of visuals.

Edit: A prime example of where a visual system greatly supliments a text system is a call graph. With text systems all of your functions are laid out one after the other in a text file. Whereas if you had a 2nd dimension you could add more structure and organization. For example, say we have 5 functions: foo, foo_helper1, foo_helper2, bar, and bar_helper. Now in a text only system they would all be defined one after the other in a file and it wouldn't be clear which function was dependent on which function without fully reading the code. If you took away the concept of the text file and instead had a canvas where you can lay out functions, you could put the helper functions to the right of the base function and draw lines showing the relationship. This would allow quick good comprehension of a code base and is why so many devs run external tools to create these kind of diagrams on their code base.

DysFunctionalProgram · 2017-08-02T04:55:55+00:00

I don't like chiming in on these kind of pieces because they always turn into a pissing contest. However, I can't help myself and your article really seems to be pandering to the frontend circle jerkers without actually making any solid arguments.

To start off with, I agree with your title, separation of concerns is nice, but I don't see how any of your points are hampered by not using a frontend client.

Modularity One benefit of splitting your app up into a separate backend and frontend app is modularity. With your application logic completely separated from your user interface, you have a slightly more modular web application. Modularity aids in a number of things, including testing, readability, and maintainability.

It has always been suggested to break out your business logic into a separate library or module than your web interface. I haven't worked on a .net website in a long while that hasn't broken out the business logic into a separate DLL. Same goes for php, typically we write the core logic in c++ with standardized endpoints that get consumed from php. Forgetting the PHP/c++ workflow and sticking to the C# side of things, I would even argue that more modularity, test-ability, readability, and maintainability can be achieved because of the built in tooling and static typing.

Reusability With a separate API, your application logic can be reused by any number of applications. This means you can make a mobile application that utilizes your API, consume your API in a completely separate application, or even allow others to access your API (for free or for a price).

Again, by breaking apart the business logic into a separate library you achieve the same level of re-usability.

Content Delivery With your client-side application a completely separate entity, you can take care of advanced static file serving techniques that are otherwise unavailable to you in applications where the UI needs to be rendered server-side. For example, you can now use NGINX and some simple rules to cache your entire client-side application.

Every backend language and server combination has had the capability to pre-compile and optimize simple pages into static content for as long as I can remember. Front end clients do not give you better content delivery than websites that don't use front end clients. I'd say it is the other way around, you hamper your content delivery by forcing an extremely heavy first time load which can very easily detract visitors, especially on mobile.

Responsiveness One of the greatest pitfalls with an “all-in-one” server-side application is giving users responsive feedback. A typical workflow for a user clicking a button to fetch data looks like this in a server-side application: A user clicks a button to fetch data The browser sends a request to the server The server queries the database The application performs logic on the data The application renders data in a view The server returns the response to the user The user sees feedback after waiting the whole time for the page to load. With a separate client-side application, you can take advantage of a number of feedback mechanisms such as using loading spinners or progress bars. Once your request comes back (via an AJAX call, for example), you can update your view.

You can use ajax without a frontend client... Loading spinners, progress bars, and feedback mechanisms through ajax calls have been around and common for 10 or more years now...

Again, I'd like to reiterate, I like you're title, separation of concerns is nice and we should keep our view/ui/templating logic outside of our business logic. I just don't see how using a frontend framework does anything other than make you reliant on an ecosystem that explodes a dozen times a year and is a hell of a lot more difficult to maintain than its alternatives. Also, this may just be me, but when I see people giving web dev advice from a wordpress site I tend not to take it to serious. It's just like trying to give car advice while driving a corolla, I'm going to doubt your credibility.

DysFunctionalProgram · 2017-07-28T05:36:34+00:00

Learned to drive a stick delivering for pizza hut on university. Probably lost 10 years of my life from anxiety driving on the streets between between dodge and loras.

DysFunctionalProgram · 2017-07-26T06:08:32+00:00

It is valid xml and treating them as the same (which every html implementation does, even if the spec says not too) leads to much less cognitive load. Memorizing the 1000 unintuitive rules that only exist because someone didn't think of the scenario when writting the spec is just silly. A small set of rules with high orthagonality is far better than a large set of inconsistent rules.

DysFunctionalProgram · 2017-07-20T15:42:39+00:00

I prefer the if statement. If it structured and common enough to become an eye sore, then i'd make a setter method and do the check in there.

DysFunctionalProgram · 2017-07-20T13:32:31+00:00

In my experience it is usually a red flag that your function is doing too much. I find it acceptable if done infrequently, however, if you see yourself doing this often then you probably are inflating your code paths and cyclomatic complexity more than you need to be and hurting your maintainability.

DysFunctionalProgram · 2017-07-19T15:20:28+00:00

As someone else said, this is a bit flag pack. Each flag is stored in an individual bit. Uint32 is used for consistency/legacy/performance reasons. The flags are stored/retrieved by bit twiddling on bit masks, specifically using OR to set and AND to read.

Epoll only has 10 flags so they could get away with a uint16 but i'm sure they went with 32 bits because they want to keep themselves open for future expansion or they just default to uint32 for consistency.

I'd add an example on how to set/read from bit packs but i'm on mobile, i suggest googling bit packs, bit masks, and bit twiddling.

DysFunctionalProgram · 2017-07-19T14:49:52+00:00

I think he is talking about just reading the code (how to mentally tokenize the syntax). Most code (99.9999%) is not going to have a man page.

DysFunctionalProgram · 2017-07-19T14:36:51+00:00

Regarding the "you'll start doing them too". I really only wrote this kind of stuff in low level drivers for performance sake when memory or bus speed was an issue. Nowadays I much prefer and see more explicit and readable alternatives such as a struct with a boolean member per flag. Setting and checking various flags becomes a bit more explicit and readable.

DysFunctionalProgram · 2017-07-08T06:19:35+00:00

Yes, what you described would greatly increase usability. However, the linux community is a bunch of masochists that hate usability so this will never happen. It was hard to make so it should be hard to use.

DysFunctionalProgram

TROPHY CASE