4 ms·
Is Python not an OOP language? I think it is, so OOP design patterns still apply to it. So the differences you observed might be not because of a language itse
by pkolaczk 6y ago
Is Python not an OOP language?
I think it is, so OOP design patterns still apply to it.
So the differences you observed might be not because of a language itself, but the complexity of projects these languages are applied to and cultural differences of the teams. So far I haven't worked on Python projects as big (in terms of functionality) as Java projects I've seen.
As for data science, so far I haven't stumbled upon any Python code that wouldn't look very similar translated to Java, Scala, R or Rust, assuming same libraries existed. Most of the code is very simple really: load data into some vector/matrix, apply some library code on it, get a different vector/matrix back, etc. The only thing that holds me to Python really are libraries.
As for concurrency - gluing systems together sometimes needs concurrency to cut the latency down. And in data science parallelism also means performance, and often it is needed. I'm not that convinced Python is a clear winner here.
- dragonwriter 6y ago> Is Python not an OOP language? I think it is, so OOP design patterns still apply to it. “Design Patterns” in software (particularly when talking about what you see in code) are used largely to refer to things that are not just design patterns, but a combination of design pattern plus workaround for limitations in the facilities for reusable abstraction in the target language that prevent implementing the design pattern via reusable abstraction. In that use, there aren't really “OOP design patterns”.
- pkolaczk 6y agoFair point. So what are these limitations in facilities of abstraction that Python doesn't have and Java has?
- OneWingedShark 6y ago> As for concurrency - gluing systems together sometimes needs concurrency to cut the latency down. And in data science parallelism also means performance, and often it is needed. I'm not that convinced Python is a clear winner here. Ada is really quite good here, the Task is something such that I would say that if your application is inherently going to be dealing with concurrent processes you should seriously consider Ada. -- The 2020 standard is adding a Parallel keyword/block so that it should be (in theory) as easy to use e.g. CUDA parallelization as simply as compiling your code with a CUDA-aware compiler.
- 7thaccount 6y agoI think the winners in data science are Python, R, Matlab with Ada's share being non-existent. There is a reason for that. Ada doesn't have the numerical or data frame or stats libraries or any REPL functionality or charting libraries...etc. Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems.
- OneWingedShark 6y ago> Ada doesn't have the numerical or data frame or stats libraries Ada has a pretty nice set of numerics (Ada.Numerics.*), but the "lack of libraries" is almost a non-issue when the foreign-function interface is as simple as: Function Example_1(Item : Some_Matrix) result Some_Matrix with Import, Convention => Fortran, External_Name => "EX1"; > or any REPL functionality There are a few people coming in from data-science who lament the lack of REPL, while I might do one, it's rather low on my list, though I think HAC is trying for REPL or something like it. (I haven't used HAC yet.) > Language ecosystems are the thing that matters. I'd rather write Avionics or high speed trading systems in Ada, but data science? Maybe for some very niche problems. I agree that the ecosystems are what matters, and this alone would be enough to fuel my general hatred of C: the amount of time, effort, and money spent on C, whether "making a better C" or crippling tools (eg text-diff vs real semantic diff) or making "it 'mostly' works" accepted is simply astronomical.
- 7thaccount 6y agoI think you've already stumbled on a little problem and that is one of using a FFI. Python's Numpy handles all of that for me, so I never have to leave the walked garden of Python. Many scientists/engineers have similar views and likewise have very little Fortran or C experience, so having the kitchen sink distribution with (import numpy) is preferable to FFI.