But what about (theoretically) infinite sized channels in elixir!

Boooo! C++

I like this

Right, I'm sure other engineering endeavors such as the Manhattan project really just consisted of a lot of crappy engineers and then one good engineer who solved all the problems.

Pair programming is great. It's basically a design session in the middle of programming, it's true that you lose some capacity, but the thing about multiple people working on the same code-base is that even if everyone involved is competent you're always bound to have decreases in productivity due to synchronization.

Your experience is clearly that of someone who works on teams with a wild gradient in abilities, but a well recruited team would be far more balanced. The following points are just wrong:

"When you work with 2 then you only get a compromised solution, never the best solution."

"If 2 good developers work at one solution they you only get a 50% chance to have the best solution."

"Good developers that ask for feedback by the team only do it because they are nice to the team. To give the team a chance to also contribute. In reality they don't need the team to nail that project."

All problems in software are the same in the abstract, but different in their specifics and most people have their preferred toolbox of abstract solutions to abstract problems. 2 people don't need to work together to combine their ideas into one good solution, but the biggest benefit is usually from one telling the other why the other's solution isn't optimal and then both try to think of something better.

Apart from collaborating to arrive at a good algorithmic solution, pair programming is also good to get the ball rolling on producer/consumer or API/consumer work, because you can go into it with your own concerns, agree on a contract that addresses all those concerns and then split up later to implement.

For your last point in particular, that's just ridiculous. By that logic you're saying that any piece of software that has ever been written could have been written by a single person... and I guess that's true in a vacuum but in the real world you have deadlines and timetables and to meet those you need more than a single developer and when you have more than a single developer they need synchronization points so that your project doesn't bottle-neck on a single person writing the entire thing while others watch because they didn't reach any kind of agreement before-hand or a total-mess where everyone is working on whatever they think is most important and the same functionality ends up being implemented 12 different times once for every use case, while some other functionality doesn't even exist without pulling in scraps from 12 different places.

agreed 100%.

Yeah, when I said market value I meant that they have earned and currently do in that range at multiple places of employment. Location matters a lot I guess, if you're somewhere in middle America it's probably less likely, but that money also goes a lot further over there.

The most I know someone makes in a programming role (non-managerial, non-architect) is 250k, which I admit is probably pretty rare (also they're no in their 30s, but 50s)

Every programmer that I know over 30 has a market value of 150+k USD

This. minus all the racist shit.

I don't know... I mean 80K is basically starting salary. Most practical learning happens on the job so if he keeps his eyes out for opportunities to learn and progress his skills he'll be at 150k by his late 20s.

he can definitely earn 80k+, why not?

I said that what you wrote is correct and the OP is just raging against AGILE for reasons that aren't AGILE-related and justifies his dislike of it with his own dogma.

The more rave like this the less I feel like you know what you're doing.

You keep complaining about this, but I feel like it must be specifically the environment you're in.

AGILE is a nice methodology for when the final product specifications are not stable, it forces product owners to allow developers time to work on specific features, yes it creates technical debt and need for refactoring which bad teams don't allot time for, but the alternative in the same environment would be having to rewrite the entire Application, or never actually produce anything at all, because the dynamic requirements keep any progress from being made altogether.

Working at a bank right now. People really underestimate how complex the development process is, because the clients don't actually know what they want (and this is somewhat fine, because what they want is quite complicated usually.) It's a non trivial management task of avoiding scope creep, finalizing requirements, working through the inevitable tech-debt, etc etc. I'm not saying things can't be done better, but simply that things are not complicated without a reason

Unit testing is good for libraries and computational components, but can't replace integration and smoke tests for applications.

This is basically correct. The OP is just a raging dogmatic.

Not on any significant project.

Not all projects are as easy as letting developer talk to the clients and all of a sudden everything is magically clear.

Pair programming is pretty good for some broad strokes, for integration and for debugging.

AGILE works just fine, so do most other methodologies.

Ubuntu XFCE4

Terminator terminal

Vim for C

IntelliJ + VIM plugin for Scala/Haskell/Elixir

Fuck python, you can put lipstick on a pig, but ...

It's relatively easy to set up. It allows your process to be as simple or as complicated as you want (from pushing into a single remote repo via ssh to having a multi-tiered developer-lieutenant hierarchy for merging and curation)

Because in today's world people (including myself) find it difficult to formulate a plan of action and committing to it unless the plan brings positive results in two steps or less.

On top of that, programming is something that's advertised to be super big and important these days, but only a small percentage of the population has the mental disposition to be truly engaged and immersed in its details.

I love git!

I think he meant blaming the user of the language (programmer) rather than user of the application written in said programming language.

If you want to go with the practical approach of building things and getting them done then start with Python or Javascript. At a certain point you will realize some of the many limitations of those languages and then you can come back and ask for advice on how to overcome the specific limitations that you've encountered that have you stumped.

If you're more interested about the nature of program execution and want to consciously learn about what's happening in the machine in parallel you should start with C.

Don't start with Lisp.

No, other than some theoretical concepts.

Three steps to writing OOP code:

1) Avoid inheritance.

2) Declare methods in interfaces ONLY.

3) Use classes that are filled with static methods and immutable data gratuitously.

Also, avoid "oop patterns" unless they are entirely applicable

You're right I didn't haha.

Please stop using technology <X> even though it works great and satisfies your requirements, because I don't like <Y> about it.

No one wants a developer for those languages.

I don't know C# at all, but it's probably because it lacks typeclasses and type inference. 2.5 evaluates to double. 2.5f evaluates to float. This makes sense from the stand point of memory management, because it needs to know how much space is required for data even before it assigns the data to a variable, because it needs to evaluate the literal by loading it from memory. If it's anything like C, the constants (such as 2.5 or 2.5f) will be stored in read-only memory. This is only true in C for strings, C# may be handling primitive types like C does strings (via pointers/references) , before you can assign them they need to have some memory allocated for them on the stack/heap and then the reference to that memory will get assigned to "num1". If you try to assign a double to a float type variable it probably either fails or does weird run-time casting which is in best practice to avoid.

This is all conjecture, but I'm guessing that's the explanation.

That's not script kiddies, it's multiple people working on complicated systems with time constraints who don't all magically have a shared brain partition.

Established frameworks solve a lot of these problems, because there are established references, best practices and support available

You're exactly right. People who say that frameworks should be ignored and everything should be written from scratch are the real script-kiddies. Writing a one-liner is easy so they think they can build entire systems by writing a bunch of their one-liners.

Much better advice: use as much existing code as possible. Most of the time this involves frameworks, because frameworks are attempts at generalizing existing code for a wider set of purposes. Are all frameworks well-designed? no. Are they a pain to use or learn at times? yes. Are they they still worth it, for any significantly large project they are.

Any code is only as good as the support for it. Any time you home-roll your own solution in order for it to really remain a solution for anything it needs to be supported. If you're running a business that means employing more people. If you're writing code alone or in a small team, it puts more responsibility on your shoulders to maintain and slows down your development.

This argument that people who use frameworks don't even understand how computers work is so silly. It's a good thing they don't. Productivity comes from specialization, if you're building project there's probably some small seed of originality in it which makes it worth writing, everything else is just boilerplate. If you choose to write the boilerplate yourself you're probably an autistic idiot.

All these new features have some serious trade-offs.

GIT is pretty damn intuitive and simple to use given the inherent complexity of version control. It has many functional advantages over SVN and few if any disadvantages, but if you're not interested in any of the things that set it apart then it can seem slightly harder to use for no apparent benefit. That being said git is probably the easiest tool to use out of those in the modern toolbox stack, so if you're having problem with it I'd love to see your rant towards garbage like Vagrant, Chef, Docker, Jenkins and etc that are both annoying but are also commonly employed by teams.

I prefer printfs over C++ dumb << >> overloading. In C you can achieve polymorphism for specific type instances with some boiler plate. It's definitely not optimal.

Yes, you can't have OO without polymorphism but you can have polymorphism without OO, and it's the better kind of polymorphism.

OO was invented originally as a system of abstraction that could be used to attract people to computer science programming and that could be explained/sold to the business people who are sponsoring projects which don't understand the technical side at all (just like things like Agile and etc are now.) It was very convenient because it "solved" both these problems well, because it related abstract computational entities to RL entities like cars/bicycles and their parts.

Unfortunately like most multi-purpose solutions it is actually a poor solution for at least one of its intended problems, in my opinion it is definitely bad for the programmer, here are some examples of why I think it's bad.

Classes: They serve both as data-types and modules. It doesn't make any sense from computer architecture standpoint and little sense from RL standpoint too (which is supposed to be the selling quality.)

Yes, bicycles have wheels and stuff, but bicycles don't have "methods". "Driving" isn't a property of a bicycle it is an abstraction over its intrinsic physical properties. If the block of the bicycle class is meant to represent stuff that a bicycle has, the internal state of the bicycle should be logically separated from the functionality it's capable of.

From the technical standpoint it doesn't make sense either. The default elements of programming are datatypes and functions. Functions are blocks of data that can be executed, datatypes are look up tables into data that describes the properties of the datatypes. A Class defines both a type and functions. Functions are united together into modules which are a good abstraction over the program memory of the program. Datatypes are compile-time elements, while data objects are pieces of memory that are meant to follow the properties of the corresponding data-type. But in OO if I instantiate an object of a certain class it seems like you also instantiate the methods corresponding to that class. that would be horrible inefficient and in reality it does work the same way as in imperative or functional programming (tables of function pointers) however it doesn't change the fact that a "Class" is a concept that's overloaded it's both a data-type and a module, this makes it a bad abstraction for programming.

It is true that Interfaces are meant to alleviate this problem, but the fact that you can define method prototypes in classes and not just interfaces opens up the possibility for poor programming style.

Will continue later.

Continued: another problem with OO is that the facility for generics are abysmal. Basically the object you're calling a method on can be generic but no other parameters easily can with any useful guarantees. The reason this is a problem is ultimately because object methods have ownership over their methods, but the type parameters of the methods don't. This is a problem that interface don't fully fix either.

Subtype polymorphism or inheritance (the signature feature of OO) is also very limiting. It forces you to implement methods youll never use or to refactor inheritance hierarchies frequently, as a result its best not to use inheritance hierarchies as little as possible and just rely on interfaces which are quite limiting in comparison to some of the features other languages have like typeclasses.

I like it.

That's a little harsh.

Object Oriented programming is cancer.

C++ is not OO, it's many things and OO is one of its worst things.

Using C++ like C but with the semi-automated memory management features and good libraries like Vector is a very good and may actually be the best way to use C++. Modern C++ is also ok if you know how to use its features without inducing sickening compile times.

I'm employed by a huge bank and writing Scala.

I disagree. VMs are really big right now and understanding how they work is more useful (unless you're working on embedded systems.) Learning Assembler isn't going to teach you much about VMs.

so edgy

Scrum is alright for rapid development/prototyping when the requirements are unclear. It may not be optimal for developers but it at least creates a predictable environment for planning and prioritizing items/features, which is a big achievement in it of itself when end-user requirements are up in the air.

I absolutely hate OO and I wasn't even programming in 1994. Interfaces are ok, but don't go far enough (type classes are more powerful and useful) but subtype polymorphism is just cancer. Attributing ownership of functions to datatypes is only reusable if you introduce internal states, which is a huge cause for bugs in major projects. Internal states should be reserved for very few things like thread-safety and encapsulated into explicit contexts, instead of that in OO every single object potentially has hidden internal state.

Classes are horrible.

C++ added some other things that are very good such as the tools for semi-automated memory management, but overall the language is way too large. It requires a lot of discipline on the side of the development team and a strict code guideline so I prefer C.