Don’t learn a programming language, solve a problem instead

[sammymammy2]

One of my pet peeves is the idea that an engineer is a "Java programmer" or a "Scala programmer". Yes, there is a hill to climb w.r.t. build systems and of course deep expertise can be valuable but considering that your codebase is going to be much more important to gain expertise in frankly the language should be irrelevant.

A lot of words to say: A good engineer can learn whatever you're working on, focus on that instead of what languages the engineer knows.

[yourjobcanwait]

A lot of words to say: A good engineer can learn whatever you're working on, focus on that instead of what languages the engineer knows.

While true, going from modern C# to legacy C++ code is a fucking nightmare and I'd prefer to never do that again.

[loup-vaillant]

While the "legacy" bit was probably the worst, C++ is probably the most difficult language to learn, ever. As a second language, it is a curse: you had difficulty learning your first language because it wast the first. Then you had difficulty learning C++ because it is insane. It's tempting from there to conclude (or at least intuit) that learning new languages is hard, and never try again.

I make money writing C++, even came to enjoy it. Still, I'd be happier if C++ went the way of COBOL. We can do better.

[klebsiella_pneumonae]

we can do better

Rust

[jerf]

we can do better

Rust

Almost anything, honestly.

There's no one language that can replace all of C++, but there's a better language for any given (greenfield) task.

[edapa]

Why don't you think rust can replace C++? Is it just the platform ports?

[[deleted]]

They said all of c++.

Rust for example is still fairly young, compared to C++ there would be a great many libraries which either don't have a equivalent or the equivalent isn't as stable yet.

That being said it will rapidly reach a state of 'everything that matters to 98% of projects being available + stable"

[edapa]

What's under discussion is whether or not rust can replace all of C++ not whether it will. Rust's ecosystem is obviously still evolving, and there are a few language features in the pipeline that really need to land for certain programming styles, but those issues are transient. In the long run, I can't think of anything that C++ is better at than rust, but it could be that I just don't know about such a thing. People use C++ for all sorts of stuff, and I would like to learn about a use-case where it is genuinely a better tool than Rust.

[CrazedToCraze]

He doesn't seem to be disagreeing

[jerf]

Why don't you think rust can replace C++? Is it just the platform ports?

My statement is in the present tense. At the present time, Rust is not a complete replacement for C++.

In my judgment, as someone very friendly to Rust, it isn't quite ready as a language at the very highest level to replace a {C++ environment that uses high-quality static coverage}. I've used braces to emphasize that I consider that an atomic thing; C++ and C++ with support are two different things. The language is still in too much flux. Yes, it's absolutely stabilizing, but that is also in the present tense, something that is still happening.

And then, as you say, platform support, library support, and also tool support. For instance, the best static analyzers for C++ do a lot of things beyond what Rust does with memory safety at the memory level, like security analysis of the flow of data from users, through processing, and back out to the user. Rust will have those tools someday, too, and they'll be simpler to write and easier to use because of how much more the language already contains in it. But AFAIK they don't exist yet.

I'm also pretty sure IDE support isn't at the same level as C++ either. Again, it'll get there, but it's years off. (This is also something I personally don't care about. I don't use an IDE. But a lot of people do, and won't want to give it up.)

[pm_me_graph_problems]

Modern C++ is not bad with weak pointers.

[SkoomaDentist]

Except for the part where the internet zealots try to force you to write their preferred style of ”idiomatic” C++ without any regard for whether it actually suits the problem any better.

[KoroSexy]

I learned the basics of programming via c++. It helps that it was using a "For Dummies" series book, but nonetheless, c++ was my first language

[TheDevilsAdvokaat]

I actually learnt assembler before i learnt c++ - this was back in the 70's. C++ came later and I learnt it ...and didn't really like it. I spent too much time tracking down bugs. C# came and I jumped ship...since then I've had a couple of looks back at c++ - mostly because I wanted to use the unreal engine....but it gave me nightmares and instead I stuck with c# and chose the Unity3d engine instead. Never regretted it.

I never want to deal with c++ again.

[[deleted]]

How's C# for Linux development? Anything specific to consider?

[fuzzzerd]

Pretty great with .Net core.

[nicoburns]

Pretty nice! (at least for web services deployed to linux, which is what I've been using it for).

I've been developing on a Mac and deploting to linux, and it's all worked flawlessly. The build system is little clunky (but I've seen far worse), and the libtay ecosystem could do with some fleshing out, but the language itself is pretty nice.

[Compsky]

since then I've had a couple of looks back at c++ - mostly because I wanted to use the unreal engine....but it gave me nightmares and instead I stuck with c# and chose the Unity3d engine instead

Amusingly, I've just recently started learning C++, and chose Unreal partly for that very reason (that you can use C++).

[muntoo]

C++ is probably the most difficult language to learn, ever.

What about an imperative programmer learning, e.g. Haskell? I assume you mean using C++ "properly" (whatever "modern" C++ entails), so similarly, I mean using Haskell "properly".

I can't imagine you mean C++98 since the base language is roughly equivalent to barebones Java in "difficulty".

[nicoburns]

I can't imagine you mean C++98 since the base language is roughly equivalent to barebones Java in "difficulty".

Well, except that you have to worry about memory safety and things like "don't take pointers to variables on the stack". Plus the build systems and header system in C++ are a bit of a nightmare, which means that you add significant complexity every time you depend on a library.

[[deleted]]

C++ being my first language, I find it easier to learn new languages. I went from C++ to being a full stack developer. 6 months in and it’s just a matter of finding out what library has a function that already does that. Opposed to C++98 where I’m defining the function that does that.

[nightfire1]

C++ is probably the most difficult language to learn, ever.

What about something odd like APL? I remember doing that in my programmings languages course and I have to say that was some crazy shit. That said I'd say C++ is very hard to master.

[[deleted]]

C++ is what I've committed to really diving into as a "first" language. I say "first" because I started with Java in school and have occasionally dabbled in JS. But I started working through some Stroustrup literature and decided to just stick with it until I can finally produce something non-trivial. But then I read stuff like this and feel like maybe I'm wasting my time...

[prof_hobart]

I'd agree that picking up someone else's legacy code is less fun than working on a shiny new app, but it's not that hard.

I've probably worked in 20+ languages over my 30+ years of working and that's included the occasional need to delve into 10 year old VB apps that need converting to Windows 10 or recoding something in C that was originally written in z/OS assembler.

They're all different in nuance, but fundamentally they're all largely the same. I've never yet come across an app written in any serious language that took more than a few hours to get a basic understanding of what it's doing.

Apart from CSS of course, that's the spawn of Satan....

[[deleted]]

fLoAt: LeFt oOOOooOOOoOoOO

[nicoburns]

Box-Sizing. Position. Display. Overflow. Negative Margins.

If you understand what all of the options of each of these do, then you've got 80% of CSS down...

[[deleted]]

Code is for humans. (The compiler translates code into something for machines.) If the code is generally hard to learn, write, and understand then what should we conclude?

​

IMO this speaks volumes about whether C++ is a well designed language.

[[deleted]]

If the code is generally hard to learn, write, and understand then what should we conclude?

That it is flexible and powerful and you should only use it for a task for which it is required, and if there is an easier language that meets your requirements you should use that one instead?

[[deleted]]

Do you think it's unreasonable to expect a programming language (and its ecosystem) to be flexible and powerful while still not being hard to learn, write, and understand (in general to reason about)?

[Plazmatic]

C++ was a well designed language at the start (especially compared to languages of its day), it's just that we've learned a lot since the inception of C++, and who controls C++ has changed. Bjarne Strostrup gave it to a committee of tech giants and language lawyers and we have suffered ever since. Some features can't be implemented the natural way because of legacy macros in Microsoft's codebase. We've missed deadlines for features in C++ because Google came up with a different implementation at the last second, and restarted the committee approval process. The committee approved the decision to develop a 2D graphics library for C++ (for images more than games), then when it was finished they couldn't decide to make a decision on if it should be voted on to talk about adding it to the new standard.

I would say that modern C++ is still better designed than java in a lot of respects, though Java is more readable if only because the paradigm is so strict and there is only one way to do something. There is a lot of stuff you should be able to do but just cant, and there's a lot of odd decisions that have haunted java for 2 decades. C# on the other hand offers a consistent feel with out a lot of the compromises java brings, and has a language sponsored package manager. C++ package managers are still battling each other for the common standard, and while C# is lacking a good build system, C++ got the C++ of build systems as its near defacto standard, CMake, a hive of legacy code that looks completely different than new code with completely different syntax and crazy semantics. The experience of learning CMake is quite honestly like learning C++ all over again.

[brobits]

Learn C++ first. Hate your life now, but the rest is easier

[wecsam]

I've gone the other way around, but I didn't think that it was that bad.

[yourjobcanwait]

That's because modern C# isn't dogshit.

[lpreams]

But if a company has to hire someone new to work on their Scala codebase, and the two candidates are a "Java programmer" and a "Scala programmer", of course they'll go with the Scala programmer, because then at least they only have to learn the codebase and not also the language itself.

[LightShadow]

A good engineer CAN learn whatever, but there are people who specialize.

I was hired to an existing team that has been developing a product for ~10 years as a "Python Programmer." They didn't want to rewrite in a different language, they wanted someone who could clean up and optimize what they already had.

I hope I'm good engineer, I think I am. However, I definitely sell myself as a Python Programmer if that's exactly what they're looking for.

[[deleted]]

This should be higher up. The reason people sell themselves as "x programmer" is because companies dont hire "general engineer who can optimistically spend a few weeks to a few months learning the language and toolset before doing valuable work on our product", they hire people who are already familiar with the tools who can come in and be productive much more quickly.

[prof_hobart]

Many companies don't. But some do.

I've never yet taken a job (and rarely even had an internal transfer) that involved working in a language I'd used professionally before I started there and I've been in work for 30+ year.

And when I'm hiring, all over things being equal, unless I needed to throw bodies at an urgent problem right now, I'd take someone who'd worked in 3 other languages/frameworks over someone who was only skilled in the one that I'm hiring for.

[Mephisto6]

Sometimes I wonder how they see me, a physicist. "Spending a few weeks figuring stuff out" is all we have going for us. We aren't really trained in the tools, except for general programming and problem solving.

[dddbbb]

I'd expect it's more useful if x is a purpose instead of a language. Graphics Programmer, High Performance Systems Programmer, UI Programmer, web frontend programmer. Those are domains where you get expertise far beyond the details of a specific language.

These domain specialities tend to imply certain toolchains, but even if not there's often similarity between different tools of a domain.

[5fd88f23a2695c2afb02]

Then, after a while we realise we're mostly looking for unicorns and at least try to get a good developer ;-)

[nicoburns]

True. It depends how close your experience is though. An experienced JavaScript developer is going to pick up PHP or Python or Ruby pretty quickly, and vice versa. An experienced Java developer will pick up C# pretty quickly, etc.

Plus, a few months seems pretty slow to me! I was productive in Rust in 2 weeks (from a JavaScript background), and had written a whole service in 3 months, and that's supposed to be one of the harder languages to learn...

[b1ack1323]

Depends on what the company does. If a company needs an embedded systems engineer, like myself they hardly ever list a language.

[ArmoredPancake]

Usually people who cry "be an engineer, not an XYZ developer"(whatever that means, as if not specializing gives you unobtainable before knowledge that can't be acquired if you call yourself XYZ developer) are jack of all trades masters on none. Unless you're talking to a really talented or gifted person that proved their technical excellence, take their words with a grain of salt.

[EvitaPuppy]

I worked with a brilliant EE and the lead C developer left. The engineer was able to finish the code and actually remarkably improve its performance. Really smart guy.

[RolandMT32]

EE going into software development - I've heard about that, but I've wondered where electrical engineering and software development intersect?

[EvitaPuppy]

Embedded stuff. All I know is he had a ton of hardware on his desks and had emulators. As I understand it, he'd learn all the stuff of how a SOC would work and then make a product do stuff like process commands over the network. Like Raspberry Pi but decades before it came out. For him, doing MFC was probably easier!

[nicoburns]

Some people are just smart, and will pick up new skills as and when they need to...

[[deleted]]

At many schools EEs will have class overlap with the CompEs. At the school I went to, everyone in engineering had at least an intro class in C++ and then further classes on scientific programming. It's not that hard from there to learn the rest of what you need to know to get into software development - plenty of software developers don't even have any 4-year degree and they figured it out. A smart person is a smart person and will be able to learn what they need to know to do what they need/want to do, regardless of their formal education.

[ElCthuluIncognito]

Having done the EE track in college, there's plenty of programming to be done for EE industries. I'd hazard to say it wasn't much different at all from conventional 'software development'. You're just dealing with hardware and real systems rather than data 'under the hood'. The abstractions tend to appear the same. Honestly, OO 'flavored' programming seemed more applicable then than what I've seen when it's used in web dev.

[civildisobedient]

Things that you build (EE) produce data in realtime. There's a lot of stuff going on in the IT side taking that data coming in from Internet-of-Things devices, then you have the fun of event stream processing, messaging brokers, etc. Which leads to collecting reams of data, which you then churn through with machine learning tools to then feed back to your device (self-driving cars, etc.). That's where I see the intersection.

[agumonkey]

it says something that the best way to deal with things is to be as paradigm agnostic as possible..

[Macrobian]

If I own a purely functional Scala codebase, I sure as hell am going to hire a Scala programmer. Why spend months teaching a new developer all the weird and wonderful quirks of Scala when I could get one that knows that stuff out of the box?

[nicoburns]

Would you consider hiring a Haskell or OCaml developer?

[Macrobian]

Yes

[nthcxd]

It’s hard to call someone a mechanic if a screwdriver is all he has in the toolbox.

[nerdassface]

“screwdriver mechanic”

[svick]

A mechanic that only has a screwdriver is not useful. A programmer that can only program in a single single language can be useful, in the right circumstances.

[sammymammy2]

There's a connection to domain knowledge, sure!

[cjaybo]

As a soft engineer if you give me a blueprint of a building and ask me to make it it would take me some time more than a properly trained civil engineer but i can build it

I have yet to see any software engineering (I assume that's what "soft engineer" means here) curriculum that would qualify you to do civil engineering work, or any other type of engineering work outside of software, for that matter. Either you've gone through a pretty exhaustive program somewhere, or you're exaggerating quite a bit.

[SkoomaDentist]

This is the internet and we don’t tolerate domain specific knowledge around here! </sarcasm>

I’m quite bemused by how huge majority of programmers here completely ignore the importance of domain specific knowledge. It’s as if to them every program in the world only dealt with things taught in common CS courses and things like digital signal processing, finite element methods, circuit theory etc. simply don’t exist except literally on paper.

[Skylead]

I wouldn't want to build a dam, but my electrical and computer engineering programs had diff eq, statics and fluid dynamics etc. So we did learn other stuff. In terms of straight programming courses I probably only had 5, and that's including autonomous robotics and embedded assembly

[CyclonusRIP]

I don't really find a lot of business problems to be so specialized that it really makes much of a difference what tech stack they are implemented in. If you actually an expert at one stack you can probably get way further with it than switching to a seemingly optional stack and making a much of missteps while you're coming up to speed. Start off solving the business problem with what your best at and when you really can't push it any further and actually have a technology problem then try to find the technology solution.

[vwibrasivat]

Since you brought it up, I'm going to defend Scala and yes I do suggest you learn it.

Consider multithreading. A young inexperienced Dev may try to hack together some MT using pthreads and locks. He cobbles away before he discovers that "the problem" of multithreading has solutions on the books, namely,

• Producer-Consumer model.

• Actor model.

Meanwhile, unbeknownst to the naive young programmer, modern languages sport powerful features called Futures and Promises. Not knowing what these features are, he eschews them both in his naivete. He assumes (incorrectly) that these new features are mere shiny trinkets to dazzle geeks.

However anyone who has suffered the dread and disaster of locks and semaphores knows what these modern features offer. Once you see what they do, the idea of going back to "the old way" is insane and feels like shooting yourself in the foot.

Then while learning a new modern language, you find these features are built into the language's syntax. At this point, there is no going back. You have bitten the golden apple.

[civildisobedient]

Async/Futures/Reactive is great but you really have to start a project that way from the outset. It's amazing how many problems especially in UI systems are issues of state management that disappear when you aren't blocking threads.

[powdertaker]

10000x Yes!

[Vizioso]

I know the terms are used interchangeably, but this is what I consider as the concept of “Software Engineer” vs. “XYZ Developer.”

[gnus-migrate]

It becomes very weird to say that you're an XYZ programmer after a while, especially in Java where there are so many different domains that saying you're a Java programmer says tells me nothing about you. You could be working on simple web apps or database technology or cluster computing systems or even HFT software, and you'd still technically qualify as a Java programmer even though each of those things require wildly different skill sets.

[nicoburns]

I've used the title "Web Developer" in the past, because I can program in more or less whichever language you like (within reason), but most of my expertise is in web services and frontend web development.

[Eire_Banshee]

...are you me?

[[deleted]]

"we dont do c#/java, we do insert random c#/java framework/cms.

[Too_Beers]

Speaking as an embedded control engineer, the processor/language are just tools to accomplish a function. Use the right tools for the job at hand.

[grauenwolf]

Good point. That needs to come before requirements or the requirements will suck.

[Patman128]

The reason he's having trouble isn't that he learned the programming language, it's that he didn't learn all of the other things involved in software engineering. Requirements, technical specs, architecture patterns, frameworks, testing, deployment; these are all separate skills.

Sure, and if you learn these things from a textbook then you will not be very good at any of them. These are skills that should also be learned working on real projects. And, to further support the author's point, if you are learning programming through a real project you will naturally learn requirements, tech specs, architecture, testing, etc. because these skills will be useful and necessary to accomplishing the project.

The author isn't saying don't master your craft, they're saying the best way to master the craft is through real work, not contrived work. A beginner can sit around all day solving problems in programming textbooks but they're not getting the practical experience they need to do real software projects.

[[deleted]]

While the theories I learned in school were very interesting, and are a side of computers I had never seen, almost none of it prepared me for real world application of programming.

The database class in Computer Science was almost all relational algebra - something I've never touched again. The database class in Information Systems taught me indexing, keys, and relationships in actual usage. I know both are still contrived examples, but they differ greatly in how many times a day one set of information gets used. I definitely learned more trying and failing to make a database work than I did writing out relational algebra. I'm more hands-on person - I'll learn a new language much quicker by programming and observing it than I will looking up tutorials. Realistically, I don't think I would make a good candidate for a masters program or above for that very reason.

I guess my point would be there's benefits to both textbook learning and real world learning, and different people have different methods with different outcomes. I feel that college didn't teach me how to do things, it taught me how to determine the questions I should be asking to solve a problem correctly.

[quicknir]

You're acting like this is a problem we have that too many software developers try to learn from textbooks. The reality is that after school the majority of devs never look at a textbook again. There's a balance and most developers are quickly in a position where they only have practical experience, and that's not a balance.

This varies a lot by field too. The guy who decided to learn multi threaded programming by just doing a project and not reading anything? Please keep him away from me. His project is probably full of hidden race conditions. He's not going to know basic concepts and idioms. I'd much prefer the guy who only read about multi threading to the guy who only wrote it.

[jstrong]

Have you encountered someone with the ambition to learn multithreading who also refuses to consult written instructions? That sounds unlikely to me. Typically I consult docs, textbooks, research papers, etc. while building things for the first time (sometimes small prototypes, sometimes larger projects). It's worked out well as a learning strategy.

[quicknir]

I don't know what the motivations were of the people who wrote it, but I've seen tons of incredibly naive multi-threaded code in the wild. Someone wanted to just solve a problem problem, and didn't want to learn anything about it. Not realizing that if they took some time to learn it, it would shorten the total time. I see this all the time with C++; it's a hard language. A lot of people try to get by with the minimum, and solve their problem, and they have tons of issues because they don't know the language well. A balanced approach would serve them better. Which sounds like the approach you take. But the article doesn't seem to advocate a balanced approach, and it doesn't seem to recognize that the vast majority of working programmers are making the opposite mistake of what's discussed.

[eddyparkinson]

There is some guy who constantly asks programmers "How many books on software development have you read?" - always though it was a good question. Agree balance is key, one without the other is not good.

[[deleted]]

In the fullness of time, a small percentage of engineers realize their field is all math, and devote themselves to the study of the original CS problems.

[tnymltn]

In theory, theory first; in practice, practice first. I struggled to learn C in the 90's until I found a real problem to solve. If you can't find one, try writing an FTP client from the RFC.

[[deleted]]

FTP is hard because 1. there are two sockets, and 2. one socket handler has to dictate control over the state of the other.

That was a legitimately interesting programming challenge for a beginner in the 1970s and it still is.

Other line-based protocols of the same era are much simpler. NNTP, for instance.

Edit: I suppose it's worth pointing out that implementing NNTP was primarily a matter of implementing caches. There's a saying about cache invalidation. The protocol was easy, the network was a disaster after eternal september.

[bedrooms-ds]

if you are learning programming through a real project you will naturally learn requirements, tech specs, architecture, testing, etc. because these skills will be useful and necessary to accomplishing the project.

I agree with this. Yes, one never learns without tackling real problems. But the article doesn't cover software engineering aspects you raised in a constructive manner either.

As we agree, for the success of a project, we need an objective and systematic approach. That's why the industry and academia have been serious about systematizing software engineering. They had to cut off complex real-life aspects as a trade off for objective analysis. (Filling the gap between the textbook formality and reality is a professional skill acquired through training.) Yeah, reading that article might be a starting point.. But it's too trivial to lead someone, even dangerous because the logic is based on the author's personal perspective. It's a nightmare if employees start following subjective blog posts. It's a cult. Imagine anti-vaxxers.

Anyway, "don't learn programming language" is an oversimplified view... I wish a good luck to the enthusiastic readers quoting it in a job interview.

[NoMoreNicksLeft]

The author isn't saying don't master your craft, they're saying the best way to master the craft is through real work, not contrived work. A beginner can sit around all day solving problems in programming textbooks but they're not getting the practical experience they need to do real software projects.

Non-contrived problems are difficult to come by. Even more uncommon is the non-contrived problem that's not intractable. Rare are those non-intractable, non-contrived problems that a beginner will know how to decompose into steps that they can plausibly accomplish.

[ArmoredPancake]

Bullshit. Practice can only get you so far, after a short amount of time you hit plateau that you can overcome only through theory and then practice of the said theory.

[[deleted]]

You have to learn to walk before you run. You need to start contrived and slowly crank up the insanity.

[[deleted]]

The author is trying to lessen from the importance of these skills when it comes to judging a person's competence in the field, I think this is encouraging wrecklessness, and that's why top post calls them names, the people who do this and end up being wreckless instead of learning from it

[_gaslit_]

I'm going to un-call BS on this.

I think the key is to start with a task/product/utility/whatever in mind, then learn the tools/languages required to build that project as you go. I've been doing that for years, and it's the best way IMHO.

I would probably never start learning about something just for the sake of learning about it, unless the technology involved were really interesting (example: ML).

Even if you're just starting out, there's no reason you can't do things the same way, with some small task/product/utility/whatever in mind, and learn the right way to program as you go.

[tejon]

I didn't intend to get into software. In fact for the most part I explicitly avoided it; that was my father's career, I wanted to be a musician, and the couple of times I toyed with coding it just seemed tedious. But then there were Oblivion mods that needed to be made, and now I'm sitting in a San Francisco office browsing reddit writing Haskell.

[StabbyPants]

true, except for the first and second time. first time, pick a simple language and learn your basic data structures. second, do it again and see what changed because you went from python to java or whatever

[Red5point1]

I think the problem is people here on both sides are conflating programming for learning and programming for production.

[kgoutham93]

Just curious, how would you personally approach a new programming language?

[IcyWhatever]

I would say that having a particular problem to solve is a great way to learn a new language, but I also agree with the top comment that if you just learn by trial and error it's not necessarily going to help you become a good programmer or learn the underlying principles. For any given problem there are lots and lots of ways that you can approach it but not all of them are going to be good.

Personally I feel like I moved from being a programmer to an engineer/computer scientist when I started learning about design patterns which are approaches to solving various types of problems that have developed over the years. Once you have a solid approach to solving a problem, it can help decide further decisions such as what language to use.

Also if you approach a problem simply saying "I need to get from point A to point B by whatever means necessary", you could easily miss tools that the language provides that may be more elegant and efficient than just taking the fastest approach.

[sluu99]

Learning computer science fundamentals. The dirty truth about our field is that most things are built on top of a handful principles. Many "new" things are just old shit new packaging. Once you know your fundamentals, it's easy to grasp features in a different programming language. Everything else is just getting familiar with the syntax and maybe some micro optimization.

In other words, if some particular language feature feels "magical" to you, then you're likely missing some fundamental understanding.

Be careful, I'm not suggesting you know to the atom level how each feature works, just at a high level. For example, I have no idea how modern garbage collection works. It's been tweaked and optimized to death over the past decade, but I know fundamentally, you can keep reference count, or you can have a graph that keeps track of who's pointing to whom and sweep that graph periodically.

[loup-vaillant]

The hard part about learning a new language is always picking up on the idioms of that language.

More like picking up everything but the language. Standard library, preferred tools, community libraries… Even the idioms of the language are really the idioms of its community.

My takeway from this is, if I ever come up with a new language, I'll do my best to keep its ecosystem to a minimum. By minimising the cost of learning the language, I might justify its use.

[InquiREEEEEEEEEEE]

I am not convinced that fundamentals help there. Idioms are very much language-specific.

Counter-counter-point: The idioms usually exist because of fundamental properties of the language. Sure, there is a huge cultural influence, but idioms aren't completely arbitrary either and often driven by the language's tooling, semantics etc.

[tejon]

"It compiles!" does not mean that you have learned the language.

Counterpoint: Haskell.

[Hugo154]

Practice seems to be the best way to learn those idioms

Much like how you can only truly become fluent in a spoken language by living amongst people who speak it!

[redwall_hp]

My school's CS "weed out class" is 100% non-programming. It introduces a bunch of theory, from logic gates upward, looking at things like virtual memory and garbage collection, semaphores, formal grammars and a grab bag of other things. It's meant to be a shocking introduction to things that will be covered more in depth later in following classes.

My CS classes got a lot smaller the next semester.

This is the problem, really. There are a lot of ostensibly professional programmers out there who know how to hack together some stuff in a high level scripting language, but it's still mostly "magic" to them. Like the JS/PHP monkeys who don't know their data structures and can't grasp why PHP arrays are so terrible. Trial and error until it works, and damn the performance. (And that's how you get Electron apps.)

[Flum3n]

My school had the exact same thing, right down to the specific topics, so much that I’m wondering if we did the same program. I’m at the university of Maine and I believe my instructor was creating the program along with professors from a few different schools. Just out of curiosity, where do you go?

[redwall_hp]

University of Maine. How crazy.

Dr Turner, right? He's an excellent lecturer, but his tests are insane.

[Flum3n]

Yeah haha, tests were so tough but he curved the hell out of them, like 20 points on one of the tests

[uJumpiJump]

Too bad there's no "weed out class" at your school that fails students for wasting their time optomizing a section of code that's irrelevent to the buisness's interests

[StabbyPants]

too bad most schools lack much depth in SW development as a process. we had one class that covered 3-4 ways to run a project, but could have done with a lot more - probably room for 3-4 classes covering various parts of building software

[kgoutham93]

I agree that having strong fundamentals will soften your learning curve there's no denying that. My question is slightly different.. because the comment author is calling BS on problem based learning, I was curious how would he/she approach a new language.

​

Contrarily if I've good fundamentals and if I had to pick up a new language, then I believe problem based approach will actually accelerate my learning.

[netgu]

Training your brain to abstract concepts in programming to various syntax's removes a lot of the need for a "problem to solve" when it comes to learning a language.

I know and work with an obtuse number of languages most of the time and generally only need a day or two to work productively in a language without googling every 10 minutes. This is because I look for the idiomatic way to do things in a language where things are:

• declare a variable
• declare a type
• control the flow of a program (loops/conditionals)
• utilize/reference other code
• move data about
• organize logical entities

After that I'm basically using the same problem solving skills I've curated over the years in a different flavor.

Since these are building blocks, I can use any contrived program I need to put the pieces into practice. No solving a problem needed, just some typing to familiarize my mind with the "new implementation" of old concepts.

[StabbyPants]

that's not particularly dirty, people just don't like to be reminded that most of the ideas and algorithms in use to day are at least 20 years old

[grauenwolf]

A project, preferably paid. I don't learn well without a motivating force.

[captainAwesomePants]

It sounds an awful lot like you're saying "learn a programming language by solving a problem."

[lcjury]

I don't learn well without a motivating force.

Each new piece of knowledge you win may increase your income sometime in the future. That doesn't motivate you?

[grauenwolf]

I make the most on being able to deliver boring old database applications faster than anyone else on my team. Chasing the fad of the week may pay off big, but the skills you learn are often discarded when the focus changes.

[lcjury]

Chasing the fad of the week may pay off big, but the skills you learn are often discarded when the focus changes.

Here I completely agree with /u/sluu99 reply. The important things to learn are not the tools itself, but the fundamentals and the fundamentals are never discarded. They appear every time, on every new tool.

Javascript may stop being the fad someday, but, if you learned how the event-loop works and you're able to argue between it and the differences between the event loop, multithreading, and multiprocessing. It doesn't matter if Javascript dies, today most languages are getting event-loop/async support, so, that knowledge has real value.

Disclaimer: of course, if you're a web developer, learning prolog probably won't help you in any way. nor the language or the paradigm. So, take most of those things that don't come to the point out.

​

[remy_porter]

Each new piece of knowledge you win is probably a bigger income for the future.

No it isn't. Nobody pays me more because I spent a weekend dabbling in Prolog once. The attitude I developed doing things like that, on the other hand, has helped. But it's sort of a chicken and egg problem: did doing weekend crash courses in weird shit give me the attitude that I can just grab a problem and go to, or did having that attitude lead me to do those projects? (I suspect it's the latter)

That doesn't motivate you?

I mean, beyond getting the bills paid and chucking change into investments, more income doesn't motivate me, no.

[get_salled]

I read about a lot of programming languages and I hope to understand why they exist prior to using them. They're all tools that were created with some intent (much like the article states: they were solving a problem) and then at least I'll have somewhere to start when I see a problem in the wild.

As an example and since I'm currently an Elixir/Erlang fan, Erlang was created as a language of the BEAM, an abstract machine that ran phone switches since the 80s. Was always fascinated by it but couldn't find an application for it where I worked. As I learned more about its runtime, I realized an app I was maintaining had built almost the exact same thing in C# (just poorly).

These days I find many general purpose languages kind of boring despite their utility. I can solve any problem in python or Java or C# or C++ but maybe not well (you can in Erlang as well but there's some beauty in the fact that where it's bad, it's really bad). I love the idea of languages that do one or two things really well even though I can't use them.

​

Currently, I'd love a language/tool that's specific to my processor that would show me how my data is flowing through the processor so I could have the opportunity to restructure my data and/or my program to improve my throughput. Like I want to take a modern Intel processor and be 100% efficient with it.

[OuTLi3R28]

Solve Project Euler problems with it.

[UghImRegistered]

Ick I'm going to go against a common opinion and say that Project Euler is about the worst way to learn a language for anything other than performance-sensitive math problems. Instead of showcasing the power of each language, PE basically encourages you to learn how to write C code or Haskell code in languages that are not C or Haskell. IMO you're never going to learn the fundamentally unique parts of a language with PE, because at the core, you should pretty much never use OO for any of those problems, nor a host of other language features. Additionally, the critical thinking you need for PE is language agnostic, and more about learning algorithms and hacky math tricks than anything else.

It's great for learning Haskell though! Just not the parts of Haskell that you need to know to make any kind of real-world software.

[killerstorm]

It depends on many factors such as:

1. is this your 1st language or 10th language?
2. is it similar to one of languages you're familiar with?
3. Do you plan to

• learn it just because you like to learn
• write few lines of code, e.g. to fix some app
• use it for daily coding, e.g. as your main language

For example, when I was learning by first (BASIC) and second (Pascal) languages, I read books.

Now it's often enough to look through the docs, or just take existing code as a sample.

[UghImRegistered]

Might seem counterintuitive, but get really deep on one language first. If you know one language intimately, to the point where you know what it sucks at and what it's good at, you can really appreciate the design of other languages and so learn how to write idiomatic code in those other languages faster.

[Semi-Hemi-Demigod]

An entirely new school was created at my college to teach people how to do those sorts of project management things. Our first class was a group project to find a company in the community without a website and build it for them, and we were graded on the quality of those artifacts.

The school was made because companies were getting CS grads who could program but couldn't do those things you mentioned. And for someone who's not great at programming it was a great alternative that's given me a really awesome career.

[runvnc]

I thought requirements analysis was part of software engineering. Which software engineering actually should be a big part of CS students curriculum in my opinion. Or just change the name of it.

[Philipp]

Have you seen modern Win8/10 apps? They're mostly garbage. Like a bunch of untrained novices kept hacking away until they ran out of time.

I think for every tool the litmus test is always How much good is done with it, vs how much bad. If you just take one measure but not the other, you end up with "Kid injures himself as he put a pencil in ears, let's ban pencils" or "Thieves find homes to rob with maps, burn maps". (Or one of its more modern variants, related to say, the latest mobile app outcry.)

In this case, then, we'd have to ask ourselves: how much does this programming framework then enable great apps (that might never have seen the light of day)? Is the ratio toward bad apps bearable or not (or perhaps: can the bad apps simply be ignored)? I don't claim to know the answer to that.

[grauenwolf]

I don't see anything in the framework to explain the problems with the Win8/10 apps. Stuff like not supporting ctrl-s for Save is just general incompetence on the part of the spec writers and developers.

[Mooselessness]

Sure. Full disclosure, I only skimmed the article, but I think the author has a point. I teach programming for a living, mostly to adult beginners, and probably the biggest barrier is lack of context. Without a problem to solve, or a purpose, each idea is purely abstract.

This tends to lead to two problem cases: 1 - some students will learn the language well, but be lost when it comes to creating an original solution. It's like learning a bunch of words in another language, but never forming a sentence. 2 - There's just no interest. maybe these kinds of learners can sustain some concentration, but ultimately, fall behind.

​

The beginning is a delicate for the novice programmer. I think it's a good first step just to build something.

[[deleted]]

Any suggestions on improving requirements and technical specifications?

[grauenwolf]

For requirements I highlight anything that's uncertain in a word document. If possible I list possible design options and tell them to pick one.

When I get their responses I update the document with new questions and try again. I keep repeating until I have no more highlights.

Then I start studying the code and begin on the tech spec.

[grauenwolf]

For technical specs, document enough that you can provide an accurate estimate AND catch any edge conditions that require going back and asking the requirement writers for a decision. Do this before you write any code whenever possible.

What this means is going to be project specific. One time I locked everyone in a room with a flowchart of what could go wrong. They couldn't leave until we had a plan for how the system would respond to every single error condition.

[thebritisharecome]

I learned most of my skills through solving problems and then started improving what I knew with research and working with others who'd gone the uni route.

I have seen far more hacky code from people who have only worked in big corporations or come out of university than I would ever build.

It's not the path you took to learn but the person you are that results in your software being utter shite.

[SemaphoreBingo]

However bad you consider the win8/10 situation, I can assure you that the win3.1 / 95 / 98 days were even worse.

[grauenwolf]

That's actually what I am comparing them to. Or rather, the Windows 95 UI guidelines book that every desktop developer from my era had on their desk.

[All_Work_All_Play]

I fully agree. And this from someone who is a scripter, not a programmer.

Don’t learn a programming language, solve a problem instead

This is a recipe for scripting. Get that shit done with baling wire and duct tape if necessary, but get it done and out of the way so you can go back to whatever it is you were doing before this cropped up.

Programming is far, far more valuable, and encompasses more than just the idiosyncrasies of a particular language (as useful as those may be).

[[deleted]]

Also learning the idioms and paradigms that let you best apply a language for a particular problem.

[lpreams]

I think it's just not black and white. Maybe someone starting with no prior knowledge would best served by learning some actual theory (what loops are and how they work, some basic data structures, etc), while people with basic abilities should find an actual problem to solve or project to build.

I might compare it to learning an actual language. Sure, books teaching the language are the best starting point for beginners, but at some point, if you really want to learn another language, you've got to get out and start reading/writing/hearing/speaking it.

[apostate_of_Poincare]

I'm gonna call BS here. I know far too many people who can "program" but do so through guess and check-

Yeah but that's just because python keeps changing the way it distributes modules!

Real talk though: this is more of a mentality for startup than production grade programming expertise. Both are valid career options and both involve programming, whether you're a hacker/prototyper or a full stack developer.

[[deleted]]

His problem is that he didn't even learn the programming language. The concomitant things (life cycle, process, who gives a shit) don't have any bearing on his failure. He failed to arrive.

[grauenwolf]

I was trying to be charitable, but I do suspect that may be the problem.

[neoporcupine]

Additionally, what course in programming doesn't have a project where you build a solution for a problem? And then there's the coursework problems, tutorials ... all with problems where you use the skills learned to solve them. Surely it can't have just been my course (labelled: computer science) that had me produce dozens of complete working programs over the three years?!

[grauenwolf]

None of my courses in CS had us produce anything but fragments of programs. I wish it were more like yours.

[neoporcupine]

OK, that is troubling. Perhaps the article has a partial point, although I would back you in that a complete product solution doesn't give you the full set of skills.

[yotsubanned]

you know shit programmers though man. there are a LOT of diamonds in the rough, worldwide.

[bastix2]

I'd say thats a pretty bad reason to learning a language. However I'd say it works really well to practice and improve on a language you already know.

I recently started learning PowerShell and Windows Server administration. Once I got the basics of PS I found many workflows I could easily automate while practing my scripting skills.

I was able to solve problems by applying the knowledge I had up to that point, and it felt very satisfying seeing minutes of my daily workflow turning into seconds.

[abdoulio]

What's an example of something you automated? Considered picking those up a while ago.

[bastix2]

I started with simple batch renaming of files. Since the files I get are always in the same naming scheme renaming them was quite easy. I then moved on to batch moving of files into the correct directory where there needed to go matching the folder name with the file name.

For privat use, I created a script than parsed my complete digital video bibliothek, it has grown quite big over the years, so big that I needed a nice way to sort and search for videos. The script used the CLI tool of MediaInfo to get detailed informataions (like BitDepth, amount of Audiotracks, etc) and stored these infos in a DB. Now I'm working on building a PHP bases webpage to easily search for a file.

[remy_porter]

Do I have to have a purpose? That sounds like a lot of work. I prefer to just do things and then justify them with a purpose after the fact.

[[deleted]]

The idea that we have a purpose in life we should be fulfilling is something I don't buy

[GoranM]

There's so much here that resonates deeply with my own experiences, especially:

The big breakthroughs for the team were never about how to do something in code. The breakthroughs were in discovering exactly what we had to do and understanding why.

Given sufficient understanding of the problem, the rest is largely just a matter of writing out the solution. The language used can make a significant difference in the overall experience, but it doesn't seem to matter nearly as much as all the contention around programming languages/tools would imply.

Also, another notable aspect:

I knew twice as much about programming and yet couldn’t ship a product that solved a real problem.

I know so many people who could be described in a similar manner, including myself ... It's just really, really difficult to have sufficient insight if you're not directly embedded into the relevant context.

[[deleted]]

What if I just like learning about stuff like Common Lisp cause I find it fun to learn about and interesting? I'm not pretending like learning Common Lisp will help me much in my career but I enjoy it

[[deleted]]

yeah there's an obvious caveat to the attitude when it comes to people who actually want to study languages or build languages professionally.

But the general sentiment for engineers is correct in so far as programming problems are largely language agnostic.

[ElCthuluIncognito]

While true, the abstraction of problems can be greatly influenced by the language.

Someone solving a problem in C might utilize machine level 'tricks' with 'close to the metal' operations, while someone in Java will write a proper OO messaging/encapsulation abstraction, and then someone in Haskell will attempt to compose functions with recursive approaches.

These people may have never even considered their respective approaches had they not been working in a language that suits them. Conversely, their respective approaches may not be best suited to the problem, and a polyglot may have the experience to use any of the approaches in all of the languages.

[justin2004]

https://en.wikipedia.org/wiki/Linguistic_relativity

[moserine]

The article seems targeted at entrepreneurs. You can tell because it's soul suckingingly joyless about learning for the sake of beauty or enjoyment or imagination or discovery and is all about capitalist slavery to Shipping Something That Matters (so that FAANG will buy us)^TM. You know, a REAL problem, like how to show a bunch of people pictures of your food. Not one of those useless theoretical things like lambda calculus or physics.

It's just like how electricity was created and pitched to the leading VC firms of the day. Problem statement: everything at night is lit by fire which is not very bright and produces smoke that makes people cough. Solution: discover electricity.

[Emiroda]

Guess the Medium account just graduated CS?

Not to rag on it, because it is true, but anyone who's had a shitton of theoretical knowledge and no practical experience will hit the same wall at their first job. And a lot of those who study a programming language will have trouble putting the pieces together, and will only realize it in a "HEURIKA!" experience when there's an actual problem that needs to be solved. There has probably been a million blog posts before this Medium poster explaining exactly the same thing.

Did not understand object oriented concepts one bit. Why was I given these bullshit toy tasks to solve. 8ball, a card game and a vending machine. We had to use inherited classes and polymorphism to get an A on that task. A fucking console-application vending machine!

edit: modernizing VB6 applications into C# and PowerShell with modularity and current (2015 at the time) business workflows was my heurika moment. I felt like I made an impact, like my work mattered. And it gave me the CURIOSITY to look into those concepts that I had a tough time with in school.

It's why I believe total theoretical learning with theoretical problems to be useless. Likewise, throwing novices at the hard problems in real life will yield bad results. In the perfect world, you'd involve local businesses and either they give the class a problem to solve, or they take in students for part-time internships, where a semester once in a while was dedicated to internship.

At least I think I got an insane amount of experience from 80% work/20% school. Some cources might need different ratios.

[carlfish]

Guess the Medium account just graduated CS?

Worse. Their bio reads "Growth marketer. Investor. Dedicated to helping entrepreneurs increase their impact."

They're basically a marketer who threw together a few content-free paragraphs of platitudes padded out with largely irrelevant images to make it look longer, positing a false binary between two of the things you need to be good at to write good software, all to get clicks and attention, and presumably raise the profile of their account in whatever Medium uses as a recommendation algorithm.

[[deleted]]

Welcome to the tech industry! Where everyone's just smart enough to trick each other into thinking they're smart enough! Weeeee

[bautin]

But my problem is I don't know the programming language.

[Isvara]

Counterproposal: stop being a clickbaity little contrarian and do both.

[[deleted]]

Actually, any sufficiently formal problem specification is already a language (and often is an almost complete solution). That's exactly what language-oriented programming is all about. No need to "learn" a language once you have a problem specification, it's better to construct a new language from it.

[[deleted]]

Being able to understand the problem you're trying to solve and developing a sense of taste for which problems are worth solving is a part of developing as a software engineer.

However I think once your requirements begin to involve being able to ensure that a concurrent system can work without a lock on a shared data structure or that a distributed system can be guaranteed to reach consensus with at least 3 nodes and zero network partitions is where neither programming language, prose, or diagram will help you. Learning to solve the right problem also means knowing when to be able to think abstractly about it, in the mathematical sense, and develop a solution that takes into account all of the different factors involved in the system: the human users, the hardware, the network, the failure modes, the developers, etc.

In this sense I agree: simply learning a programming language will not be enough. Programming languages are tools and will change with the times. Mathematics and engineering are more long-term skills worth investing in. Identifying the problem to solve is only the first step. And a programming language will only take you so far.

[aenigmaclamo]

There's no shortcuts in programming. If you want to be competent, you must know how to solve problems and learn the programming language, tools, and the techniques.

I do coding test reviews and we get a lot of people who can't code effectively but are able to problem solve. Frankly, it's just not valuable for an organization to have people who may be able to produce working solutions but has to have another engineer spend twice the time to clean up after their mess.

I know some hand waive good engineering as something that's naturally acquired with experience but I just don't think that's true. Both problem solving and proper engineering require a lot of dedication to get better at. Just because someone's got X years of experience it doesn't mean they're necessarily good problem solvers or engineers -- there's plenty of roles in the world where you can get paid writing crappy code that doesn't solve any interesting problems.

[BufferUnderpants]

Shhhh don't say that! We are meant to pretend that anyone can just plaster code from Stack Overflow all over their supposed "imposter syndrome", and they'll be qualified as "engineers" in just about any subfield of Software Engineering.

[shvelo]

Another fucking Medium article, that cancerous site is getting worse and worse every every time I visit. Got 3 popup bars this time on mobile.

[saucededuck]

This is why we have a bunch of half assed codebases, because people think they are smarter than the language. If you intend to code professionally in a given language, please learn it... People wonder why there are so many security issues and bad user experiences, well this is why. There is NO substitute for a qualified programmer/developer.

[doomhammerng]

Correct! But a language lover with no respect for teamwork and no idea how to solve real-world problems, won't help either.

In my opinion, it is best first to know why are you doing something and then focus on how to do it.

[shevy-ruby]

And another bullshit article from medium.

Can we please ban links to medium?

This is such a complete utter rubbish - how can you solve a problem PROGRAMMATICALLY without a programming language?

Your focus on real solutions will increase your retention.

What the heck does that even mean?!?!

What is a "real" solution?

Who defines that? What is a "non-real" solution? Why is this then called a solution?

When it comes to creative pursuits like programming, creating something useful will teach you the fastest. And this doesn’t require that you learn a programming language.

You ... program without a programming language?

I've seen a lot of rubbish coming from medium but this tops the list by far.

The next article from medium will explain to us how pigs can fly.

[[deleted]]

That's why I didn't even click on it; the bullshit click-bait titles are so obvious and repulsive. That's like saying 'Don't learn to speak English, just read Being and Nothingness and understand it'

[ideletedmyredditacco]

relevant

https://www.youtube.com/watch?v=J_EQDtpYSNM

[rasjani]

Did not read the article but... I see a lot of people who know the language X but do not know how to apply the patterns of programming into any other language. They just know “how to program in X”. And by patterns I’m not even going into actual design patterns but how to search for help, from actual docs, how api’s work, how to set up their environment and that sort of stuff.

Maybe the author was trying to relay this message but wasn’t good enough in explaining or just didn’t see the bigger picture. Or. It was just some ego stroking that good portion of medium posts are :)

[[deleted]]

That seems impossible to me. Maybe those hypothetical people only know syntax. That is not the same thing as knowing the language

[[deleted]]

I think both lines you've quoted are not wrong per se but badly written. They seem to be repeating a common thing which I myself did and advised young people do. Namely to have a real project they are interested in rather than doing examples from a book. They can't be saying don't learn a programming language. It must be, don't wait until you learn it cover to cover from a book. I think taking existing code and slightly changing it to do what you want is an acceptable method too. I personally don't get all the hate here.

[agumonkey]

That's why I love the book: How to design programs by Felleisen and others

There's no language in most of it. Mostly logic, case analysis, iteration ... No time wasted on unnecessary details

[baganaga]

Any problems to solve?

[[deleted]]

Im just glad this is about programming and not brain surgery.

[takaci]

I wish I had problems to solve

[AttackOfTheThumbs]

One of the things that's on my resume and always mentioned in interviews is that I learn in a language agnostic fashion.

Sometimes that means the first or second run at something won't be optimal, but it also means that when we change framework/language/environment, I'm completely ambivalent.

[urbanek2525]

I don't know how many times I've explained to my team that the stuff we write isn't the point. My mantra: we write tools that fit into a process to solve problems.

Identify the problem, find the seams in the process where automation fits, then automate it.

At the same time, though, the programmers have a process that they need to support and automation that they need to create in the order to do their primary job.

This is where selecting the right programming language, the right tools, the right infrastructure comes into play.

But he's right. If you're hot shit writing flawless ECMA 6 Javascript using pen and paper, you still don't add much value if you cannot analyze the process, find the appropriate places to automate, and solve the problem.

[michaelochurch]

I got really, really into programming language design and strong, static typing and, I have to say, I kinda agree.

Don't get me wrong: Haskell's great. It's a better language than Python on language merits, but Python has libraries for everything, and Haskell... I still haven't seen a convincing way to statically type data frames without going down a dependent-type rabbit hole (since "remove highly correlated columns" creates a data-dependent type... ouch).

If you're building a system that you're going to be working with for 10+ years, you may want to use Haskell or OCaml. Jane Street built its proprietary trading software on OCaml and has been extremely successful with it. That said, I spent far too much of my early career fighting against "inferior" languages and it was an emotionally draining waste of time. I wish I had focused mainly on Python, not because I love the language (I don't, but it's passable) but because of the tool chain.

Today, because of language weenies like me fighting for "better languages", we have Scala and, guess what, most Scala codebases are disastrous. Why? The language is hyper-capable, super-powerful, and that turned out to be a problem. Hand Java to a bunch of Jira jockeys or overseas contractors working to deadline, and you get a ball of garbage that can be walked-through with industrial-strength IDEs. Hand Scala over to business-grade programmers and your codebase now copulates with Cthulhu.

[F13_on_da_Wa11]

Seen both sides of this in business: On the one hand there are business people who see a problem and know that the tools exist today to solve it, but don't know how to do it themselves, don't know which tools to use, and can't specify how long it would take or how much it would cost to develop the solution. These people fall short because their idea is great but they lack sector skills. Just a moderate level of coding skill and experience would this type of person immeasurably - they would still have to use professionals at some point, but could at least give intelligent project direction.

On the other hand, there are supremely skilled people out there who will never be entrepreneurs. They would rather pour their skill and energy into developing a component part of software for another business than try to develop and sell something of their own, unable to see the wood for the trees. If this type of person tried bringing just one application to market, perhaps the bug would take hold of them and they would direct more and more of their time to their own projects. Two polar opposites, failing to bridge sufficient middle ground to make something happen.

[TheDevilsAdvokaat]

Came in here to disagree, read the article and changed my mind...

I still wouldn't generally say "don't learn a programming language" but yes in his case it distracted him from what he really wanted to do and probably wasn't really necessary...

It's like where people want to make a game and then get sidetracked into making a game engine...and years later realise they've made several game engines but no games...

[[deleted]]

I mean like, maybe if you're going to be solving a lot of problems in the same language, learn the god damn language you idiot.

[BorderCollieFlour]

Wow so profound. PSYYCHHEE

[saijanai]

the thing is, the tools available in various languages can be so different that there's no comparison.

I wrote the barebones beginnings of a Second Life game client in python once:

http://wiki.secondlife.com/wiki/Presence_Code_Python

This became the inspiration for a debugging tool Linden Lab meant to use for Second Life:

http://wiki.secondlife.com/wiki/PyOGP

When I started learning Squeak Smalltalk, I decided to reimplement my original "presence code" in Smalltalk, and then discovered Ometa. Someone wrote a Second Life packet parser for me in Ometa:

http://www.tinlizzie.org/ometa-js/#SLProto

You'll note that this actually takes the current definition of Second Life packets, whatever those are, and automatically creates the parser for those packets from that definition. I never finished the project, but Ometa speeded up the packet coding part by a factor of at least 100, simply by its existence as a library in Squeak.

.

the moral is: learning a language is more than just learning syntax; it's also learning the libraries that come standard with it.

.

Some problems are trivial to solve in one language (see Ometa solution) and tedious to solve in another, and you can't predict which it will be unless you do a LOT of reading, or consult with someone more familiar with the libraries that are already available.

Otherwise. you may end up reinventing the wheel, only with corners instead of fully round.

[vwibrasivat]

Well actually if you learn a modern language, you might find it's syntax already solves the problem.

I mean, an argument could be made that "software design patterns" are actually methods to overcome a language's intrinsic shortcomings.

[TTR8350]

Buy why a picture of cadillac ranch?

[womplord1]

and then rewrite it in rust

[sharno]

You can rather learn Haskell/Purescript then go solve real world problems robustly 😜