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.
JuliaLang: The Ingredients for a Composable Programming Language
131–140 of 228 posts
Re: JuliaLang: The Ingredients for a Composable Programming Language
#132Earlier 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.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#133Earlier 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.
Re: JuliaLang: The Ingredients for a Composable Programming Language
#134Earlier 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…
Here's a revamp based on protocols https://github.com/apple/swift-numerics
Re: JuliaLang: The Ingredients for a Composable Programming Language
#135Earlier 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…
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
#136Earlier 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?
Re: JuliaLang: The Ingredients for a Composable Programming Language
#137Earlier 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.
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
#138Earlier 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…
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
#139Earlier 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…
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
#140Julia 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…
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.