Hacker News Reader

Comment by segmondy | Hacker News Reader

In my opinion, that's what's wrong with the world. Chasing tech, pick something solid and stick with it. I have seen developers barely get decent in one language only to drop it and learn a new language. Picking up the basics of a language is easy, but it's knowing the nuisance that separates the professional from the amateur.

View on HN

> Picking up the basics of a language is easy, but it's knowing the nuisance that separates the professional from the amateur.

I disagree.

I went from C# to Node.js and back to C#. I learned the hell out of JavaScript, and yet I feel like nobody will ever care that I can explain some of its nuances and gotchas. Language nuances are constantly evolving anyway.

Learning Node.js unlocked whole paradigms I didn't understand in C#. I never really "got" functional programming. Switching between the two helped me understand the pros and cons of different approaches. I discovered a lot of the things I miss from JavaScript are actually there in C#, just a little off the beaten path. On the other hand, I can appreciate "the C# way" and breathe a sigh of relief that certain gotchas do not exist in that environment.

Whilst it's true that one can program in a functional style in almost any language, I fail to see how javascript would help someone learn about functional programming.

It's true that you can program in a functional style in almost any language, but it's just simpler for Javascript. Functions are first-class objects in Javascript, and arrays have built-in forEach, map, reduce, and filter -- all useful for a beginner in functional programming. C++ and Java have lambdas and foreach, but they aren't as simple to use.

There is nothing wrong with map, reduce and filter, but I believe this is just conflating nice and usable APIs for iterators with functional programming.

http://letoverlambda.com/index.cl/guest/chap5.html

s/Lisp/JavaScript/g

C# on the other hand, support FP pretty well, as long as static typing without HM is acceptable.

Functional Programming is about working with mathematical functions. Having "first-class functions" in the language is nice, but then passing function pointers around is nothing more than procedural programming [1] and yes, the difference is huge.

As for those utilities you mention, Javascript is the most broken of them all:

    >>> ["10", "10", "10"].map(parseInt)
    [10, Nan, 2]

[1] https://en.wikipedia.org/wiki/Procedural_programming

Why does functional programming have to be about math?

That is precisely the kind of insistence that prevents people from adopting functional languages for real world programming tasks.

JavaScript certainly lacks language level support for function composition, but it has the basic tools to allow you to build combinators and compositional functions yourself, and when dealing with functions as data you often find you can elegantly refactor code by building such a thing - so in terms of 'learning about functional programming' JS can be a great workbench to help procedural minded programmers discover those tools by discovering and building them.

So maybe JS doesn't teach functional programming, but it does at least introduce you to paradigms from which it is possible to see the benefits of a functional language.

Of course, if you then hear that those languages are only for doing math in then you'll stick with JavaScript.

> Why does functional programming have to be about math?

You've misunderstood the GP's point. It's not that FP is about math, it's that you want to emphasize mathematical functions -- functions that don't rely on inputs other than their parameters and return values in a consistent co-domain. This is just good style to improve testability and minimize sources of potential bugs.

> Why does functional programming have to be about math?

Because that's its definition. Change that definition and it becomes meaningless. Functional programming is about working with functions that always have the same output for a given input - the definition of mathematical functions and I wouldn't have to say mathematical if software developers wouldn't feel the need to overload technical terms. Pascal and other languages had great names for pieces of code taking arguments and that aren't functions: procedures, routines, subroutines, etc.

> That is precisely the kind of insistence that prevents people from adopting functional languages for real world programming tasks.

So let me get this straight, in order to get people to adopt something, you want the definition changed in such a way as to become meaningless?

Also, I do expect software developers to know at least high-school level math, because CS is math. Even if you lack a formal education, that's no excuse for ignoring theory that can help in your daily work, especially in this day and age with so many online resources available for free.

So that others don't have to spend time searching: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

What does that example prove, other than the two methods aren't compatible?

If a properly designed method were passed into map it would work fine.

In essence: ["10", "10", "10"].map(Number)

The link just explains why it's happening, I'm not passing judgement on whether it's bad or not.

the way JS does closures, and the mandatory async nature of everything, leads to a world where you're working with functions a lot more than you would be in languages in the same family (garbage collected, lenient, a la python and ruby). from there, functional programming concepts like partial application and currying start to pop up. if you dive into frameworks like react.js, you start to encounter pure functions and immutability. it's not what I would call a "functional programming language", but I find the concepts show up more than usual, and I think that's because functions are one of the more advanced primitives in the language

First class functions seem to be often confused for functional programming, and JS has first class functions.

> Learning Node.js unlocked whole paradigms I didn't understand in C#. I never really "got" functional programming

Don't get me wrong, but I'm pretty sure you still don't get functional programming, because functional programming is not practiced within the Javascript / Node.js ecosystem.

Yes, there are some exceptions here and there, some libraries like Facebook's React have FP-inspired ideas in them (even though those components are modelled with state and hence have nothing to do with FP) and working with asynchronous results signalled by callbacks is so freaking horrible that people have began using Promise abstractions sort of inspired by FP, except most of them broken. But no, unless you're into one of the languages that actively promote FP, like ClojureScript, PureScript, Elm, Scala.js, then you're probably not doing FP.

As evidence, go to GitHub, pick any sampling of Javascript projects and witness how a vast majority have nothing to do with FP.

Furthermore I think that with this argument you're proving the parent's point. If you want FP, then take the time to learn and work with one of the languages that actively promote FP and be prepared to suffer because it's not easy.

It's much easier to be a rockstar developer when the pool of developers is so small. The game of chasing the "best" technology is pretty much a ponzi scheme.

"Picking up the basics of a language is easy, but it's knowing the nuisance that separates the professional from the amateur."

From learning perspective correct. I don't think developers chase new languages, I think it's more, play 'catch up to latest language' to be more employable. You would hope companies, CTOs, lead techs choose languages to solve the unique business problems. Language choice looks more, to me, like taste. Like choosing something ^nice^ from a menu at a restaurant depending on what is palatable.

I can't tell, I know many developers today who are on the new shiny js thing, golang, elixir, scalar, rust train, but they never got really good in their first language be it Java, python, or php.

They use linux or OSX. But they don't know awk/sed/bash, give em a very simple problem, they would write 1000 line of OOP, united test code when a few line of scripts would solve it.

I know many programmers, who graduated with a CS degree, they go out of their way to implement ridiculous rule engines and overly complicated systems, when they can just use prolog and glue their app to prolog.

I've witnessed many so called fullstack developers who break out in cold sweat at the sight or thought of writing SQL. They want an ORM.

This is what I call chasing, new things, when the old things are rock solid. I see this today, where people cry about PHP, but yet don't even use it's good features. Go use NoSQL solutions but never even had a clue about their SQL DB.

/rant

> They use linux or OSX. But they don't know awk/sed/bash

Am I in the minority of developers then? I don't know awk and sed and I'm honestly not very interested in learning them. But bash I definitely agree with. I still use a cheatsheet to get the syntax right because it's weird as hell imo.

Worth reading "Area Number Three" on this blog post from Steve Yegge: https://sites.google.com/site/steveyegge2/five-essential-pho...

Isn't that just a `grep -R [regex pattern]`? Not sure where something like awk or sed fits in to solve such a problem.

The primary point was one of mindset, but the second example in the cited section is a tailor-made sed example:

Let's say you're on my team, and I've decided I'm a real stickler for code formatting. But I've got peculiar tastes, and one day I decide I want to have all parentheses stand out very clearly in your code.

So let's say you've got a set of source files in C, C++, or Java. Your choice. And I want you to modify them so that in each source file, every open- and close-paren has exactly one space character before and after

Whoops, didn't notice that one. Thanks for linking that post by the way. Great read.

Most Yegge blog rants are well worthwhile, IMO. I wish he wrote more of them.

Y'know - after thinking about it a little, I'd argue that this is a question that could serve a second purpose. The obvious out-of-the box implementations of this in sed/perl/etc. would all fail to properly handle open and close parens in strings and comments. Particularly multi-line comments and strings with escaped quotation marks inside of them.

I like sed. I like perl one-liners. I would consider it a mistake to try to do this on a real codebase in a batch manner with just a regexp. You'd be far better off googling to find a source code formatter that includes a real parser, like clang-format.

The question specification is such that you don't need special handling of comments, strings, etc. "every paren" isn't qualified as "that is part of the code".

The point of the question is more to gauge your understanding of/familiarity with available tools and ability to think laterally rather than immediately jump to "I've got to write some real code to solve this"

I'd probably reach for ANTLR to write a quick parser since working with such a stickler is likely to require more code formatting changes in the future.

As an aside, the stuff I used sed/awk for in the past have pretty much been replaced by Python for me. These days it's pretty rare to not have a default Python install on any Unixy box one spins up and in the rare cases I use Windows I tend to install Anaconda so it's also slightly more cross-platform for my use cases.

awk and sed are fantastic for command line processing of text. You really should take a look at them. All that said, if you don't find yourself trying to do something in bash and thinking "there must be an easier way" then you're problem sets may just not need them.

edit: comment was about perl, I didn't notice discussion below

"I don't know awk and sed and I'm honestly not very interested in learning them. But bash I definitely agree with."

Awk/Sed are optimised for text/data processing.[0] While Bash might work, will the script work on all systems (and version)? [1] awk & predecessor sed are good for one liner programs and suitable for problems that need fast, reliable solutions.

reference

[0] Opening, closing files; reading, breaking and counting record fields.

[1] OS use Bash or Bourne? https://en.wikipedia.org/wiki/Bash_(Unix_shell)#Portability

Then again, sed works differently on different platforms, and awk is not the same as gawk or nawk, both of which have many more features than standard awk. If you're used to the GNU implementation, you might be surprised to find your script doesn't work on a system without the gawk implementation.

On Linux, I can use this sed command: sed -i ‘s/^”//’ example.txt

That deletes any quotation marks that are at the beginning of a line. It does it in-place, and while you have the option to rename the old file and replace it with a new file with the original name (using "sed -i.bak ‘s/^”//’ example.txt" would move the existing example.txt file to example.txt.bak and write a new one in-place), if you leave out the .bak, it just writes it in-place with no backup file.

On OS X, though, that command won't work. You have to specify a backup file, even if it's blank. "sed -i “” ‘s/^”//’ example.txt" would replace the text in-place without a backup. sed -i “.bak” ‘s/^”//’ example.txt would replace the file and move the original to "example.txt.bak".

Even with sed and awk, you still have to stop and wonder if it will work cross-platform.

This is why I have gripes about the OS X command line. I can't confidently use the scripts I do on Ubuntu/Mint/Debian. Like, get with the program, Apple. It infuriates me and I'm moving entirely off their platform as soon as my Mac kicks the bucket.

OS X is not Linux. It's a BSD-derivative, and doesn't use the GNU toolchain. It isn't that it's "not with the program." It's that it's not the operating system, or toolchain, you're familiar with. Install homebrew and GNU tools[1] if you want them.

If you used an operating system that shipped with BusyBox, you'd be similarly frustrated. But operating systems are tradeoffs with pros/cons. Using a different set of tools makes it distinct, not "out of date".

1. https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-c...

"OS X is not Linux. It's a BSD-derivative, and doesn't use the GNU toolchain."

True, but I was thinking awk/sed was a good multi OS tool with minimal code effect.

Oh, my mistake. I was under the impression that sed/awk/grep/ack/etc etc were part of the POSIX standard toolchain, rather than the GNU toolchain.

I have a script which installs and aliases all the equivalent GNU commands on OSX. You can fix a lot of the annoyances.

"Then again, sed works differently on different platforms"

Well that kills my idea why to use awk/sed. What would you use @freehunter?

Perl, Python, Ruby

True, defeats the idea of a one liner in bash/awk/sed.

Well the beauty of one-liners is that they're quick and dirty. They don't need to be portable, you don't usually maintain a one-liner for years. If you need something portable, you should use a real cross-platform language like Perl, Python, etc. Something that's independent of the OS you're running.

"Well the beauty of one-liners is that they're quick and dirty. They don't need to be portable, you don't usually maintain a one-liner for years."

Given that description, I'd agree. Now I understand the crux of the problem, problem solved using disposable code in terse language or script.

I don't think you are in the minority, assuming you have a reasonable way to quickly parse text. I think most developers just Google for one-liners or throw something together in Python to solve text-parsing tasks at hand, rather then trying to remember which tool uses which type of regex with which argument.

There's no reason to use awk or sed when perl exists (a2p and s2p have existed for decades)

There is no reason to use perl in situation when awk kicks its butt with clearer, shorter code free of distracting sigils and other line noise

Awk is also POSIX standard; a good remaining reason to use it (if it is a feasible alternative for a task) is that a script has to be portable outside of GNU/Linux.

I like Perl a lot better than awk, buy I do agree with the general sentiment of using the language that makes for the clearest code for the task at hand, especially the smaller ones. Which makes me a frequent awk proponent.

So I'm surprised at the following part of your comment:

> There is no reason to use perl in situation when awk kicks its butt with clearer, shorter code free of distracting author and other line noise

In my experience, the shorter ask code tends to be the one with sigils.

But in a lot of ways awk seems way more modern than Perl (Perl 5 at least). You actually have functions with parameters rather than having a weird @_ array that you need to shift values from. Honestly, if I didn't know otherwise, I'd think awk came after Perl.

Functions with parameters in a () is already in Perl 5. Search for subroutine signatures.

http://perldoc.perl.org/perlsub.html#Signatures

If you're getting along fine without awk then by all means, don't learn it. But just today I had to quickly get a raw list of all US area codes (and only area codes). After a short Google search, I realized the fastest way of downloading and formatting it without having to do a secondary step was this:

  curl https://raw.githubusercontent.com/kedarmhaswade/cities/master/area-codes.csv | \
  awk -F, '{print $1}' \
  > ~/area_codes.txt

Now, could you use grep? Yeah, sure. But for really quick examples like this - things that lend themselves to it (e.g. a raw CSV with mostly crap you don't need but something you do), this is super fast. Anything more complicated and I'd break out a regex, though.

I break out in a sweat contemplating how to get an ORM to efficiently do something that would be simple in straight SQL...

Use SQLAlchemy, ORM gets easy :)

Agreed for the most part, although we should acknowledge that those "new and shiny JS things" make for some extraordinary RAD times and generally don't take too long to learn (at least to become productive). They may have serious limitations, but for side-projects developers can get to an MVP with haste.

"for side-projects developers can get to an MVP with haste."

That's the caveat you want to hear. Also Facebook with php and HHVM [0] not wanting to break things too much.

[0] https://en.wikipedia.org/wiki/HipHop_Virtual_Machine

I think that's fair enough, but I'm not sure I equate one to the other. Your examples are complaining about a lack of exposure to different kinds of tools that already exist rather than lack of depth in tools that the developers use.

Although grossly unfair, it's sometimes instructive to split people in two categories in order to consider a point. With that in mind, I notice that there are programmers who want to learn as little as possible in order to get the job done. They want tools to make things easy for them so they don't have to understand the underlying concepts. How many times over the decades have I had to unwind bad commits in source code repositories because some programmer refuses to learn how to use the software directly and leaves their IDE to do it for them? Same again for build systems. How many times have I worked with programmers who refuse to understand what a pointer is, because now that we have GC apparently we don't have to worry about leaking resources? How many programmers never bother to learn the syntax of the language, preferring to generate snippets and cut and paste from StackOverflow (or back in the old days, you would have entire applications built primarily from cutting and pasting examples from MSDN)?

Yeah, this is a problem (and has been a problem for as long as I've been a professional programmer -- i.e., a long time ;-) ). But the people who are chasing after the new shiny don't really exhibit that attitude for me. To the extent that everybody who wants to work tomorrow has to keep learning, no good developer is exempt from this. But I find the people who really chase new stuff without getting a proper grounding in the old stuff have a few overwhelming things in common. They are young (to the industry). They are excited. They want to learn.

My experience has been that if you show them the very, very cool things you can do with awk/sed/bash/prolog (Really? You use prolog!? I'm seriously impressed) they will get similarly excited by that.

Really, you use Prolog (in the shell)? What for - have you blogged about it anywhere?

Interviewer: sort this file of 1,000 names. Here's a Linux laptop.

Candidate 1: writes some Python code

Candidate 2: writes some C++

Candidate 3: runs "sort names.txt"

I'm pretty new to the industry, being young, but as soon as I got a machine to run a Linux VM on, I spent hours reading docs and man pages and books on Bash and general *nix commands. Definitely helped me become a better programmer. It's amazing what you can do with simple POSIX commands. I didn't even know about sort until now, but it'll help me a bunch now.

Run `info coreutils` and get a general sense of the tools available. There are things you'll use all the time like sort, uniq and wc. Things you'll use occasionally (`foo | column -s $'\t' -t` reads all the lines of standard input, splits each on a tab and then lines everything up in nice columns) and things you might rarely need, but when you need them they're amazing: tsort, for example, is really useful for managing dependencies in certain circumstances.

Candidates ask no questions?

Although, it'd be fairly simple to do this in python:

python3 -c 'import sys; list(print(line.strip()) for line in sorted(sys.stdin, key=str.lower))'

s/nuisance/nuance

They probably meant nuance, but I think the biggest part of experience is knowing all the nuisances (especially in the accompanying development environment) and how to get around them.

"expression #1, char 17: unterminated `s' character"

Reply on news.ycombinator.com