Object Oriented

Just start with Python. It manages to be both one of the most popular languages to learn programming with as well as one of the most popular languages for professionals. It makes easy things simple and hard things possible. It's really excellent.
Learn C at some point. People will tell you that it's the best language ever invented. It's not, it's really shitty. However, it's still very widely used, very influential, and frequently the best option for low-level programming, so if you're going to learn multiple languages C should be one of them.
To get a taste of how much variety there is and stop yourself from getting stuck in a single style, learn the basics of a bunch of other unusual programming languages in different styles. For example, Scheme, Haskell, Prolog, FORTH and Erlang. None of those are likely to end up being your go-to language for getting shit done but they will expand your mind.
Java is a horrible language but you might be forced to use it at some point and it will teach you all about the bullshit parts of OOP that you might be expected to know at some point.

oh, so you're a gullible idiot. (if this were true, by the way, i'd insist you learn LISP first)
learn python, it's easy enough that a child can grasp it, and after you get a basic understanding, try to learn the basics of several other languages.
your'e positing something about an opposition between procedural programming and OOP that is the nerd equivalent of that model who posted a pic of her typing "cd code" and tagged is #programming. except i think she knew she was bullshitting and you probably think you said something meaningful.
go find a copy of Seven Languages in Seven Weeks (pragmatic press) and throw yourself at that after you do a couple of weeks of remedial Python. Then go buy a copy of SICP and carry it around for a while. maybe try to crack the spine in a year or two.

this user gets it.
you will have to learn java eventually, but don't start with it. not because of the OO paradigm or anything fruity like that, but because java is a fucking mess.
if you were raised by hoarders, your conception of what "a tidy house" means will be forever twisted from reality. The same is true with java and "easy to follow code".

youtube.com/watch?v=1S1fISh-pag

Yes and no. I started with Java, a statically typed and OOP-only language, and it made trying out dynamically typed languages, like Python and Javascript, feel off and strange at first. But once you get used the differences in the layout of syntax, you realize most languages are actually pretty damn common.

In other words, pick whatever you like, at least long enough to have a good foundation of the basics (data types, conditionals, loops, basic OOP, if you care), then you'll be able to pick up any language you like decently easy and it won't matter.

Lisp is one of the worst languages ever made. Its distance to real hardware paradigms prevents programmers from thinking of problems in terms of how they will actually be solved. It will sound like a troll, but even BASIC is a much better language than Lisp to learn on as memory works the way memory really works and you'll have learned something useful by the time you outgrow it.

t. cmissile fizzbuzzer

Lisp is like Marxism. Even though nothing good was ever made with it, people keep pushing that shit anyway.

kys retard

...

classic LARPer mistake

But Scheme is a Lisp dialect.

It's not Lisp when we do it!

Learn LOGO.

OOP is an ideology that has results. Oop patterns (common structures that work as patches upon oop-lacks) simply work. They most likely will give you a quasi mantainable and quasi scalable solution most of the time if you know how to apply them, which is moderately easy

However, they don't ever give you the best solution, and sometimes they might stand in the way of the best solution. "well I'll just not use patterns" you can't. The moment you use an oop language young people that came out just from uni will start parroting about "which pattern are you using" and retarded shit like that. Project managers will start speaking about buzzwords that you should follow just because someone made a fancy diagram of how the project works that actually doesn't match reality.

As I said. It works. But it works like a hammer. And for OOP acolytes, every problem is a nail.

Not only that, but OOP forces a lot of abstraction in an attempt to solve several of the problems that might arise on big projects. And I say attemp. Sometimes it works, sometimes it doesn't. However the truth is that, at some point you might realize that you don't know what the fuck are you doing because OOP kept hiding from you what the fuck was happening on the actual machine, what the fuck was your actual data.

inb4 someone will tell you how oop is great or something. Ignore them. You will not regret this advice. Learn OOP when you know at least to some extent how memory works, and just to make sure you understand what people are talking you about.
Also ignore people obsessed with memory safety. Memory safety is extremely important, but anyone acting like it's a must in every domain is just part of some meme jihad from reddit. You will lose a lot of time trying to juggle around with dozen types of pointers before you even understand what a pointer is.

Source: A person that has been programming OOP since more than a decade and was at some point an obnoxious kid trying to force oop bs everywhere... I'm thankful I've managed to free from this curse.

Go is a dialect of C :^)

There is literally nothing wrong with programming in Java.

Personally I disagree. I find OOP code almost unreadable.
I can't remember where but I once read a quote that said if you do something different then it IS different. Every time I imagine that my "objects" are similar I just remind myself of that and come up with a better solution.

Go and C are both specific languages. Lisp is not a specific language, it's a family of languages that includes Common Lisp, Scheme, Clojure, Emacs Lisp and a bunch of other obscure Lisp dialects.

Where do you see the analogy between group theory and functions/objects? I know both group theory and programming, but I don't see how they related to each other.

It's not really true. After a while you start to see that every kind of programming language tries to achieve the same thing, they just have different ways to get there. None of them try to fundamentally change the way a computer works. And a lot of them have heavy abstraction or "magic boxes" that you'll have to accept at face value if you only ever do high level languages, which is why learning something like C is so valuable.

If you know C you probably don't have to "learn" any high level languages at all, just look at the reference material as needed

If you know Assembly you probably don't have to "learn" C at all, just look at the reference material as needed

Yeah, like OCaml (or rather, like Reason, because it inherits C syntax). Functional first, POO second.

Lisp means Common Lisp, and you would know that if you bothered to look at anything from the community in the past 20 years, LARPcuck

Are you seriously suggesting a beginner start out with functional programming languages?

Try Prolog some time.

Functional programming is actually really good for people who have a math or engineering background and just want to implement some of their formulas and algorithms rather than fiddle with bits. The problem is that most books about Scheme and Haskell are about teaching you the language rather than teaching you the mindset of FP; I wasn't getting FP until I began reading SICP. As always it comes down to what OP wants to write code for.

No it doesn't, it's not my fault when idiots keep conflating a family of languages with one particular language of that family. There is a reason Common Lisp is called Common Lisp and not just Lisp.

Well, from the pov of a non OOP person, OOP surely must look unreadable. However as you gain experience within OOP everything starts making sense in terms of OOP. You can look at a class and, if it's "well written" you instantly understand what the class is supposed to do (not unlike someone choosing correctly the types and names of parameters in C, except now you have to choose correctly everything about a class to do this).

non-OOP starts to look ugly, and you end up doing classes for things that don't require classes. You start demanding certain standards that everyone high in OOP asks for but don't really apply everywhere.

In truth, you needed something that required at most 1000 lines of code, but now when you're in OOP world you need like 5000, distributed in several classes just 'cause.

Worst than that, in the supposed domains where OOP supposedly is better (big projects with big teams) you will find that you have to enforce everywhere laws to constrict OOP expresivity or else your codebase will turn into shit fast. If you don't have a strong leader imposing a good style shitty unmanageable code is a guarantee. Of course, this applies everywhere, non oop included. However in non-oop languages enforcing good style is easier.

In our current project, a dod non oop project, our style guide has like 3 pages. While the oop workers need a much much more extensive document.

If I understood correctly, you are saying a function that essentially performs the same operations, isn't the same as long as at least one of the operations depends on a type T?

At work, we have a system in which users may decide to select one of the columns of any table in a set of tables to use it as a source of a value in an operation. The field is then stored in a DB as an Id. The operation is essentially the same all the time, and this is pretty much the only thing that changes. From the Id of the field, assuming the fields aren't ordered in memory the same way all the time because we are not hacky masochists, how would you solve this without writing an enormous switch to detect the type of struct that's being procesed? You could even pass it as another argument to the function that does the operation, but you are just passing the burden of the operation alone.

Protip: the elegant and brief solution implies polymorphism.

OP is right, though. I got into programming at age 14 and it was C. It totally shaped my way of coding and thinking about it. Also I'm trained to be careful because you can fuck up so fast with C. On the other hand it's really easy to hop on Java, VB.net or python. Concept-wise C++ and Java are close to each other but I find C++'s syntax to be a massive pain in the ass.

So go for C, OP. The rest will follow. Also C is highly relevant in the industry.

If you can't come up without a good, simple solution without OOP, you might be too high in OOP to begin with. Your problem doesn't seem too bad. I'll not say that you can't have it with OOP, however I'll say that I'll doubt your ability of performing good OOP consistently if you can't come up with a good non-OOP solution.

Agreed. I mean, I program with C++ but if you're afraid of doing some math then that's a little fucked. Algorithm creation is fun!

OOP has failed.

OOP is supposed to help in big projects, because those usually require big teams.

However, it's becoming more and more apparent that a good chunk of big projects end up requiring a lot of performance. That means, if your server expends more energy, more electricity and is slower, then your end product will not either be worth the price, or just not fast enough.

I reccomend watching this whole thing:
youtube.com/watch?v=rX0ItVEVjHc

you might not like it right now, but each time you are doing some oop bureaucracy, try to remember this video. With time you'll realize how right he is.

not learning o-o first doesn't "ruin" you, any more than knowing what a goto statement is ruins you.

if you don't know object-oriented code, then it is helpful to begin with c++.
this way you can write a reasonably small (console/command line) program in non-o-o style, and then ask how it might be re-written in o-o style.
seeing how both programs are different but are written to do the same thing is something I found very illuminating.

object-orienting is just a way of associating one or more variables with one or more subs/functions (methods). it's just a way of keeping code organized.

i would also warn you: object-orienting seems dumb with small programs, where you can remember what all the different variables are and you know when they get written with valid values and can be read. o-o doesn't really get useful until you get into huge programs with thousands of variables that you cannot remember them all.

and you can abuse an o-o language like java, just by making one base class and putting ALL your variables in that.
o-o is easy once you get the hang of it tho, and if the program grows in code lines,,,, eventually you will regret that you didn't organize it better

beyond that, there's not much differences over most languages except assembly.
most languages you do the same things: create variables in types, if-then statements, do-while loops and so on. it is just a matter of the syntax of how they have to be written for different languages

for job marketability, that is a regional thing
where I am I'd say C++ and Java are good bets.
java is o-o only but with a bit of Java you can download Android Studio (it's the Android program IDE, free download from Google) and write programs for Android, which is easy to show off, as you can run it on a phone or little tablet... (easy to show off to other people)

python is mostly a web admin/webserver thing. if you wanted that.
Ada, scheme, lisp and the other niche languages,,, if you wanna. they won't get you hired most places, and they don't do anything dramatically different.

lel, I nearly got a heart attack watching this guy talk.

Get a load of this guy...

I can think of another way of solving it, but languages like Rust could probably not pull it off. Weakly/duck typed languages like JavaScript, Python or Lua would require hackish solutions. It also depends on how much you know about the parameter at compile time, but it would probably be more verbose than letting the object handle itself in many cases.

So, what about less LARPing and more commenting on how would you do it without OOP?