5 ms·
>> You appear to believe that: Syntax is what makes programming difficult This is exactly the problem. People spend so much effort looking for better syntax th
by cryptica 7y ago
>> You appear to believe that: Syntax is what makes programming difficult
This is exactly the problem. People spend so much effort looking for better syntax that they miss the most important part of programming. It's about design and structure, the syntax doesn't really matter at all. I don't even care if it's dynamically typed or statically typed or functional or not. A bad developer will produce bad code no matter the language is. I've seen this over and over.
It's not so different from human languages. It doesn't matter what the language is; if you know it well enough, you can write a great novel with it... But only if you're a good author to begin with.
A bad author is not going to start learning French because they couldn't write a successful novel in their native English... Instead, they will work on their storytelling because they know that they are at fault, not the language.
I've written code in many languages and I can produce good software with any of them. The language I'm most familiar with is the one which allows me to work faster, but it has basically no effect on quality of the code.
For example, in the past, I've written Golang code after learning it a couple of days before for a job interview and the interviewer (a well known developer and founder of a popular startup at the time) commented that it was one of the best designed/structured samples he has seen. It took me a long time to write it because I had to look up stuff all the time but it seems to have had little effect on the quality of the code.
People have to stop blaming tools and start blaming themselves. It takes over a decade of intense work (nights and weekends too) of constant self-blaming and adjustments to become good at coding. That's if you have natural talent for it. If you're not a natural then you have to be even more patient.
- xiphias2 7y ago,,I've written code in many languages and I can produce good software with any of them. '' If you write code yourself and view that as the main advantage, type systems matter less. But when working in a team having statical typing as a written contract between people can help development substantially.
- tluyben2 7y agoI am still more productive with a type system, also on my own. When projects reach a certain size, it just helps a lot in keeping things working and clean long term. This 'contract' can be with your former or future self, and, in my experience, helps a lot.
- xiphias2 7y agoI usually start with no/little type information in Julia and then add type imformation when it can't be inferred easily.
- hhas01 7y agoPublic interfaces should ideally be formally typed, both to provide a behavioral contract between parties and to serve as user documentation. Whether the contract is enforced at compile- or run-time is secondary to having a formal mechanism for expressing it in the first place; ditto whether the code hidden behind those interfaces is explicitly typed, inferred, or untyped. Two problems that tend to occur in practice: * Untyped languages (e.g. Python, Ruby, JavaScript) typically lack a formal dialect for expressing parameter and result types, and most don’t even provide formal mechanism for annotating interfaces. Without a common language for expressing interface types, it’s nigh impossible to develop the tooling and education that are the necessary prerequisites to popular adoption. * Typed languages (e.g. C†, Java, Swift) frequently have poor/limited expressivity, creating friction for users, who end up fighting against the type system instead of working with it to describe their precise needs, while failing to provide the promised safety. e.g. Inability to describe numeric bounds means many functions with integer/double parameters will be partial, and passing inappropriate values will trigger runtime errors/aborts/undefined behaviors (e.g. divide-by-zero, bad array index). And that’s just the easy stuff. Python3 is one exception to the former, in that function interfaces can be formally annotated, though the language itself doesn’t provide the mechanism to enforce those annotations. And Eiffel is something of an exception to the latter in that interfaces are annotated with a mix of compile- and run-time checks. And then, of course, there’s ongoing work on dependent type systems and no doubt other CS research that may someday filter down into the production languages in mainstream use. But it’s tough and slow, and a giant wildly-inconsistent ballache in the meantime, with more really badly reinvented wheels than it’s possible to count. -- † Inasmuch as C can be said to have a “type system” at all (Really, it’s just got a handful of annotations for allocating memory on stack.)
- dkersten 7y ago> It's about design and structure, the syntax doesn't really matter at all. While it’s true that you could write any program in almost any syntax, that does not mean that syntax isn’t important. Syntax is the UI if a programming languages and as with any UI, UX matters. (You can accomplish tasks with bad UI’s too but that doesn’t mean it’s pleasant or efficient) Syntax shapes how you think in a language and how you view or use the semantics. We have many languages which are semantically essentially the same and only differ in syntax and people prefer one over the other often for different purposes. Ergonomics are important. Hell, many people won’t even give languages whose syntax they don’t like a chance... (don’t like lisp parentheses? Python significant whitespace? Forth’s stack shenanigans? J/k/apl/Perl’s keyboard-mash-symbols? Etc)
- tluyben2 7y ago> the syntax doesn't really matter at all. Somehow it does though: I find even j/k/apl easier to parse in my head than Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far nicer to read and write. And, even though I understand the semantics and can write code in Ruby, if I have a choice, I would never touch it again. And that's only syntax/idioms. I find JS also quite rancid syntactically, but not as repulsive as Ruby. And I know other people have this with different (or the same) languages as well; like someone else said, most people (even on HN) won't even try languages with a 'weird' syntax, even if they are proven to be more productive in some cases relevant to them. I know quite a lot of Lisp-y coders (most of them do Clojure these days) and they don't understand how/why you would ever use anything else. Most people here (maybe including you) have the inverse of that. As there are blazingly fast Lisp/Schemes on every platform, why are you using Go or another syntax than the basic AST? And yet you are and most of us are. If syntax does not matter, why have any syntax at all?
- skinnymuch 7y agoYeah for sure this is a big thing. I love Ruby’s syntax and if I could, I’d love to write in it all day if I was being paid the same amount as another language. Psychology is also at play. JavaScript I agreed can be quite rancid. But knowing it’s the only language that works in every browser, I internally whined about it less and now rarely do at all.
- tluyben2 7y agoI do not really whine about it (except when people are talking about it as I do feel it's important to have and hear different opinions) and of course JS is currently a necessary evil. Thinking about that too much makes no sense and serves no purpose, but when I step back, I know I just really don't like it. And then I just get back to coding. With Ruby I have a harder time doing that. Guess it's taste and 'first experience'; my first Ruby experience was inheriting a very large, badly written (very hacky) RoR codebase I had to migrate 2 versions up to the latest RoR. It was pure hell. So it would be a combination of things that gives me such PTSD for syntax.
- qaq 7y ago"but it has basically no effect on quality of the code" well if you include number of bugs of certain class as a criteria of quality it would be pretty hard to argue that there is no difference between say Rust and C.
- F-0X 7y agoI think C has better syntax than Rust, by miles. Rust's syntax is the bastard child of C++ and OCaml and is more than the sum of its parts. Rust code having fewer bugs has absolutely nothing to do with its syntax.
- qaq 7y agoI was replying to the sentence about choice of lang. not having much effect on the quality of software.
- brutt 7y agoAfter 3 years Rust and 20 years of C, syntax of C and C-like languages (C++, Java) looks awkward to me, because in C I need to write more code to get uglier result.
- ncmncm 7y agoI have coded C since 1984, and C++ since 1988. I found Rust syntax extremely easy to switch to, but I found switching back to C++ syntax extremely difficult. Do not learn Rust if you think you might need to code C++ or C ever again. Rust probably should have used "." in place of ";". Or anything, really.
- andreareina 7y agoA master can make good work with shit tools, but they'll still prefer to work with good tools. Syntax matters because it's part of the interface, and so it has the ability to clarify or confound. Destructuring assignment; async/await instead of CPS (technically not exactly equivalent due to variable scope, but close enough in actual usage); pipe operators/macros instead of (third-function (second-function (first-function the-data))). None of these make the language more powerful but they do aid clarity and concision, as well as just making the language nicer to use.
- simion314 7y ago>Syntax matters I would say a good developer can make the code clear, I can make my ES5 code clearer then some bad ES7 code, most of the time clear code depends on how you name and split your code in logical and intuitive steps.
- cryptica 7y agoI'm a big fan of async/await and I can appreciate what it achieves in terms of helping to prevent coding errors. I've rewritten an entire open source WebSocket framework in async/await, so I know exactly what the benefits are. But in spite of that, in the grand scheme of things, I still think it doesn't really matter. The architecture of the project is much more important. I had been working on that project for 3 years but migrating it to async/await only took me about 2 months of casual after hours work. The reason it was so easy to migrate and that I didn't have to write the project again from scratch is precisely because the architecture was correct to begin with. When you think about code quality in terms of how much (or rather, how little) time it takes to maintain it to adapt to industry trends, architecture is by far the most important factor. Because even if everything changes from underneath you, a good architecture will survive the test of time. Any other metric to measure code quality is arbitrary and meaningless IMO. It's mind boggling that my previous comment received downvotes. I guess it reinforces the point that the author of the article is making. The average developer is incapable of understanding what is important. If people can't articulate what their goal is and they don't know what is important in order to achieve this goal, then there is zero chance that they will be able to make the right tradeoffs. Because there is no free lunch, every decision is a tradeoff. If, like for the vast majority of projects, there is a good chance that the requirements will change significantly in a year or two, then you need to know what really counts and architecture is one of those things that can stick if done correctly.
- caiocaiocaio 7y agoIt's true that some people can write extremely clean, beautiful Perl. Nevertheless, it's still a lot less effort to write clean, beautiful Python or Ruby.
- jejones3141 7y agoIf syntax doesn't matter at all, then why haven't more people switched to [insert name of esoteric programming language]? Programming is indeed about design and structure, so why create tools that gratuitously distract programmers from design and structure?
- shadowgovt 7y agoI've used enough graphical programming languages to have come to believe that syntax matters (iff you're constraining your definition of "programming" to "writing strings of ASCII or Unicode by hand that get interpreted into an executable format by an intermediary program" ;) ).