Slashdot Mirror
'Pragmatic Programmer' Author Andy Hunt Loves Arduino, Hates JavaScript (bestprogrammingbooks.com)
Andy Hunt is one of the 17 software developers who wrote the Agile Manifesto, and he co-authored The Pragmatic Programmer. Now Slashdot reader cerberusss writes:
In an interview with Best Programming Books, Andy Hunt mentions he "hates languages that introduce accidental complexity, such as JavaScript -- what a nightmare of pitfalls for newbies and even seasoned developers... My go-to languages are still Ruby for most things, or straight C for systems programming, Pi or Arduino projects." Furthermore, he mentions that "I tend to do more experimenting and engineering than pure code writing, so there's occasionally some soldering involved ;). Code is just one tool of many."
Andy writes that he also likes Elixir, talks about Agile, reveals how he survived his most challenging project, and says the biggest advancement in programming has been the open source movement. ("Imagine trying to study chemistry, but the first half of the elements were patent-protected by a major pharma company and you couldn't use them...") And he also answered an interesting follow-up question on Twitter: "Do you feel validated in an age of Node and GitHub? Some of your best chapters (scripting and source control) are SOP now!"
Andy's reply? "We've made some great progress, for sure. But there's much to be done still. E.g., You can't ship process."
Andy writes that he also likes Elixir, talks about Agile, reveals how he survived his most challenging project, and says the biggest advancement in programming has been the open source movement. ("Imagine trying to study chemistry, but the first half of the elements were patent-protected by a major pharma company and you couldn't use them...") And he also answered an interesting follow-up question on Twitter: "Do you feel validated in an age of Node and GitHub? Some of your best chapters (scripting and source control) are SOP now!"
Andy's reply? "We've made some great progress, for sure. But there's much to be done still. E.g., You can't ship process."
..programmers with screwdrivers" a mentor of mine in SW engineering once said. I've largely ignored that dictum, as a more problematic group is programmers who have no idea what a screwdriver (or soldering iron) is for. Programs exist to interface with the real world in some way, and understanding the larger (sometimes analog or wetware) view can make the difference between an elegant, but useless, piece of code and something that changes the world.
Because of course one of the people involved in creating one of the worst management fads ever would also join the JavaScript hate train.
"The Pragmatic Programmer." Hardly. Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.
Ever notice how prolific JS users rarely defend the language? Of course it's badly designed. We use it because it's pragmatic to use the lingua franca of programming.
What isn't pragmatic is using languages with declining market share because they feel aesthetically "better," or imposing horrible management fads like Agile/Scrum on your team against their will.
So I'll pass on joining this guy's fan club.
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
Over the years I've come to realize that programming languages aren't standalone beasts. When you pick one, you get a lot of other stuff along with it: common libraries and frameworks, runtime systems, problem domains, communities of programmers who do things a certain way, and the sources where most people learn them. That last bit is not to be overlooked, one of the best features of C is The C Programming Language.
As for pitfalls for newbies -- I think that's the browser, not Javascript. Javascript seems pretty straightforward in Node.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
A number of newer languages are embracing the idea of protecting the programmer from doing the wrong thing by accident, and I welcome this trend.
Even though I enjoy my occasional work with Python, the other day I accidentally forgot to explicitly reference a specific variable from a returned tuple, the error code I wanted to check against. Python happily let me compare tuple_value != 0 without complaint. While it may be possible to conceive of a situation in which a programmer MIGHT want to compare a tuple against an integer, it seems like 99% of the time, it would be best to throw an error, and force the programmer to do such an operation explicitly, rather than assuming it was intentional. It would have saved me a lot of hassle had this operation not been permitted. So, just one example there.
JavaScript has a lot of similar issues, from what I understand, such as weak scoping rules, global by default, no namespaces, and overly-generous implicit type coersion. All these things seem to work against the programmer, even if they were originally designed as conveniences.
It's really a shame that "what we have" for the web is JavaScript, so it's sort of impossible to work in web and ignore it. In my particular industry, "what we have" is C++. I'm not sure whether I should feel fortunate or not compared to web programmers. C++ has it's own particular nightmare of complexity, but the good news is that with C++, you can protect yourself from stupid mistakes with enough self-discipline, and the language has improved remarkably in the last 6 years.
Irony: Agile development has too much intertia to be abandoned now.
Original submitter here... I just came here to compliment the editor (EditorDavid). This is my first time submitting and thought my summary was pretty good. But EditorDavid just went above and beyond, extending it with stuff from Twitter, couple of sentences on Andy Hunt's work ethic cetera.
It's been tradition to hate at the editors here, but this time I have to hand it to them, compliments are in order.
8 of 13 people found this answer helpful. Did you?
As someone else said, often Javascript is the right tool for the job, because the job is manipulating DOM elements in a web browser.
A major new future in Netscape 2.0 was that it had Scheme embedded, for scripting. Ten days before the public beta, it was decided that the Scheme effort couldn't be salvaged - it just wouldn't work. But Netscape's hype had promised embedded scripting. So in ten days Brendan Eich designed, coded, tested, and integrated Javascript. 10 days for all of that means he had about two days to design the language. It shows. Other languages have had years, or at least months, of design. Javascript had about two days. Eich did an amazingly good job, for weekend design project.
Obviously Javascript has matured a bit since then, but its origin as the mother of all all-nighters, the crashiest of all crash projects, still shows in its design, its inconsistent naming of functions, etc.
Reading this, I'm thinking back to the early '80s when COBOL could be described exactly the way you are talking about Javascript.
Now, we're 30+ years later and people who have experience with COBOL (and the systems/tools that work with it) are in hot demand because of applications that won't die.
In 30 years, will we see the same need for programmers that understand how Javascript is programmed and can support the applications that were written in it?
Mimetics Inc. Twitter
often Javascript is the right tool for the job
Eh... right tool, or only tool?
systemd is Roko's Basilisk.
As he says himself he doesn't code, he "experiment". So for useless fool never making anything useful an unpopular terribly designed and unremarkable scripting language with the shittiest syntax short of mocklangs would be perfect.
It's funny that you mention that, because I was going to say that Javascript is a lot better if you program in it as if it were Scheme than if you try to program in it as if it were Java.
The inconsistent naming of functions makes the same point I was making: that's not a language problem, it's an API problem. If you take Javascript out of the browser and put it into a freshly designed runtime environment (e.g., Node) that aspect of the language experience goes away.
Another language that "has" this problem is R. R is peculiar enough anyway -- it doesn't seem to have any scalar types. If you assign 3 to X ("X <- 3"), it creates X as a vector of length 1 and puts 3 in X[1]. If you say "X + 1", it's the equivalent to the Python "map(lambda n: N+1,X)". That's surprisingly easy to get used to, because it works in the problem domain the language targets (statistics). What's harder to get used to are the libraries, which are magnificent in their comprehensiveness but are obscure, inconsistent, and poorly documented.
Those libraries are a major reason to use R -- much like CPAN is a major reason to use PERL. This makes those libraries' irregular design and stunningly half-assed documentation an inextricable part of the experience of being an R user. The closest thing I can compare it to is learning a natural language like French. You need books with titles "100 Irregular French Verbs Conjugated" because when the conventions aren't uniformly applied you have no choice but to drill until you have the specifics memorized.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
AVR stuff is just looping around, reading and writing bits and bytes. Fair enough. Elsewhere In C I would use pointers for linked lists. Hard to get stuff done without dynamically allocated data structures.
http://michaelsmith.id.au
Anything which works at the OS level has threads because it can spawn processes. The JVM has threads because it can't (easily) spawn processes, but many implementations use processes for JVM threads. JS, with lambda expressions and even driven programming claims to be threaded but is not. Its just callbacks where you have no control over when the calls are going to be made (usually in a rush when your main call ends).
Like it or not, our applications require threading. Your indexer has to keep running while your user presses buttons. That sort of thing.
http://michaelsmith.id.au
JS is a lingua franca but its a very bad one. It wouldn't be so bad if the language had actually been designed and was consistently implemented.
That being said our industry never learns. We dealt with termcaps and incompatible ChUI terminals in the 80's, odd and/or incompatible desktop graphics capabilities thru the 90's followed by browser incompatibilities and now vastly different JS engines. You would think the industry would eventually figure out that taking decades to establish baseline standards for software means that the horse is out of the barn (and it burned down and they put up a shopping mall in its place) because the standards come too late.
Each company views the giant gap between rising popularity of something and the actual establishment of a standard as a place to drive a wedge and establish a competitive advantage. In the meantime developers and users suffer and projects come in even later; even more over budget and still not fully functional.
Suppose you were an idiot. And suppose you were a member of congress. But then I repeat myself. -- Mark Twain
One thing I've really screw over "agile" projects is a concept I call the agile lawyer. In theory law is supposed to make society fair. However we have people called lawyers that while they can help you they can also use their expertise to completely pervert the idea of fairness. Similarly I've seen the same idea crop up in agile. You'll have a guy, usually a scrum master, can totally quote any particular part of agile you could mention. However when it comes time to actually do agile they just end up using agile doctrine to fuck over the development team. Shit like oh you're self managing but you can only grab from the top of the backlog. Oh, another one is keeping interesting projects out of the sprint process so, surprise surprise, they can work on it themselves. Of course the classic, everybody is equal on the team, except most of the planning of projects that's special and only the leads get to put their 2 cents in on that.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
One can hate javascript because it's badly designed and still use it because it's the best tool for the job.
And using a language with declining market share can also be very pragmatic, for example when it's the best tool for the job.
Python is the Java of the scripting world, verbose and full of inconsistencies.
That sounds like Python 2. Python 3 is much better.
Railing against Javascript is like refusing to speak english because it's a convoluted language filled with inane rules, exceptions and colloquialisms.
Ruby is objectively superior to both Python and Groovy
You forgot to put a smiley at the end of your statement so people could tell you're joking and not being stupid.
lucm, indeed.
Ruby is better at string manipulation and unix integration than any other language, including Perl.
No it's not. Just because *you* can't do string manipulation in other languages doesn't mean those languages are not as good as ruby. It just means you're a one-trick pony.
There are many languages I personally don't like, such as Go, Scala or C++. But I can see why someone would choose one of those for a specific project, because they each have specific advantages.
But there is no aspect of ruby that another language isn't better at. Even for the "casual programmer" niche Python is much better.
And don't get me started on RoR. it's been a long time since I've heard of RoR projects in contexts other than getting rid of them and rewriting them in something that works. Whoever invented ruby and RoR owes the IT world billions of dollars wasted on nightmarish maintenance and abysmal performance.
lucm, indeed.
the most widely deployed OS in the universe
You're really good at making unsupported claims.
lucm, indeed.
nt
Depends on what you're writing. I wrote a fairly large Arduino library (Automaton) and to keep memory overhead to a minimum I really needed a linked list and pointers.
In the case of R, there's a sub-universe of it's own using the Hadley Wickham (and his cohorts) packages tidyr and so on. If you buy into the hadleyverse (he prefers the name tidyverse).
I'm particularly interested in the new packages for reading data readr and readxl, which are supposed to be much faster with saner defaults. The old read packages had a habit of treating all strings as though they're a database enumerated type, it would try to "tokenize" everything on the fly...
I think what you're talking about with R is a symptom of any long established language-- there's bound to be lots of oddities, cruft, workaround for misfeatures, and a bewildering array of competing libraries to do things in slightly different ways.
Personally, I wouldn't complain about R favoring vectors ops (it's better then struggling along implementing your own the way you need to in most languages). There's plenty of oddities: first of all, the "." is not a method call, though it's used everywhere in names (just like "_"): R does however *have* method calls, they're implemented with an arrow, just like perl5 ("->"). The type system is a little strange, where if you've got an aggregate of items all of the same type, the aggregate is regarded as being of the same type...
Anyway there's a new Wickham book "R for Data Science" that's supposed to be pretty good. Let me give you a link to it, O'Reilly has broken their website (e.g. they no longer have the word "book" visible on it's front page): http://shop.oreilly.com/produc...
Elsewhere In C I would use pointers for linked lists.
Don't use linked lists if you care about performance. If writing a dynamic array is a pain in the ass in C then stop using C. Use C++ instead.
And don't give me that ignorant crap about C++ being bloated in comparison to C and thus unacceptable for embedded uses.
This guy wrote pong for the C64 in under 1KB of compiled code (including sprites!) with ZERO ram usage.
And French was the Lingua Franca for awhile because Francs was a dominant country, and English has been Lingua Franca for awhile because Great Britain and then the US became dominant counties...
The phrase "lingua franca" means it's in common, widespread use and it's easy to find someone who speaks it. It does not imply excellence of any sort. If you guys want to fight about something, maybe you could think a little harder about what you're fighting about.
Your ignorance is astounding and frightening.
Amusing, coming from someone who claims to know "the most widely deployed OS in the universe".
Prove it. (And then make sure to share your data with NASA).
lucm, indeed.
No it's not, OO has three pillars - encapsulation, inheritance, and polymorphism. JavaScript doesn't let you inherit and encapsulate at the same time - it's one or the other, as such JavaScript's OO is objectively broken in a fundamental way.
JavaScript does OO, but as the GP said, it does it badly, because it's broken.
In contradiction to what you say, the languages you list actually have it right, because they're true OO languages that implement OO properly and thoroughly.
It looks like the issue is that you don't know what OO is - if you think JavaScripts OO is a good implementation, or superior to that in the other languages you listed then the problem is your understanding, not their implementation. This is confirmed in your final paragraph, where you demonstrate a complete lack of understanding about what object orientation is and means. You're arguing that you think true OOP is FP, which is entirely nonsensical.
So again, JavaScript's OO is objectively broken based on the fundamental principles of object orientation - you can't rationally argue against that no matter how much you may wish to try. When you do, as you have here, all you've done is demonstrate your complete lack of understanding on this subject.
I suggest you learn a bit about the history and intentions of OO. It's not about message passing, it's about organising data around objects, hence the 3 pillars of OO. They're called the 3 pillars of OO because they're the 3 pillars of OO - the fact you don't even know about their existence really speaks volumes. You may wish to pretend OO is something else but again, that's because you're wrong, not because you're the god you think you are that gets to redefine unilaterally terms for the entire programming community across the globe.
You obviously need some basic computer science education, because you wouldn't even get into university with that level of ignorance of the topic.
OOP stems from Simula, and later Smalltalk - in fact, small talk was the first termed OOP language, hence why those languages that stem from it's ideas are the ones implementing a correct interpretation of OO. The fact you're not aware of this once again highlights why you're exactly the sort of person you cry as bringing the quality of knowledge on Slashdot down - you don't even have a basic grasp of the topic and it's history that you're talking about. You're just saying things because you're a language fanboy, asserting they're right, whilst being actually completely and utterly wrong.
I can see why you're confused on the topic though, Joe Armstrong intentionally misled people like you to allow you to pretend you were doing OO even when he was very clear that you absolutely were not. You basically didn't understand his actual point. Here he explains why they did that, and why Erlang is intentionally not actually OO:
http://harmful.cat-v.org/softw...
Enjoy your education, or continue being wrong on the internet. It's really up to you.
It doesn't really matter how you want to wriggle out of it, you're saying "Erlang is what OO is meant to be, but it's not OO".
You realise that makes no sense right? If it's not OO, then it's not what OO.
You're caught up on such random vagaries that you completely miss the point of OO - to be able to think about systems as objects, and classes of objects because that's an effective way to map to the real world. Hence why we have the pillars of OO - the very definitions of what an OO language has to support to be able to support object oriented analysis, design, and programming.
I'm sorry that you have a completely nonsensical view of what OO is and why OO is, and why JavaScript isn't by any measure a proper OO implementation, but that's really your problem.
Still what else would I expect from someone who criticises Java whilst defending JavaScript? You're pretty clearly just some script churning amateur. Leave development to us experts, you might break something.