JuliaLang: The Ingredients for a Composable Programming Language • Hacker News Board

Re: JuliaLang: The Ingredients for a Composable Programming Language

#171

Post by eigenspace » Mon, Feb 10, 2020, 10:36 PM UTC

cosmojg wrote: post #150

eigenspace wrote: post #102

Earlier quoted context omitted.

Right, but you said > there will no longer be any reason to use any other garbage-collected language . (emphasis mine). I was just curious as to why you specified garbage collected there.

I equate garbage collection with larger static binaries. Julia's static binaries are especially large since they package the entire sysimage. I'm excited about StaticCompiler.jl because, by cutting out the sysimage, it promises to make Julia more competitive with other garbage-collected languages like Nim, Go, Crystal, etc., all of which produce relatively small static binaries. However, like these other garbage-coll…

I see, thanks for the explanation!

I think with StaticCompiler.jl, if you create a binary where the compiled code knows there won't be any GC, for instance, say you only ever work with Tuples and floating point numbers, I don't think there will be any GC runtime in the compiled binary.

I could be wrong about this though.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#172

Post by hpcjoe » Mon, Feb 10, 2020, 10:39 PM UTC

real_eng_ wrote: post #33

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…

Why every Julia user can't help but trash Python at every occasion? It's getting really tiring

Hrm ... I recall Pythonistas trashing Perl as line noise, and other languages as well, for many many years. I'm not saying its right, just that karma, sometimes, comes back into focus.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#173

Post by JustFinishedBSG » Mon, Feb 10, 2020, 10:40 PM UTC

Iwan-Zotow wrote: post #164

socialdemocrat wrote: post #28

Earlier quoted context omitted.

Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math. I work with both and I never found this a big problem. This is on par with com…

Whatever I'm doing this is wrong. Simple example - I have Python sequence [0...N) to process. If members are independent, I could split it with easy in Python and do it in parallel: [0...N) -> [0...M) + [M...N) for any M between 0 and N. Basically, Python sequences/ranges/etc are monoids in many cases. Simplest composition rule - monoid, with unit element and associative composition. In Julia it really looks ugly, yo…

You're inventing problems that don't exist. Every thing you said is applicable exactly with 1, 2 or whatever based indexing. It literally doesn't matter.

Julia's sequences/arrays are monoids too, I don't see what it has to do with anything.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#174

Post by socialdemocrat » Mon, Feb 10, 2020, 10:41 PM UTC

byt143 wrote: post #161

socialdemocrat wrote: post #159

Earlier quoted context omitted.

I don't think so, I may be wrong, but I am quite sure you would get a significant performance penalty in Swift if you used protocols all over the place. For instance if `func foo(bar: Number)` in Swift would give bad performance I believe as the number object would have to be boxed. Julia can work with abstract types in a lot of instance without getting any performance penalty due to how the Julia type system works a…

Perhaps this helps? https://github.com/apple/swift-evolution/blob/master/proposa... and this https://twitter.com/jckarter/status/1202260205074968578

Must confess I am a bit too tired to parse that text effectively at the moment, but I don't think that is a solution. It is basically a solution to deal with generics across libraries. In C++ this is a big problem right. Templates cannot really be put in libraries. You put them in header files.

So if you put generics in a library and link it, how are you going to know what to specialize and what not to specialize? That is the problem it seems to be they are solving here.

But this is still a compile time issue they are solving. What I am talking about is an issue that happens at runtime.

If I call a function f(x, y, z) and don't know the exact types of x, y, z at compile time, then Swift has no way of generating an efficient implementation of f. Julia OTOH due to its support for multiple dispatch CAN create an efficient implementation of f(x, y, z) for all possible types of x, y and z.

Actually on further reflection I cannot see any way an AOT compiler can solve this problem. Say you got this definition:

    f(x: Number, y: Number, z: Number)

A Swift library could in theory compile all sorts of concrete variations of this function for concrete number types. However there is no way it can provide all number types. The user could provide new subtypes of Number not known when the library containing f was created.

I was a big Swift fan before and did not like JITs but Julia really convinced me how absolutely amazing Just in Time compilation is, especially combined with a dynamic language. You can just do so much crazy stuff that you have no way of achieving in a sane way in a statically type ahead of time compiled language.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#175

Post by socialdemocrat » Mon, Feb 10, 2020, 10:56 PM UTC

FranzFerdiNaN wrote: post #15

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…

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…

> The clear advantage of Python is the enormous ecosystem that is available

Could have said that about Perl back in the day too, or a great number of languages.

The key problem Python faces competing against Julia in the long run is that Julia runs faster with less resources. By that I mean that because packages in Julia combine easier and are written all in Julia, it is simply much faster to develop equivalent functionality in Julia compared to Python.

Thus as Julia grows the speed of advancement will just keep growing. There is also a sort of asymptotic curve for most software. As you reach certain complexity advancing gets slower. Python due to its age has acquired a lot of cruft which will slow development down.

I know exactly how this feels from having worked on very similar software products of different age. The older software really had problems keeping up speed. The younger software moved ahead faster due to cleaner design. We needed far less people to add more features than the competition.

Python will struggle with old design decisions it can no longer undo. Look at e.g. the enormous amount of man hours required to get JIT compilation working in Python. It still does not work well. Meanwhile Julia has require less manpower making a whole language with better JIT compilation.

Language design matters over time. I don't claim Julia will overtake Python any time soon. But over a long time frame I think it is inevitable, because legacy goes against Python in too many areas.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#176

Post by mkborregaard » Mon, Feb 10, 2020, 10:58 PM UTC

UncleOxidant wrote: post #149

StefanKarpinski wrote: post #136

Earlier quoted context omitted.

It means that if you would have hit a breakpoint in code that is run in compiled mode, the breakpoint doesn't trigger—because it's being run normally at full speed without breakpoints, not being interpreted in the debugger (which knows about breakpoints).

I read this as in compiled mode breakpoints don't trigger at all. Is that correct? Edit: Ok, I tried out compiled mode and it does stop at my breakpoint. The verbage in the documentation is a bit difficult to understand on this point. I'd guess you need to first set your breakpoints prior to going into compile mode?

Learning a lot from this thread, seems really usfeul

Re: JuliaLang: The Ingredients for a Composable Programming Language

#177

Post by mkborregaard » Mon, Feb 10, 2020, 11:01 PM UTC

hpcjoe wrote: post #163

Recurecur wrote: post #145

Earlier quoted context omitted.

"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." How so? Julia is a fine general purpose language. I'd go so far as to say it's more appropriate than Python for a wide class of problems!

In many ways, Julia is a better python than python, if only for the lack of the (quite insane in the 2000s) program structure by text formatting. That is a misfeature. Julia is fast out of the box. You don't need Julia + some-other-language to get performance. You can use your GPUs fairly trivially from within the language (though this is implemented as FFI, it still has an idiomatic feel to it). As for the previous…

Program structure by text formatting is a misfeature, though. What you do need though to make sure code remains readable is strong convention. I think actually that's the most unique feature of Julia (as also alluded to in the post) - how much of julia's ecosystem that works because of social convention (and conversation).

Re: JuliaLang: The Ingredients for a Composable Programming Language

#178

Post by socialdemocrat » Mon, Feb 10, 2020, 11:03 PM UTC

int_19h wrote: post #120

baron_harkonnen wrote: post #63

Earlier quoted context omitted.

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.…

> 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.

Absolutely disagree. I will claim Julia is a BETTER general purpose language than Python. I am not an academic or researcher. I use Julia over Python because I find it better is almost every regard apart from startup time ;-)

Julia outdo Python as a glue language. Integration with C/C++, Fortran, Python, R and the shell is awesome.

I have rewritten large bash shells as Julia code. Due to the need for having a language more broadly available on customer computers, I tried rewriting it in Python. I found that far more painful.

Package management is IMHO superior in Julia. REPL environment is superior. Expressiveness of language is superior. Nothing in Python matches the power of Julia macros. Multiple dispatch is insanely useful and dead easy to use. Python has nothing like it out of the box.

That you can more easily redefine types at runtime and full class hierarchies can offer some advantages at times. However I don't find that it makes up for the power of multiple dispatch and macros.

Don't make the mistake of thinking that Julia is only suitable for scientific work, because that is where it is currently used.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#179

Post by socialdemocrat » Mon, Feb 10, 2020, 11:15 PM UTC

smabie wrote: post #30

sgt101 wrote: post #13

Earlier quoted context omitted.

could you expand on the "too bad typing is only for dispatch"? I've enjoyed the way that the Julia type system can be used...

It can’t be used for compile time correctness checking? i.e Julia isn’t a statically typed language.

You can do some form of type checking with stuff like Lint.jl. I mean since Julia uses a bunch of type information and Julia parses code into data structures which are easy to process, you can to a lot of your own type verification before running a program.

However I see Julia not being a statically typed language as a feature. If Julia was statically typed you would pretty much have lost everything that makes Julia a great language.

You cannot do multiple dispatch with a statically typed language efficiently.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#180

Post by socialdemocrat » Mon, Feb 10, 2020, 11:30 PM UTC

Symmetry wrote: post #158

sgt101 wrote: post #131

Earlier quoted context omitted.

Yes - I understand why some people are keen on static types, but type inference is a powerful way to create funcetionality and I believe that the separation of concerns between the dispatcher and the programming code (removing the logic of decisioning from the code and using type inference instead) leads to clearer programs. I can't think how you can have that and have static checking as well (although I know that th…

Lots of languages with static typing use type inference. Haskell, OCaml, Go, Rust, Nim, etc. Even C++ has auto these days which I think when combined with templates gives you what you're talking about though it is a bit clunky. EDIT. For instance in Haskell I can just declar a function to sum the things in a container by saying summer a = folder (+) 0 a And the compiler will figure out that the function accepts a Fol…

I think he possibly phrased it wrong. Dynamic languages don't do type inference, they carry type with each value at runtime.

Dynamic and statically typed languages each have their own wonderful advantages. There is just no way of replicating all the advantages of dynamic typing in a statically typed language.

It is hard to sum up why in a short sentence but I have tried to articulate it in a longer article here:

https://medium.com/@Jernfrost/the-many-advantages-of-dynamic...

Keep in mind this focuses only on advantages of dynamic languages. It does not mean I don't consider that static languages don't have their own unique advantages, but that was not the topic of my article.

The primary problem with static typing as I see it is the complexity and mental overhead it adds. It is not just the complexity in the type system and the language itself, but also in the tooling surrounding it: build system, dependency management, binary interface definitions, debuggers, REPL etc.

The complexity makes meta programming very hard to do for a software developer of average intelligence.

Where I see a use for advance static languages is for very specialized systems which need a high level of correctness and where a company is able to do the job with a small team of very bright people.