Comment by setr | Hacker News Reader

Comment by setr | Hacker News Reader

If I understand the helper code part correctly, libraries are banned? That makes the challenge quite pointless, as it doesn’t even pretend to be equivalent to “real world” usage. All it can show is the julia language has it by default... but not whether the language’s design actually leads to something more clean, readable and sufficiently fast than what would “normally” be done in other languages.

It doesn’t really matter if python doesnt have as powerful an array syntax as julia, if I can pull in numpy (a standard, battle-tested library) and produce equivalent (and good) code.

But if I pull in numpy, and still can’t produce code as nice as julia (because of whatever limitations of python as a language), then there’s an argument to be made for switching to julia.

But going purely off what the language gives by its initial installation... its just an arbitrary limitation to give the question one answer.

The article claims that it proves the point ... "This can be unfair since Julia has lots of functionality for array algorithms built in, but also illustrates the point" ... but assuming good intentions, I'm not sure what point that is? At best, you might be comparing APL languages to one another, but nothing broader than that.

I like Python for the aesthetic reasons pg summarized so well in The Python Paradox essay.

Despite it has great libraries, I think it's the wrong language for scientific computing. In a nutshell, it's much harder than it should be to write concise and performant code. There's a huge stack of things used to achieve this, which often makes it complex to reason about performance and obscures the underlying mathematics: cpython, NumPy, pandas, Cython, Numba, PyTorch...

Julia is really appealing because it's very close to executable mathematics. And thanks to a few language design decisions, it's very easy to write performant code and reason about it.

For example, Julia ML libraries like Flux have full composability with Julia code. That's a game changer in terms of simplicity. Tensorflow is getting ported to Swift to mimic that feature.

that's exactly why I made that point debatable ;) Feel free to use Numpy, I'd consider that as the Python base array library anyways;) Note though, that this challenge is aimed at the people, that need to implement libraries like Numpy ;) But if Numpy is a good enough basis to actually create such a new flexible implementation, consider me impressed!

The way I have experienced it (with Javascript, Perl, Python and Matlab) is that many casual users give up whenever you mention packaging. Any language that lets people go very far without involving external modules will get significant usage from amateur programmers.

Hell, so do I; I absolutely hate learning new package ecosystems & infrastructure (but I absolutely do not have interest in learning a language without a decent package infrastructure). Probably a bigger blocker for me than learning the language itself!

But it's not clear to me that this "challenge" is intended to say that array operations are easy, for a newcomer to the language. As I understood it, it's an argument for Julia being better in the long run, for the code that requires "developer effort, performance and extensibility"; that is, elements of the language beyond the first few days of using it, for packages larger than what would be written by "amateur programmers"

If depicting usage for the amateur was the main point of the article, it totally went over my head

Posted my comment before reading the challenge, you are right it is definitely not about newcomers.

>If depicting usage for the amateur was the main point of the article

You understood that right, it is not :) That's why I wrote, that I'd probably need years to create the same implementation in any other language.

I do think it does have a widespread implication for the ecosystem though, and therefore at some point will also be relevant to newcomers.

elsewhere it suggests “Python + Numba” and “Python + C” as possibilities. i have to assume that numpy would be okay. i mean, it’s close to being part of the standard library at this point.

Totally breezed over that paragraph; you’re right, my concern was unecessary

I think NumPy can be considered Base Python, at least for scientific computing. Go ahead and give it a try.

In the beginning the article talks about contestants being things such as "python + numba, Python + C" and later it says:

> "Types & Functions From Different Packages It's mandatory to use an existing package without changing it. This can also be emulated by putting it in an isolated module not using any constructs defined in our implementation."

I don't know if the article has been revised, but this I read the rules about libraries completely opposite from you.

The rule is about the implementation itself, but the other one is part of the benchmarking code. You'll need to be able to use the implementation, that doesn't rely much on external libraries, with types from other packages. If you read the article, you'll find Julia is all about composing functionalities from different packages. Its a major driving factor behind the ecosystem - and usually not possible if your language relies on c libraries to do the heavy lifting.

If libraries are banned, then his reference implementation already fails. It uses an "import" on the very first line.

Well, it imports from Base - Anyways, too many people got hung up on this rule, so I deleted it... It wasn't very important anyways, as long as the core implementation is somewhat from scratch.

Then a question for you, as I don't know Julia the Language, how much is required from Base. In other words, if you didn't have the import from Base, what can you not do?

In a language like Unicon/Icon, I can "$include" a source file, I can "link" an ucode (compiled source, unlinked) file, I can "import" a ucode class file, I can put all the source in the same file or I can get the compiler to bring all the files together on the command line and it will basically end up with the same result.

Does Julia provide Base as source to allow you to do anything like the above?

> if you didn't have the import from Base, what can you not do?

So the part that gets loaded when you load the language/compiler is what is referred to as Base. So, it's kind of impossible to not have it and it is part of the language. So it's somewhat like asking, what can you do without "importing" integers? (ok, that's a hyperbole, but you get the idea ;) ) But, the source code does get shipped, so you might actually go in there and change stuff if you want, and Julia will pick up those changes - even, to get back to that hyperbole, how integers are defined, since they're implemented in pure Julia. I'm not a 100% sure what you're aiming at, but does that answer your question? ;)

Sorry for the tardiness of my response, I have been doing other things including sleeping.

It does answer the question in that it appears that Julia, as a language, doesn't provide you with much to start with, not even the bare bones. I have seen commentaries back in the 1980's that discussed such language designs. It makes for some uniformity but does require much work to be done to create the basic infrastructure that would allow and enable others to use these kinds of languages out of the box. Interesting in some ways, I suppose.

Guess I wrote my answer more ambiguous than I thought: the exact opposite is the case... Julia Base is huge and includes much more than most other languages I know - and that's what gets loaded on start, whether you like it or not ;)

Reply on news.ycombinator.com