Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

sinews.siam.org

Post reply on HN
Print view View original

241–249 of 249 posts

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#241

Post by mruts »

StefanKarpinski wrote: post #232
mruts wrote: post #201

Earlier quoted context omitted.

Why do you think that "end" is superior to more lightweight syntax? One might argue that using "end" doesn't really matter, but I am extremely skeptical one could argue it is superior to a curly bracket or a tab in any way at all. PS: And in regards to your last statement, maybe "end"s aren't seen very much anymore is because language designers' agree with me, not that somehow my opinion is influenced by the syntax o…

Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using…

I actually agree with you on the last part, I do find python's tab indention unsettling. I just think it's better than using "end"s.

In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical).

I'm not trying to argue about any particular syntax. Just that, syntax should be as concise as possible and not include extra identifiers that confuse the eye.

As an aside, I also think that programming languages should probably use less words, and more symbols, as it lets people who are familiar with other spoken languages to more easily adopt them.

Also, using more keywords (like end), restricts the name space of variable names.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#242

Post by mruts »

pavon wrote: post #238
mruts wrote: post #50

Julia is interesting, but the block syntax is a little off-putting. I'm not sure why someone would design a language that uses 'end' to delineate a block. Curly brackets make sense. Tabs make sense. But 'end'? All it does is make code harder to read and harder to write.

I love the use of end for blocks! It avoids the arguments about brace placement on one hand and problems with space sensitive indention on the other. It is simple, consistent, easy to read and write. Yes, easy to write. Seriously, I can type short words like end just as quickly as I can type shift-}, two keys off in the extremes of the keyboard layout. I think it gets a bad reputation from languages like bash that ha…

I mean, what about auto-generated code? Not only does using words forbid potential variable names, but it makes code generation more difficult as well (as does tabs). A good positive example is Haskell, which uses tab for normal block delineation, but also allows curly brackets (which is usually only used for auto-generated code).

By sharing block delineation with variable namespaces, the language creates a whole bunch of problems (a block identifier is essentially a newline followed by a “end” vs the much simpler “}”).

Also, the more english centric a language becomes, the harder it is to learn for non-english language speakers.

Moreover, words are used for variable names, while symbols are disallowed is many/most languages. By having block delineaters share the variable namespace, you detract from the readability of the language (as well as restricting variable names as I mentioned earlier).

One might ask: Does any of this matter in the scheme of things? The fair and honest answer is: not really, it’s a minor syntactic difference. But I firmly believe using words to end blocks is still inferior, even if it’s not a big difference.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#243

Post by pjmlp »

yellowapple wrote: post #229
pjmlp wrote: post #215

Earlier quoted context omitted.

That OO concept is pretty much Simula specific, Lisp languages got influenced by the work done in LOOP and Flavours which lead to the design of CLOS, the origin of multi-methods idea. Building on top of your remark, Julia's approach is more "call the visible implementation of this function that better matches the types of all given parameters". And these are only two possible ways of doing OOP, there are a few other…

That OO concept is also what Alan Kay et. al. were envisioning when they coined the term "object-oriented". It's all about message passing between blackboxed instances with isolated/private states. Multi-methods and such are cool and useful, but they're kinda secondary to that core concept (which Julia doesn't really have, to my knowledge at least). In other words: object orientation != strong typing (even if they do…

I never said that object orientation == strong typing, rather that Smalltalk/Simula OOP isn't the only way of doing OOP.

CLOS, Beta, SELF, Oberon (the first version), Component Pascal all have explored different ways of doing OOP.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#244

Post by dagw »

mbauman wrote: post #225
dagw wrote: post #222

Earlier quoted context omitted.

Python cannot even index lists by ranges (or other lists) True for python lists, but not true for numpy arrays.

Oh, I'm well aware. That gets at my point, though: Julia's ranges are _just_ arrays, and behave like all other arrays in the language.

Agreed. The fact that python has several 'array-like' data structures with subtly different interfaces is not my favorite feature of the language.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#245

Post by StefanKarpinski »

mruts wrote: post #241
StefanKarpinski wrote: post #232

Earlier quoted context omitted.

Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using…

I actually agree with you on the last part, I do find python's tab indention unsettling. I just think it's better than using "end"s. In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical). I'm not trying to argue about…

> In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical).

Yes, Matlab does this too. However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array functionality as Julia does. The classic example in Matlab is that when the interpreter sees `a(b(c(end))))` it needs to dynamically look up whether `c` is an array or not to decide if the `end` refers to the length of `c` or not, if not then it has to check if `b` is an array or not, etc. That would be even worse in Julia since the question of "is it an array or not" can be somewhat fuzzy. It's perfectly possible to implement an array-like type that uses indexing syntax and does not subtype AbstractArray. In Julia, when you see `log(v[end÷2])` it's syntactically unambiguous that this means `log(v[length(v)÷2])` which is only possible because of the distinct syntax for array indexing and calling functions. There are other where this distinction is essential as well, such as broadcasting [1].

[1] https://docs.julialang.org/en/v1/manual/arrays/index.html#Br...

> I actually agree with you on the last part, I do find python's tab indention unsettling. I just think it's better than using "end"s.

Ok, well we made the opposite judgement—we found `end` preferable to indentation. When you create a language you get to pick syntax that appeals to you.

> I'm not trying to argue about any particular syntax. Just that, syntax should be as concise as possible and not include extra identifiers that confuse the eye. > As an aside, I also think that programming languages should probably use less words, and more symbols, as it lets people who are familiar with other spoken languages to more easily adopt them. > Also, using more keywords (like end), restricts the name space of variable names.

You may appreciate K and other APL derivatives, although they are not known for their readability. But they certainly don't favor English speakers over anyone else.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#246

Post by ChrisRackauckas »

StefanKarpinski wrote: post #245
mruts wrote: post #241

Earlier quoted context omitted.

I actually agree with you on the last part, I do find python's tab indention unsettling. I just think it's better than using "end"s. In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical). I'm not trying to argue about…

> In regards to you the use of brackets, array indexing and function calls can use the same syntax: lisp and scala seem to manage just fine. There's a lot of unnecessary syntax in a lot of languages that doesn't really serve any purpose (besides historical). Yes, Matlab does this too. However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array fu…

>However, not syntactically distinguishing array indexing from function calls has problems in a language that provides as much array functionality as Julia does.

The best example is probably the differential equation solution type in Julia. When you have a solution `sol`, the interface gives you `sol[i]` as the values in the solution's time series and `sol(t)` the continuous solution of the differential equation. This are natural ways to describe both the discrete array-like and continuous function-like nature of an ODE's numerical solution, and that syntax wouldn't be possible without distinguishing a function call from indexing.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#247

Post by Stubb »

civility wrote: post #75
Stubb wrote: post #38

Earlier quoted context omitted.

Python without GIL to provide real shared-memory threading would address 90% of my issues with the language.

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains. Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

I'm using compiled libraries for all my heavy lifting—the Python code is there to glue those libraries together in convenient manner that allows for exploratory programming. GIL-free CPython would let me distribute computations across multiple cores without having to deal with the overhead of multiprocessing (serializing objects across process boundaries, etc.).

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#248

Post by 3JPLW »

mruts wrote: post #242
pavon wrote: post #238

Earlier quoted context omitted.

I love the use of end for blocks! It avoids the arguments about brace placement on one hand and problems with space sensitive indention on the other. It is simple, consistent, easy to read and write. Yes, easy to write. Seriously, I can type short words like end just as quickly as I can type shift-}, two keys off in the extremes of the keyboard layout. I think it gets a bad reputation from languages like bash that ha…

I mean, what about auto-generated code? Not only does using words forbid potential variable names, but it makes code generation more difficult as well (as does tabs). A good positive example is Haskell, which uses tab for normal block delineation, but also allows curly brackets (which is usually only used for auto-generated code). By sharing block delineation with variable namespaces, the language creates a whole bun…

Autogenerated code is very easy in Julia — there is no string processing at all. You can splice things directly into quoted code (working at the literal syntax level) or manually modify the `Expr` representation in a lispy manner (in which case there aren't any `end`s at all). Code generation is _really_ easy, thanks to its lispy inspiration.

Block delineation in Julia doesn't require the newline. You can just throw a ` end` at the end of the line. Often you'll see folks put the `;` line delimiter there, too, to make things super-clear (as that's generally how you delineate multiple expressions on the same line), but it's not required for an `end`.

And while it is indeed a little sad that you can't use `end` as a variable name, we make the most of it by using it to also represent the last index in an indexing expression like `A[end]`.

So, yeah, not a big deal at all, but very few of your detractions even apply in the first place. :)

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#249

Post by civility »

Stubb wrote: post #247
civility wrote: post #75

Earlier quoted context omitted.

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains. Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

I'm using compiled libraries for all my heavy lifting—the Python code is there to glue those libraries together in convenient manner that allows for exploratory programming. GIL-free CPython would let me distribute computations across multiple cores without having to deal with the overhead of multiprocessing (serializing objects across process boundaries, etc.).

If your compiled code is thread safe, you can releae the GIL in your library and achieve parallelism with current CPython. If your compiled libraries are not thread safe, you can't get parallelism anyway.

Maybe, if your heavy lifting functions are very short lived, releasing and acquiring the GIL is holding you back...

Btw, I'm not defending the GIL. Python has enough visibility and significance to deserve a good implementation. It's just that most people don't realize the slowness of CPython itself is a bigger impediment to performance than the GIL. Python should be in the same speed league as JavaScript, but there are too many things hindering progress.

Post reply on HN