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

JuliaLang: The Ingredients for a Composable Programming Language

white.ucc.asn.au

Post reply on HN
Print view View original

111–120 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#111

Post by JadeNB »

goatlover wrote: post #89
awb wrote: post #76

Earlier quoted context omitted.

Sure, some do, but past adoption is not a guarantee of future adoption. 20 years in the future is a long time. Just look at Flash. Who knows, maybe a Quantum OS will dominate that doesn't support Python. So yes, if someone will still be using Python in 20 years, I'm sure you're right. But Python just as easily could be relegated to a niche domain while other languages take over a broader range of applications. Especi…

I'm more responding to the idea that programming might become simple and automated, and we can't even predict technological changes a year or two out. You're right that Python could be relegated to a niche language in 20 years. That does happen. What hasn't happened is a fundamental change to programming languages since the 1960s, despite the incredible increase in computing power, ubiquity of computers and much bett…

> What hasn't happened is a fundamental change to programming languages since the 1960s

I think the rise of HLLs is an example of a fundamental change. It was still reasonable to be hand-writing assembler for lots of applications in the '60s.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#112

Post by mark_l_watson »

vasili111 wrote: post #44
mark_l_watson wrote: post #16

Earlier quoted context omitted.

I have a collection of short Julia code snippets that do non numeric things like text processing, semantic web clients, etc. But in general I agree. Fir me, Lisp languages, Haskell, and Python are more general purpose.

>Fir me, Lisp languages, Haskell, and Python are more general purpose. You mean Julia as language is not enough good for general purpose or it lacks ecosystem (frameworks, libraries) for general purpose use?

I didn’t express that correctly. What I meant to say was that I investigated Julia as a possible “use it for everything language.”

For me, general purpose has to include deep learning tools.

I really prefer Lisp and Haskell, but although Haskell’s TensorFlow support is pretty good, I found it easier to just use Python. I have had problems with the SBCL Common Lisp TensorFlow C bindings, but perhaps that was my fault.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#113

Post by mark_l_watson »

e12e wrote: post #68
mark_l_watson wrote: post #16

Earlier quoted context omitted.

I have a collection of short Julia code snippets that do non numeric things like text processing, semantic web clients, etc. But in general I agree. Fir me, Lisp languages, Haskell, and Python are more general purpose.

What part of Julia isn't lispy enough that you don't consider it a lisp? I'm not saying you're wrong, just because there a scheme in there, just curious.

The internal Scheme language was not easy for me to access.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#114

Post by huijzer »

Julia is by far the favorite language I have written code in. It is extremely expressive, while also being easy to read. Most design decisions are spot on. For example, the language has syntactic sugar, but not too much. Everything in the base library makes sense and seems to be there for a purpose.

Other niceties are the meta-programming capabilities, which allow for things like inspecting the llvm code and printing a variable name `x` plus output by only typing `@show x`. Then there is the fact that anonymous functions actually look like how you would describe a math function! (That is, `f(x) = 2x` is a valid function, as is `f(x) = 2π`.)

However, there is one thing I do not like at all. That is the loading time of packages. When starting julia and running `@time using DataFrames` it takes about 38 seconds when recompiling some stale cache. If all caches are good, the the load times for some common packages still add up to 1.1 + 4.5 + 1.1 seconds according to `@time using Test; @time using CSV; @time using Dates`. Therefore, nowadays I prefer to use R. For most of my use cases R outperforms Julia by a factor 10.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#115

Post by cwyers »

gugagore wrote: post #83
dcolkitt wrote: post #66

Earlier quoted context omitted.

> R shows how you can succeed just fine with a kinda weird language. One thing that most people don't appreciate about R is the subtle influence from lisp world. This makes it really feel like the language is optimized for data science down to the most basic syntax level.

I'd love an example of the subtle influence. In any case, the influence of lisp on julia is pretty obvious if you're familiar with lisp, I believe.

I believe that R was originally an implementation of S in Scheme, because of the restrictive commercial licensing of S and the desire to have a free-as-in-beer alternative that was S-compatible. This comes through in things like R's metaprogramming:

https://adv-r.hadley.nz/meta-big-picture.html#meta-big-pictu...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#116

Post by tgflynn »

cultus wrote: post #96
tgflynn wrote: post #27

Earlier quoted context omitted.

> multiple dispatch, which is strictly more powerful. In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. I can extend class B's functionality by adding only code that is specific to it. I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.

Single-dispatch OOP dispatches (implicitly) only on the first argument, self. That is how Class B can provide the functionality of A. Multiple dispatch can dispatch on all arguments. Thus, OOP single dispatch is a special case of multiple dispatch. In your example, functionality in class B can be written simply as ordinary generic functions, which are inferred to their most general compatible type without annotations…

Yes, but in Julia the problem is that inheritance isn't allowed from concrete types. So this example in Julia would mean that A is an abstract type whose objects can contain no data. So you have to figure out a way to implement functionality on A without having any data to work with. There are several ways to work around this but they all involve considerably more code complexity than would be required in a language like C++ that supports classes.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#117

Post by goatlover »

JadeNB wrote: post #111
goatlover wrote: post #89

Earlier quoted context omitted.

I'm more responding to the idea that programming might become simple and automated, and we can't even predict technological changes a year or two out. You're right that Python could be relegated to a niche language in 20 years. That does happen. What hasn't happened is a fundamental change to programming languages since the 1960s, despite the incredible increase in computing power, ubiquity of computers and much bett…

> What hasn't happened is a fundamental change to programming languages since the 1960s I think the rise of HLLs is an example of a fundamental change. It was still reasonable to be hand-writing assembler for lots of applications in the '60s.

Sure, but HLLs are decades old and ubiquitous by the 80s. There's no reason to think PLs are going to fundamentally change in 20 years. They could, but it's just speculation at this point.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#118

Post by jamescont »

mark_l_watson wrote: post #113
e12e wrote: post #68

Earlier quoted context omitted.

What part of Julia isn't lispy enough that you don't consider it a lisp? I'm not saying you're wrong, just because there a scheme in there, just curious.

The internal Scheme language was not easy for me to access.

Same here bro

Re: JuliaLang: The Ingredients for a Composable Programming Language

#119

Post by tgflynn »

vanderZwan wrote: post #87
smabie wrote: post #10

Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension c…

> It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday I was under the impression that if you write a function that takes very specific sub-types as its parameters, and then try to call it with invalid parameters (that is, values that cannot be converted to the right type via the promotion rules) that Julia will complain about this?

It will complain, but typically only at run time.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#120

Post by int_19h »

baron_harkonnen wrote: post #63
FranzFerdiNaN wrote: post #15

Earlier quoted context omitted.

Python will still be used 20 years from now. The clear advantage of Python is the enormous ecosystem that is available, the millions of questions on SO giving solutions to every problem you can run into, the books and learning materials etc, programmers and corporations having invested loads of time and effort in building, maintaining and battle-testing libraries. Don't get me wrong, i think Julia is an amazing langu…

I remember when Python was a new and exciting language and people said the exact same thing about Perl. "You'll never see Python replace Perl for string processing, Perl has such a huge ecosystem!". At the time Perl was the de facto interpreted/"scripting" language. Sure Perl is around still, but it has become a rather niche language used in a small number of specific communities. I use Python everyday, and still hav…

Python replaced Perl in many niches, because Python was better suited to general tasks. For string processing, it wasn't as convenient, but there were so many other things where it was clearly a better choice. And being able to use a single "good enough" language for everything is itself a major convenience.

Julia is the opposite - it's better than Python in one particular narrow niche, and cannot replace it broadly. So it has to offer enough to justify going from one language to two.

Post reply on HN