10 ms·

I think you can write any program using only advanced concepts from the problem domain, not advanced concepts from programming itself. For example, I'll happily

I think you can write any program using only advanced concepts from the problem domain, not advanced concepts from programming itself. For example, I'll happily implement a difficult numerical algorithm for inverting a matrix, but I won't write a monad framework in C++ for that. IMO there are almost no projects that call for programming cleverness (as opposed to problem domain cleverness). You can get very far with boring imperative code that any beginner can read, with powerful algorithms introduced only locally and documented clearly.

verelo 10y ago
This is exactly the attitude I try get into every developers head! Please write maintainable code using common and broadly understood methods. There is no award for surprising me in how fancy your solution is, in fact the opposite.
- klibertp 10y ago
  > There is no award for surprising me in how fancy your solution is, in fact the opposite. While I can agree with "no award" part, I don't think "the opposite" should be true. How do you know you got surprised because the method was "fancy" instead of because your knowledge was lacking?
  - verelo 10y ago
    While I do not go around trying to beat people with a stick when they make things I see as overly complex, I think it's good to have a conversation about it, sit down together to find the simpler solution [or accept the one that is already implemented] and hopefully reach alignment on the path forward. It's totally possible my knowledge is lacking, which is why the conversation is critical. If I just need to be educated on why something I saw as complex was the right decision, so be it, and I look forward / enjoy those opportunities. At the end of the day, I run the tech team and founded this company, while others might come and go, I need to feel ownership over the code, product and most importantly it's shortcomings. If I cannot own that openly, I cannot lead/direct others, and that is when technical teams really start to fall apart imo.
  - BurningFrog 10y ago
    Doesn't matter. If your code is not understandable by most developers, it is probably worthless in practice.
    - klibertp 10y ago
      The only thing that lays further ahead on that road is the lowest common denominator, copy-pasted code and lots and lots of mediocre code monkeys. I don't want to go there, although I can understand people who would like programming to work that way.
- jimbokun 10y ago
  "Please write maintainable code using common and broadly understood methods." Often times, the most common methods are the most obfuscated and unclear. Maybe this is my perspective just because I am a Java developer. Pulling in lots of poorly understood dependencies. Depending on annotations that change execution flow in complex ways that are very difficult to follow, even with a sophisticated IDE. Deploying into complex web containers. ORMs mapping method calls into who knows what SQL calls. Lots of superfluous mutable state everywhere. (I'm looking at you Spring. Although Spring Boot is a definite improvement.)
  - deleted 10y ago
    [deleted]
  - verelo 10y ago
    Sorry, the use of the word 'common' was a poor choice [and I'm actually not sure what would be a better choice]. I agree with you wholeheartedly. I honestly find a lot of those common methods very confusing.
  - Roboprog 10y ago
    Thank you. After 30+ years of programming, I am often completely disgusted at what a bunch of magic filth JEE/Spring is. The guy(s) who made annotations in Java 1.5 deserves extreme punishment :-)
    - AstralStorm 10y ago
      Nah, annotations are great when they're used for their stated purpose, that is, annotating code. They shouldn't have been allowed to actually change runtime behavior or be used to control code generation.
- lmm 10y ago
  Sure, but to my mind monads are common and broadly understood, at least compared to all the alternatives for achieving the same kind of thing (e.g. AOP shudder).
  - AnimalMuppet 10y ago
    Within FP, sure, monads are common and (at least should be) broadly understood. Outside of FP, though, monads are neither common nor well understood. You make these broad statements about monads as if FP was the whole programming world. It's not. It's probably less than 5% of it.
    - smaddox 10y ago
      But isn't typical high-quality OOP code essentially Monadic code? State is encapsulated in an object and transformed by method calls. Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. The basic operations are all the same. OOP is just less strict with how you can transform objects, i.e. function/method purity is not enforced.
      - catnaroek 10y ago
        > But isn't typical high-quality OOP code essentially Monadic code? Nope. > State is encapsulated in an object and transformed by method calls. Monads aren't objects (which necessarily have a runtime manifestation). Monads (as used in functional programming) are abstract type constructors (which normally don't have a runtime manifestation). > Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. Monadic bind satisfies three concrete, clearly defined algebraic laws. The use of monads in functional programming arose from the field of denotational semantics, which gives “programs” (by which functional language semanticists mean “expressions”) precise mathematical meanings in a compositional manner.
        smaddox 10y ago
        I understand what a Monad is. My point is that high-quality OOP code typically adheres to the rules of Monads. I didn't say Monads were objects. I simply talked through the most common properties and operations of OOP code, in order to show how they are closely related to the operations on Monads. I understand that OOP code does not, in general, satisfy the constraints of Monads. Hence, why I specified high-quality OOP code, which, in contrast, typically does.
- lacampbell 10y ago
  What's fancy to you? What's broadly understood? Will you get upset if someone in your java codebase uses lambdas or optionals or even the ternary operator? All of the above are still considered black magic to many in our industry.
  - AstralStorm 10y ago
    If a standard feature in your language of choice confuses or upsets you when it is not misused... You may have a problem. The problem is typically lack of willingness to learn.
  - verelo 10y ago
    It totally depends on the situation, is it something the whole team needs to work with on a regular basis? And is it really the most optimal solution (those two questions are highly interlinked)? If that's the case then we might want to a) educate everyone else first or b) pick something we know will be less of a struggle for others to maintain. I guess there is always option c) ask the original author never to leave and be available 24/7 to answer questions, but that, obviously, isn't realistic. Edit: I answered the question poorly. Are you "writing art" or doing your job? I don't mind if the outcome is pretty, but your first priority is to do your best in your role within the organization. If the author or the code feels that is the case then generally I won't ever get upset with anything they do.
- slededit 10y ago
  I work on a product that was mostly C. At the time the developers loved it! Look at how clear and explicit everything is. These days however people recoil in horror when they see parts still in that old C style. The rest of the world can and will change their definition of what "common and broadly understood" means.
organsnyder 10y ago
I rarely solve difficult programming challenges. I solve difficult business challenges all the time.
- phantarch 10y ago
  I'll echo that sentiment, I experience it daily. Very rarely is a business itself abstract and complicated enough to merit an abstract and complicated technical solution. Meatspace is still pretty simple.
  - chimprich 10y ago
    There's often a non-complicated solution to a difficult problem but spotting it takes some skill and experience and sometimes takes longer to implement than a more obvious complicated solution.
    - AstralStorm 10y ago
      And sometimes complicated problems can really be solved only by a complicated solution, but can be half-assed in a simple way. You pay for the partial solution much later. It is good to avoid future discounting in this way.
- deleted 10y ago
  [deleted]
- BurningFrog 10y ago
  I usually solve difficult programming challenges by turning them into simple ones.
- krylon 10y ago
  For the past couple of years, I have been employed as a sysadmin, but for the past ~two years, my main task has been to implement the glue that hooks up several software systems we use and write what could be reporting tools. Programming-wise it's been kind of dull, actually. No fancy clever stuff. At the same time it's been demanding in terms of understanding the business perspective on things. How do you define "costs accumulated on a given project" or "coverage contribution of a given project"? Having no background in business management or accounting, I have little to no clue, but it sure was interesting to find out. So, yeah, we're in the same boat, I guess. ;-)
jasim 10y ago
Give me my procedures, conditionals, and loops, and I shall move mountains. Assembler (Prince of Persia): https://github.com/jmechner/Prince-of-Persia-Apple-II https://github.com/jmechner/Prince-of-Persia-Apple-II BASIC: http://softwareengineering.stackexchange.com/questions/149457/was-classical-basic-ever-used-for-commercial-software-development-and-if-so-ho http://softwareengineering.stackexchange.com/questions/14945...
- cr0sh 10y ago
  Regarding that second link: My career in software development started with BASIC - Pick BASIC to be exact. It was 1992, and I was 18 years old, had moved to Phoenix a week after graduating from high school to attend a local tech school (now defunct), and I needed something to pay the rent after having my hours cut as a cashier for Osco Drugs. Seeing my other classmates at the time taking "apprenticeship" positions doing electronics work, I decided to "cold-call" nearby companies, and landed on a "mom-n-pop" shop doing software development work. I put in my application, and they took a chance on me. They didn't hire me as a software developer, though - but as an "operator" - the guy to "run reports, keep paper in the printers, and mount tapes" for the actual programmers, to free up their time. I learned how to load a open-reel 9-track tape drive with vacuum columns at that place...something I have never used since. I was "in heaven" - being paid much more than I was as a cashier (but finding out much later that I was actually "underpaid" - oh, the ignorance of youth!), while doing less work! They gave me access to an account on their IBM RS6000 system running AIX - and one of the guys gave me a book on PICK BASIC to look over, and play around with. The shop developed "insurance claims management" software for the "Arizona Health Care Cost Containment System" (AHCCCS) - basically Arizona's form of Medicaid; this company's software managed claims (accounting, billing, etc). They used a form of PICK called "UniVerse": https://en.wikipedia.org/wiki/Pick_operating_system https://en.wikipedia.org/wiki/Pick_operating_system PICK (and UniVerse) were actually very interesting systems on their own; kinda a self-contained OS that integrated a programming language (BASIC) with a relational (and multi-value!) DB, along with other stuff. It compiled to a byte-code, which some manufacturers made CPUs to run (instead of interpreters); the idea was "portable software" across multiple architectures. Basically the idea of Java before Java. It worked out about as well, of course (because every implementation of PICK was just a bit different). Anyhow - the programming language used was BASIC - and my experience up to that point was writing bits and bobs of BASIC (plus some assembler - for the 6809 and 6502 processors - interestingly the latter was for the Apple IIe - CALL -151 was my friend; hand assembly of op-codes in the monitor - ugh). Well - they were monitoring the account, as I coded up adventure games and other diversions in PICK BASIC. The programmers and owner started feeding me with tasks ("hey, can you fix this issue" or "can you build this demo for the printer", etc) - and I proved myself. They hired me after I had graduated the tech school, and I've been here in Phoenix ever since. As far as BASIC and businesses are concerned - it is still used today, as much as everybody rants on it. Besides Visual Basic (large following there), PICK BASIC is still used (it has a legacy almost as long and broad as COBOL), and there are many other old "business BASICs" that existed and still have users today. I also know that there is at least one industrial robot arm manufacturer who sells a "Robot BASIC" to program and control their arms. ...and BASIC lives on today, of course - both closed and open-source variants. I'm more familiar with the various open-source BASICs. You have Gambas (which looks very much like VB), then there is QB64 (multi-platform 64 bit compiled QBASIC if you will), and also something called "BaCON", which is a "BASIC-to-C" converter (just the other day I was thinking taking it, and dumping out some Web Assembly code - essentially to see if I could get a BASIC program compiled to run in a web browser). There are also more than a few interpreters in javascript and other languages that can run BASIC code of some sort or another. Would I recommend it for new projects of large scope? Probably not, but I wouldn't outright discount it, either. I think it still has its place in the computing world, though that world is doing its best to ignore it in the hope that it is forgotten. It did teach some "bad habits" - but I think that a modern form of it, with proper OOP support, could be a very powerful teaching language for beginners - which is what it was always meant to be. It will always have a spot near and dear to my heart, at least.
lmm 10y ago
I don't think you can write maintainable code without monads. Code has to be written in the language of the business domain so that it can be understood in those terms, so you can't (to take an extreme example) have every other line being "if err != nil ...". But if you leave secondary concerns completely implicit then your code also becomes unmaintainable because you can never understand what any given function is doing (at the implementation level) and so you can never maintain anything. You need the dual perspective that monads or something like them give you where you can say "this is a secondary concern in this code but it is there". It's not about "programming cleverness" - there's nothing "clever" about monads, rather the monad is a very simple and boring interface that turns out to be a good tool for helping you write code that does what it looks like.
- emcq 10y ago
  I might be confused, but there is ample evidence that you can write maintainable code without monads. Take the Linux kernel, NASA rovers, or redis - all written in boring old C with no monads and great results.
  - AstralStorm 10y ago
    Linux kernel is the opposite of boring old C, as in procedural code. It is nicely factored object-oriented C in most of the important places.
  - vkjv 10y ago
    If you replace, "maintainable" with "easily maintained by a large group of people" the statement holds true.
    - emcq 10y ago
      Can you give an example of a project maintained by a large group of people written with monads? The only one that comes to mind is Spark, and while I haven't used it recently, was nightmarishly buggy with many subtle corner cases :/ Even jumping outside of C, Atom, Eclipse, Chrome, FireFox all are maintained by large groups of people and dont have a single monad!
amelius 10y ago
> I think you can write any program using only advanced concepts from the problem domain, not advanced concepts from programming itself. But that is a trivial statement considering that a Turing-complete subset of most (all?) languages is relatively simple. The point addressed by the article is maintainable code, which is something else.
- fatbird 10y ago
  OP's point is that the best way to write maintainable code is using bog standard, boring code and leaving clever solutions to the level of the problem domain.
  - AstralStorm 10y ago
    Bog-standard meaning not testable and not contract-based? Clever solutions and abstractions (hey, immutability is clever right?) can really help out reasoning. And sometimes you really need clever things due to problem domain, so you really end up with totally not boring code. For example, you wouldn't cook up your own matrix manipulation everywhere, so you use a clever solution instead. Writing operations directly opposed to composing and optimizing them. Or in high performance world, using a much more complex but lock-free algorithm instead of the "bog-standard" locked one, sometimes the benefit is huge. The real important part is to exactly document the clever parts and enforce contracts on them, so you do not end up with potpourri everywhere.
manmal 10y ago
With some caveats. Execute 10 network requests in parallel on background threads, then reconcile their results, after that fire off another 3 requests in parallel (again, on a background thread), reconcile all the values you got so far, and return to the main thread. Oh and repeat the whole thing every time the user session's token changes, or the user requests a manual refresh. Also don't forget to cancel all running requests when the process is interrupted before it is finished. One more thing: If one request fails, bubble the error to the main thread and skip all subsequently planned requests. You CAN solve this with counters and locks (be careful about deadlocks though), but you will save yourself a lot of pain if you just use a FRP framework. You will also be able to easily react to the things you forgot ("Oh the requests should also be halted and retried after connectivity is lost"). So where do you draw the line? Do you spare your coworkers the agony of learning FRP or do you implement something where you suspect it will horribly crash and burn in production?
edblarney 10y ago
+100 This took me 10 years to realize. I find myself getting rid of everything clever, my code reads like a boring instruction manual. I'm starting to deeply re-think how code interviews should be conducted. Instead of asking smarty-pants questions, we should be asking mediocre questions and just asking someone to put together a straight-forward and simple solution. Important: it's surprisingly difficult to make code that looks simple and boring :), it often takes some iteration.
multinglets 10y ago
Attitudes that Lead to Mixing Problem Domains

verelo 10y ago

This is exactly the attitude I try get into every developers head! Please write maintainable code using common and broadly understood methods. There is no award for surprising me in how fancy your solution is, in fact the opposite.

klibertp 10y ago
> There is no award for surprising me in how fancy your solution is, in fact the opposite. While I can agree with "no award" part, I don't think "the opposite" should be true. How do you know you got surprised because the method was "fancy" instead of because your knowledge was lacking?
- verelo 10y ago
  While I do not go around trying to beat people with a stick when they make things I see as overly complex, I think it's good to have a conversation about it, sit down together to find the simpler solution [or accept the one that is already implemented] and hopefully reach alignment on the path forward. It's totally possible my knowledge is lacking, which is why the conversation is critical. If I just need to be educated on why something I saw as complex was the right decision, so be it, and I look forward / enjoy those opportunities. At the end of the day, I run the tech team and founded this company, while others might come and go, I need to feel ownership over the code, product and most importantly it's shortcomings. If I cannot own that openly, I cannot lead/direct others, and that is when technical teams really start to fall apart imo.
- BurningFrog 10y ago
  Doesn't matter. If your code is not understandable by most developers, it is probably worthless in practice.
  - klibertp 10y ago
    The only thing that lays further ahead on that road is the lowest common denominator, copy-pasted code and lots and lots of mediocre code monkeys. I don't want to go there, although I can understand people who would like programming to work that way.
jimbokun 10y ago
"Please write maintainable code using common and broadly understood methods." Often times, the most common methods are the most obfuscated and unclear. Maybe this is my perspective just because I am a Java developer. Pulling in lots of poorly understood dependencies. Depending on annotations that change execution flow in complex ways that are very difficult to follow, even with a sophisticated IDE. Deploying into complex web containers. ORMs mapping method calls into who knows what SQL calls. Lots of superfluous mutable state everywhere. (I'm looking at you Spring. Although Spring Boot is a definite improvement.)
- deleted 10y ago
  [deleted]
- verelo 10y ago
  Sorry, the use of the word 'common' was a poor choice [and I'm actually not sure what would be a better choice]. I agree with you wholeheartedly. I honestly find a lot of those common methods very confusing.
- Roboprog 10y ago
  Thank you. After 30+ years of programming, I am often completely disgusted at what a bunch of magic filth JEE/Spring is. The guy(s) who made annotations in Java 1.5 deserves extreme punishment :-)
  - AstralStorm 10y ago
    Nah, annotations are great when they're used for their stated purpose, that is, annotating code. They shouldn't have been allowed to actually change runtime behavior or be used to control code generation.
lmm 10y ago
Sure, but to my mind monads are common and broadly understood, at least compared to all the alternatives for achieving the same kind of thing (e.g. AOP shudder).
- AnimalMuppet 10y ago
  Within FP, sure, monads are common and (at least should be) broadly understood. Outside of FP, though, monads are neither common nor well understood. You make these broad statements about monads as if FP was the whole programming world. It's not. It's probably less than 5% of it.
  - smaddox 10y ago
    But isn't typical high-quality OOP code essentially Monadic code? State is encapsulated in an object and transformed by method calls. Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. The basic operations are all the same. OOP is just less strict with how you can transform objects, i.e. function/method purity is not enforced.
    - catnaroek 10y ago
      > But isn't typical high-quality OOP code essentially Monadic code? Nope. > State is encapsulated in an object and transformed by method calls. Monads aren't objects (which necessarily have a runtime manifestation). Monads (as used in functional programming) are abstract type constructors (which normally don't have a runtime manifestation). > Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. Monadic bind satisfies three concrete, clearly defined algebraic laws. The use of monads in functional programming arose from the field of denotational semantics, which gives “programs” (by which functional language semanticists mean “expressions”) precise mathematical meanings in a compositional manner.
      - smaddox 10y ago
        I understand what a Monad is. My point is that high-quality OOP code typically adheres to the rules of Monads. I didn't say Monads were objects. I simply talked through the most common properties and operations of OOP code, in order to show how they are closely related to the operations on Monads. I understand that OOP code does not, in general, satisfy the constraints of Monads. Hence, why I specified high-quality OOP code, which, in contrast, typically does.
lacampbell 10y ago
What's fancy to you? What's broadly understood? Will you get upset if someone in your java codebase uses lambdas or optionals or even the ternary operator? All of the above are still considered black magic to many in our industry.
- AstralStorm 10y ago
  If a standard feature in your language of choice confuses or upsets you when it is not misused... You may have a problem. The problem is typically lack of willingness to learn.
- verelo 10y ago
  It totally depends on the situation, is it something the whole team needs to work with on a regular basis? And is it really the most optimal solution (those two questions are highly interlinked)? If that's the case then we might want to a) educate everyone else first or b) pick something we know will be less of a struggle for others to maintain. I guess there is always option c) ask the original author never to leave and be available 24/7 to answer questions, but that, obviously, isn't realistic. Edit: I answered the question poorly. Are you "writing art" or doing your job? I don't mind if the outcome is pretty, but your first priority is to do your best in your role within the organization. If the author or the code feels that is the case then generally I won't ever get upset with anything they do.
slededit 10y ago
I work on a product that was mostly C. At the time the developers loved it! Look at how clear and explicit everything is. These days however people recoil in horror when they see parts still in that old C style. The rest of the world can and will change their definition of what "common and broadly understood" means.

organsnyder 10y ago

I rarely solve difficult programming challenges. I solve difficult business challenges all the time.

phantarch 10y ago
I'll echo that sentiment, I experience it daily. Very rarely is a business itself abstract and complicated enough to merit an abstract and complicated technical solution. Meatspace is still pretty simple.
- chimprich 10y ago
  There's often a non-complicated solution to a difficult problem but spotting it takes some skill and experience and sometimes takes longer to implement than a more obvious complicated solution.
  - AstralStorm 10y ago
    And sometimes complicated problems can really be solved only by a complicated solution, but can be half-assed in a simple way. You pay for the partial solution much later. It is good to avoid future discounting in this way.
deleted 10y ago
[deleted]
BurningFrog 10y ago
I usually solve difficult programming challenges by turning them into simple ones.
krylon 10y ago
For the past couple of years, I have been employed as a sysadmin, but for the past ~two years, my main task has been to implement the glue that hooks up several software systems we use and write what could be reporting tools. Programming-wise it's been kind of dull, actually. No fancy clever stuff. At the same time it's been demanding in terms of understanding the business perspective on things. How do you define "costs accumulated on a given project" or "coverage contribution of a given project"? Having no background in business management or accounting, I have little to no clue, but it sure was interesting to find out. So, yeah, we're in the same boat, I guess. ;-)

jasim 10y ago

Give me my procedures, conditionals, and loops, and I shall move mountains. Assembler (Prince of Persia): https://github.com/jmechner/Prince-of-Persia-Apple-II https://github.com/jmechner/Prince-of-Persia-Apple-II BASIC: http://softwareengineering.stackexchange.com/questions/149457/was-classical-basic-ever-used-for-commercial-software-development-and-if-so-ho http://softwareengineering.stackexchange.com/questions/14945...

cr0sh 10y ago
Regarding that second link: My career in software development started with BASIC - Pick BASIC to be exact. It was 1992, and I was 18 years old, had moved to Phoenix a week after graduating from high school to attend a local tech school (now defunct), and I needed something to pay the rent after having my hours cut as a cashier for Osco Drugs. Seeing my other classmates at the time taking "apprenticeship" positions doing electronics work, I decided to "cold-call" nearby companies, and landed on a "mom-n-pop" shop doing software development work. I put in my application, and they took a chance on me. They didn't hire me as a software developer, though - but as an "operator" - the guy to "run reports, keep paper in the printers, and mount tapes" for the actual programmers, to free up their time. I learned how to load a open-reel 9-track tape drive with vacuum columns at that place...something I have never used since. I was "in heaven" - being paid much more than I was as a cashier (but finding out much later that I was actually "underpaid" - oh, the ignorance of youth!), while doing less work! They gave me access to an account on their IBM RS6000 system running AIX - and one of the guys gave me a book on PICK BASIC to look over, and play around with. The shop developed "insurance claims management" software for the "Arizona Health Care Cost Containment System" (AHCCCS) - basically Arizona's form of Medicaid; this company's software managed claims (accounting, billing, etc). They used a form of PICK called "UniVerse": https://en.wikipedia.org/wiki/Pick_operating_system https://en.wikipedia.org/wiki/Pick_operating_system PICK (and UniVerse) were actually very interesting systems on their own; kinda a self-contained OS that integrated a programming language (BASIC) with a relational (and multi-value!) DB, along with other stuff. It compiled to a byte-code, which some manufacturers made CPUs to run (instead of interpreters); the idea was "portable software" across multiple architectures. Basically the idea of Java before Java. It worked out about as well, of course (because every implementation of PICK was just a bit different). Anyhow - the programming language used was BASIC - and my experience up to that point was writing bits and bobs of BASIC (plus some assembler - for the 6809 and 6502 processors - interestingly the latter was for the Apple IIe - CALL -151 was my friend; hand assembly of op-codes in the monitor - ugh). Well - they were monitoring the account, as I coded up adventure games and other diversions in PICK BASIC. The programmers and owner started feeding me with tasks ("hey, can you fix this issue" or "can you build this demo for the printer", etc) - and I proved myself. They hired me after I had graduated the tech school, and I've been here in Phoenix ever since. As far as BASIC and businesses are concerned - it is still used today, as much as everybody rants on it. Besides Visual Basic (large following there), PICK BASIC is still used (it has a legacy almost as long and broad as COBOL), and there are many other old "business BASICs" that existed and still have users today. I also know that there is at least one industrial robot arm manufacturer who sells a "Robot BASIC" to program and control their arms. ...and BASIC lives on today, of course - both closed and open-source variants. I'm more familiar with the various open-source BASICs. You have Gambas (which looks very much like VB), then there is QB64 (multi-platform 64 bit compiled QBASIC if you will), and also something called "BaCON", which is a "BASIC-to-C" converter (just the other day I was thinking taking it, and dumping out some Web Assembly code - essentially to see if I could get a BASIC program compiled to run in a web browser). There are also more than a few interpreters in javascript and other languages that can run BASIC code of some sort or another. Would I recommend it for new projects of large scope? Probably not, but I wouldn't outright discount it, either. I think it still has its place in the computing world, though that world is doing its best to ignore it in the hope that it is forgotten. It did teach some "bad habits" - but I think that a modern form of it, with proper OOP support, could be a very powerful teaching language for beginners - which is what it was always meant to be. It will always have a spot near and dear to my heart, at least.

lmm 10y ago

I don't think you can write maintainable code without monads. Code has to be written in the language of the business domain so that it can be understood in those terms, so you can't (to take an extreme example) have every other line being "if err != nil ...". But if you leave secondary concerns completely implicit then your code also becomes unmaintainable because you can never understand what any given function is doing (at the implementation level) and so you can never maintain anything. You need the dual perspective that monads or something like them give you where you can say "this is a secondary concern in this code but it is there". It's not about "programming cleverness" - there's nothing "clever" about monads, rather the monad is a very simple and boring interface that turns out to be a good tool for helping you write code that does what it looks like.

emcq 10y ago
I might be confused, but there is ample evidence that you can write maintainable code without monads. Take the Linux kernel, NASA rovers, or redis - all written in boring old C with no monads and great results.
- AstralStorm 10y ago
  Linux kernel is the opposite of boring old C, as in procedural code. It is nicely factored object-oriented C in most of the important places.
- vkjv 10y ago
  If you replace, "maintainable" with "easily maintained by a large group of people" the statement holds true.
  - emcq 10y ago
    Can you give an example of a project maintained by a large group of people written with monads? The only one that comes to mind is Spark, and while I haven't used it recently, was nightmarishly buggy with many subtle corner cases :/ Even jumping outside of C, Atom, Eclipse, Chrome, FireFox all are maintained by large groups of people and dont have a single monad!

amelius 10y ago

> I think you can write any program using only advanced concepts from the problem domain, not advanced concepts from programming itself. But that is a trivial statement considering that a Turing-complete subset of most (all?) languages is relatively simple. The point addressed by the article is maintainable code, which is something else.

fatbird 10y ago
OP's point is that the best way to write maintainable code is using bog standard, boring code and leaving clever solutions to the level of the problem domain.
- AstralStorm 10y ago
  Bog-standard meaning not testable and not contract-based? Clever solutions and abstractions (hey, immutability is clever right?) can really help out reasoning. And sometimes you really need clever things due to problem domain, so you really end up with totally not boring code. For example, you wouldn't cook up your own matrix manipulation everywhere, so you use a clever solution instead. Writing operations directly opposed to composing and optimizing them. Or in high performance world, using a much more complex but lock-free algorithm instead of the "bog-standard" locked one, sometimes the benefit is huge. The real important part is to exactly document the clever parts and enforce contracts on them, so you do not end up with potpourri everywhere.

manmal 10y ago

With some caveats. Execute 10 network requests in parallel on background threads, then reconcile their results, after that fire off another 3 requests in parallel (again, on a background thread), reconcile all the values you got so far, and return to the main thread. Oh and repeat the whole thing every time the user session's token changes, or the user requests a manual refresh. Also don't forget to cancel all running requests when the process is interrupted before it is finished. One more thing: If one request fails, bubble the error to the main thread and skip all subsequently planned requests. You CAN solve this with counters and locks (be careful about deadlocks though), but you will save yourself a lot of pain if you just use a FRP framework. You will also be able to easily react to the things you forgot ("Oh the requests should also be halted and retried after connectivity is lost"). So where do you draw the line? Do you spare your coworkers the agony of learning FRP or do you implement something where you suspect it will horribly crash and burn in production?

edblarney 10y ago

+100 This took me 10 years to realize. I find myself getting rid of everything clever, my code reads like a boring instruction manual. I'm starting to deeply re-think how code interviews should be conducted. Instead of asking smarty-pants questions, we should be asking mediocre questions and just asking someone to put together a straight-forward and simple solution. Important: it's surprisingly difficult to make code that looks simple and boring :), it often takes some iteration.

multinglets 10y ago

Attitudes that Lead to Mixing Problem Domains