Julia programming language
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
So, it's yet another scripting language? No thanks.
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
So, it's VB?
-
So, it's yet another scripting language? No thanks.
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
Interesting post, it seems very popular on Slant: programming-languages-for-data-science[^]
-
Compiled/interpreted isn't a determinant of whether or not a language is a scripting language. BASIC can be either, yet isn't a scripting language. Perl can be either, yet is a scripting language.
-
So, it's VB?
No. Here's a small sample I was messing with
module A
function ProcessDir(topDir)
global dirCnt # Declare these variables as global so they
global fileCnt # can be used in the main code.
global totalSizeRead recursively through the top, counting directories and files, totaling the
file space used and printing the directory or file name to stdout.
for (root, dirs, files) in walkdir(topDir) # walkdir function returns tuples for dir in dirs # Count directories i aDir = joinpath(root, dir) # Create fule path name--same as "root \* '/' \* dir" dirCnt += 1 println("Directory # ", dirCnt, " = ", aDir) end for file in files # Count files and total file sizes. if ((file == ".") || (file == "..")) continue end if (endswith(file, ".md")) # Select only files with a suffix of "".md" fileCnt += 1 fn = joinpath(root,file) sz = stat(fn).size # Get file permissions and file size totalSize += sz println("File # ", fileCnt, " = ", fn, ", size = ", sz) end end endend
Main processing in this module
dirCnt = 0
fileCnt = 0
totalSize = 0
subDir = ".julia"
println("Starting directory processing")
ProcessDir(joinpath(homedir(), subDir))
println("Directories = ", dirCnt, ", Files = ", fileCnt, ", Total size = ", totalSize)end
:
-
Compiled/interpreted isn't a determinant of whether or not a language is a scripting language. BASIC can be either, yet isn't a scripting language. Perl can be either, yet is a scripting language.
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
-
No. Here's a small sample I was messing with
module A
function ProcessDir(topDir)
global dirCnt # Declare these variables as global so they
global fileCnt # can be used in the main code.
global totalSizeRead recursively through the top, counting directories and files, totaling the
file space used and printing the directory or file name to stdout.
for (root, dirs, files) in walkdir(topDir) # walkdir function returns tuples for dir in dirs # Count directories i aDir = joinpath(root, dir) # Create fule path name--same as "root \* '/' \* dir" dirCnt += 1 println("Directory # ", dirCnt, " = ", aDir) end for file in files # Count files and total file sizes. if ((file == ".") || (file == "..")) continue end if (endswith(file, ".md")) # Select only files with a suffix of "".md" fileCnt += 1 fn = joinpath(root,file) sz = stat(fn).size # Get file permissions and file size totalSize += sz println("File # ", fileCnt, " = ", fn, ", size = ", sz) end end endend
Main processing in this module
dirCnt = 0
fileCnt = 0
totalSize = 0
subDir = ".julia"
println("Starting directory processing")
ProcessDir(joinpath(homedir(), subDir))
println("Directories = ", dirCnt, ", Files = ", fileCnt, ", Total size = ", totalSize)end
:
IMHO, needing to keep your statement confined to a single line gives me more of a 1970's feel, than anything elegant. I don't feel like a lack of semicolons is a help, and it's one of the things I like least about Python.
-
No. Here's a small sample I was messing with
module A
function ProcessDir(topDir)
global dirCnt # Declare these variables as global so they
global fileCnt # can be used in the main code.
global totalSizeRead recursively through the top, counting directories and files, totaling the
file space used and printing the directory or file name to stdout.
for (root, dirs, files) in walkdir(topDir) # walkdir function returns tuples for dir in dirs # Count directories i aDir = joinpath(root, dir) # Create fule path name--same as "root \* '/' \* dir" dirCnt += 1 println("Directory # ", dirCnt, " = ", aDir) end for file in files # Count files and total file sizes. if ((file == ".") || (file == "..")) continue end if (endswith(file, ".md")) # Select only files with a suffix of "".md" fileCnt += 1 fn = joinpath(root,file) sz = stat(fn).size # Get file permissions and file size totalSize += sz println("File # ", fileCnt, " = ", fn, ", size = ", sz) end end endend
Main processing in this module
dirCnt = 0
fileCnt = 0
totalSize = 0
subDir = ".julia"
println("Starting directory processing")
ProcessDir(joinpath(homedir(), subDir))
println("Directories = ", dirCnt, ", Files = ", fileCnt, ", Total size = ", totalSize)end
:
reminds me a bit of ADA
-
No. Here's a small sample I was messing with
module A
function ProcessDir(topDir)
global dirCnt # Declare these variables as global so they
global fileCnt # can be used in the main code.
global totalSizeRead recursively through the top, counting directories and files, totaling the
file space used and printing the directory or file name to stdout.
for (root, dirs, files) in walkdir(topDir) # walkdir function returns tuples for dir in dirs # Count directories i aDir = joinpath(root, dir) # Create fule path name--same as "root \* '/' \* dir" dirCnt += 1 println("Directory # ", dirCnt, " = ", aDir) end for file in files # Count files and total file sizes. if ((file == ".") || (file == "..")) continue end if (endswith(file, ".md")) # Select only files with a suffix of "".md" fileCnt += 1 fn = joinpath(root,file) sz = stat(fn).size # Get file permissions and file size totalSize += sz println("File # ", fileCnt, " = ", fn, ", size = ", sz) end end endend
Main processing in this module
dirCnt = 0
fileCnt = 0
totalSize = 0
subDir = ".julia"
println("Starting directory processing")
ProcessDir(joinpath(homedir(), subDir))
println("Directories = ", dirCnt, ", Files = ", fileCnt, ", Total size = ", totalSize)end
:
Does look a lot like Fortran.
-
Always a glutton for punishment, I started experimenting with the Julia programming language a few days ago. Here's some of my takeaways (keep in mind I'm a newbie to this language and environment, so these are first impressions). 1) On the language itself -- "Mikee likes it." I like a lot of thing about language itself. After working in C, C++, Pascal, Fortran, and few dozen other languages, I like the simplicity and structure of the language while it maintains a high level of capabilities. C++ is just sometimes too time consuming with its strong variable typing such that many statements become "classAVar = classB.getter().toclassA()....". Julia pretty much infers a variable's type from its usage. (You can have strong typing for a variable if you want.) Statement structure tends to be simpler and clearer: no need for statement ending ";", if condition statement(s) end for x in statement(s) end 2) I like the "module" approach which is similar to javascript. Just "import" a module. No need for separate header files/class definitions/etc. All too many times, I've had to spending a lot of time trying to find where a function was located (one of my pet peeves is that some people like to mix putting executable code in a header file or in the body). 3) Lots of automatic conversion for strings to integers/floats and vice versa. But you can override them. 4) Lots of capabilities for arrays, tuples, and vectors. Some are a little obtuse and higher on the learning curve. Now for the bad news: 1) Build time is longer than most languages. Takes a long time to go from edit to test. 2) Primary development environment is REPL with IDE's are based on the Atom editor with Juno plugin. It's OK, but on a scale of 1-10, I'd give it about a 4. Not very efficient compared to MSVC or Qt Creator. Some things are downright cludgey. 3) Documentation is skimpy in both explanations and examples. Learning effort is substantial. 4) GUI support is based on GTK and needs substantial more development. Overall: Bottom line--I like it, but it is early in its life cycle. Just released in 2018, I commend the authors for what they have accomplished. Their intent was to take the best from other languages such as C++, Lisp, Fortran, etc., and to that end, I believe they have accomplished what they set out to do. It is obvious that they targeted (and they have said as much) the scientific/engineering market place. But, I thin
Lack of strong typing means huge runtime bugs when things scale. People need to stop writing junk software in junk langs only good for basic code scripts. Has javaScript / Python taught anyone anything? Bloated, slow and more prone to runtime bugs all thanks for the lack of strong types. No thanks in hell.
-
Not sure about what you mean with
Quote:
classAVar = classB.getter().toclassA()....
but probably
automitigates it. By the way, it looks interesting. Thank you for posting. -
IMHO, needing to keep your statement confined to a single line gives me more of a 1970's feel, than anything elegant. I don't feel like a lack of semicolons is a help, and it's one of the things I like least about Python.
-
Does look a lot like Fortran.
-
Lack of strong typing means huge runtime bugs when things scale. People need to stop writing junk software in junk langs only good for basic code scripts. Has javaScript / Python taught anyone anything? Bloated, slow and more prone to runtime bugs all thanks for the lack of strong types. No thanks in hell.
-
The way I understand julia is that all variables are "auto" unless you explicitly type them. The example I used was kind of a generalization of a lot of C++ code I've looked at where I had to read through a bunch of noise to get to what was intended.
-
Quote:
The way I understand julia is that all variables are "auto" unless you explicitly type them.
So it is the other way around.
Quote:
The example I used was kind of a generalization of a lot of C++
It looks 'pre-auto' code.