- marmalade2413 parentIt's not akin to a psychopath telling you they're sorry. In the space of intelligent minds, if neurotypical and psychopath minds are two grains of sand next to each other on a beach then an artificially intelligent mind is more likely a piece of space dust on the other side of the galaxy.
- An absolutely fantast book. I've read it cover to cover a couple of times during my PhD (which focused on neural networks and numerical solvers). Gives the right amount of depth to serve as a detailed introduction whilst covering a lot of the key areas in optimisation. I still use this book as a reference years later.
- I recently picked up Gleam for a small medical imaging project and I can quite honestly say I've never had more fun with a language. Docs are great and the whole language is small enough to be learned in about an hour.
- Thank you! Ah I may need to work on improving the RSS reader. It seemed to work with my newsreader but it's far from perfect...
- Yes! It's not hosted via Emacs but here's the static site generation process: https://abdrysdale.phd/colophon.html
- I would be remis if after reading this I didn't point people towards talk box ( https://github.com/rich-iannone/talk-box) from one of the creators of great tables.
- Adding fuel to the fire of "this is over engineering" but this is overkill right?! I'm not in the web development field but my own site is just deployed with Emacs (specifically HTML generated from org-mode).
- I was going to write a response but you've put what I would have said perfectly. The problem, at least in academia, is the pressure to publish. There is very little incentive to write maintainable code and finalise a project to be something accessible to an end user. The goal is to come up with something new, publish and move on or develop the idea further. This alone is not enough reason not to partake in practices such as unit tests, containerisation and versatile code but most academic code is written by temporary "employees". PhD's a in a department for 3-4 years, Post Doc's are there about the same amount of time.
For someone to shake these bad practices, they need to fight an uphill battle and ultimately sacrifice their research time so that others will have an easier time understanding and using their codes. Another battle that people trying to write "good" code would need to fight is that a lot of academics aren't interested in programming and see coding as simply as means to an end to solve a specific problem.
Also, another bad practice few bad practices to add to the list:
* Not writing documentation.
* Copying, cutting, pasting and commenting out lines of code in lieu of version control.
* Not understanding the programming language their using and spending time solving problems that the language has a built in solution for.
This is at least based on my own experience as a PhD student in numerical methods working with Engineers, Physicists, Biologists and Mathematicians.
- The key elements that I consistently see missing when comparing languages is the cost/effort of maintenance and how easy is to write fast/slow code.
The former boils down to, there's little point saving time in the writing of new code when new versions of the language hinder the use of old codes. Julia, being a very young language, simply does not have the legacy of backwards compatibility that Fortran has and as a result libraries written today are unlikely to work in 10 years time. Partly because of Julia's age and partly because backwards compatibility is not valued as much as it is in Fortran. The GNU Fortran compiler can still compile code written nearly 50 years ago (https://gcc.gnu.org/fortran/).
The second point is that benchmarks like this seem to focus on tuned implementations, which is really important, but another important aspect is how easy is it write fast code. With Fortran, it is very easy to write very fast code as a lot is abstracted away from the programmer so they can focus on FORmula TRANslation. My experience with Julia has not been the same and thus for people don't have the time to perform such optimisations, Fortran may still be the better choice.
I do look forward to watching the development of Julia but for now I'll stick with using Fortran as the high performance numerical language in my tech stack.
I'll finish with something I've read but I can't remember from where:
Over the years there have been many examples of "X with replace Fortran" and the only thing that ends up getting replaced is X.
- The choice of 1 based array indexing is due to Julia having it's roots in mathematics - which is a common choice for mathematics based programming languages (e.g. Fortran, Julia, MATLAB/GNU Octave, Mathematica, R and Wolfram). The reason being is that matrix notation starts at 1 and not 0.
For a comparison on array indexing in different programming languages see here: https://en.wikipedia.org/wiki/Comparison_of_programming_lang...
From personal experience, I wouldn't let something as simple as starting index getting in the way of programming for a language as you'll soon start automatically switching to thinking in 1 based and 0 based indexing depending on the programming language.