4 ms·

"Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This statement is built on a false dichotomy. And it is n

by shele 13y ago

"Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This statement is built on a false dichotomy. And it is not really true for Julia, take the type system for example, sophisticated AND unintrusive.

StefanKarpinski 13y ago
Jeff and I were slightly miffed at being called "not language nerds" ;-)
- carljv 13y ago
  Language nerds (or geeks), definitely! Maybe he meant something like "language dweebs" or "language snobs." Julia's great strength, I think, is that it was designed by folks with very good grounding in language design, but who prioritized practicality.
- Glide 13y ago
  I cringed when I read that in the blog. I came across the benchmarks on the home page and I was thinking there was no way that it was possible to write a language that looks that good and performs that well without being a "language nerd."
exDM69 13y ago
> "Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This makes me a bit cautious about the language. Scientific computing people are often very smart but they are not programmers or computer scientists and may do funny things that a computer scientist would not. Like one based indexing of arrays in Julia. This is not a big deal but I'm a bit wary that there may be some nasty surprises for a language geek computer scientist like me :) Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward. There's a flip side to this too, if you're dealing with scientific computing there seems to be a wide variety of scientific computing libraries available in Julia [2]. Overall I find this language very interesting and it is on my shortlist of new languages to take a look at when time permits. [1] http://docs.julialang.org/en/latest/manual/strings/#unicode-and-utf-8 http://docs.julialang.org/en/latest/manual/strings/#unicode-... [2] http://docs.julialang.org/en/release-0.2/packages/packagelist/ http://docs.julialang.org/en/release-0.2/packages/packagelis...
- astrieanna 13y ago
  I think it's more like Julia is what happens when "language geeks"/experienced programmers write a language that's for technical computing, with a deep understanding of their problem domain and empathy for their users. Strings in Julia are meant to be addressed in for loops; they index by byte not character because it's slow to index by character once you include Unicode. Julia trys, in general, to give you control over low-level things rather than hiding them with magic. I like Julia because it's homoiconic, because of it's type system, because multiple dispatch is fun and new, and because it's just plain fun to write. I do static analysis, not math/science.
- simonster 13y ago
  > Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward. Yes, it's a little awkward, but to understand why this tradeoff was made, think about how you'd get the nth character in a UTF-8 string. There is a tradeoff between intuitive O(n) string indexing by characters and O(1) string indexing by bytes. The way out that some programming languages have chosen is to store your strings as UTF-16, and use O(1) indexing by two-byte sequence. That's not a great solution, because 1) it takes twice as much memory to store an ASCII string and 2) if someone gives you a string that contains a Unicode character that can't be expressed in UCS-2, like 🐣, your code will either be unable to handle it at all or do the wrong thing, and you are unlikely to know that until it happens. The other way out is to store all of your strings as UTF-32/UCS-4. I'm not sure any programming language does this, because using 4x as much memory for ASCII strings and making string manipulation significantly slower as a result (particularly for medium-sized strings that would have fit in L1 cache as UTF-8 but can't as UCS-4) is not really a great design decision. Instead of O(n) string indexing by characters, Julia has fast string indexing by bytes with chr2ind and nextind functions to get byte indexes by character index, and iterating over strings gives 4-byte characters. Is this the appropriate tradeoff? That depends on your taste. But I don't think that additional computer science knowledge would have made this problem any easier.
  - 13y ago

by shele 13y ago

StefanKarpinski 13y ago

Jeff and I were slightly miffed at being called "not language nerds" ;-)

carljv 13y ago
Language nerds (or geeks), definitely! Maybe he meant something like "language dweebs" or "language snobs." Julia's great strength, I think, is that it was designed by folks with very good grounding in language design, but who prioritized practicality.
Glide 13y ago
I cringed when I read that in the blog. I came across the benchmarks on the home page and I was thinking there was no way that it was possible to write a language that looks that good and performs that well without being a "language nerd."

exDM69 13y ago

> "Julia was not designed by language geeks — it came from math, science, and engineering MIT students" This makes me a bit cautious about the language. Scientific computing people are often very smart but they are not programmers or computer scientists and may do funny things that a computer scientist would not. Like one based indexing of arrays in Julia. This is not a big deal but I'm a bit wary that there may be some nasty surprises for a language geek computer scientist like me :) Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward. There's a flip side to this too, if you're dealing with scientific computing there seems to be a wide variety of scientific computing libraries available in Julia [2]. Overall I find this language very interesting and it is on my shortlist of new languages to take a look at when time permits. [1] http://docs.julialang.org/en/latest/manual/strings/#unicode-and-utf-8 http://docs.julialang.org/en/latest/manual/strings/#unicode-... [2] http://docs.julialang.org/en/release-0.2/packages/packagelist/ http://docs.julialang.org/en/release-0.2/packages/packagelis...

astrieanna 13y ago
I think it's more like Julia is what happens when "language geeks"/experienced programmers write a language that's for technical computing, with a deep understanding of their problem domain and empathy for their users. Strings in Julia are meant to be addressed in for loops; they index by byte not character because it's slow to index by character once you include Unicode. Julia trys, in general, to give you control over low-level things rather than hiding them with magic. I like Julia because it's homoiconic, because of it's type system, because multiple dispatch is fun and new, and because it's just plain fun to write. I do static analysis, not math/science.
simonster 13y ago
> Another example is the byte addressing of UTF-8 strings, which may give an error if you try to index strings in the middle of a UTF-8 sequence [1]. s = "\u2200 x \u2203 y"; s[2] is an error, instead of returning the second character of the string. I find this a little awkward. Yes, it's a little awkward, but to understand why this tradeoff was made, think about how you'd get the nth character in a UTF-8 string. There is a tradeoff between intuitive O(n) string indexing by characters and O(1) string indexing by bytes. The way out that some programming languages have chosen is to store your strings as UTF-16, and use O(1) indexing by two-byte sequence. That's not a great solution, because 1) it takes twice as much memory to store an ASCII string and 2) if someone gives you a string that contains a Unicode character that can't be expressed in UCS-2, like 🐣, your code will either be unable to handle it at all or do the wrong thing, and you are unlikely to know that until it happens. The other way out is to store all of your strings as UTF-32/UCS-4. I'm not sure any programming language does this, because using 4x as much memory for ASCII strings and making string manipulation significantly slower as a result (particularly for medium-sized strings that would have fit in L1 cache as UTF-8 but can't as UCS-4) is not really a great design decision. Instead of O(n) string indexing by characters, Julia has fast string indexing by bytes with chr2ind and nextind functions to get byte indexes by character index, and iterating over strings gives 4-byte characters. Is this the appropriate tradeoff? That depends on your taste. But I don't think that additional computer science knowledge would have made this problem any easier.
- 13y ago