4 Likes
McCarthy (invertor/discoverer of LISP) himself said, "Pure Lisp was a discovery , everything that has been done with it since has been an invention.
3 Likes
Flames? Hell no!
My management philosophy is roughly:
- Hire reasonably intelligent people to write code
- Give them enough rope to hang themselves very slightly
- Be supportive as they learn
Recreation:
Not pictured: my nice 8GB HP Chromebook, which I was hoping to turn into something of a modern Lisp Machine. It’s good as a Chromebook, I’m going to buy a 14" MBP soon. What kind of engineer am I if I can blow $3k on a Syntrx, but only spend $400 on my computer?
5 Likes
The only reason I still use Perl so much is because my coworkers would be even more upset if I used CL…
Luckily though I’m not working as a SWE right now and instead as a sysadmin so there’s “more rope” 
1 Like
Perl is a fantastic tool for that job. I can still, uh, bash out some perl code for batch/system tasks in my sleep. I made a promise to myself not to years ago, and almost always force myself to use python (maintainable!), or bash, or awk, or sed, or … as appropriate.
2 Likes
Probably a better thread for this be
6 Likes
I recently had to write a fairly nontrivial log parser and for the sake of my coworkers did a proof of concept in both Perl and Python. Perl smashed the Python implementation in terms of performance by a wide margin, but I suspect that has more to do with my lack of Python experience and less to do with innate Perl attributes.
This thread is getting pretty off topic so I’ll try to reign it in a bit:
I was on a team a while ago writing a distributed networked block storage system n Rust. We found the language to be pretty ergonomic and the compiler features/borrow checker/etc are extremely helpful for writing code that runs in the way you think it does.
With that said, after we got the proof of concept working and moved onto the performance, it became a complete nightmare trying to figure out how to maintain the sanctity of the various hot paths (no unsafe{}, etc) while trying to squeeze performance out of it. Perhaps this was a problem more with our engineering team than the language, and we were able to increase the performance quite a bit, but we ended up using unsafe{} quite a bit.
It left me with a weird taste in my mouth regarding Rust, it seemed to be that when the going started to get rough and you needed to start squeezing the hot paths, you were left with few options besides the usual C antics of throwing pointers around and other unsafe stuff.
To bring it back to the Elektron question, I’m fascinated by what they’re doing with it there. I can’t imagine doing Rust in a realtime environment. Maybe some more experienced Rust gurus could speak to it.
2 Likes
Will respect @Jukka’s suggestion but WRT SICP just wanted to drop this link with a contrary opinion (that I share). The structure and interpretation of the computer science curriculum — Northwestern Scholars
1 Like
Don’t know if you have noticed, but there is a ClojureScript legend here on Elektronauts. Not very active.
2 Likes
Even if that’s the case then there is still plenty of value in having a language where you have to add an explicit “here be dragons” flag.
It’s great documentation and encourages you to keep it to a minimum.
In C it’s very easy to do something crazy without even realising it’s crazy.
3 Likes
Double agree:
- Mods, please feel free to delete or move my comments here.
- I have no opinion on CS education. I believe you are the subject matter expert here, and I will happily defer to your informed opinion. That said, I’m enjoying working through SICP in my semi-retirement when I’m not noodling on the synths or trekking across the country.
FWIW, a few coding jobs in high school, and several read-thrus of GEB allowed me to speedrun a BS+CS degree at a highly competitive and well ranked engineering school. I’m weird and don’t expect this will work for many others. SICP is probably a better approach even if it is not particularly good on average.
3 Likes
Not trying to spoil your fun, but even for that purpose, there are things about it that would frustrate me. I came to an appreciation of this particular subject fairly late in life (and synths even later!).
1 Like
I’ve got a bottle of sake, a syntrx, lyra, chromebook, SICP and working A/C all in a decent suburban hotel. If you want to spoil my fun, you are going to have to step up your game. 
Oh, and something like 5 sets of headphones between the hotel and storage unit, for some reason. 
Can’t stop here, it’s Lisp country!
6 Likes
Anyway, conceptually, I feel FP is much easier to understand initially, over OO (Java/c++ class based OO).
We fill fledgeling engineers’ heads with this garbage and then they all go, “FP is too hard to learn”.
I didn’t go to school for SWE, (i actually went for Linguistics.)
I went to a bootcamp in 2013 and learned Ruby and some JS. l realized very early on in my career, if you write Ruby and Javascript functionally, (no side effects, no mutation of state, pure functions, composition, etc) You’ll have way less bugs. (Way harder to do in Ruby, but if you avoid state mutation and if/else statements you’re like 25% of the way there)
Eventually, we moved away from Ruby for new services and started writing them in Elixir (FP language on the Erlang BEAM virtual machine. and Rust for NIFs.) For anything that absolutely needs typing and needs to be fast we use a subset of OCaml/C libs. (stuff like audio finger printing.)
For those who do write javascript, you can learn the ins and outs of FP quite easily. I recommend the following.
and
And how this relates to rust,
Rust is primarily geared towards the procedural/imperative style of programming but it also lets you do the functional style of programming as well. I would even go further, The ownership model, standard library, emphasize on iterators, and numerous other things do lead to code that is usually most idiomatic when written in a functional style. It will unlikely be completely equivalent to a solution written in Haskell or Clojure. but it’ll get around some of the warts that people find mind boggling about Rust.
Thank you for coming to my TED talk.
Object Oriented - barely functional
Java
Truely - Multiparadigm Languages (even mix of OO and FP and others)
Ruby
JavaScript
Impure Functional Languages (Mostly FP with some other paradigms)
Elixir
Clojure
OCaml
Pure Functional Programming languages
Haskell
Imperative/FP
Rust
Imperative
C
6 Likes
I won’t take that as a challenge, but if and when you have the inclination, you might take a look at the Interpreters chapter of some of my recent writing. (Part II, which is more meaty from your point of view, will be posted in full by the end of the month.)
1 Like
I will and do. If you happen to have something commercially published, DM me and if it doesn’t cost eleventy million dollars I’ll buy the print/ebook.
1 Like
I developed my materials with public funding and a generous IP policy, so I’m putting everything on the Web (so I can maintain it) under a CC BY-NC-SA 4.0 license.
5 Likes
If I wasn’t now slightly bored with programming and thinking about moving into “people” (management/scrum/product), I’d be all over this. JS Allongé (and SICP) used to be on my TODO list. The snippets I read a few years ago had a wisdom and elegance I still crave in my code (but not enough to get fluent, at least not at the moment).
1 Like
There is a podcast episode with horrible sound but still good content interviewing Jimmy M at Elektron, they talk about the coding among other things.
8 Likes
Bookmarked.
2 Likes