7 ms·

Your programming language is probably unproductive

• Eire_Banshee 10y ago
  What is it about programming that just causes people to constantly bash languages they don't use?
  • alec_theriault 10y ago
    When a person learns a language, they are making an investment of sorts - they are saying "I think this is a language that I will invest time into learning because ...". That "..." is usually (unfortunately) "it is becoming more popular and I will have a competitive edge being familiar with it before others". The bashing of other people's languages is a way of either (1) rooting for what you're invested in or (2) reassuring yourself you made a good investment.
  • collyw 10y ago
    Am I allowed to bash Java / Visual Basic having used them in the past?
• jrcii 10y ago
  I beg to differ, Mr. Sokol -- I use LOLCODE.
• MollyR 10y ago
  I personally find python to be the sweet spot for me with all of its libraries and syntax. I use other languages when I need to squeeze every drop of performance from some hardware.
  • kvark 10y ago
    For some performance, check out the Boo language. I got hooked up on it for quite a while. Python syntax + .Net platform and rich meta-programming = lots of fun.
    • jdc0589 10y ago
      a couple jobs ago, for some reason we used boo, in an otherwise 100% c# .net project, to manage our IoC/Dependency injection configuration layer. I still have no idea why.
• JoeAltmaier 10y ago
  tl:dr: personal preferences about visual style in coding.
• aikah 10y ago
  elegant =/= productive . Granted F# is backed by .NET so it has access to a large existing ecosystem (on Windows) which makes it fairly productive ... once it has been learned.
• FranOntanaya 10y ago
  Placing braces in their own lines, using optional braces and not inlining short ifs are almost always styling choices, not programming language faults. The "simple example" is ridiculously biased.
• jdc0589 10y ago
  blah blah blah. clickbait title, same old complaints about language syntax that doesn't agree with someone's personal preference, etc... Some people like braces, like me. It doesn't matter at the beginning/middle of a code block much, but the clearly visible terminating } is what does it for me. I need that. If every whitespace significant language had strict formatting standards, shipped with a formatting utility (e.g. gofmt), and actually enforced formatting standards everywhere (including stuff like number of empty lines between functions, etc...), then I would be on board with no braces and whitespace significance. Until then, the inconsistencies you run in to in whitespace significant land just don't work for my brain. Then, some people hate braces and love whitespace significance. Cool. doesn't matter. the end.
  • unsignedqword 10y ago
    I've been using a language that uses python-style indentation (Nim) and while I've grown to like to like the language itself, the back of my mind pines for braces. At least using braces, I can immediately auto-indent a region of code and not have to worry about anything. I sucked it up, though, and I got used to the pythonic syntax anyway. Either way, opening an article that says "Your programming language is probably unproductive" which immediately devotes itself to whining over pedantic syntax bullshit...makes me not want to read it.
  • nimmer 10y ago
    Can you provide an example on how a formatting standard would help showing where a block terminates?
• yellowapple 10y ago
  Apparently unproductive == has curly braces.
• gravypod 10y ago
  > The introduction of braces in the code was a trigger for a number of religious wars, and it made us, developers, focus on the design of the language instead of focusing on the most important thing in our work - solving real problems. How can you correctly solve problems without being able to look at your code and reason, instantly, about what is grouped together. Let alone tracing through your code but just seeing what statements are grouped with what. One such suggestion, as provided by the author, is whitespace. I can't tell you how bad of an idea this is. Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends. It's less key strokes but that doesn't mean it's easier or better. > Languages like Java and C# made it to the almost ridiculous point where not only we have to be very explicit about every aspect of our code, but also made us split this code into an endless amount of files I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other. In the end, I don't think a language can be (un)productive. A language is the means for expressing a solution. Your job as a programmer is to conceive a solution to a problem and pick a language that will best let you express that problem. Some times functional languages are better at this, some times other languages are better. The thing we should be arguing about is what is best expressed in which language.
  • hockeybias 10y ago
    Agreed. Threw up a little in my mouth regarding whitespace...
  • 6DM 10y ago
    I started a project out using jade in nodejs, after a while I had a page with enough elements/nesting going on that I was having a hard time keeping track of what was grouped where. Particularly when taking some work a designer did, making it jade compliant, then pasting in. Aside from a short "if" statement, I now no longer think it's sexy to abandon ending notation whether it be braces, elements, etc.
    • gravypod 10y ago
      I'd suggest you not leave if statements un-braced. I remember a study where they found the most common bug in most experienced open source developers was leaving out the braced initially, going back to make a change, and having that change introduce a bug. Basically they had if (x) then() and went back and did if (x) new_call() then() and caused an error that happened silently. This is something you definitely want to avoid and I personally don't trust myself, after a no-sleep code fixing bender, to remember to add {} around something if I'm editing an if. I'd probably forget. Again, I'd say shorter does not mean better.
• pjc50 10y ago
  I program in embedded C, you don't have to tell me it's 'unproductive'. It's just convenient and familiar. A while ago I started writing something about meter in programming languages; what could we gain by thinking not just about making them look more like English but more able to be read aloud? I didn't come to any useful conclusions, but I do note that of all the unpronouncable symbols we use the semantic whitespace of python is the most difficult to convey adequately.
  • AnimalMuppet 10y ago
    > I program in embedded C, you don't have to tell me it's 'unproductive'. It's just convenient and familiar. It's also probably more productive for that purpose than almost anything else. Why? Availability of tools, and also fitness for use. You usually don't really want to be using Python, say, in that environment, because you don't want to have to burn an interpreter onto your device, and you don't want the runtime inefficiency, and and and...
  • hackinthebochs 10y ago
    >what could we gain by thinking not just about making them look more like English but more able to be read aloud? I wouldn't be in favor of a programming language that tried to enforce verbalizability (I'm thinking something like basic here). But I do think that having a program "tell a story" is a boon for comprehension. Have operations, variable names, function names, choice of where and when to use a function, etc be in such a way to optimize the narrative quality of the code. But I don't immediately see a way for the language construction itself to benefit here. I think having clear structural code is a boon to quickly scanning and understanding the structure of code.
    • pjc50 10y ago
      Mm. Taking literate programming literally. Perl certainly tried to do this, Wall being a linguist. It resulted in things like the Perl fridge poetry set, but it didn't enforce it and also allowed a line noise style.
• kazinator 10y ago
  Counterpoint to the remarks about braces and partial application: Implicit partial application is a poor idea that makes programs incomprehensible. If you pass only three arguments to a four-argument function foo, you should see a "foo: insufficient arguments" error, and not a function of one argument popping out. The semantics of obtaining a partially applied function doesn't depend on syntax. It can work fine when function arguments are delimited by parentheses. For instance, suppose that if we write (cons 3) we automatically get the equivalent of (lambda (x) (cons 3 x)). That's partial application, with parens. We can then do (mapcar (cons 0) '(1 2 3)) and get ((0 . 1) (0 . 2) (0 . 3)). Is that a good idea? Firstly, we lose variadic functions and functions with optional arguments. (list 0) can't return a lambda; it already has a meaning; (list) produces the empty list, (list x) a list of one element which is the value of x, and so on. We could end up with an embarrassing proliferation of fixed arity functions like list1, list2 and list3. It's not that much of a chore to have an explicit partial application operator: Say: (op list) -> (lambda (. args) (apply list args)) (op list _ 1) -> (lambda (arg) (list arg 1)) If that is too verbose, and used often, we can dedicate alternative closure punctuators to it: {list} -> (op list) {list _ 1} -> (op list _ 1) So braces now help with partial application, enabling it when we want it. The notation keeps code crystal clear because everything is delimited. We know that (op foo 1 2 3) or {foo 1 2 3} partially applies exactly three arguments to foo, no more or less, and we know that (foo 1 2 3) calls foo with exactly three arguments.
• anondon 10y ago
  So functional programming seems to be the bleeding edge programming paradigm that hackers seem to agree on. What other paradigms are highly regarded among hackers?
  • pixelbath 10y ago
    OOP? DRY?
  • virtualwhys 10y ago
    > What other paradigms are highly regarded among hackers? None, but hybrid object functional languages have been on the rise in recent years (though, like FP based languages, still very much niche). See Scala, Ceylon, OCaml, among others. Language functionality aside, multi-target is the next great wave. For example, came across this today[1], pretty awesome -- compiles to server-side, client-side, and native! Would be quite nice to write-once run literally everywhere with a single language, but that looks to be a couple of years off (if there are production ready tri-target languages out there, I'd like to check them out). [1] https://github.com/mkotsbak/scala-native-tellstick-example/tree/crossProjectWithSJS https://github.com/mkotsbak/scala-native-tellstick-example/t...
  • collyw 10y ago
    Personally I like mixed metaphor languages these days using different paradigms where appropriate. In Python I find OOP good for higher level structure, and a more functional style for lower level units.
• jwatte 10y ago
  For small programs, dynamic, runtime tag checked languages as pioneered by LISP are great environments! (Python, Ruby, JavaScript, Smalltalk, PHP, ...) For large programs, making the computer instantly tell you where you remembered wrong is more important (like Haskell, as well as Pascal, C++, Java, C#, etc.) By comparison, small syntactic differences fade into the background noise. This is not news.
• tscs37 10y ago
  I think we should go back to LISP/Scheme, the only language that supports whatever you want, how you want it and when you want it while still being functional. Tho admittedly, most LISP libraries tend to strive for the same age as LISP itself, as it looks.
  • phyrex 10y ago
    There's a whole bunch of more modern lisps than Common Lisp, such as Racket and Clojure
    • tscs37 10y ago
      I don't find either to be a very attractive alternative, Common Lisp just has that kind of ... air around it. Although I admit that Clojure is a decent language.
• exabrial 10y ago
  I think one of the most impressive things I ever saw was at a programming competition while I was in college. I was paired with a suspenders and graybeard and we needed to optimize the brute forcing of a password. He opened a hex editor and kicked out some SPARC assembly that was many times faster than what I was doing in Bash. Lesson: You can be productive anywhere. Here's the thing when it comes to language design: Define a single way to do something. Yes, be politically incorrect and realize you might hurt some people's feelings if you make braces mandatory. Or make them close their tags on HTML. But in the end, what you're adding is simplicity: The arguments move from "you don't write code the way I do" to other more important things.
• zzzcpan 10y ago
  I find this kind of logic to be a common problem among people designing programming languages. It's an interface to talk to a machine, it's not really a toy to play with. And for any good interface the goal is to make sure people have to think as little as possible, learn as little as possible new things and be able to predict behaviors easily. It doesn't matter whether you like braces or not, we have them, they are predictable, no one has to learn them again. Anything else would force thinking and learning and ultimately cannot be a better choice for decades ahead.
  • emodendroket 10y ago
    We have a few models and they all seem to work fine.
• mamcx 10y ago
  I don't like C-like languages. Prefer pascal/python. In delimiters think is far better "begin or do /end" than "{}", but mainly because if you have keywords like "if, while, for" then switch to symbol then switch again is "ugly". I think symbols are for data structures or math or operators, not keywords. key...WORDS. That is. However apart for that, and also dislike the use of space and implicit type. I use F# and like it, except for how ambiguous is for a lot of things. What is the point of have a super-strong type engine and when you look at: let getProductById repository id You still need to use intelli-sense or check the code as with dynamic languages? If I'm into a static typing, I wanna fully use it. When I see: getProductById repository id Type inference defeat me as a user: The computer know what that is, yet, is hidden from me. Not much different than in dynamic languages. Ah, you can annotate it if want! But then you break the language convention. Is bad to let the user decide, because then everyone will decide, but different. So, I think is better in a type-static language to annotate the types, all the time. Because that is how the language really is, and is the way to unlock the benefit of better documentation/clarity that is one of the benefits of static type. This is my main gripe with F#/OCalm. Also apply code require gymnastic because something is unclear in a secuence: let result = getId code save result bla bla When things start or end?. And F# have let fun = and let fun()= both things different. This create a compile time bomb where call some effect trigger before things are ready. In short: have a way to group and mark blocks is great. Python is closer to how do things with space/indentation. ----- Syntax is very important. I don't dismiss it like other people that think is just "sugar". Syntax is our user-interface. When is closer to what the language is, better.
  • dllthomas 10y ago
    > So, I think is better in a type-static language to annotate the types, all the time. I agree. ((int)((int) 5) + ((int) 5)) - ((int)2) is way clearer than 5 + 5 - 2.
    • mamcx 10y ago
      Is well understood that that apply to function/classes/types, etc.. not the non-sense example you pick. And by the way, a + b + c is not more clear than Int + Int + Int... or sum(customer, products) vs. sum(Customer, ProductArray)
• chias 10y ago
  In the example provided under "White space", I find the first (9-line "bad") example significantly better than the 3-line replacement. I can see in a fraction of a second what the first one does. The second one? 3-4 seconds to be about 85% sure I know what it's doing, and about 6-10 to be certain.
• angryasian 10y ago
  I'm wondering if this guy ever had to maintain other people's code or work with a large code base. IMO readability trumps a lot of these points.
  • emodendroket 10y ago
    Arguably, braces make it harder to read code because you can have misleading whitespace. But I mean, this is what linters and formatters are for.
    • deleted 10y ago
      [deleted]
• mwkaufma 10y ago
  Productivity isn't a subjective quality, it's a measurable quantity. Without measurements, you're just bikeshedding.
• makecheck 10y ago
  I don’t think the complaint about braces is looking at the right issue. The issue with braces is that many languages allow multiple lines and indentation when there are no braces. If languages required you to either say "if (foo) bar()" ON ONE LINE or use braces, 99.2% of all the issues would disappear. Heck, I’d be in favor of a new C17 standard just to add this restriction.
• wruza 10y ago
  Actually his example has noise in both cases. Compare that to Lua's: return id > 0 and repository:get(id) Also in C you can #define maybe(cond, ptr) ((cond)?(ptr):NULL) macro and use it everywhere.