Live data from Hacker News

JuliaLang: The Ingredients for a Composable Programming Language

white.ucc.asn.au

131–140 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#131
post #30
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.

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 there are some compilers for some Julia code as mentioned in this thread)

Re: JuliaLang: The Ingredients for a Composable Programming Language

#132
post #94
post #77

Earlier quoted context omitted.

More than this, C is from the 70s, and C++ is from the 80s. This is 50 years from now for C. So I'd say python is likely to be still here 20 years from now, given how popular it is.

Python will still be around, but how popular it'll be is an open question. For example, Pascal or Perl were huge in their prime, and while they continue to stick around, the torch has been passed on.

Sure, but if Julia relegates Python to a niche and Rust does the same thing to C, they're still the same kind of approach to programming, and not some high level, mostly automated thing. They don't fundamentally change how people program.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#133
post #30
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.

Presumably this means that no one has implemented a suitable static type checker or its type annotations don't provide sufficient information for a static type checker to work in principle?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#134
post #126

Earlier quoted context omitted.

I am a big fan of Julia, but Swift is perhaps the only statically typed object-oriented language (apart from Objective-C) which I have found offers some similarity in flexibility to Swift's way of dealing with types. With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia. It means you can take an existing class which…

> With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia. You can add methods or computed properties, but that's about it. That's only one axis of flexibility, and it's really only syntactic sugar for writing and calling your own functions. You can't add any other kinds of features, unless they chose to use protocols…

So it's a package, not a language issue?

Here's a revamp based on protocols https://github.com/apple/swift-numerics

Re: JuliaLang: The Ingredients for a Composable Programming Language

#135

Earlier quoted context omitted.

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be include…

How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it…

I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this.

Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#136
post #108

Earlier quoted context omitted.

Sure! 'C' in the debug REPL enters compiled mode. https://github.com/JuliaDebug/Debugger.jl#compiled-mode

I guess what I don't understand is this part (regarding the compiled mode): "The drawback is of course that breakpoints in code that is stepped over are missed." what exactly does that mean?

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

Re: JuliaLang: The Ingredients for a Composable Programming Language

#137
post #57

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…

> Python will still be used 20 years from now So much technology has come and gone since 2000. If innovation continues to accelerate I'd be hesitant to predict what 2040 will look like. Programming might become so simple and automated that we won't need StackOverflow to the extent we do today. It's really hard to predict the next year or two let alone the next 20.

>So much technology has come and gone since 2000. If innovation continues to accelerate I'd be hesitant to predict what 2040 will look like.

Not much core technology -- e.g. programming languages and their ecosystems.

Frameworks, or specific business cases or tools ('grid computing', 'big data', 'no sql' etc) sure...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#138

Earlier quoted context omitted.

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be include…

How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it…

Languages like Python, Rust, C# or even Java have module systems that I find are more restrictive, but much easier to follow. You always have the pertinent information at hand. Each file containing code clearly tells you two crucial pieces of information:

1. Where the code fits in the greater picture

2. Where the dependencies of the code in a file come from

Python, whose module story is actually pretty poor, is still easier to follow than Julia, because it just matches the file/directory structure. You can reason about the hierarchy of a python library by just navigating the directories. In a normal python project, each file is one module and it's dependencies are clearly specified as imports.

Rust relies on the file system as well, and much better defined rules than Python. I find this great, because the file system is already hierarchical and we are used to the way it works. When I open a file in a Rust project, I know immediately where it fits in the hierarchy - because it is implied from the file system. Rust gives you a bit more flexibility in that you can define submodules in each file.

C# & Java qualify the namespaces fully in each file. While the file structure is not as clear anymore at the file system level, a single file contains all the information necessary to determine where the code fits in and where it's dependencies come from.

Now let's take Julia:

A single module will be often split across multiple files. Since they share a single namespace, the imports happen at the top level where the module is defined and includes all it's source files. When you open a source file, you have zero information where all the functions and data types are coming from (or where they are going for that matter).

I see the following pattern systematically emerge in Julia code:

- A function is defined in file A

- File A is `included` in file B, where it forms part of module X

- It is then imported into module Y in file C, but it is not actually used there

- As it is finally used in file D, which is `included` in module Y in file C itself

The problem is that there is no link from file A to file B, or module X for that matter. File A could be part of a dozen modules, or zero. Neither is there a link between the usage of the function in file D and where it is coming from. You actually have to find all the places where file D is included, and then check what flavor of the function does each location import. The relationships are established at some indeterminate level in the hierarchy.

Again, don't get me wrong, this is just a wart on an otherwise very pleasant language. I wouldn't be complaining if I weren't using it.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#139
post #76

Earlier quoted context omitted.

Programming languages from 2000 remain, though. C, C++, Java, JS, Python, etc. Even Fortran, Cobol and Lisp remain in use. There’s been attempts since the 80s to popularize visual and and higher level approaches to programming, but the traditional languages still dominate. And the newer ones like Go, Elixir and Julia are like the traditional C, Lisp and Fortrans.

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…

>Sure, some do, but past adoption is not a guarantee of future adoption.

Not a guarantee but still the best predictor.

>20 years in the future is a long time. Just look at Flash.

Flash had a lot of things against it. Proprietary (aside from niche implementations nobody really cared about or used), single vendor, not owing its platform (browser vendors owned it), and not really that useful (aside from casual online games its main other use was small animations and intro pages).

And even then, it also took the combined effort of 3 browser vendors to kill it, and its public ousting from its mobile platform from the biggest company on Earth...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#140
post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

I don't understand type systems very well. When you say "check correctness" do you mean something beyond static linting with type-hints, like in Python? Or do you mean something deeper, like in functional languages like Elm and F#?

Also, is there always a trade-off between types and flexible meta-programming? Like, OCaml has meta-programming capabilities, but they make type-checking way harder, according to my PhD friend who's written extensively in Scheme and OCaml.

Post reply on HN