LWN: Comments on "An introduction to the Julia language, part 1"

An introduction to the Julia language, part 1

Cyberax — Fri, 21 Sep 2018 19:04:43 +0000

> I don't ever recall seeing a mile 0 mile marker on the road. Mile 1, Mile 500, etc, yes. Mile 0?
Lots of cities in Russia have them. There's a famous one in Moscow: https://commons.wikimedia.org/wiki/File:0_Kilometer_Point...

An introduction to the Julia language, part 1

jake — Fri, 21 Sep 2018 18:40:39 +0000

Exit 0 on the Garden State Parkway ... Cape May, NJ ...

other places as well ...

jake

An introduction to the Julia language, part 1

pizza — Fri, 21 Sep 2018 18:35:51 +0000

> I don't ever recall seeing a mile 0 mile marker on the road. Mile 1, Mile 500, etc, yes. Mile 0?

There's a particularly famous one in Key West, Florida. (At the start of US Highway 1)

An introduction to the Julia language, part 1

ssmith32 — Fri, 21 Sep 2018 18:32:51 +0000

I don't ever recall seeing a mile 0 mile marker on the road. Mile 1, Mile 500, etc, yes. Mile 0?

(Or kilometer, or feet, depending on your activity & country).

I will grant that, when diving, you can have a depth of zero, but that's the only example I can think of ..

I never climbed a zero foot rock wall. Or used a 0 foot rope when doing so.

Please elaborate with examples...

An introduction to the Julia language, part 1

mcortese — Wed, 19 Sep 2018 19:16:19 +0000

Can someone come up with an example where one needs A=B to be a link instead of a copy?

An introduction to the Julia language, part 1

ghane — Wed, 12 Sep 2018 00:39:29 +0000

To quote Donald Knuth: https://xkcd.com/163/

An introduction to the Julia language, part 1

VITTUIX-MAN — Mon, 10 Sep 2018 22:19:47 +0000

I take you get his point though. When you do more mathy stuff, you get less offset by one errors with 1-indexing, whereas C-thinking people, what most computer people are, say likewise that of course 0-indexing is natural.

Engineers dislike Matlab too, because we too start from 0 usually.

An introduction to the Julia language, part 1

marcH — Fri, 07 Sep 2018 08:16:11 +0000

> the data overall supports the Julia team's contention that Julia has generally achieved parity with Fortran and C

Is Julia ready for *faster* than C? https://queue.acm.org/detail.cfm?id=3212479

(Fortran already is in some cases)

An introduction to the Julia language, part 1

marcH — Fri, 07 Sep 2018 08:13:08 +0000

> Merely restating your wrong assertions and adding some new ones doesn't make them any less wrong than they were.

In any case your tone makes sure the points you're trying to make start with a significant disadvantage.

An introduction to the Julia language, part 1

mgb — Thu, 06 Sep 2018 16:32:25 +0000

And yet in the real world beyond FORTRAN we do measure sizes starting with 0 for empty and we do measure locations starting from 0 inches, 0 miles, and 0 degrees.

An introduction to the Julia language, part 1

fgrosshans — Thu, 06 Sep 2018 15:55:17 +0000

> "Prehistoric" means "we know nothing about it save what can be deduced/ inferred from artefacts because there are no written records dating back to this time". If you knew how people had counted in prehistoric times, they thus wouldn't have been prehistoric.
> That's a contradictio in adiecto.

No, it is not a contradiction. Written record does NOT mean no data. For example, comparative linguistic, tells us about languages before they get attested in writing. If one looks, for example, at the best known language families (but it is also true for others), one can see related words for numbers (both cardinals and ordinals) starting at one, the words for zero appearing much later, in historical time. Form this data, it is difficult to conceive widespread prehistoric zero-indexed counting practice, which would simultaneously disappear across these wide-spread and non-communicating civilizations with the invention of writing.

Another counter-example is proto-historic Mesopotamia, where we have written/material notation of numbers centuries before this number notations evolved into a full writing systems, which included a zero, but later and only in technical texts.

An introduction to the Julia language, part 1

CycoJ — Thu, 06 Sep 2018 12:25:02 +0000

Two things that seriously put me off julia last I tried, were:

1. They copied the most infuriating bits of matlab. The 1 vs 0 indexing is maybe a might annoyance, but the stupid use of the "." and " ' " to denote element-wise and transpose is horrible. My numeric programming is to the largest degree not linear algebra, so I mostly want element-wise operations. I can live with the fact that they defaulted to matrices instead of arrays by default (although I would argue they should actually call it properly), however using the '.' is just horrible. When I was still using matlab, I don't know how many hours I was debugging code where it ended up being "search the missing ." They are way too easy to overlook in regular editors but often don't cause your code to crash, but simply give non-sensible results (often not easy to deduce what went wrong). Similarly for the ' as the transpose operator, again a symbol that is way to easy to overlook, but will often not cause a crash but simple wrong results. I see the same errors with the students I supervise who are still using matlab (I know I am doing my best to convert them to use a proper language). This really is a significant development cost.

2. When I tried it a couple of years ago the recommendation for getting the best speed was to unwrap vector operations into loops. Hopefully they fixed that by now, because the reason whey I use a high-level programming language is because I don't want to do explicit loops for multiplying to arrays.

An introduction to the Julia language, part 1

oldtomas — Thu, 06 Sep 2018 10:16:35 +0000

> The 1-based indexing has been used in mathematics for ages because [...]

Translation: "My preference is The Way God Intended, so everyone should do it My Way". Not very convincing, is it?

> The 0-based indexing was only thought a clever idea because then you can avoid "wasting" a memory word,

Bzzzt. Wrong. When I started my studies (physics, maths), 1975 (four years after C), most languages around indexed still from 1. Language implementors were no idiots (even back then, go figure!) and didn't leave "word zero" empty just to start counting from one.

Our maths faculty counted from zero, physicists were half this, half that way.

My observation since then is that math faculties tend to vary between counting from one or from zero; those strong in mathematical logic and model theory seem to prefer zero.

My take is: I clearly prefer zero to be a natural number. But starting a holy war on this is the worst of all three choices.

Come on: you can do better than that.

An introduction to the Julia language, part 1

Wol — Thu, 06 Sep 2018 06:52:13 +0000

> Fortran has been considered practical long term, and there you can index arrays any way you want - even with negative indices

And FORTRAN is 1-based and you can't change the index. They were prepared to change and break things when they went from FORTRAN to Fortran, yet this is something they extended rather than broke.

(Don't feed a FORTRAN loop into a Fortran compiler and expect it to work! Incidentally this is 1 or 0 based - a FORTRAN loop is 1-based while a Fortran loop is 0-based :-)

Cheers,
Wol

An introduction to the Julia language, part 1

Wol — Thu, 06 Sep 2018 06:43:47 +0000

> Typically in languages with 0-based indexing the idiom will be to use a < comparison for the upper bound

Which is a trap for the unwary, or noob.

All languages have idioms. I once wrote a piece of code - in a class for C beginners - that effectively did

count = 0
for i = 1 to 13
count += (cardvalue == 3)
next

to find out how many threes were in the hand. I just could not get the lecturer to write the addition line correctly on the board until I told him to write it down, character by character, as I spelt it out. To me, that idiom is second nature, to him it was totally alien.

And yet, it SHOULD be completely natural to users of any language (like C) where the language defines the result "true" as being represented by the integer "1". (Note I said "result" not "value" ...)

and you'll find plenty of C programmers to whom the "<" idiom is alien, until they've been programming in C for quite a while and had it rammed in to them.

Cheers,
Wol

0 versus 1, the eternal battle

Wol — Thu, 06 Sep 2018 06:33:37 +0000

> Don't mathematicians usually designate elements of arrays starting from 1, such as a₁, a₂, a₃, …, an?

This is a LIST. Arrays are usually used to store lists. Lists don't exist in relational theory, and arrays are second class citizens in C. Hence relational/C guys don't understand why people should want to start at 1 :-)

Cheers,
Wol

An introduction to the Julia language, part 1

Wol — Thu, 06 Sep 2018 06:31:08 +0000

> In both the real world and the computer world we measure sizes using cardinals starting with 0 for empty.

And how many ordinary people do you know in your "real world"?

In my real world, most people aren't interested in maths. In my real world an object with size 0 usually doesn't exist. In my real world I would be tearing my hair out if I tried to explain why counting from 0 made sense.

Yes, I count from 0 when programming in C. But my preferred language "sort of" starts counting from 1 - arrays have an element(0), but that's all arrays, including two- and three-dimensional arrays! And the language does fancy things with element 0, precisely because it doesn't make sense to have an element 0 in normal use - you don't have a zero-th element in a list. (Programmers - database guys especially - seem fixated on sets, which because they don't have order, lack the concept of counting FROM ONE.)

And when I'm programming *for* the real world, an array location of 0 actually almost never makes sense. There's a reason C says an array and a pointer are equivalent - 0 makes sense for pointers, it does NOT make sense for arrays, and as someone who knows both C and FORTRAN as first-class languages, I always find it weird using arrays in C precisely because it is a pointer-based language, whereas the concept of pointers is totally alien to FORTRAN.

As an assembly-level language C doesn't hide the fact that *internally* arrays start at 0. But it's a damn sight easier to use a higher level compiler (like FORTRAN) to hide that fact from the user, because if the user is not a professional programmer (ie most FORTRAN guys, and Julia's target audience) they have no need to know that.

Cheers,
Wol

0 versus 1, the eternal battle

bjlucier — Thu, 06 Sep 2018 05:25:36 +0000

You might look at the Scheme language SRFI 122

https://srfi.schemers.org/srfi-122/

which contains my suggested way to work with arrays. Not quite a_penguin, but almost.

An introduction to the Julia language, part 1

kvaml — Thu, 06 Sep 2018 02:34:29 +0000

Mark and Luke were counting days between events in their narratives. They disagreed on how that count should be performed.

Ancients lacked zero and lived before Descartes. Insisting that we should continue to count as they did is probably a mistake.

An introduction to the Julia language, part 1

togga — Mon, 03 Sep 2018 18:58:44 +0000

"This is not something a scientific programmer will commonly do"

Really?

I guess this "scientific programmer" will not commonly integrate different components from different languages either. Nor does this "programmer" commonly need to map anything to a memory model (protocol, disk-layout, ...). This "scientific programmer" you describe seem very limited to me.

Is Julia designed to be a programming language aimed for computers or for mathematicians that don't want to change old habits inherited from a time before computers existed?

An introduction to the Julia language, part 1

leephillips — Mon, 03 Sep 2018 15:31:25 +0000

Yes, if your calculation is such that you can take advantage of these libraries, you will get the performance of C or Fortran, with, for many routines, automatic parallelization. But, as I said in the article, "you can only take advantage of this if your calculation fits the pattern of an available routine". What Julia offers is fast performance not only for standard manipulations, such as matrix multiplication, but for calculations that do not fit one of these molds, for which you would need to write loops over arrays or other data structures.

An introduction to the Julia language, part 1

anselm — Mon, 03 Sep 2018 12:14:42 +0000

This is why many people in science these days use SciPy and NumPy, which essentially push many such calculations into C extensions and keep the Python code reasonably high-level and fast.

An introduction to the Julia language, part 1

billygout — Sun, 02 Sep 2018 21:20:26 +0000

What's more confusing to me is that `global` was needed in the assignment statement in the loop, but not in the first line in the loop `print(i)`. Why would that be?

An introduction to the Julia language, part 1

Cyberax — Sun, 02 Sep 2018 08:51:14 +0000

The "two language problem" here is for a very particular case of scientific code.

If you're using Python then you often have to use C/C++ to get enough performance because Python itself is too slow for naïve looped calculations.

An introduction to the Julia language, part 1

droundy — Sun, 02 Sep 2018 03:03:18 +0000

Yes, and as someone who teaches computational physics using python, this is probably the worst problem in terms of confusing students and introducing bugs that students are unable to track down. It seems a terrible idea to reproduce this bug in a language specifically intended for scientists with little training in programming.

An introduction to the Julia language, part 1

droundy — Sun, 02 Sep 2018 02:59:24 +0000

This seems like the major flaw in the idea that Julia solves the two language problem. If it's not a general purpose language then it's always going to be a second language for anyone with more than the most basic needs.

An introduction to the Julia language, part 1

k8to — Sat, 01 Sep 2018 22:47:08 +0000

Sure, though I agree with the contention that suggests many people give too little care for it across the breadth of coding scenarios. I know I've made the error, and I'm pretty anal retentive about thinking about edge cases and trying things out to validate correctness.

An introduction to the Julia language, part 1

mpr22 — Sat, 01 Sep 2018 20:45:28 +0000

The level of "caring about code quality" I would want to be applied to safety-critical software for operating a flight control system, radiotherapy machine, or nuclear reactor is much, much higher than I think is reasonable to apply to, say, a seven-day roguelike :)

An introduction to the Julia language, part 1

cpitrat — Sat, 01 Sep 2018 19:35:54 +0000

I've often heard the 'I don't write critical code, I don't need all your safety practices' or 'seriously, why would I need unit tests ?' from researchers, including some in computer science. One of them once published a paper and a few months later, another researcher contacted him telling he couldn't reproduce the result and whether he would share his code. It turns out he found multiple bugs that made his result invalid. It turns out you should care about your code quality even when you're not writing code for a nuclear reactor.

An introduction to the Julia language, part 1

rschroev — Sat, 01 Sep 2018 09:02:25 +0000

I see where you're coming from. Yes, modern languages in many cases don't require you to index at all, so I guess you could say that any indexing you do need is low level. That doesn't make Dijkstra's reasoning low level, I think, but I see your point.

Thanks for clarifying.

An introduction to the Julia language, part 1

danielpf — Fri, 31 Aug 2018 22:56:30 +0000

> Did you read EWD831, "Why numbering should start at zero" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx...)?

Yes I did long long ago. I have programmed scientific applications in many languages (Basic, Algol, Pascal, C, Fortran, PLI, APL, Lisp, Forth, for some of the oldest) over decades and did not find Dijkstra arguments compelling. In practice the most convenient indexing scheme depends on the problem. Sometimes one would like to index arrays starting with negative numbers, or using other sequences, like x,y,z.
For some other problems (say indexing the day of the month) starting with 1 is the most obvious.
Forcing scientists and other users to count with a single rigid scheme while the compiler can easily do the translation is, like programming in assembler, wasting neurones: it distracts from higher level considerations.

Fortunately Julia, like Matlab or Fortran, allows to operate on arrays and other structures as global objects, or index them with complex conditions, so it is less and less necessary to care about the default indexing basis.

For example a matrix product in Julia or Matlab takes one line:
julia> X = A*B

The equivalent C code requires several lines, 3 loops, 3 indexes, where the 0-based indexing must
be respected as well as the matrix dimensions, and of course is far less optimal for large matrices
than what is done internally by Julia.

sum = 0;
for (i = 0; i < m; i++) {
for (j = 0; j < q; j++) {
for (k = 0; k < p; k++) {
sum = sum + A[c][k]*B[k][d];
}
X[c][d] = sum;
sum = 0;
}
}

So the way out of the 1- or 0-indexing discussion is to program at higher level than indices when possible, and to have the freedom to choose the starting index when not possible.

An introduction to the Julia language, part 1

rschroev — Fri, 31 Aug 2018 20:52:51 +0000

I'm not going to argue for or agains 0-based or 1-based indexing, I just want to point something out:

> And scientists are like normal people, they mostly don't care about the assembly language level elegance that Prof. Dijkstra was promoting.

Did you read EWD831, "Why numbering should start at zero" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx...)? Dijkstra's arguments are completely language-independent, and are rather abstract and high level. I don't understand where you get the notion that his reasoning has anything to do with assembly language level. And I certainly don't understand how/where Dijkstra was promoting assembly language level elegance. You're not confusing things with Donald Knuth's MIX and MMIX, I hope.

An introduction to the Julia language, part 1

epa — Fri, 31 Aug 2018 20:35:50 +0000

The idiom of "in your fortieth year" is also known in English (and even the 1-based year numbering is explained by the long form, the two thousand and eighteenth year of Our Lord). Also, of course, your first birthday is not really your first.

An introduction to the Julia language, part 1

leephillips — Fri, 31 Aug 2018 19:22:57 +0000

Thanks for that interesting comment. I wonder if it would be possible to create subscript indexing with macros. Have you looked into Donald Knuth's literate programming system? Your remarks suggest that it might interest you if you haven't.

'But now, as it [Python] has "matured", it makes the programmer specify more things that have nothing to do with the heart of the algorithm.'

Can you give an example of what you mean?

0 versus 1, the eternal battle

mgb — Fri, 31 Aug 2018 17:39:47 +0000

a₁, a₂, a₃, … is a sequence. Sequences often start with a₁ but this is not always the case. However a sequence is a function, not an array.

If a sequence is finite you can represent or even define the function by an array of values but you'll usually want to work with with an expression defining the function.

(x, y, z) is a kind of finite sequence but in a high-level language you're probably going to access the ordinates by name or implicitly iterate over them rather than accessing them as (a₁, a₂, a₃).

An introduction to the Julia language, part 1

hackerb9 — Fri, 31 Aug 2018 17:36:04 +0000

This was a timely and helpful article for me.

Every so often, the language I've been using becomes encrusted with extra requirements that make programming less joyful but safer for, say, a nuclear power reactor. Since I don't program nuclear power reactors, this has sometimes led to me shifting my coding preferences.

In the early days, Python started out looking very much like executable pseudocode, which I thought was fabulous. But now, as it has "matured", it makes the programmer specify more things that have nothing to do with the heart of the algorithm. Even C, which is pretty ugly nowadays with all the mandatory casts and declarations, was much more readable, almost beautiful, back when it was invented.

Maybe some day programming languages will have dynamically expandable footnotes and we can encapsulate all the ugly (but necessary) details in some hidden away spot that won't distract from the main point we're expressing. It's kind of ridiculous that most of programming today uses pretty much the same typography capabilities of Hollerith punchcards.

Until that day, Julia looks pretty awesome, at least in its 1.0 state. In terms of being able to powerfully express concepts in a natural way and with a minimum of mandatory cruft, it has Python beat. It's so far been as close to C in speed as I need and much faster than Octave and Numpy. I love that the REPL command line works the way I expect and already know: tab completion, LaTeX to express Unicode (while ɛ> ♥ <3), emacs editing key sequences, history, multiline editing, defaults to printing to console if no semicolon, and on and on.

And, can I just say, that I love having a language the properly treats Unicode as the default instead of ASCII. I can talk about ℵ₀ ∈ ⅄ or use a variable named ɛ when that's what I mean instead of spelling it out in English ("epsilonButYouKnowThatBackwardsThreeVariant"). Although, I do kind of wish Julia did not use Unicode for subscripts, as it is rather lacking. For example, you can't write dB_SPL. Also, to me subscripts are the most compact and readable way to specify the index into an array, as in: a_i = a_i-1 + a_i-2. If they were going to support subscripts in a mathematical language it would have been nice to have it be as a syntactical alternative to using square brackets.

All in all, I think Julia is a strong contender to be my language of choice over the next decade, or until it becomes old and ossified. I did notice one little annoyance already. The print function cares whether there is a space before the open parenthesis. Apparently this is a new thing as it complains that I'm using "deprecated" syntax. I can live with it, but I hope it doesn't foreshadow Julia 2.0 becoming even more naggy and less natural.

0 versus 1, the eternal battle

danielpf — Fri, 31 Aug 2018 16:58:34 +0000

A modern language like Julia allows to take an arbitrary sequence or set of any type, and loop over it.
Also any label can index the elements of a table.

In pseudocode it reads like

From Monday to Friday do ... end,

From "a" to "r" do ... end

Age[John]

When operating over structures one can need either global operations such as

A = sin(B) + 1

where A and B are structures (could be arrays), or one needs to operate on a subset of the structures
determined by a condition (for example all the prime numbers in array A are set to 0: A(isprime) = 0).
In such frequent cases the way the elements are addressed is irrelevant.

So the higher level people program the less relevant the indexing is.

An introduction to the Julia language, part 1

rsidd — Fri, 31 Aug 2018 16:08:43 +0000

Ok, here's what many of you are missing. Arrays are discrete. Time is continuous -- eg hours, years, which can exist non-integrally. So is the FFT (ok, it's discrete but it's an approximation for a continuous thing.)

Zero-indexing makes sense for "discretized" continuous or periodic things. It makes sense to label the first hour after midnight the zero hour: the markers are 0 and 1, at either end, and even for continuous periodic things, the "mod" argument makes some sense for zero-indexing.

For sequences in general, nobody refers to "a" as the zeroth letter in the word "algorithm". It is the first letter. This is just how daily language works and also how mathematical notation works for the most part. The FFT may start from a zero-index but that's fundamentally because it's based on an assumption that the sequence is periodic. Vectors are always 1-indexed, except in relativity where time gets the index 0 while spatial indices are 1,2,3 -- and that too is for historic reasons (originally time was 4, but in imaginary units; when they figured it's better to use real units and a non-Euclidean metric, they chose 0 to avoid confusion.)

An introduction to the Julia language, part 1

farnz — Fri, 31 Aug 2018 15:59:27 +0000

Or go further, as some places in Japan do. A bar can be open (say) 1800 to 2700, meaning in 12 hour terms "from 6pm today until 3am tomorrow"; similarly, a long distance transit route might have the last vehicle today leaving at 2330 and arriving at 2530 (meaning 0130 tomorrow), while the next vehicle leaves at 0015 and arrives at 0215.

Basically, today started at 0000 - time then runs continuously so that 2530 today is the same as 0130 tomorrow, and 4930 today is the same as 0130 in two days time.

An introduction to the Julia language, part 1

hackerb9 — Fri, 31 Aug 2018 15:26:20 +0000

Or do it like I've been told the U.S. Army does: 0..24. 0 and 24 refer to the same hour, but they use them to make the rest of the context consistent: for example, We are meeting in the War Room from 23:00 to 24:00 and then having an ice cream social from 0:00 to 1:00.