You've also extrapolated your anecdotes to make a sweeping statement that implies that all FP is spaghetti.
You've made no objective counterpoints. Reducing any platform or language to "bad" sounds like someone that never quite understood the benefits of FP. Imperative languages are no silver bullet. Literally every code base that I'd ever worked in exhibits the same issues you describe as "spaghetti". But how does FP make it more so?
Do you write unit tests? Tell me how you've not come across a codebase in a non-FP language that didn't require some insane fixture or factory or set-up code and it was insanely difficult to reason about because you had to invoke methods in a particular order to set an object up to be tested for a particular scenario. This is not the case with functional languages. You don't get the rug pulled out from under you very often and if so, it's typically centralized in the "actor" or process whose state can change whereas state is EVERYWHERE in most imperative languages and even challenging at times to introspect, especially when encapsulation is done right in some languages.
Just because you've written more detailed points does not mean that they're valid or good. It just means that you have thoughts.
If you've asked people to send you good projects, then you're already in a mental state that disallows you from accepting a good project. There are many. Don't ask, just search on GitHub -- many projects that don't even come from core devs. It's been much easier for me to reason about and push fixes to these projects compared to Ruby or JavaScript projects.
I mean, we get it. You hate Elixir and you hate FP. You're entitled to that opinion, but please don't tell others to stop using it without having worked with it heavily and an accepting mentality to dig beyond the surface.
This is a fair thought. It's why some wonder why people use Vim, emacs, or keyboard shortcuts in general...
However, one of my reasons is that I work out of coffee shops a lot. Not having to bring an extra piece of hardware that takes up space is a big deal for me and not taking my hands off the keys is a big deal.
I was a gamer (Counter-strike), and as precise as I believe my mouse-clicking to be, it is far less precise than the correct sequence of keystrokes to get to some parts...
Readline shortcuts available in most shells, i.e., ctrl-a (beginning of line), ctrl-e (end of line), meta-b (back a word), meta-f (forward a word).
In Vim - I can delete entire code-blocks with a quick sequence and have my cursor ready to type, and I can move chunks of code with their delimiters far more easily than my fairly precise mouse clicking and highlighting then moving my hand back to the keyboard to hit backspace. I can also switch to a "tab" (buffer in Vim) with a few keys without having to cycle through tabs or use a mouse to find the tab I'm looking for with a mouse.
There are many benefits, it's why even though text editors have come so far, people still continue to write Vim plugins for them -- think VS Code, Atom, and all the IDEs that Jetbrains produces...
Don't know about the comp levels but the title / experience / pay seems totally whacky - a staff-level engineer with a total of 5-7 years of experience? IME this role is for very experienced ICs who don't move into management but are still key leaders.
Has title inflation followed the general trends of post-secondary grade inflation?
Richie -- absolutely absolutely stunning and incredible!
I thought I was making strides. I've taken two BradfieldCS courses and have had some personal mentoring from Myles even before Bradfield was born.
If the original question asker is reading this thread, I can lend some more insight having done MOOCs and Bradfield.
First off, Oz and Myles are behind teachyourselfcs.com, one exceptional and concise site which their curriculum is sort of based off of. Oz is also the author behind, "You Are Not Google" that was HUGELY popular on here a couple years back.
The thing that Oz and Myles brought was their incredible enthusiasm coupled with their passion for mathematics and computer science. They were practitioners teaching at it from a practitioner's perspective with the goal of providing another practitioner the CS most applicable to their jobs. These courses were in-person in San Francisco for a while (but no longer). Look up either Myles or Oz on Twitter and you'll notice that they're very much still engaged in technical conversations and the computer science and how to teach it today.
The one thing I always always took away from the teachyourselfcs.com site is the section under, "Why learn computer science?"
> There are 2 types of software engineer: those who understand computer science well enough to do challenging, innovative work, and those who just get by because they’re familiar with a few high level tools.
> Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers progress toward more fulfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership or high-quality individual contributions.
I have an inkling that Richie, right here, is EXACTLY what they were talking about when drafting this. This blog post exemplifies this.
I've learned so much from the both of them, but I can honestly say, Richie, if you're reading this, this was a f*ckin' gem! Would love to grab coffee with you some time once the pandemic's over.
> It felt like each library had its own idioms and syntax rules
This sounds like the way software should be. No? Domain-driven design? Or are you saying that they don't follow industry nomenclature?
> It was hard to have consistent architectural patterns across a team
Is this a symptom of everyone being new the language on the team or the language itself? Elixir is a very simple language compared to Python and Ruby in my experience. There are certainly way more people that have done the latter two. What's comfortable isn't always better.
I'm wondering how aware of the trade-offs you are in using an imperative language as compared to one that's functional. If the nitpick/gripe you're having is around readability and syntax, I'm sure there are enough counters in other languages that you've worked with where the code was just spaghetti and hardly testable
Have you considered that productivity comes more with time? I get the sense that you've worked in a team with very few experienced developers that have either worked with Elixir/Erlang or functional languages. My experience has been that those with extensive experience in OO or imperative languages w/o ever treading into FP have had a much harder time adopting Elixir and it has resulted in slower development early on, but those willing to learn, march much faster after ramp-up.
But if you value correctness, less bugs, and easily testable code, it's hard to beat functional languages in this area, and I'm not even talking about just Elixir
> I've seen an elixir/phoenix backend rewritten completely in python/django and it was a big improvement in developer productivity.
Is this really a better idea? If you're mentioning "consistency enforcement", why not use Golang? Elixir also has a formatter built into its toolchain.
Take my responses with a grain of salt -- because if you're just doing a CRUD app and not buying into what the BEAM gives you from an operational perspective, it's probably not that worthwhile?
Recently started my journey with Rust having worked with Elixir in production for about two years, but I keep an ear out on Rust and Elixir/Erlang development
My question: are you familiar with the Lumen project? https://github.com/lumen/lumen#about. Both projects appear to have some overlap. Secondly, what, if any, will be the primary differentiators here? (I've not looked at either projects in too much detail)
One of its creators, Paul Schoenfelder (Bitwalker), you're probably familiar with as he's authored a few popular libraries in Elixir and the other core developer, Luke Imhoff, is ensuring that WASM is taking players like Elixir/Erlang into account being a part of one of the organizations or committees if I recall correctly
I second this - I come from a self-taught background and have been moving down the stack since and am 80% through the Rust Programming Language book. I am very excited with this and am happy to help where I can :)
Like someone else had mentioned, the list is comprised of channels geared heavily at web development featuring content for early career developers.
There are a ton of channels that dig deeper in more general software and particulars:
1. Algorithms Live! for those that are into competitive programming
2. PapersWeLove for those that are into white papers and the research that underpins some of the systems that we use today
3. 3Blue1Brown for mathematics
4. ThePrimeagen for Vim and other software things
5. Gaurav Sen for digestible chunks of system design components
6. code_report for just programming. The author is going through Structure and Interpretation of Computer Programs (SICP) at the moment
7. commaaai archive for following George Hotz, founder and creator of comma.ai, a self-driving car company. He was a former Googler working on zero days (security)
8. Jon Gjengset for Rust. He's got a lot of great videos as an open-source contributor in Rust projects and was most recently at MIT doing his PhD
9. Bitwise is a bit old (last post was a year ago), but former Oculus lead dev teaching folks about compilers, simulators, FPGA-based hardware, and other low level topics from a practitioner
10. Two Minute Papers for quick high level hits/overviews of whitepapers
11. Engineer Man for great short introductions into various parts of the stack, scripting, Unix, and other abstractions
There are many more and recorded streams from other programmers teaching random things. There are tons of engineers on Twitch representing a multitude of companies like Lyft, CockroachDB, Netflix, and others working on open-source projects.
As a more experienced developer, I much prefer these channels over the ones listed, but my point is that the content is there when people actually search. The YouTube algos may not pick up all of them immediately and is most certainly more dominated by content directed at less experienced devs, but I much prefer some of this to the course recommendations that others are stating. Courses are really good, once you're convinced you want to do a deep dive into something, but most people do not finish MOOCs.
Thanks for this. As is often the case, webdev seemingly seems to suck the air out of the room at times in discussions of programming, and there are a lot of other super interesting domains out there.
dwoot's posting (and replies) seems much more useful than the article, which simply lists a whole bunch of links with no description or commentary. A curated list is, to my mind, much better than a simple search result that anyone can come up with.
Good maxims, but I find that Ben's videos lack depth -- don't get me wrong, but you're just not gonna get the expert domain knowledge in any particular area watching his videos. It's also primarily for those with less experience. I still watch them as they're entertaining from time to time.
You've also extrapolated your anecdotes to make a sweeping statement that implies that all FP is spaghetti.
You've made no objective counterpoints. Reducing any platform or language to "bad" sounds like someone that never quite understood the benefits of FP. Imperative languages are no silver bullet. Literally every code base that I'd ever worked in exhibits the same issues you describe as "spaghetti". But how does FP make it more so?
Do you write unit tests? Tell me how you've not come across a codebase in a non-FP language that didn't require some insane fixture or factory or set-up code and it was insanely difficult to reason about because you had to invoke methods in a particular order to set an object up to be tested for a particular scenario. This is not the case with functional languages. You don't get the rug pulled out from under you very often and if so, it's typically centralized in the "actor" or process whose state can change whereas state is EVERYWHERE in most imperative languages and even challenging at times to introspect, especially when encapsulation is done right in some languages.
Just because you've written more detailed points does not mean that they're valid or good. It just means that you have thoughts.
If you've asked people to send you good projects, then you're already in a mental state that disallows you from accepting a good project. There are many. Don't ask, just search on GitHub -- many projects that don't even come from core devs. It's been much easier for me to reason about and push fixes to these projects compared to Ruby or JavaScript projects.
I mean, we get it. You hate Elixir and you hate FP. You're entitled to that opinion, but please don't tell others to stop using it without having worked with it heavily and an accepting mentality to dig beyond the surface.