Why the Creator of Ruby on Rails Prefers Dynamic Typing (hey.com) 148
"I write all novel client-side code as JavaScript instead of TypeScript, and it's a delight," says the creator of Ruby on Rails. Posting on Twitter, David Heinemeier Hansson opined that TypeScript "sucked out much of the joy I had writing JavaScript. I'm forever grateful that Yukihiro 'Matz' Matsumoto didn't succumb to the pressure of adding similar type hints to Ruby."
When it comes to static vs dynamic typing, "I've heard a million arguments from both sides throughout my entire career," Hansson wrote on his blog today, "but seen very few of them ever convinced anyone of anything."
But wait — he thinks we can all get along: Personally, I'm unashamedly a dynamic typing kind of guy. That's why I love Ruby so very much. It takes full advantage of dynamic typing to allow the poetic syntax that results in such beautiful code. To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.
I'll also confess to having embraced the evangelical position for dynamic typing in the past. To the point of suffering from a One True Proposition affliction. Seeing the lack of enthusiasm for dynamic typing as a reflection of missing education, experience, or perhaps even competence.
Oh what folly. Like trying to convince an introvert that they'd really like parties if they'd just loosen up a bit...
These days, I've come to appreciate the magnificence of multiplicity. Programming would be an awful endeavor if we were all confined to the same paradigm. Human nature is much too varied to accept such constraint on its creativity...But it took a while for me to come to these conclusions. I'm a recovering solutionist. So when I see folks cross their heart in disbelief that anyone, anywhere might fancy JavaScript over TypeScript, I smile, and I remember the days when I'd recognize their zeal in the mirror.
Hansson also sees the "magnificence of multiplicity" in positions about functional vs object-oriented programming. "Poles on both these axes have shown to deliver excellent software over the decades (and awful stuff too!)."
When it comes to static vs dynamic typing, "I've heard a million arguments from both sides throughout my entire career," Hansson wrote on his blog today, "but seen very few of them ever convinced anyone of anything."
But wait — he thinks we can all get along: Personally, I'm unashamedly a dynamic typing kind of guy. That's why I love Ruby so very much. It takes full advantage of dynamic typing to allow the poetic syntax that results in such beautiful code. To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.
I'll also confess to having embraced the evangelical position for dynamic typing in the past. To the point of suffering from a One True Proposition affliction. Seeing the lack of enthusiasm for dynamic typing as a reflection of missing education, experience, or perhaps even competence.
Oh what folly. Like trying to convince an introvert that they'd really like parties if they'd just loosen up a bit...
These days, I've come to appreciate the magnificence of multiplicity. Programming would be an awful endeavor if we were all confined to the same paradigm. Human nature is much too varied to accept such constraint on its creativity...But it took a while for me to come to these conclusions. I'm a recovering solutionist. So when I see folks cross their heart in disbelief that anyone, anywhere might fancy JavaScript over TypeScript, I smile, and I remember the days when I'd recognize their zeal in the mirror.
Hansson also sees the "magnificence of multiplicity" in positions about functional vs object-oriented programming. "Poles on both these axes have shown to deliver excellent software over the decades (and awful stuff too!)."
Of course (Score:5, Interesting)
Static typing is better for large projects because A) when you have a lot of people working on a project, it helps keep things organized. B) It lets your IDE help you with writing code.
Re:Of course (Score:5, Insightful)
Static typing is better for large projects because A) when you have a lot of people working on a project, it helps keep things organized. B) It lets your IDE help you with writing code.
Let's also throw in C) It allows the compiler/optimizer to do a much better job of generating efficient code, since with static typing, the compiler/optimizer knows much more about what your code will and won't be expected to do at run-time.
Re:Of course (Score:4, Insightful)
Re: (Score:2, Insightful)
If you care about your code as anything more than a run-once cobbled together hack to munge some data for your paper and which will never see the inside of a computer other than the one it was written on, then you're not writing your code in Ruby or Python.
What about Reviewer Comments? (Score:3)
What happens when you get the reviews back on your paper, and Reviewer 3 insists that you add another plot to describe concretely a point you glossed over.
What will your "run-once cobbled together hack" do when you call upon it to run a second time?
You "turn around" the paper and tell the Associate Editor that another plot is not needed. Reviewer 3 is laughing maniacly, "Mwuh-huh-huh-huh-huh!"
The point being that even if something is not a commercial product, "run-once" is not an attribute of softw
Re:What about Reviewer Comments? (Score:4, Funny)
You make up some plausible-looking data for the plot, obviously.
Re: (Score:2)
For a most companies (Score:4, Insightful)
Re:For a most companies (Score:5, Insightful)
Re: Of course (Score:2)
Re: (Score:2)
Re: Of course (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: Of course (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Of course (Score:4, Interesting)
Implicit type conversion chains so beautifully with reflection/serialization bullshit and to punch through input sanitizers/validators too.
Programmers can't be trusted with it.
Re:Of course (Score:5, Insightful)
Type deduction (Score:3)
Some people seem forever stuck with "syntax issues" and fail to move past. Don't see the "code". See the blonde, brunette, redhead...
Some people just love debugging, instead of removing whole classes of bugs in the first place.
Re: (Score:2)
Some people just love debugging, instead of removing whole classes of bugs in the first place.
I take it you sit in the former camp then?
Re: (Score:2)
Re: Type deduction (Score:2)
C++ means more debugging
Re: (Score:2)
You seem to think that C++ programmers are constantly manually allocating memory or twiddling with bits and pointers at every level of the program.
We have the things like vectors and templates for a reason. To build abstractions that don't require delving deep into the machine all the time, without sacrificing performance. Then there's constexpr, wh
Re: Type deduction (Score:2)
Ideally you want bugs resolved before you even run your program. Debugging means finding problems at runtime, which is a fair bit more complicated and time consuming.
Among all systems languages, rust eliminates the most categories of bugs from ever making it into your program at runtime to begin with, without sacrificing performance. C++ developers hate Rust though because the language has a much more strict definition of soundness for code, and generally pushes you into doing the safest and most optimal th
tunnel vision (Score:5, Insightful)
Amazing. A dude who mostly manipulates strings doesn't care about typing. The debate vanishes as you get closer to the hardware.
Re: tunnel vision (Score:5, Insightful)
Isn't this his point? If you aren't close to the metal, then just let the compiler handle it.
There are plenty of people who don't need to be low level programmers and likely shouldn't be. It doesn't mean they add no value to the ecosystem.
This being said, never been a rails fan.
Re: (Score:2)
Isn't this his point? If you aren't close to the metal, then just let the compiler handle it.
I'm not entirely familiar with Ruby but I don't believe there's any compiler involved here.
There are plenty of people who don't need to be low level programmers and likely shouldn't be. It doesn't mean they add no value to the ecosystem.
That depends. Personally I have very, very low tolerance for laggy things, which frameworks like this are more likely to deliver.
Re: (Score:2)
I'm not entirely familiar with Ruby but I don't believe there's any compiler involved here.
I'm not that familiar with Ruby, either, and I concur that there's no "compiler" for it, as in compiler that compiles C or assembler. But I do a lot of Coldfusion development (nowadays in Lucee and Adobe CF both) and the server engine creates JAVA bytecode out of the CF code. Many people call the JAVA bytecode compiler a "compiler". So it may really depend on the interpretation of what a compiler is.
Ruby: for those who think Java is too hard. (Score:5, Insightful)
There are plenty of people who don't need to be low level programmers and likely shouldn't be. It doesn't mean they add no value to the ecosystem.
It's not necessarily JavaScript, Python, and Ruby's fault that they have shitty ecosystems and are associated with disaster after disaster. They attract low-skilled developers that do a shit job. However, to your point, these folks provide value, but it is negative. The personalities that love to create meaningless frameworks and reinvent the wheel because it's more fun than reading the docs on existing frameworks are a problematic cancer. They make UIs slow. They make billions of machines do more work than they should. They contribute to climate change with their inefficiency...but hey....dynamic typing is fun!!!!
Java used to have a HUGE problem with this. Framework after framework would be introduced with no clear reason why...then server-side rendering fell out of fashion and those people went to JavaScript and python to write shitty code.
Most Ruby apps I've seen are slow and brittle and have been rewritten or abandoned. There are not a lot of Ruby success stories. I don't blame the tool, but the tool attracted some read problematic people to write code in them. A talented engineer can write great code on any platform and a maniac can write devastating code on any platform as well. But when you pick a platform, you get the platform, the technology, but also the ecosystem and talent base. Ruby attracted everyone who thought "Java is too hard." This was good for Java...but man...we really have to do something about those low-end professionals.
Re: (Score:3)
Man on java frameworks.. after doing JSPs i got bloodied on early JSF on the java side. (well... and well before that early and EJB. mmm.... EntityBeans... )
i also remember when Ruby (or, really, Ruby on Rails) was the new hotness and all the cool kids were doing it because "functional programming!". Then Node.js came along and all the early adopter framework writer types moved over to that.
I have to give them both, and Python, props for forcing the Java universe to try to become more dynamic and easy
Re: (Score:2)
Rhe cool,kids were doing it because we are so tired of spelling out everything to the slow Java Compiler who can only read XML“
Ruby on Rails was to a large extent a protest against the burpcratic horrors of Java and the ugliness of PHP
Ruby is a beautiful language by any means, it is based on SmallTalk, not ALGOL
Re: (Score:2)
Most Ruby apps I've seen are slow and brittle and have been rewritten or abandoned. There are not a lot of Ruby success stories. I don't blame the tool, but the tool attracted some read problematic people to write code in them.
UGH. You are reminding me of my current boggle: samba admin-tools. If you want to manage a Samba DC you have two choices AFAIK, use Windows or use samba admin-tools. admin-tools is distributed only as source and an appImage which segfaults immediately on my system. It's written in ruby as an addon for YaST, which is itself a clusterfuck. The build process doesn't correctly pass configure flags through to subprojects, and some of the subprojects (parts of YaST) have shitty build settings requirements like th
Re: (Score:2)
To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.
He's also never heard of Heart of Palm Salad, which is served with a scoop of pistachio ice cream as the "dressing". And it is rather good...
Dynamic typing is like meaningful whitespace (Score:3, Insightful)
It works beautifully in small code snippets that fit into a single screen. The moment your function runs to more than 80 or 100 loc, it becomes more difficult to keep track and increases the probability of making an error.
Re:Dynamic typing is like meaningful whitespace (Score:4, Insightful)
Re: Dynamic typing is like meaningful whitespace (Score:2, Insightful)
Long functions with incorrect indentation are still correct in a curly brace language. And can be automatically indented to your liking by any half decent editor.
Re: (Score:2)
Re: (Score:2)
They may be semantically correct, but they won't be parsed correctly without significant extra overhead by humans.
Pulling down a menu item to automatically fix the indentation is significant extra overhead? I guess I'm selling myself cheap, I use menus all the time.
Re: (Score:2)
Re: (Score:2)
If you have to fix the indentation, doesn't that mean that it is significant? Make up your mind, please...
No. It doesn't. A warning is not an error. You do NOT have to fix the indentation. You have the option to do so. My mind is made up, and I already know what I think, without any help from people who willfully refuse to understand the argument.
Re: (Score:2)
Re: Dynamic typing is like meaningful whitespace (Score:5, Insightful)
If you care about the correctness of any code review, you definitely have to fix the indentation.
And you can do it by pulling down a menu. As opposed to Python, where you have to understand the code to fix the indentation if it's lost. I do not understand why this is even an argument. Control flow through indentation is literally a throwback to punch cards. Anyone who thinks it's a good idea is ignoring the lessons of computing's past. That literally is how things used to work, and we figured out it was a terrible idea and moved past it.
Re: (Score:2)
Re: (Score:2)
So no, "We figured out it was a terrible idea" is blatantly bullshit.
Well, it's obviously bullshit in that Guido clearly didn't figure it out, and lots of other people are unclear on it besides. In other ways, it's perfectly true. The vast majority of us understand why it's a bad idea, the rest are making excuses for bad decisions.
Re: (Score:2)
Pulling down a menu item to automatically fix the indentation is significant extra overhead?
Good grief yes. That's positively barbaric. Hit = of course.
Re: (Score:3)
Incorrect indentation isn't a problem in the real world as that can be fixed in less than a second at the press of a button. Provided, of course, that you use a language with sensible syntax.
What was your point again?
Growing Up (Score:3)
Ahhh, the stories of a guy figuring it out as he grows up.
--
Poetry is an echo, asking a shadow to dance. - Carl Sandburg
Ummmm (Score:5, Insightful)
JavaScript and delight should never be used in the same sentence. Hell, even the guy who invented JSON thinks it should be retired.
https://devclass.com/2022/08/0... [devclass.com]
Re: (Score:2)
Totally agree. I had trouble with JavaScript at first but its my favorite language. Much more productive with it compared to the strongly typed languages. Yes you can get in trouble with data types if you aren't reasonably careful but hey, be a little careful.
Re: (Score:2)
I've called it 'almost elegant' in the past. There is a great little language under the baggage it's collected over the years. Get rid of 'new' and just about all of the ES6 crap and you'll find that there's a clean, powerful, and expressive language to rival the likes of Scheme waiting for you.
The web could have had a lot worse.
Re: (Score:2)
Nope (Score:5, Informative)
"Joy" and "JavaScript" do not belong in the same sentence.
Re:Nope (Score:4, Funny)
I don't know about that. Watching my colleague tear his hair out as he unravels some unreadable Javascript really sparks joy in me.
Ruby on Rails? (Score:2)
It's not 2010... is this relevant at all in 2023?
Beautiful code (Score:3)
Why do people say Ruby is beautiful code? Or can be used to write beautiful code?
Just about everything described as idiomatic Ruby looks plain ugly. The gem names are beyond stupid having no relation to their function.
Plus Ruby is slow, like really slow.
Why are people doing this to themselves when they can just use python which is easier to learn, faster to run, better supported, and more readable?
Strong or weak dynamic typing? (Score:3)
Re: (Score:2)
Dynamic typing isn't going away, but anyone who believes 2 + true isn't an error must have their keyboard taken away.
but it's isn't true and false, its 0 or 1.
Re: (Score:2)
Fine until you have to read someone's code (Score:4)
Re: (Score:2)
Re: (Score:2)
Hi -
Probably a lot. But the reality is that most people don't comment their code today. And type declarations are a type of self-documentation - and the compiler checks that it is up to date.
My original comment stems from the massive amount of pain that I have had reverse engineering Python code to use machine learning libraries - trying to figure out what kind of thing some method returns. Same for Go code.
Also, a few times I had to refactor large codebases in Ruby and Java. For the Java code, no new error
Answer is pretty simple (Score:3)
Dynamic typing is better if you prototyping and you are going to throw the code away. E.g. when I'm solving school math problems, I don't want to specify the type for variable X, it would be too much work with no benefit.
Static typing is better if you have live with the code you write. So if you are going to maintain the code you write, you want to know the types. I have wished Javascript to have static typing many times when I have had to change the data structure. It is just so much easier when compiler tells you every location you need to change.
DEFINT A-Z (Score:2)
Static typing makes my code fast
DEFINT A-Z
Dynamic typing is fine (Score:2)
Dynamic typing is fine if you like debugging more than writing working code.
Re: (Score:2)
Authenticate(User)
What is "User"? The object? The Name of the User? Authenticate then calls DoAuthenticate(User) so you need to dig down a long way to find out. And it only crashes when you actually call it.
This type of thing drove me mad doing some Wordpress work (PHP, all dynamic). I could live with the PHP quirks, but not the lack of typing.
Re: Both have their place (Score:2, Flamebait)
If you can't answer that question for the codebase you work on, it has nothing to do with dynamic typing.
Re: (Score:2)
Hence my example of access control.
Re: (Score:2)
You check the internal API docs for Authenticate, and it'll tell you.
PHP isn't the strongest at handling that, and it can get a bit strange in Wordpress, but it is quite possible.
I'll counter that with any sort of list or queue object. Lets say you want them to hold 'verbs', objects that specify an action that must be taken and holds the subject and object to be 'verbed'.
Do you REALLY want a master class that includes pointers for every conceivable subject type, every conceivable object type, and every conc
Re: (Score:2)
You check the internal API docs for Authenticate, and it'll tell you.
Sure. "The Authenticate method authenticates user. User: the user to be authenticated"
Industry standard comments just repeat the signature. No typing in the signature, nothing in the docs, if they exist at all.
Re: (Score:2)
Actually... [wordpress.org]
Re: (Score:2)
I was going to reply up above that your example sounds like a documentation problem.
Your documentation being shit is more of an argument to improve that than to embed it in strict typing.
Re: (Score:2)
If the internal API docs tell developers what type User is, how is that remotely better than using a language where that type information is formally specified in a way that development tools can use?
Re: (Score:2)
What, so the developer can randomly try each type until the compile doesn't fail?
Re: (Score:2)
You're not a professional programmer, are you? (Score:5, Insightful)
What I do notice however is that inexperienced and less capable coders often argue for static typing with bogus arguments and strong emotions. They often say that "of course" it is the _only_ sane thing to do and anything else is broken. This just shows their insecurity and fear of being found out as not being good at coding, nothing more.
Sorry buddy. I'm sure you're mind-blowingly amazing at your personal projects, but for us who work for a living, static typing is essential. I am a GREAT programmer...one of the very best in my company...but...yeah...I'm 1 guy. We need a team of 100s across many products and some take less pride in their work and depth of experience and knowledge than I do. I don't have time to master every nuance of every project I am asked to help with. I am thrown on projects after 2 meetings and told to help them get back in shape...the burden of being viewed as one of the best in the company...becoming a fixer. I am grateful for Java's constraints and Maven's uniformity. I read code from contributors from many continents, many who have left the company and can quickly figure out what they did and what the meant to do.
.1%. For Python and node.js projects, QA and our users typically caught those errors...because most professionals write shit unit tests and the compiler isn't their to catch them. We hire sharp programmers for both teams and they consistently deliver later and with lower quality...our Java and C teams?...don't seem as motivated, but their record is far better. This matters a lot when you're the guy writing the checks.
If YOU were actually good at your job, you'd spend a lot less time coding and a lot more time integrating established frameworks. You'd be reusing code and delivering a lot less lines and a lot more quality. Language doesn't matter if you know how to do your job. The brilliance of one syntax vs another means little when you actually know what you're doing. You may hate Java. I don't care...most of my time is manipulating APIs, not writing pure Java. The beauty of your favorite language vs the horror of mine means little to me because I actually know how to do my job well and that means understanding other people's code and reuisng it rather than writing things the way I want to. However, I once was young like you and remember making similar arguments.
However, the world doesn't revolve around your ego or mine. People pay me good money to get software working. They don't care how talented you or I view themselves. They want "good enough," not exquisite. They want maintainability over excellence.
Ugly Java from 10 years ago vs your favorite language du jour?...doesn't matter. They want stuff reliable and working...scalable and cost-effective...and that compiler has saved many projects. It emboldens me to refactor more. Python and JavaScript?...those have been disasters in our company because when we update libs to patch vulnerabilities, they break all over the place.
With Java, the compiler catches 95% of those errors. The unit tests catch the other 4.9%...our QA dept typically catches the last
As great as you may be...all it takes is one shitty coworker to kill your system....one guy with a far less motivation than you can do a lot of damage....at least if you're actually a working professional...especially one from a profitable company that hires a full team...that can't all fit in a single minivan.
Re: (Score:2)
If you think the language doesn't matter, why don't you skip the compiler bullshit and just hand assemble machine language? Oh, that takes longer and introduces needless errors? Almost as if the language matters?
And yes, a zillion years ago, I actually did end up hand assembling and just entering a routine in hex on very rare occasions. It sucked!
Meanwhile, if the project is as big as you say, you have to have unit tests anyway to make sure the inputs and outputs of the chunk of code from the slacker half w
Re: (Score:2)
Re: (Score:3)
Goodness no. I've worked with far too many great programmers. Everything becomes a mess of new "frameworks", rather than just simple straightforward code . Great programmers minimize complexity.
Re: (Score:2)
Goodness no. I've worked with far too many great programmers. Everything becomes a mess of new "frameworks", rather than just simple straightforward code . Great programmers minimize complexity.
Frameworks are created to minimise complexity. If your frameworks don't do it, either you don't need a framework or you are creating it wrong.
Re: (Score:2)
Frameworks should be created to minimize complexity. Mostly they're created to get the next promotion or because the programmer in question is suffering from galloping Dunning Krueger. Not to say frameworks are inherently bad, just a lot of programmers.
Don't forget illiteracy (Score:2)
Frameworks should be created to minimize complexity. Mostly they're created to get the next promotion or because the programmer in question is suffering from galloping Dunning Krueger. Not to say frameworks are inherently bad, just a lot of programmers.
I'd say a top reason programmers write frameworks is they never bothered to learn how to use the code they're hiding the complexity for. I saw some guy write his own JPA wrapper. I looked through it carefully and realized he simply didn't know how to use JPA properly. He never read the docs, just saw some code examples, said "this sucks, I can do better"...and rewrote his own custom persistence framework...not realizing Spring did everything he wanted to do out of the box. I see so many fucking working
Re: (Score:2)
wow, just wow, the hubris on you! (Score:2)
You sound like a noob here, pushing frameworks. Good programmers use frameworks. Great programmers write frameworks for the project they're working on.
Please tell me this is satire! SHITTY programmers write more frameworks than great ones. Why? The great ones read the docs on the existing ones and understood why it was created and how to leverage it intelligently.
SHIT professionals rewrite everything because they never understood the frameworks to begin with. I've seen it many times...hell, I used to be that guy when I was in my early 20s...would write things "just right" my perfect way rather than "good enough" using a conventional framework.
I
Comment removed (Score:5, Insightful)
Re:You're not a professional programmer, are you? (Score:5, Insightful)
I have no patience for "that just does not apply to me and my co-workers because we are real programmers" attitude. A code base that is too precious to be properly maintained by anyone but geniuses sounds like a code base chock-filled with liabilities to me. At some point the project should grow up and be easily maintained and improved by merely smart young mortals who want to learn, with a bit of advice from the greybeards.
Re: (Score:2)
... so you're saying a program should tend towards simplicity in all cases?
Good luck getting the budget and manpower time to justify that. As a greybeard, I wish you well. (Want to know where a good portion of the grey in my beard came from?)
Re: (Score:2)
No, he's right.
No, he is not. His and your highly aggressive response nicely demonstrates that. If you had actual facts instead of fear, you would have reacted differently.
Re: (Score:2)
In dynamic typed languages, there is no way to put that toothpaste back into the tube.
Re:Both have their place (Score:4, Insightful)
Well done. Though I presume many will be offended by your comparisons I feel as you do. and those who disagree might do well to perform some introspection.
I came from a Java background in 1999 and then discovered JavaScript. I got my first big job with JavaScript in a Ruby shop. Falling in love with Ruby centric talks about OO I applied them all to JavaScript. This was maverick as it wasn’t cool to like JS. Then as my company forced TypeScript at me and I had a chance to compare.
After 27 years programming and 13 dedicated to JavaScript I feel I can say that the advantages we get from TS are not the issues we actually have in production. The protections it offers haven’t (for me) been the issue to problems I’ve ran into. For every type issue that came up we had dynamic equivalents. == means three extra unit tests when === can get away with three less.
I have come to the understanding that much of the dynamic versus static type arguments are all strawmen. There are advantage on both sides and to exclude one over the other requires some kind of blindspot to the other. I can design and code in both confidentially. At home on my own side project I’m going to use JavaScript because I find it fun. At work I am going to use TypeScript because they told me to. If I were to run my own company I might choose a dynamic language but keep a Sauron-esque eye on everything so I can tell developers to produce quality code, documentation, and unit tests. Stop being lazy thinking some fancy compiler with magically make them think they are better coders.
Re: (Score:2)
You seem to have strong opinions based on some weird misconceptions. What was that about good programmers?
Types are semantics. Without having any constraints on the type, you have no semantically valid operations. You can have implicit or documented constraints. Or docs that tools check for you.
You're main argument against types appears to be that they, Er, prevent type errors so programmers will be more productive and the bugs will be elsewhere. Mission accomplished? That and the straw man argument that an
Re: (Score:2)
GP is one of those toxic developers who likes to treat others like shit, and probably is some sort of manager now. I feel sorry for the poor souls that have to work under him.
Re: (Score:2)
Obviously, the claim that static typing is superior is untrue.
Hmm... "Obviously." "Obviously." Right. I don't think that is the word you really want here. I think the word you want is, "I don't want to have to prove it, or point to some study that did so."
Anybody that cannot competently handle dynamic typing cannot competently write code. Anybody that strongly argues for static typing being the "one true way" should very likely not be writing production code.
Interesting that you don't say the same for dynamic typing. But I guess that would detract from your point.
Hence it boils down to these two things just being tools in the toolbox, each with its place.
You're right. And speaking as a maintenance programmer who has worked in several languages, I can say that incompetence comes in many flavors. The worst of which is the programmer who is given a hammer-s
Re: Too many stupid adjectives (Score:2)
Thank you for that. I started coding at around 14 and am now in my 50s. I've worked in a dozen or so companies, seen hundreds of coders and probably millions in lines of code.
And usually I spend many hours a day writing and reading code.
Yet I do not get the concept of 'poetic' code. I really enjoy what you can do when you lombok your code and replace getters, setters and stuff with @Data. And although they might not be efficient I like what @Builder offers you wrt readability and code safety by eliminating
Re: Too many stupid adjectives (Score:5, Insightful)
Yet I do not get the concept of 'poetic' code.
You probably don't know LISP.
Re: (Score:2)
I don't know if code is poetic.
I can attest I feel very positive and intense satisfaction when I read and work with well designed code. Simple functions that doe one thing, on scope, organized properly, with sane logic and does not drag boilerplate and workaround bullshit (often because the underlying framework has been started and designed by insufficiently experienced software engineers or poorly managed project lead developer).
This is why at the other pole; I can feel equally negative emotions when havin
Re: (Score:2)
Been on projects that have worked for **years** in "hair on fire" mode, trying to kill bugs AND implement the new features to keep the clients happy.
There are times where Technical Debt becomes so overwhelming you do have to declare bankruptcy and rewrite from scratch.
Re: (Score:2)
Sorry, friend. A lot of us replying to this post are programmers who've spent their full careers doing this stuff. As such, it can be difficulty telling an honest question from trolling, on the internet.
The reply pointing you to wikipedia is spot on, and will answer your question.