23 ms·

It's not what programming languages do, it's what they shepherd you to (2020)

• tyingq 5y ago
  >Perl shepherds you into using regexps...Note that there is nothing about Perl that forces you to do this. It provides all the tools needed to do the right thing. It does have index() and rindex(), but doesn't have a begins_with(), ends_with(), and other string functions that Python, Ruby, PHP, java, etc, have. You can roll your own, but there are arguably things missing.
  • wazoox 5y ago
    It actually has this in a more powerful form: you'd use /^./ or /.$/ of course, and if you want more explicit writing, you can use Regexp::English that provides the kind of functions you like (see https://metacpan.org/pod/Regexp::English https://metacpan.org/pod/Regexp::English ). The thing is that all of these functions are completely superfluous, because a Perlist will use regexp which are much more compact and allow writing in a nice, functional way (map and grep FTW). In fact, in most languages, manipulation of strings is so cumbersome that I go back to Perl almost every time, because a regexp is almost always the most compact, fast and readable solution. Also frankly I never heard of anyone trying to parse XML or HTML with regexps this century for anything but a quick throwaway one-liner, so the example is actually quite poor.
    • tyingq 5y ago
      Yeah, I was answering this from the article: "Note that there is nothing about Perl that forces you to [use regexes]...It provides all the tools needed" I was saying that Perl does sort of force you down the regex path, because things like starts_with() aren't there. You're basically confirming that. Also, it varies by search string size, version and machine type, but at least for me, index() is significantly faster in many situations...2 to 3x faster.
      • wazoox 5y ago
        But I don't want functions such as start_with() or startWith()! I'd much rather use regexes, which are more powerful and more expressive, than a mish-mash of tests like if ( (myvar.startsWith('hello') and myvar.endsWith('world')) or ((myvar.startsWith('Hello') and myvar.endsWith('World'))) {...} I much prefer if ( $myvar =~ /^[H|h]ello.*[W|w]orld$/ ) { } Perl doesn't have these functions because it has better, more powerful tools. It's akin to saying that Python lacks line numbers as GW-BASIC did...
        • tyingq 5y ago
          They are more powerful and expressive, but are also less efficient and significantly slower for simple things like starts/ends_with(). Benchmark index("abc","ab")==0 vs "abc" =~ /^ab/
          • deleted 5y ago
            [deleted]
          • wazoox 5y ago
            This is a canonical case of premature optimisation. I have performance problems with the database backend, the network, disk access, but too slow a regex is a completely non-existing problem in real-life for me. Or else I wouldn't be using Perl/PHP/Python/Ruby but C/C++/Rust/Java etc.
            • tyingq 5y ago
              Maybe. Batch processing huge text files is pretty common in Perl.
  • AnimalMuppet 5y ago
    What's the cause, and what's the effect? I reach for Perl when I have that kind of a problem, because Perl makes it easier than anything else I've ever seen. Does Perl push me to program that way? Or is it the kind of problem that I program in Perl that pushes me to program that way?
    • tyingq 5y ago
      That's true, though Perl was around when there weren't a whole lot of choices in languages too.
• deepsun 5y ago
  I wounder whether Java is usually used for extra-large projects just because it shepherds developers into more-less readable way of doing things. So that even multi-year hundred-people dozen-companies project still at least runs. Of course, I've seen with my own eyes that even that could be broken with enough courage (seen a company ignoring all NPEs in main()), but on average Java projects stay more readable, than, say, Python.
  • DerArzt 5y ago
    > but on average Java projects stay more readable, than, say, Python Can we say that is due to shepherding or rather that Java lays it's types bare for you any time you create or pass a variable? You can do this in python with type annotations, but since they aren't required a lot of dev's just don't. This leads to the code being harder to read in my opinion.
    • gavinray 5y ago
      In Java, everything is a class. Java didn't even have generics when it was released. Any sort of higher-order functions and support for anonymous function weren't introduced until Java 8 in 2014. Language debuted 1995, generics in 2004 (almost a decade!), and lambda/FP facilities in another 20 years. In Java, a public class has to have the same name as the file as well. You had a very constrained design space historically and some non-negotiable enforced conventions. It's similar to Go code, where most of it more-or-less looks the same and you can pick up most codebases and run with them if you're familiar with the language.
• throwaway984393 5y ago
  "Perl has several XML parsers available and they are presumably good at their jobs (I have never actually used one so I wouldn't know). [...] This is a clear case of shepherding. Text manipulation in Perl is easy. Importing, calling and using an XML parser is not." The people writing those lame scripts have the same logic the author does. "Must be hard, probably? So I won't even try to learn, I'll just use this regex" A Shepherd's job is to keep the flock safe. If the blind are leading the blind, that is a lack of shepherding. It's not shepherding users to use regex. It's letting the sheep roam free and they're falling off the cliff. Perl's problem has always been that it is too easy to use. 97% of people who write Perl aren't even programmers. It doesn't shepherd you, it lets you write programs even when you don't know what you're doing. We should require drivers licenses in order to program. Programmers think they are capable even when they're not, and their false confidence and laziness leads to shitty code that causes problems. Same for people who try to drive without passing a driver's test. It just causes harm. We should set legal engineering requirements for code just like for other trades. Otherwise some idiot is going to assume XML parsers are super annoying without even looking at them and try to use regex.
• meijer 5y ago
  Among other things, F# shepherds you into avoiding cyclic dependencies which is really nice both for readibility and proper module design.
• kerblang 5y ago
  Do not be fooled into thinking, "The language made me do it" when the culture that surrounds the language made you do it. Different technologies have cultures brought on by often self-appointed leadership figures, even anonymous ones. Those leadership figures can popularize abuse by convincing others that it's a well-established cultural norm, simply because we tend to loathe non-conformity. Third-party frameworks are often used to establish one's self as a leader and establish abusive practices. Once the foothold is firm, it becomes literally "The framework made me do it." Cultural norms mandate the framework, and the framework forces the abuse. If anyone protests about the consequences of abuse, blame is redirected back at the language. To any onlooker, the consensus seems clear: Your language sucks! Those same onlookers are happy to reinforce this perception because they are busy trying to establish competing cultures & leaders of their own. "You should try my language!" Of course their primary goal is not to help, but to improve their own status by rising the tide and lifting their own boat. If they wanted to really help, they would work on establishing better culture instead of jockeying for popular culture.
  • Jtsummers 5y ago
    Don't be fooled into thinking it's either one or the other. In reality, most of these kinds of things are a combination of social and "physical" systems. "physical" because while programming languages aren't technically physical entities, they still have their own kind of physics and paths of least resistance that people will tend to follow.
  • throwaway894345 5y ago
    100%. Recently I've been frustrated with the Python ecosystem and how many "object oriented" libraries there are which can't easily be tested because of all of the weird shit their constructors do (most recently, the class I'd like to test just builds JSON documents and sends them to an API, but the constructor hard-codes the HTTP client so you have to use magic to swap the hard-coded client with a mock). Of course, someone will come riding in to defend OOP with "that's not true OOP" and another will come riding in to defend Python with "you can write bad code in any language!", both of which miss the point: this sort of thing is much more prevalent in the Python ecosystem than, say, the Go ecosystem or the Rust ecosystem precisely due to culture. And by the way, I'm sure there are lots of other languages that have a culture of poor programming practices--the intent here isn't to pick on Python (I've used it professionally for 15 years).
• hosh 5y ago
  “The medium is the message”. https://youtu.be/ImaH51F4HBw https://youtu.be/ImaH51F4HBw McCluhan applied his thinking to radio and television, but that idea is applicable to computer software and language platforms.
• mwattsun 5y ago
  I like to translate ideas programmers talk about it to more commonly recognized bits of wisdom, so for this one I'm going with "if all you have is a hammer, everything looks like a nail" When I looked it up, I was surprised this is of fairly recent origin by Abraham Maslow in 1966 https://en.wikipedia.org/wiki/Law_of_the_instrument https://en.wikipedia.org/wiki/Law_of_the_instrument
• dkarl 5y ago
  I don't buy that "shepherding" is a strong inherent quality of a language, except in the negative sense that a language can make a particular style of programming impractical, and I don't buy that calling for "discipline" in a language is a denial of its inherent nature. "Discipline" boils down to acceptance of the lessons of experience, and it becomes easier over time. Around the turn of the century, Java seemed to require a lot of "discipline" because the people who were embracing OO at the same time they were embracing Java did all kinds of stupid things. They created deep object hierarchies with unnecessary layers and strained relationships, and their systems were slow because simple operations like formatting a date required ten different object allocations and acquiring a mutex lock or two. The GoF patterns book, a good and well-intentioned book, was co-opted as a kind of extremist OO programming handbook, so that if you got stuck trying to apply OO to a problem, you could always find a way to move forward by adding even more OO. Languages like Java enabled this (some said encouraged it) and a lot of people thought it was impossible for programmers to rein in the tendency for Java codebases to blow up with OO excess. Meanwhile, a lot of fanboys thought that OO shouldn't be reined in, that the way out was through, and they doubled down on their principles. In other words, OO was the hot new thing, and early adopters using OO languages like Java had a tendency to spiral into an OO frenzy that created ridiculously convoluted codebases and slow, complex systems. But this wasn't inherent to Java. It was a combination of Java's ability to write that kind of code, along with a naive zeal for exploring the kind of solutions you could build using inheritance-based OO. Even the fanboys warned that you could, if you weren't sufficiently dedicated to OO principles, write procedural code in Java, putting your logic in static methods and your data in behavior-free, non-encapsulated record-style classes. Twenty years later, we no longer think of Java as a language that infects people with an insatiable desire to create inheritance spaghetti, which they can only resist through discipline. It selects for people who are infected with that desire, sure, but an average programmer coming to Java will be leery of building complex inheritance hierarchies and using inheritance to solve problems it isn't well-suited for. It isn't discipline any more; it's just something people know to do, for their own sake. Building deep inheritance hierarchies and FactoryFactoryFactoryFactories is foolishness, not the one natural way to use Java. Right now, I think something similar is happening in functional programming. I wouldn't be surprised if every fundamentally new programming model suffers from the same growing pains, until the lessons are learned, blind optimism becomes educated appreciation, the zealots are forced to find something else to be fanatical about, and we no longer say it takes "discipline" to avoid the pathologies but merely an awareness of what has been learned from past mistakes.
• lamontcg 5y ago
  Yeah I really don't like this. It reinforces the idea that the best programming languages should be dumbed down to avoid people ever abusing features. I fully support the right to carry and bear footguns and that programmers need to be trained in the responsible use of them. So things like unicode identifiers (allowing the use of π as a variable name), custom operators and operator overloading (so `matrix * vector` rather than `matrix.VecMult(vector)`) can all be used in certain domains to produce perfectly readable domain-specific code. They can also be abused, but that isn't an argument against their use. The argument by the author seems to be around a case where in perl bashing on XML with regexps is easier than XML parsing, which sounds like proper XML parsing needs to be made simpler, easier, more performant, more standardized or whatever it is about proper XML parsing that causes perl authors to not use it. Somehow there's too much friction there which needs to be addressed. The way this argument usually winds up though is someone argues that regexp parsing needs to be made worse to punish people for using it in order to shepherd them into the "better" way.
• weakfish 5y ago
  This is why I enjoy Go, it shepherds you to write clear and uniform code that cannot be mistaken. This is 'boring,' true, but I will die on the hill that engineering should be boring if that's what produces a robust outcome. Elegant functional trickery can be cool in a personal project, but I don't want to spend 2 hours deciphering someone else's elegance when trying to solve a business problem.
  • xigoi 5y ago
    items.filter(item => item.isSelected) is not “functional trickery”.
    • kubb 5y ago
      For weakfish it might be - maybe he's never thought about what this does and when he sees it, his eyes gloss over it as unreadable cleverness.
      • Dylan16807 5y ago
        I feel comfortable saying such a person would be wrong.
    • macgyverismo 5y ago
      Let’s play devils advocate; does it return a filtered list, does it change itself or both? As clear as it may look at first, I still would have to look in the docs to find out.
      • Zababa 5y ago
        You could make the same arguments when you're working with slices in Go. Take append(slice, element). Does it return a slice with the element appended to it, or does it modify the slice in-place?. For some things, you have to look at the docs, that's how it is. Usually languages have conventions around that. In JS, map, filter and reduce always return a fresh array and leave the initial array untouched.
• jerf 5y ago
  A somewhat more established term for this is "affordance". See the results for https://duckduckgo.com/?q=programming+language+affordance https://duckduckgo.com/?q=programming+language+affordance , for instance.
  • unionpivo 5y ago
    Thanks, that was some interesting results. Here goes my morning
• crate_barre 5y ago
  This can derail the convo a bit, but one of the major criticism of React as a view layer library is that it shepherds you into doing a whole lot, much like a framework.
  • pygy_ 5y ago
    "React is not a framework" is marketing BS. Your code calls a library. A framework calls your code, which is what React does. It is a view framework, not an app framework though.
• dack 5y ago
  This resonates - I've thought about certain technique and language couplings as "impedance mismatches", where the technique itself is fine and good, but the language makes it a horrible experience that's not worth it. The example that I've run into most is trying to write functional immutable code in Java. I have just never gotten it to work well - of course there are libraries that have weird workarounds (that aren't compatible with standard data types or libraries), or tons of boilerplate you could write, but ultimately Java just fights you the whole way. It's not really worth going down that path imo, and better to switch to something like kotlin or scala if you can.
  • erik_seaberg 5y ago
    @Value and @Builder from Lombok get you halfway to Scala case classes. Just because Java requires a bunch of noise doesn’t mean your staff has to reread it.
    • dtech 5y ago
      Having arguments against Java deflected with "oh but annotation processors" is so annoying. Just because you can somewhat patch the holes doesn't make it a weakness of the language. Same arguments are used for C ("just use static analysis") or untyped languages ("just add a bunch of unit tests") In my current project we use Error Prone, Checkstyle, Immutables, JSR305, NullAway and a couple of other things. It makes the language tolerable, but it's a massive waste that each setup needs to introduce and tune those, and often inexperience or lack of knowledge will mean they're never introduced, if only because after a while they become painful to introduce. Better languages exists, some are even JVM, which just do this stuff properly.
  • deepsun 5y ago
    Try Kotlin, they basically just fixed that, keeping the rest of Java as it is.
  • AmpsterMan 5y ago
    Java 17 is getting pretty good about this. Records in particular are great.
• mikewarot 5y ago
  My favorite programming language remains Pascal, I wonder that that says about me? I've been described as slow but reliable.
  • WalterBright 5y ago
    It says you like typing BEGIN and END over and over and over ...
    • caslon 5y ago
      Is there a single-word descriptor for languages that depend on so much syntax just to get going? Pascal, C, ALGOL, D, etc. Verbose, maybe, but that's not as fun as some of the catchy words there are to insult languages that aren't.
      • jakear 5y ago
        Boilermaker language. As in: you make a bunch of boilerplate. And also you get your beer but you’re liable to get a shot in the foot with it. (This is all off the top of my head)
      • zelphirkalt 5y ago
        Maybe ad-hoc, as in "not planned ahead well at the time of designing and thus needing lots of fixes for edge cases" or perhaps inelegant as in "requiring many concepts as opposed to something like Smalltalk, which fits on a post card".
      • deleted 5y ago
        [deleted]
    • pjmlp 5y ago
      What about endless typing attributes that the language should infer for itself and instead forces everyone to write templates to work around such matters?
      • deleted 5y ago
• cutler 5y ago
  PHP has to be the worst offender with its pseudo-Java boilerplate enshrined in its PSRs. PHP is a perfectly fine procedural language but version 5 was like the Second Coming of Christ with its religious devotion to all things OOP. I don't know about shepherding - with PHP it's more like being beaten over the head with a club.
  • heurisko 5y ago
    It was a great move for PHP to take inspiration from Java. It gave people a recognisable syntax and structure, to run things on PHP's shared-nothing architecture, which is arguably its real strength. Similarly it was a great move for Symfony to take inspiration from Spring. All the older PHP projects like Drupal have slowly been ported over to using it. I have never met anyone who seriously wants to go back to PHP 4.
  • tored 5y ago
    PHP is not perfectly fine as a procedural language. There are several important features missing, like Function autoloading, without it you need to come up with a reliable way to require dependencies. This usually differs from project to project in a non-reliable way and will be messy if you don’t think this thru. It will also affect things like testing. Only global state or (closed) function state. Namespaces are fake in PHP, it only adds the namespace name to the class name or function name, you can’t store anything inside a namespace like in C++. Thus everything is global, which is horrible and bug prone. You can use static inside a function to keep state as an alternative, but that is hard to manipulate from the outside when needed. It can be done with a separate function that keeps track on other functions state. When I tested modern pure procedural that is what I did. No typedef for function signatures. If you want to create a contract enforced by the compiler you use interfaces in OOP, in procedural you want to define function signatures instead, but there is no reliable way to do that in PHP without classes (ignoring any external tooling that uses phpdoc) Testing. Have you loaded a function into the runtime you can’t unload it again, thus mocking a function you already tested becomes impossible. You can solve this by running every test unit in a separate PHP process, but that is expensive. These are the biggest and none of them will probably never be fixed, perhaps function typedefs has the biggest chance but I doubt it. If you are writing a large project (+500k lines) all of these are very important. That is why OOP PHP rules because it can handle all of this. The problem with OOP is that many of the legacy OOP projects inherited the inheritance based OOP from Java, however today we know that composition based OOP is better (both in Java and PHP).
• Animats 5y ago
  I've become worried about Rust as "async" worms its way into more crates. "Async" is optimized for I/O bound programs. The special case of a large number of slow network connections talking to a server, web services, is what it's really used for. If you have multiple compute-bound tasks crunching away, it's a mismatch.
  • jollybean 5y ago
    Async is also used in UI programs with intermittent, event based interactivity. That's 'front end and back-end' ... probably the bulk of software right there. A bunch of threads running 'compute bound tasks' is probably a special case.
  • zekica 5y ago
    I don't think they are mutually exclusive. You can use async and threads at the same time.
    • lmm 5y ago
      You can't really in rust, because it doesn't let you abstract over async-vs-not. If your function does something that a caller might want to happen async, it has to make a choice about whether to do it in an async way and return future (cumbersome and inefficient to use from blocking thread-based applications), or do it in a blocking way (unsuitable for use from async applications).
      • Arnavion 5y ago
        Function is async and you want to run it synchronously? Create an async runtime and use its equivalent of `runtime.block_on(async_fn())` to drive the future to completion synchronously. Function is blocking and you want to use it in an async context without blocking the async worker thread? Use your runtime's equivalent of `spawn_blocking(|| sync_fn()).await` that will run the function call in a threadpool dedicated for blocking tasks. (Both those examples are for tokio.)
        • 5y ago
• Tozen 5y ago
  I will have to say that I like the direction that the V programming language (vlang) is going. It has blended many good qualities of Oberon/Pascal, C, and Go. I've read a lot of debates among C and Pascal advocates, so good to see newer languages trying to find middle ground. Debatably, the Go language has put itself somewhere in the middle, as a more modern acceptable compromise and blend with its own twists. The V language is continuing on the path of where Go went, where readability, maintainability, and simplicity is more evident. Doing so, where it feels like a more natural feature. At the end of the day, many want to be more focused on the problems to be solved, not tripping over the eccentricities and traps of the language. Clearly, perfection will probably never be achieved. But, I do like where various newer languages are going, as it shows progress. Usability, being easy to learn and teach, as well as being more practical about common programming issues.
  • msie 5y ago
    Looks interesting! First time Ive heard of it!
    • brabel 5y ago
      Beware V is infamous for severely overpromising on its website while most of the features it lists are not even started yet. A few years ago it was heatly discussed on HN... Most people seem to agree V is a textbook example of vaporware[1]. [1] https://christine.website/blog/v-vaporware-2019-06-23 https://christine.website/blog/v-vaporware-2019-06-23
      • Tozen 5y ago
        It's 2022 now. They've had 82 releases on GitHub and are in continuous development.
        • gompertz 5y ago
          Agreed. I'm sick of people referencing that damn website from 2.5 years ago. It's not vaporware whatsoever... It has over 12k github commits FFS. It's an excellent language and has a great community on Discord of excellent people. Frankly the more I read on HN the more I think Zig, Nim, (possibly Rust) supporters here are rather toxic to the community.
• lmm 5y ago
  This seems like a rediscovery of https://www.haskellforall.com/2016/04/worst-practices-should-be-hard.html https://www.haskellforall.com/2016/04/worst-practices-should...
• AtNightWeCode 5y ago
  Not only programming languages. Tools does this too like GIT.
• grahamlee 5y ago
  It's interesting when the creators had a clear intention to shepherd people one way and the programming community went another. Both Objective-C and Java (which was informed by ObjC significantly, including having a few implementors hired from NeXT) clearly intend for low level, C-style imperative code to be isolated early behind a message-passing interface and for systems to be built out of message-passing between objects. This is most explicit in Brad Cox's book describing the ObjC way, "Object-Oriented Programming: an Evolutionary Approach". In practice, a lot of Objective-C software and quite a lot of Java software is designed as big C-style procedures which call into APIs using object methods. Similarly, the OP describes Perl, which is designed using a postmodern philosophy: however you think about your problem, you can solve it that way! In practice as OP describes many people reach for regex.
  • dmux 5y ago
    >...clearly intend for low level, C-style imperative code to be isolated early behind a message-passing interface and for systems to be built out of message-passing between objects. >...Java software is designed as big C-style procedures which call into APIs using object methods. Do you mind going into more detail regarding those two styles in Java? I wouldn't exactly say that Java shepherd's its programmers towards the message passing style at all.
    • AmpsterMan 5y ago
      The default scope of everything is package level. If one writes all of their code in one directory, Java is basically procedural code with syntactic sugar for functions with structs as the first parameter. The moment you want to share with other packages, one has to use the public keyword. I'd argue what Java 'wants' you to do is to have a few public methods that operate on internal state, but it doesn't care too much if state is shared within a package. A good Java API wouldn't have many Setters/Getters that do nothing but set/get references to internal objects, but rather ones that parse and make sense of it's internal state. In practice, I've found most codebases don't care about any of that so every variable is private, they all have public getters/setters (so it's NOMINALLY encapsulated) and most methods are public with a few private methods strewn about.
• wruza 5y ago
  This shows how much programmers hate distraction. Perl doesn't really shepherd you into regexp, it's just easy to s/// in it, so you think: hmm, searching for a good xml library takes time, replacing is fast and non-distracting. In C, replacing in a string is so much harder, so you're okay with setting up a parser and using it. If only Perl had this out of box: use xml; foreach (xml::select(<STDIN>, "item[color=orange]")) { $_->setattr("color", "red") } print(xml::result) But just install XML::Parser you could say! Well, look here: [123] and tell how to do the above from it quickly. You can't. You still want regexp-like selector thing and Perl semantics, not just a deep hash of hashes of arrays of hashes which loses Perl's appeal instantly. Better languages have better tools to work with out of box, and these tools match the language spirit. There is no XML Parser for Perl on CPAN, they all are for some other language that Perl isn't. [1] https://metacpan.org/pod/XML::Parser https://metacpan.org/pod/XML::Parser [2] https://stackoverflow.com/questions/487213/whats-the-best-xml-parser-for-perl https://stackoverflow.com/questions/487213/whats-the-best-xm... [3] https://metacpan.org/pod/XML::LibXML https://metacpan.org/pod/XML::LibXML
  • bmn__ 5y ago
    > Well, look [at libxml] and tell how to do the above from it quickly. You can't. Bullshit. Any reason for writing such flamebait? On /. you would have been voted into oblivion for that. use XML::LibXML; my $dom = XML::LibXML->load_xml(IO => STDIN); $_->setAttribute(color => 'red') for $dom->findnodes('//item[@color="orange"]'); print $dom->toString;
    • wruza 5y ago
      It is bullshit, as many commenters already noted, but it is also my experience back then, in the light of an article's meaning. The experience was bullshit, let that sink in. Perl, google, CPAN documentation on the first two (big) modules gave no clear reason to not s/// and go deeper. I chose s///. Was(am) I smart? Probably not so much. Was all of that inviting me to s///? Yes. And it worked, I had to parse these stupid enormous xmls into my computer parts warehouse where I worked at, and had no time to read all the manuals while clients crowded at the door. Look at the doc again, where is your snippet there? Down 2 levels of links probably. You didn't write this right the first time you opened it in your browser. Where is ->findnodes() reference? I skimmed ::DOM, ::Document, ::Element to no avail. Even now my patience is over, while e.g. jQuery made it obvious "$(sel).attr(…)" even though I never really used it nor read its docs.
• bullen 5y ago
  When I was studying Masters in Physics Engineering in Uppsala I spent all my time in the Sun+Solaris computer labs instead of going to the lessons we had in our Math and Physics courses. I fell into the rabbit hole of HTML+.js+Applets and just couldn't do anything else. I made my first HTTP server that I ran on the university account without anyone noticing! :) I found Karl Hornells javaonthebrain.com (little did I know he was sitting in the building next to me): You don't need to code Java in a stupid way, here is how you do it like C without cache misses: http://www.javaonthebrain.com/java/iceblox/iceblox.java http://www.javaonthebrain.com/java/iceblox/iceblox.java "Java does not shepherd you into using classes and objects, it pretty much mandates them." - Well it mandates ONE class, you do you!
  • dtech 5y ago
    High-performance Java is indeed basically writing C in Java, including using you own byte array for memory. It's amazingly un-idiomatic though, and you'll get (rightly) roasted by fellow Java developers for doing it without a clear and compelling need. In other words, you've missed the whole point of the article. Just because you can do it, doesn't mean you'll end up doing it.
    • cerved 5y ago
      You can do it for fun :P
    • bullen 5y ago
      Clear and compelling need? Isn't $1/KWh enough for you? I don't think you understand that real electricity prices can never go down! Combine that with peak computer hardware performance/efficiency and you have a time bomb that will leave nobody out of harm! Java can do atomic parallel things on multiple cores you are hard pressed to build a VM with GC to get working in C. WASM tried only VM and Go tried only GC, both failed compared to Java on the server. Servers that crash are not an option.
      • coldtea 5y ago
        >Clear and compelling need? Isn't $1/KWh enough for you? I don't think you understand that real electricity prices can never go down! So? It's not like the electricity bill is a major concern for 99% of companies with servers. It's usually less than what they pay to stock the fridge with water bottles...
• oaiey 5y ago
  I am a long term C# dev and have my educated guesses in what I am shepherd to ... But I am very curious about your opinion here since I am probably blind to this. And to keep the discourse focused on the interesting things, let us exclude "into Microsofts hands / into Azure cloud".
  • pjmlp 5y ago
    Being on the Java/.NET/C++ boat since the early days, and having been on the receiving end of those stacks on the Microsoft ecosystem, I would actually make a point of "into Azure cloud", given that the shepards at the desktop side don't seem to have any clue about what they are supposed to do after the Windows 8 debacle. Then the whole WinDev vs DevDiv politics seem to always influence what sheppards happen to take care of the herd, and the way decisions are taken. Meanwhile C# seems to be turning into the C++/CLI replacement while sucking the life out of F# and VB.NET. While I enjoy many of the latest .NET improvements, I occasionally wonder where they are going now.
• PicassoCTs 5y ago
  Now imagine what bad behaviors "No Code" languages encourage in new programmers. Lots of them blatantly encourage there users to "copy&paste" instead of using functions and structures. And if they try to encourage good behavior, the sales people start to bugger the developers to "make it simpler" and the result is again a 9000 lines long papyrus of copy & paste.
  • pjmlp 5y ago
    Depends, there are those that do encorage modularity via packages and modules. However just like in text based languages, there are always those that write functions bodies that take several screens.
• flohofwoe 5y ago
  > C shepherds you into manipulating data via pointers rather than value objects. Overly simplified IMHO, this was probably true for K&R C, but in more recent C versions (e.g. in the last two decades or so), passing structs around by value is fine and often preferable. (in general I agree with the article though, the shepherding side effect of programming languages is probably more important than the syntax and feature set)
  • GuB-42 5y ago
    How? Unless you are talking about really small structs, something like 16 bytes or less. Unless there are optimizations that I am not aware of, calling by value takes up stack space and make full copies each time. If you are doing C, chances are that you care about that. Few languages pass structs/objects by value nowadays, at least not as a default action, because it is rarely what you want. Usually, a reference is what you want. In fact, if C++ wasn't designed as a superset of C, passing by reference probably would have been the default, like in most other languages. C shepherds you into manipulating data via pointers simply because pointers are what you are using for the all important task of referencing objects.
    • jstimpfle 5y ago
      What I like about C is that one can easily tell if something is passed by value or not, because I know these things won't be modified. C++ does not have this property, because C++ has (non-const) references - so when reading code one always has to check the signature of the called function. On the other hand, C sometimes nudges you to pass by pointer where semantically you want a copy. Well, Matrix4x4 is the only example I can think of right now actually, and here I usually just bite the bullet and pass a copy, which might be a little wasteful but whatever (copying 64 bytes is not the end of the world, and the code might actually be inlined). And here, C++'s const-references can be an improvement to the situation.
• jgilias 5y ago
  It's pretty hilarious how a good part of the comment section here is some variation of what the article starts out with: Person A: "Programming language X is bad, code written in it is unreadable and horrible." Person B: "No it's not. You can write good code in X, you just have to be disciplined."
  • pdimitar 5y ago
    It is indeed hilarious. Same people that will insist (until their grave apparently) that C is fine and that the OpenSSL guys were idiots for allowing Heartbleed, nevermind the fact that buffer overflows and underflows are literally the No. 1 cause of security problems when working with C... What really ticks me off about those kinds of people is that they are extremely likely to just have been blind about their own mistakes when coding C, while loudly claiming that "you just need to be disciplined".
    • TheMonarchist 5y ago
      > buffer overflows and underflows are literally the No. 1 cause of security problems when working with C Why don't these ancient projects just move to C++ for vectors and strings, that do the buffer handling correctly for you? Surely they can run a C++ compiler on any workstation these days?
      • oriolid 5y ago
        The usual and not completely unfounded reasons are - Dependency on huge C++ runtime library and possible ABI problems. Twice so for embedded targets. - Careless use of C++ features can lead to large binaries and unexpected runtime costs. - Lack of judgement and template metaprogramming or even plain polymorphism can lead to code that's really difficult to maintain. - Bad experience with pre-C++11 versions of the language or Windows C++ APIs.
        • TheMonarchist 5y ago
          > Dependency on huge C++ runtime library and possible ABI problems. C++ runtime is hardly huge by modern standards, and the usual resolution to ABI issues is to provide C bindings. > Careless use of C++ -- Lack of judgement -- C doesn't make you immune to any of this. What are buffer overruns if not careless use of C? Edit: Considering that I suggested moving to C++ for vectors and strings, your bringing up of TMP and polymorphism sounds like a strawman argument.
• pdimitar 5y ago
  Yeah, that's very true. Try and do FP in Java or C++ or PHP or Python and see where it gets you. And before I get a ton of "ackchyally you can do X" guys, yes you technically can but there's friction and you are implicitly not encouraged to do so. I like languages that push you to think about X or Y so you can't miss it. Case in point: strong static types in many languages, or lifetimes/ownership in Rust.
  • deepsun 5y ago
    > I like languages that push you to think about X or Y so you can't miss it. Yet most modern languages steer away from checked exceptions, that you cannot miss. And I agree with them, catching UrlMalformedException from a hardcoded static url is unnecessary. But most importantly, checked exceptions just don't play well with FP, that's why they are getting pushed off the ship.
    • AmpsterMan 5y ago
      I have such a weird relationship with checked exceptions in Java. I like checked exceptions because it makes exceptions part of the API. However, much of the time it's super intrusive and try-catch can be clunky. At this point I'm convinced there is no good solution from a language level for exceptions/errors. They just suck.
      • valenterry 5y ago
        The solution is already there. It's a combination of subtyping, union types, effect-handling and syntactic sugar for effect handling. checked exceptions would be fine id they were not so clunky.
  • asddubs 5y ago
    oh I don't think doing functional programming in PHP is all difficult/frictiony. C++ there's probably a bit more friction but if you're on a modern version it's also not too bad.
  • Tozen 5y ago
• Const-me 5y ago
  That might be true for perl, but I don’t believe that’s true for programming languages in general. > C++ shepherds you into providing dependencies as header-only libraries. There’re many C++ libraries provided as DLLs too, like QT. Just because the standard library is mostly header-only, doesn’t mean that’s always a good idea for other libraries. > Java does not shepherd you into using classes and objects, it pretty much mandates them. Maybe, but modern C#, despite similar to Java in many regards, doesn’t promote any particular coding style. Classes and objects are working fine, but so is FP or procedural. And there’re decent libraries, both Microsoft’s and third party, implementing reactive and actor approaches.