|
People might know him better from Starlord / Guardians of the Galaxy.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
And what if you crossed Iron Man with a Sidewinder
|
|
|
|
|
Dunno, but if you crossed him with a steamroller, you'd get a Flatiron Man.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nice try, but you are probably too young to remember the Ironside TV series
|
|
|
|
|
A (Raymond) Burr needs an iron file, not an iron man.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
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 = <some_kind_of_cast> 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 think it has a lot of potential for general usage.
Being based on LLVM, it also has the capability of running on multiple system types. However, I did have to struggle to get it to run on my AMD K10 CPU due to the use of machine instructions that were not supported on my CPU.
For a language that is on V1.4.0, I give them much credit. I hope they are able to sustain their development efforts and take this to a level similar to MS Visual Studio or QT.
(Please remember: this a first glance on my part and subject to debugging.)
|
|
|
|
|
So, it's yet another scripting language? No thanks.
|
|
|
|
|
No, it's not a scripting language. It compiles into machine code using LLVM.
|
|
|
|
|
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.
|
|
|
|
|
You're right. See the sample code in the next message.
|
|
|
|
|
|
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 totalSize
# Read 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
end
end
# 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.
|
|
|
|
|
Statements do not need to be confined to a single line.
And semi-colons are permissible end-of-statement markers, just like C/C++.
|
|
|
|
|
|
Does look a lot like Fortran.
|
|
|
|
|
It has been initially designed for scientific computing, like Fortran/ADA/PL-I/etc.
|
|
|
|
|
|
Not sure about what you mean with Quote: classAVar = <some_kind_of_cast> classB.getter().toclassA().... but probably auto mitigates it.
By the way, it looks interesting. Thank you for posting.
|
|
|
|
|
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.
|
|
|
|
|
A lot of the code I mess with is pre-auto, some of it is even pre-computer.
|
|
|
|
|
A new programming language will save you from that just for few happy moments.
|
|
|
|
|
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.
|
|
|
|
|
I agree. Javascript is a giant PITA but I'm guessing it grew out of people trying to do simple things easily. It has just out-grown its pants.
|
|
|
|