SoylentNews is people
SoylentNews
Stumbled upon this blog entry:
One paragraph from the OP instantly stuck out to me.
I don't want to [be] a typical "code monkey". I want to go deep into low level, even to clear math when we talk about computer science, but at same time, I want to have a job in shorter period of time than let's say 3 years. I was switching so many times between Python, C++, Java and I'm nowhere. I know it's bad practise, it's worst, but I don't know, I'm just confused.
...
Web development has an extremely low barrier to entry in comparison to, say, systems programming. Setting up a Wordpress blog takes significantly less knowledge and effort than building an operating system.
As a consequence, being a web developer does not carry the same prestige as being a software engineer (whatever that is). God have mercy on your soul if HN or /r/programming learns you implemented some common functionality in NodeJS for fun. (Expect the words "web scale" to show up in the comment thread somewhere).
...
As I became more involved in online communities, the narrative became increasingly clear that my confidence and sense of accomplishment were unwarranted. PHP was a terrible language, and PHP developers were terrible programmers. JavaScript was a terrible language, and JS developers couldn't perform asymptotic analysis to save their life. Web developers don't have degrees and it shows in their code. Drupal/Wordpress developers are an absolute joke. Web developers never took a compilers course, so they don't understand just how easy their "jobs" are. Web developers are overpaid for how little they know. Web developers have everything handed to them. Web developers have never had to manage memory or make hard decisions. Web developers have no knowledge of data structures or algorithms. Web developers are not real programmers.
Armed with impulsive spending habits and a sense of urgency, I went to Amazon and purchased just about every programming book not related to web development I could find. Cryptographic protocol implementations in C, Embedded Systems development, Linux Kernel Development, etc. I wanted to learn things that real programmers knew. I wanted to learn the hard things. I bought an Arduino, started hanging out in ##c on freenode, began reading through implementations of the C standard library.
I never fully read any of those books. Most of them I never even started. I didn't do anything substantial with the arduino. I never made it passed analyzing "assert.h" in the C standard library (which I was planning on progressing through alphabetically.)
...
When you hate what you do, you stop caring about it. When you stop caring about something, you aren't going to bother learning more about it.
For a period of nearly 3 years, I was stuck in a terribly unproductive mental state. I hated web development, but I didn't know how to do anything else. Web development was all I knew. Bills needed to be paid, so CRUD apps needed to be made.And thus arose my main cognitive dilemma: I hated web development because it was easy, but it was never actually easy to me. Instead of concluding "maybe web development is actually hard and those people don't know what they're talking about", I concluded that I must be a terrible programmer.
Question to SN fellows: have you had moments like this (doesn't matter if in relation with Web development or not)? Have you crossed over them? If true, how?
(Score: 3, Insightful) by VLM on Sunday July 26 2015, @02:38PM
The biggest problem Perl has is its old, so just like mysql, you get all kinds of authoritative pronouncements that it doesn't have and never will have XYZ or whatever ridiculous stuff that was true in '94, but it hasn't been '94 for a little while now, and its been shipping with that since '95.
See mysql WRT transactions, or Perl WRT OO functionality, etc. They added pretty good regex support to Perl in the very early 90s, for example, in fact its kind of famous for it. There's probably something in CPAN that'll do anything.
There comes a point with any technology, any at all, where gradual evolution eventually means google is basically useless for the technology because the average of what you find online will be 15 years out of date, therefore all that exists is 15 years out of date. Not so.
Starting from scratch you're probably better off with Scala or Clojure if you want to do functional.
It doesn't really matter, anyway. Blaming the tools is usually a bad sign. A standard issue SN car analogy would be claiming the reason someone can't change the oil in my car is because they don't have an expensive full set of SnapOn tools. The average year of publication of all car repair manuals is probably in the 1960, therefore there are no modern car repair manuals and no one maintains modern cars. The average car repair manual, over the history of all cars, only covers carburetors, therefore no one can repair modern fuel injectors.
(Score: 2) by Marand on Sunday July 26 2015, @10:12PM
Starting from scratch you're probably better off with Scala or Clojure if you want to do functional.
I second this suggestion for anybody, especially Clojure. Not that there's anything wrong with Scala, just that it's basically "Java with new stuff botled on", which means that it's a lot easier to just keep writing code the same way you've always done it and not really learn functional programming.
Clojure, by contrast, was made ground-up with concurrency and functional programming in mind. It still has Java* interop, but it's a completely different language design that requires you pick up functional programming to use it. It's not a pure functional language (like Haskell), so you can still kludge in imperative style when you need to, but you have to actively work against the language to do it, so you start to pick up functional habits just through using the language and finding better ways to solve problems.
Trying to pick up functional programming in a language you already know, or one similar to a language you know, is tempting, but it's too easy to fall back into imperative habits without even noticing. You'll write impure functions out of habit, or mutate data instead of passing it properly out of convenience, etc. Plus you'll be fighting the language itself, like in that Perl book linked by microtodd, where there appears to be a lot of language wrangling to do in Perl what Clojure's built to do ground-up.
* substitute CLR (for ClojureCLR) or JavaScript (for ClojureScript) interop here depending on which variant you're using.
(Score: 2) by microtodd on Sunday July 26 2015, @10:12PM
Starting from scratch you're probably better off with Scala or Clojure if you want to do functional
So this is totally an n=1 sample size, but for me, I tried to pick up Lisp and Haskell more than once. Set up the compiler/interpreter, find an intro tutorial, jump in. Three or four times, and I never really "got it".
So I come across this Perl book, it starts with standard procedural perl. Start adding some recursion on a pragmatic example (walking a directory tree). Start adding lambdas and stuff in to your method calls and algorithms. About 7 chapters in, suddenly the author is like "Surprise! I just taught you lambdas!". And it then all clicked.
So maybe its not academic ivory tower. I'd probably still just get a "C" in a functional programming class. But it made me a better programmer.
(Score: 2) by VLM on Monday July 27 2015, @11:39AM
Start adding lambdas and stuff in to your method calls and algorithms.
There's a guy named Eric Normand who did some (non-free) training videos for Clojure along that general path, although his thing was abstracting cooking stuff in the kitchen, so start with super procedural, then lambda it up. Good videos, well designed and produced, although medium price.
Unfortunately I remember that one of "The Little (wtf)" series of books also worked up a similar path but I don't remember which.
Anyway those are some specifically LISP things that are like the path you describe.
Typical for the "Modern Perl 2014" book there is a technically correct section on anonymous functions and how to do them right and the limitations, but theres little explanation why or what it is, and somehow the book makes it thru the entire section without using the "L word". If you already know what they are and why you'd use them, and there's a way to write anon functions without the sub keyword, but temporarily forgot, then here it is. I think thats bad code because I can't search for "sub" in the source code while debugging if there is no "sub" notation. Anon functions are generally not fun to debug in perl code if the source gets wild and wooly and huge and spread all over. The definition of hilarious is using multiple anon functions in one block of code and the error messages all claim to be from __ANON__ , or whatever it is exactly, and good luck figuring which without stepping thru with a debugger. Well, it is kinda intended as a reference book not a textbook anyway. Its a great reference book.