And it still delivers solutions and they work. Hate it all you want.
I hate it for its patterns, but regardless...if the tool works, the tool works! If it makes sense to someone, and they can ship working software for it, it has a reason to exist.
I'm prefer type safety as in Java...
I did once too, and still like type safety when doing more manual stuff in C++, but I've come to appreciate that Python really doesn't need type safety once you understand how to make full use of duck typing. It's not worse, or objectively better, than type safety...it's just a different way of problem solving, like OOP and FP are different.
Yeah I like Scala in the sens it combines OOP, FP and has many nice ways and good picks for a certain problem in a given time. Like either use pattern matching with case classes or some other stuff but your choice, aaaand this is why I love Groovy - it's almost type safe. If you want you put in types for you to read but under the hood it's just object :D. Also you can have everything as HashMap and use like object in terms of someMap.keyNameAsDotAnnotation.
But for patterns I don't get it? Patterns enforced previously by Java tools? Or some language specific things? There's too much patterns nowadays and I hate them all equally as most people treat me like idiot for using my head instead of learning 3000 of them for each possible problem
...most people treat me like idiot for using my head instead of learning 3000 of them for each possible problem.
Aaaaaaaand you've hit the nail on the head right there! I concur.
The trouble is, almost all Java-related documentation, courses, guides, tutorials, and answers I see advocate certain design patterns, code snippets, and habits (a la "always use double no matter what!"...and yes, I've heard that multiple times). In that context, you really are not invited to think, much less to challenge, the Great Java Way Of Doing Things™.
I think Java has some neat features and ideas — it also has some horrifically terrible things, like boxing/unboxing and generics (a mal-implementation of C++'s templates) — but it all comes down to how you use it. Great software can be written in any language, Java notwithstanding!
And I've heard good things about Scala.
I think my main issue with Java, and the main reason I love Python, is the overarching culture surrounding the language. With Python, we're always in pursuit of the One Obvious Way, which is not necessarily known for any given problem, but is discoverable through careful consideration. Pythonistas welcome challenges to the known One Obvious Way for anything, so long as you can prove why your way is better. If you can, then that is gradually shared and accepted as the new One Obvious Way. (In other words, we're always looking for the optimal solution, but recognizing we'll never really get there.)
I don't see that attitude in Java. Most Java code, documentation, and courses I've seen are reminiscent to me of "eh, it works because I used the special magic patterns I was taught. Truuuuuuust meeeeeeee." Perhaps that's not the Java culture as a whole, but it's been my rather discouraging experience over the past ten years. Maybe if I used it more...but then, after that experience, I really don't want to have to use Java. Give me C++ or Python instead any day.
Yeah I know. However I do admit that I switched to Groovy and Kotlin so I'm mainly using those two not actually Java and I can say Kotlin community is not that different from Java just that they prefer to brag Kotlin is better and mostly love FP instead of OOP which is the reason I will stop using it soon probably :D. I just liked the idea to use suspend and extensions for RxJava/Reactor where you simply say .await on reactive methods and use it like impertive/procedural. That's basically the only reason I switched from it. Data classes made no difference in many ways for me except ability to use .copy.
So I would say "pattern" is not Java thing, it probably started to be a hype with C++ and the GoF through EIP and so on. Now I just heard about EIP when I started to do a lot of integrations and using Apache Camel. But I learnt quite soon I just need a lot of easy to use libraries and EIP made my life worse. So thus I'll try in free time to investigate possibility of building AEIP (anti eip) solution in Python in sense that I need nice integration but mainly from Pulsar to Pulsar in mean time enriching with extra http calls and transforming. So if anyone knows nice tool like Apache Camel but for Python and easier to use please do let me know.
So I would say "pattern" is not Java thing, it probably started to be a hype with C++ and the GoF through EIP and so on.
It started with Gang of Four, to be sure, but that book was published in 1994, one year before the initial release of Java. Design Patterns and Java have been taught concurrently in universities for a very long time, and (perhaps resultant of that,) every Java dev I've ever known is usually the first person to utter the word "pattern" in a technical conversation.
P.S. What in they hey is EIP? Search isn't being useful, and I hate acronyms. I may know the term, but haven't yet acronymized it in my head.
Sorry about that. EIP - Enterprise Integration Patterns. So Apache Camel and Spring integrations or even Red Hat Fuse. Looks nice then you realise enrich doesn't work as you need it today so I might consider pythonizing integrations with Pulsar. Maybe do it more dynamically and present it as AEIP as in anti enterprise integrations pattern just for fun. I thought like I only need Python to trigger certain stuff on new input from Pulsar and give it back once done with enriching and transformations so why have any other restrictions from patterns?
Patterns are supposed to be tools, rather than set-in-stone regulations. You can implement any (or all) of the Gang of Four patterns in Python, mix-and-match, and use however you need...or use no patterns if none of them are helpful.
Well as soon as you try your own thing with certain opinionated tools that enforce them you get my result: they look like bad guys keeping you in thin circle :D. You can, but you can see how much restrictions are in place so your better of starting from 0 and implementing them partially.
I hate it for its patterns, but regardless...if the tool works, the tool works! If it makes sense to someone, and they can ship working software for it, it has a reason to exist.
I did once too, and still like type safety when doing more manual stuff in C++, but I've come to appreciate that Python really doesn't need type safety once you understand how to make full use of duck typing. It's not worse, or objectively better, than type safety...it's just a different way of problem solving, like OOP and FP are different.
Yeah I like Scala in the sens it combines OOP, FP and has many nice ways and good picks for a certain problem in a given time. Like either use pattern matching with case classes or some other stuff but your choice, aaaand this is why I love Groovy - it's almost type safe. If you want you put in types for you to read but under the hood it's just object :D. Also you can have everything as HashMap and use like object in terms of someMap.keyNameAsDotAnnotation.
But for patterns I don't get it? Patterns enforced previously by Java tools? Or some language specific things? There's too much patterns nowadays and I hate them all equally as most people treat me like idiot for using my head instead of learning 3000 of them for each possible problem
Aaaaaaaand you've hit the nail on the head right there! I concur.
The trouble is, almost all Java-related documentation, courses, guides, tutorials, and answers I see advocate certain design patterns, code snippets, and habits (a la "always use double no matter what!"...and yes, I've heard that multiple times). In that context, you really are not invited to think, much less to challenge, the Great Java Way Of Doing Things™.
I think Java has some neat features and ideas — it also has some horrifically terrible things, like boxing/unboxing and generics (a mal-implementation of C++'s templates) — but it all comes down to how you use it. Great software can be written in any language, Java notwithstanding!
And I've heard good things about Scala.
I think my main issue with Java, and the main reason I love Python, is the overarching culture surrounding the language. With Python, we're always in pursuit of the One Obvious Way, which is not necessarily known for any given problem, but is discoverable through careful consideration. Pythonistas welcome challenges to the known One Obvious Way for anything, so long as you can prove why your way is better. If you can, then that is gradually shared and accepted as the new One Obvious Way. (In other words, we're always looking for the optimal solution, but recognizing we'll never really get there.)
I don't see that attitude in Java. Most Java code, documentation, and courses I've seen are reminiscent to me of "eh, it works because I used the special magic patterns I was taught. Truuuuuuust meeeeeeee." Perhaps that's not the Java culture as a whole, but it's been my rather discouraging experience over the past ten years. Maybe if I used it more...but then, after that experience, I really don't want to have to use Java. Give me C++ or Python instead any day.
Yeah I know. However I do admit that I switched to Groovy and Kotlin so I'm mainly using those two not actually Java and I can say Kotlin community is not that different from Java just that they prefer to brag Kotlin is better and mostly love FP instead of OOP which is the reason I will stop using it soon probably :D. I just liked the idea to use suspend and extensions for RxJava/Reactor where you simply say .await on reactive methods and use it like impertive/procedural. That's basically the only reason I switched from it. Data classes made no difference in many ways for me except ability to use .copy.
So I would say "pattern" is not Java thing, it probably started to be a hype with C++ and the GoF through EIP and so on. Now I just heard about EIP when I started to do a lot of integrations and using Apache Camel. But I learnt quite soon I just need a lot of easy to use libraries and EIP made my life worse. So thus I'll try in free time to investigate possibility of building AEIP (anti eip) solution in Python in sense that I need nice integration but mainly from Pulsar to Pulsar in mean time enriching with extra http calls and transforming. So if anyone knows nice tool like Apache Camel but for Python and easier to use please do let me know.
It started with Gang of Four, to be sure, but that book was published in 1994, one year before the initial release of Java. Design Patterns and Java have been taught concurrently in universities for a very long time, and (perhaps resultant of that,) every Java dev I've ever known is usually the first person to utter the word "pattern" in a technical conversation.
P.S. What in they hey is EIP? Search isn't being useful, and I hate acronyms. I may know the term, but haven't yet acronymized it in my head.
Sorry about that. EIP - Enterprise Integration Patterns. So Apache Camel and Spring integrations or even Red Hat Fuse. Looks nice then you realise enrich doesn't work as you need it today so I might consider pythonizing integrations with Pulsar. Maybe do it more dynamically and present it as AEIP as in anti enterprise integrations pattern just for fun. I thought like I only need Python to trigger certain stuff on new input from Pulsar and give it back once done with enriching and transformations so why have any other restrictions from patterns?
Patterns are supposed to be tools, rather than set-in-stone regulations. You can implement any (or all) of the Gang of Four patterns in Python, mix-and-match, and use however you need...or use no patterns if none of them are helpful.
Well as soon as you try your own thing with certain opinionated tools that enforce them you get my result: they look like bad guys keeping you in thin circle :D. You can, but you can see how much restrictions are in place so your better of starting from 0 and implementing them partially.
Ergo, one reason I'm choosy about what opinionated tools I use. ;)