Comment by pkolaczk | Hacker News Reader

Comment by pkolaczk | Hacker News Reader

Parent Full thread

Not sure what boilerplate in Rust or Scala you're talking about.

I admit Rust is much harder to learn initially, but once learned properly, the amount of code in both languages is very similar (as long as we're not comparing one program calling out to a library and another one doing everything from scratch). Both can be very high level.

Here is a study where they've found Python to be not much less verbose than Java actually, despite Java being generally considered a verbose language:

https://blog.wolfram.com/2012/11/14/code-length-measured-in-...

> I seriously doubt Rust will be anywhere near as easy to reason about.

I find Rust easier to reason about because there are certain constraints on sharing mutable state forcing developers to keep to very simple data flows (complex data flows / dependencies are getting hard very quickly and the compiler will fight that a lot with you). Python has none of these, so reasoning about data structures that can be freely shared and mutated anywhere can be hard. Python needs a lot of self-discipline to not end up with unmaintainable code.

That study is also based off of Rosetta code tasks. I'm not sure if that accurately portrays code in the wild. Java codebases are full of design patterns that are entirely uneccessary in Python. Ever hear someone talk about design patterns for Python? It exists, but it is niche instead of the norm and I've literally never heard it mentioned in hundreds of hours talking about Python with coworkers.

I'm sure Rust makes lots of sense when it comes to concurrency and systems programming, but that's not where Python shines or is meant to be used. In scripting, task automation, data science...etc it is really hard to beat. So maybe we're arguing over the usage of an axe and a sword on the battlefield and not about different swords lol.

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.

> 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.

I 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.

> 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.

I 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.

> 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”.

Fair point. So what are these limitations in facilities of abstraction that Python doesn't have and Java has?

Reply on news.ycombinator.com