1 languages or tech promoted by companies like Google, MS or FB
2 developers that self promote by creating a side project using the latest buzzwords and coolest languages of the month and sharing it, some do it for the CV but others do it for learning to see what is all about.
HN can't predict the future, good tech can die because is not supported by a company with money, or the company that controls it is incompetent and kills it. I am still thinking that C# and .Net could have been more popular only if MS could have just open source it from the beginning, maybe we would have now a way to do cross platform WPF apps and running them in browser with an open source Silverlight
Like some sort of colourful bird mating ritual, you have to append so many explanations so as to not offend someone's trigger-happy finger and lose karma.
Or even new ones. I’ve been given js+mongo apps by partners that I had to modify to use standard postgres before becoming responsible for herding them in prod.
Are you talking about Java 8 specifically, or are you saying that for some reason there is going to be a sea-change and corporate IT is going to start using all the buzzwords and tearing down their old systems?
If it's the later, and seeing how much enterprise has shifted in the last 30 years... if I were a betting fellow I'd say big systems will still be Java 8 in ten years time. Mayyyybe a freshly discovered catastrophic flaw in the jvm causes them to upgrade a version!
They won't tear down anything. But there will be more and more systems that were built using newer things, some which we consider cutting edge right now. Some companies will get acquired, some will go bankrupt and their old systems deprecated, etc.
Plenty of enterprise technologies have lasted more than 16 years. People are still paying good money to get help with software that's been running since the 60's. Less IT will be running on Java 8 by 2030. Maybe.
It has been a sentiment that is posted on here just about monthly, and this is surely not the first time you've seen it. Usually it yields a lot of cynical posts with clever new phrases for whatever is new, as if there are a lot of people feeling really defensive for whatever they're using.
HN is about the interesting parts of tech, pushing at the edges. Yet the vast majority of developers are developing vanilla IT processes in shops where they want it to be the most benign, easily transferable solution possible. The differential between the two isn't surprising or particularly interesting. It's an obvious outcome.
And in ten years the stuff that people talked about on HN become the normal stuff at those IT shops, and HN will be onto something else. And on your "legacy" shops you'll be using frameworks that incorporated the best of those ShinyNewThings. Or do people really think the Java ecosystem today (or the .NET ecosystem, etc) hasn't changed over that time.
And that's okay. It's okay to wait until it matured. What isn't okay is that it's usually coached in derisive, defensive terminology that denigrates whatever is "Trendy". That part isn't cool
In your last sentence, the converse also applies to would be trendsetters denigrating mature technologies. I think that the key problem is that people in this industry are quick to play the denigration card in order to justify their own beliefs, instead of fostering an environment of mutual respect. Remember, a lot of the audience of hackernews, for better or for worse, are impressionable green management that aren't exactly qualified to start powering their homes with miniaturized fusion reactors, and would be better off to keep using things like relational databases and cobol if the ends justify the means.
Does this problem play out in respect to experimental medicine I wonder?
Hehe... Cool, I'm a "dark matter developer" and I like it. Edit: Because of downvotes, I'll expand a bit for more interesting comment. I work in a pretty large corp. as a developer, and solve a lot of smaller day-to-day business problems - let's say it begins with Excel and ends with a web form. I also set up the server, database and anything else I need on Azure in co-operation with our (very big) IT provider. I find it quite interesting, but my workday ends at 16.
Dunno what hole she is in but Excel, Sharepoint are all things that new age companies don't work on & rather is the tool of choice for all things by legacy ones still chugging along.
The part when they said they spent a lot of money to port to C/C++ but couldn't get same efficiency/speed, that's the problem with most porting endeavours: you need people who grok both languages you're porting from and you're porting to, or at least understand the specs and business logic. That COBOL program has probably been optimised so much that the code makes no sense to people without understanding of the intricacies of that language.
My team spent a whole quarter on converting R code into Python, because we wanted to use Tensorflow for machine learning(). When they finally got the thing running, they found out it wasn't performing as fast as R. I thought, that couldn't be possible, they use pretty much the same linear algebra libraries. So I peeked into the code to see what went wrong and found out that they writing it the wrong way: (1) calculated on Pandas dataframe directly instead of extracting the values first when doing matrix calculation, (2) instead of plain ndarray, were using matrix instead, which is slower. Both of which someone without experience in Python wouldn't have known.
() On a hindsight, did it have to be Tensorflow? Besides, there's already an interface for R[1]. Maybe the team decided on Python anyway in case they want to try out the plethora of ML libraries available for that language.
I have been part of couple of migration projects from COBOL (and accompanying mainframe tech) to newer tech. COBOL is a very simple language. What makes porting next to impossible is the functional knowledge of the application, how it intracts with uostream/downstream systems, all the special case handling and how business users expect the new system to behave (hint: same as the existing system). Biggest challenge to porting is that you can't port an entire system at once (takes years), so when you starting migrating part by part, it has to interact with its neighbouring systems exactly how the old system worked. And that is what is most difficult part of porting IMHO..
You may be very surprised how much very serious stuff runs in and is still being written on top of Excel. Trading models dealing with tens of millions of dollars a day for example.
Yup, can confirm, Excel is everywhere. And it's even applied where it's not appropriate (VBA macros runnings on way too large datasets for hours and hours, completely inefficiently).
Dunno what hole she is in but Excel, Sharepoint are all things that small companies struggling to make a profit don't work on & rather is the tool of choice for all things by hugely profitable organisations that will pick the bones of those smaller companies in a few years time
It's a bit disturbing how much people in this industry are focused on tooling.
It's a biproduct IMO of working on boring problems or supporting morally ambiguous corps. That thing that you need to keep yourself busy and keep going in the rat race.
Tooling is great for job security. You can be absolutely shit at writing code and designing systems, yet make yourself indispensable because you know Framework X and most other people don't. All it takes is time to memorize trivia of the framework and a bit of trial-and-error to figure out how to work around framework's pitfalls.
Unfortunately, this creates a whole host of long-term issues. For example, it create the situation where complex tools have their fervent advocates, while simple tools do not (because they don't provide job security). It also create an incentive to start a sort of complexity Ponzi scheme: you add tools to manage tools to manage other tools and so on. Each new layer reinforces the job security of people working on the previous one.
It's important to keep in mind that stuff like Java 8 and C are also tools, susceptible to the same problem.
> you add tools to manage tools to manage other tools and so on. Each new layer reinforces the job security of people working on the previous one.
The first time I seen a job title of "Kubernetes Keeper" I died a little inside. It's not that these jobs didn't exist before, and sysadmin is a perfectly good role which I personally don't have the skills or desire to do, but we keep pretending that we've build a way of replacing some of the effort which just moves it around a little.
I think the focus on tooling is more because: (1) developers understand it, since they use it full-time; (2) they're motivated to write it, since it will make their life easier. Understanding business needs takes work, and writing software you will never use is uninspiring.
It's also a product of ambitious orgs. One way to out compete a competitor with more resources is to have better development, ops, and release tooling. It's not a silver bullet but it can make a large positive impact when done properly.
Geeze... the contemporary Internet, man. Ten years ago, we flamed each other over our personal preferences, and others' views were "stupid". Today, we flame on about our personal preferences, and others are implied to be "immoral". Both exercises are admittedly immature, but at the least the former was more cheeky and not so up its own posterior.
Yes, tooling is a huge deal in day-to-day life. When I think about drains on my time and productivity, I've never been too setback by having to deal with a "for" loop instead of something more monadic. However, I HAVE spent days doing painful refactoring work, that could have been done in minutes with a few right-clicks in an IDE. Build tools and CI/CD pipelines, profiling and troubleshooting tools, etc etc etc.
I can't believe that any of this stuff requires defending oneself from having "sold out to The Man".
> When I think about drains on my time and productivity, I've never been too setback by having to deal with a "for" loop instead of something more monadic. However, I HAVE spent days doing painful refactoring work, that could have been done in minutes with a few right-clicks in an IDE.
I think your examples betray your inexperience with what you're criticizing. A for loop isn't somehow corresponding to "something monadic" and safe refactoring (actual refactoring, not just renaming things, though that's obviously trivial as well) is extremely easy to do and produces great results in languages like Haskell, OCaml, etc.. Primarily this is because moving grouped things is nowhere near as sensitive as in a language like Java or the like.
But yeah, you can right-click rename all day, for sure... Never mind that other languages can let you safely re-architect the very bones of the solution with almost zero fear of coming out on the other side in failure.
Java has great tools, but let's not bring up refactoring as a real strength. It's kid's level stuff in comparison to languages that allow you to do that and more without tooling.
Haskell et al. have crap tooling and that has real consequences, but refactoring isn't one of the casualties at all. They're still better at refactoring, re-architecting and repurposing than any of the big name languages.
At least bring up debugging, system interaction or something.
I'm not sure I disagree with you, but I think the counterpoint is worth stating: that a compiler is the beginning, not the end, of a productive software engineering toolkit, and that there is no software stack that has achieved perfect tooling—quite on the contrary, I think it might be fair to say that most languages lack a great deal of tooling.
There's every reason to think that software engineers and system administrators do their job much more quickly and correctly when they have the support of rich editor support, understandable compiler errors, usable interactive debuggers, profilers, dependency management that won't set your hair on fire, etc. For whatever reason, it seems like businesses often aren't interested or successful in creating these products, so frustrated developers step in to create the tools they dream of in their own work after too many days spent refactoring with regex.
It's possible that people might be drawn to tooling projects because of some kind of internalized revulsion in response to the social impact of their employer, but I think you'd expect to see developers working on tooling regardless of whether or not this is the case because of how a lot of development tooling just wouldn't exist if it weren't for individual FOSS contributors' efforts.
It's a bit disturbing how much people in this industry are focused on tooling.
That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing.
If I went in for a root canal and the dentist said "We're gonna kick it old school today, sniff this rag of ether, I'm bored with all these tools!" I would grab the nearest scalpel and slowly back away. But yeah, if you're working on boring problems the tools won't do much to mask it.
>>That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing.
A software developer's job is to create software. Almost like an author. Some more than others. At the end of the day, no matter how good your pen is, it will not write a great book for you.
I see your point, but I think you can't ignore the power of tools.
Most software created itself is a tool, a tool which typically leverages the speed of computing to perform a task hundreds, thousands, or millions of times faster than a human could. Think making a bank transfer - I can do this in 5 seconds on my phone now, which would take me over an hour to physically head into a branch and do it in person, and even then we are relying on computing power at the branch itself.
Why would we, as software developers, act like we aren't going to use tools ourselves? For productivity, for a more pleasant (or even just less frustrating) experience?
I initially was a vim + printf debugging stalwart, but having been in a Java environment grew to realise the immense power of an IDE like IntelliJ and how beneficial it is. You can detect errors in the code almost immediately, so spelling mistakes and missed semicolons aren't a thing. You can fix them in a fraction of a second. If I write a function that could be written in a clearer way, or I'm not sure what type I should write for a variable, it will suggest it immediately and I can follow that suggestion with a press of a key.
Yes, it cannot write great software for me. But if you have worked with software where there is no autocompletion, poor debugging and profiling tools, then I find it hard to believe that you don't think that the addition of these tool can help you write at the least MORE software, and probably even BETTER software.
It is not the same as writing a novel, as much as I would like to romanticise that it is. It is about organising and coordinating components to work together, and for this tools can be a tremendous help.
Eh, I'm not really seeing the analogy to an author, whose final product is the words on the page, so in that you are right that the kind of typewriter wont help much. But a developer's code isn't the final product, it' an input to an output, and good tooling can potentially make a mediocre dev better (within limits), by catching compile time bugs, by enforcing constraints, maybe, by exposing functionality (autocomplete), enabling profilers or debuggers, etc...
The more experience I have, the more I appreciate good tooling.
Why? Because the tooling is what ends up being used every day in so many ways. A minor improvement in tooling can lead to drastically better quality of life. It's like getting a fancy but expensive office chair - no, I don't need it, but my back will thank me at the end of every day.
The catch here is that this applies across the board. For example, many new languages try to sell you on a better language design that is more convenient - and it may well be, but it doesn't matter when there's no good IDE, no good debugger, no smooth deployment story etc. PL and API design is important, but it's not more important than everything else. The languages that are the best for "quality of coding" are the ones that balance it all, and usually they have to dial some advanced aspects down to enable other areas to work. Or at least move slower with language evolution, so that new fancy features get full support across the board. It's no coincidence that languages like Java and C# - which lag behind on bleeding edge language features - have the best code completion and refactoring in the industry.
I use great software with subpar tooling all day long, and it is not a good feeling. It feels like sawing of your own arm to feed your hungry customers.
Not sure what specifics you mean by tooling but in the context of build/deploying tooling, I really enjoyed learning about it. Beyong the knowledge to be able to develop at both front/backend, setting up the CI/CD pipeline and seeing it all work seamlessly, is useful. Understanding it end-to-end is quite satisfying too.
Blindness to "old", established tools and technologies is one thing, but let's not pretend Sharepoint, Java 8, Excel, et al don't have their fair amount of suckiness and operational challenges.
I mean, Java 8, that's great! From an enterprise point of view it was released basically yesterday. I'm sure a large minority of systems still runs on Java 5 or 6.
There's very little reason not to upgrade to Java 8. Generally things just work. With Java 11 generally things just break, so it's completely another matter. I think that Java 8/11 will repeat Python 2/3 story.
There is a special place in my heart to hate the new shiny lambdas. Makes code too difficult for reading, nowhere compatible when needing to use Java 7 every now and then.
With the article would just disagree on Sharepoint, would say Confluence has finally replaced that one.
IntelliJ IDEA actually just collapses them into lambdas by default. And it also auto-generates them for you so you don't have to type them. At least that was the state of things a couple of years ago, can only have gotten even better since then.
Do you really prefer a language to not have higher order functions than with them?
Quick, what does this do (in Scala)?
(1 to 100).map(x => x * x).reduce(_ + _) ?
Or if you don't like the underscores we could make it more explicit:
(1 to 100).map(x => x * x).reduce {case (x, y) => x + y }
Let's look at the iterative alternative:
var (i, sum) = (0, 0)
while (i < 100) {
sum = i * i;
i = i + 1
}
You could argue about performance or whatever, but closures are safer, more powerful, easier to read, and more concise.
Using a language without anonymous closures is like programming blind-folded and with one hand behind your back. It's pretty much the definition of Paul Graham's "Blub" languages[1]
Of course, classes are closures and closures are classes. But classes without closures are verbose, stupid, and ugly.
sum = (1 to 100).map(x => x * x).reduce {case (x, y) => x + y }
sum = 0
for i in 1..100 { sum += i * i }
I personally find the second one easier to understand. Performance is much better unless the compiler does some magic to convert the first version to the second one.
Adding more logic to the loop also doesn't make the code more complex.
> This piece of the puzzle is the one that worries me the most. What I’m worried about is that places like Hacker News, r/programming, the tech press, and conferences expose us to a number of tech-forward biases about our industry that are overenthusiastic about the promises of new technology without talking about tradeoffs.
That's because these are marketing websites, meant to show off the newest and shiniest things, with an agenda. We like them because by our nature we like new and shiny things, but their content isn't representative of real life, like at all.
> That the loudest voices get the most credibility, and, that, as a result, we are listening to complicated set-ups and overengineering systems of distributed networking and queues and serverless and microservices and machine learning platforms that our companies don’t need, and that most other developers that pick up our work can’t relate to, or can even work with.
This is also part of human nature and my experience in the tech world confirms to me that the loudest voices are usually somewhere in the top of the bell curve of correctness or usefulness. Make friends with people who are working on real products every day and stay grounded in reality by talking to them, like knives that sharpen each other. The less they want to talk about tech or share their opinions, the more likely they are to have sane, reasonable and useful ones.
I'm right now writing code for integration with one information system using SOAP Web Service with digital signatures. Good old Java 8, wsimport, etc. Nothing wrong about it, it gets job done. I'm still reluctant to throw away XML from my Spring projects, I don't like their new approach with annotations and XML works better for me.
At work, we have some customers who want to use WebLogic and Websphere, and last time I checked those don't have versions that support anything beyond Java 8.
I still use Java 8 even on personal projects. I'm migrating those to Kotlin, so I'm at least not held back with regard to programming language features. I could upgrade those to Java 11 (or 12), just haven't prioritized taking the time to do that over other tasks, and the benefit would be minimal for these particular projects.
When using Java 8 language, I'm just happy to have lambdas and streams. Java 8 was the biggest improvement to Java language since 5 -- and I'd say it's a bigger leap that 5 was.
I'd rather keep lambdas and live with runtime polymorphism, than keep parametric polymorphism and lose lambdas.
Generics, in terms of scope, is a bigger feature, for sure. And generics make lambdas more usable. But the distance between generics and their alternative - manual casts throughout - is larger than the distance between lambdas and anonymous inner classes.
Speaking of dark matter coding, story time: a spare time project of mine involves bringing an actual, pre-generics codebase into the not quite as distant past. That beast still has real, living users! Surprisingly, a frequent complaint is running out of heap memory, so they are happily sharing their magic -Xmx incantations with values that would have been outrageously high when the code was written.
I don't use Java at work, but at home I inevitably install it for some kind of tooling. Always Java 8. I've accidentally installed Java 9 or newer a couple times and always ended up with something broken.
I’ve developed in environments where Java 8 was still the latest available version because of upgrade security issues.
I have a friend who, until very recently, was working on a system based on Java 6, which coincidentally was the latest version back when the both of us were in college.
I'm currently in a not-that-old project(2 years old) the front-end of which was built using Angular 1.x.
I have to admit I like this, because my biggest gripe with this framework was that the API changes from version to version were so intense, that you couldn't find a working tutorial for some stuff.
Now that it's not being updated that fast it's much easier.
The HN front page is similar to any community. For example, a car site's homepage will be listing the latest supercars, expensive turbos, rims, whatever... while most readers are driving a $30,000 Civic.
The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about, regardless of what the mass is doing.
Good point about communities, but I don't think it's good to say "the best and brightest in tech" in this context. HN exists to gratify curiosity, and people are more curious about things they haven't seen before, or that are currently captivating their imagination. This emotion is not a reflection of the world around us—it's aspirational. But there's a risk if we start to feel inferior because we don't get to do that at our job or whatever, which is partly what the article is about.
Incidentally, it's the same curiosity that has the current article near the top of HN right now. It's not a point that has been articulated so often, or so recently, or so well, so it's fresh. Even if we already know it, it's a fresh reminder. (And also, of course, there's the catnip of the meta dimension.)
> The best & brightest in tech are working with the best tools on the biggest problems
I don't think that's true—there is a subset of the best and brightest who work on greenfield projects very decoupled from existing customer bases, and they get to blog / present / post a lot about what they're doing. There are quite a few "best and brightest" people who are in large companies or slow-moving industries. They're often constrained to existing tooling, because moving to fancy new tooling is a huge risk and time sink for limited reward. They might be using cool personal tools—fancy editors and keyboards and window managers—but the stack they work on is generally "legacy".
And usually the problem of "How do we make this work slightly better for millions of end users" ends up being a bigger problem than "How do we do something really cool as a demo."
If they're really the best, wouldn't they have their pick of workplaces and optimize for personal enjoyment? Nobody who could chew through research level algorithm problems all day would willingly write Java 8 CRUD apps for Windows Server 2000, because those are the people that have a choice.
Personal enjoyment can take many forms and people have more than one priority in life. Big corps can also have their upsides aside from tech and process related questions that might be attractive. While I have my pet peeves that would hinder progress, I personally don't really care about a particular stack enough to get invested. If I'm too concerned with that aspect that would imply that I'm not working on the interesting part of the problem anyway.
You can handle a lot of restrictions if the domain/problem is interesting enough and the constraints put on you don't feel too taxing, e.g. because they aren't enforced for your role or team very much. I feel like company size just isn't a good indicator for personal enjoyment/growth/$whatever, lots of research oriented divisions in larger corporations will let you work on interesting topics and hand off the engineering part to teams with people that enjoy that particular aspect of our world, both working for the same company.
One, the hiring market isn't either liquid enough or high-information enough for this to work.
Two, they have their pick of workplaces and focus on finding the biggest problem or perhaps the biggest paycheck, not the most freedom in tools. I have perfect freedom in tools hacking on OSS by myself; I don't look for that in a job.
People have a strange idea of what "best and brightest" work entails.
I work with Java 8 on a greenfield high-frequency transaction platform for a very large company. It is extremely satisfying to build the "world's largest" of something, and no amount of shiny features in a cute new language would deter me from this work.
The best and brightest are working on greatest problems and are not focused on using the newest tools in many cases they are using substandard tools because they are focused on the problem.
Right. It's not what all the best and brightest are doing. It's what people like to read about, and what we want to be doing, even if most of what we do isn't that.
Not a super-driver but Enzo Ferrari used to daily drive a Fiat 128 [1] . Nowadays the former chairman of the VW Group and a member of the family that controls Porsche has just paid $18 million for a custom-made Bugatti.
The price is negligible in that the point is most people will work with Java, PHP, JS, etc at their workplaces yet indulge in the newest concepts/technologies on HN.
>The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about
We should be so lucky. Nobody knows who's the best, what the best tools are, or what the biggest problems are. We only know the ones that get written about.
Writers cover what's flashy, who's the best self-promoter, and what makes the most money.
Sites like HN and Reddit are aggregators in the literal sense. They take a large volume of data points and reduce it to a select few that get shown to most users. that aggregation function is "most interesting", not "most representative". Those are direct opposites of each other: interesting is almost by definition unusual.
I always find the subreddits that try to explicitly not target polar extremes the most fascinating from a sociology perspective. For example, this photo of a sink faucet is the most mildly interesting submission of the past year:
> The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about, regardless of what the mass is doing.
That doesn't have to mean new and shiny.
By way of analogy: the F-117 stealth fighter--the world's first operational stealth aircraft--was developed by the best and brightest (Lockheed Martin Skunk Works) and solved the biggest problem (visibility to radar). Aside from having a weird polyhedral shape and innovative radar-absorbing material, nothing about the plane was the "best", "latest", or "cutting-edge" at all. Much of it consisted of parts from other aircraft hacked together. If you actually do want to have the best cutting-edge technology all in one plane, you spend 25 years designing the damn thing--that's the F-35.
The initial version of F-35 was lifted wholesale from Yakovlev Yak-141. Basically during the wild late 80's early 90's in Russia Lockheed Martin entered into an agreement with the Yakovlev bureau to do who knows what with Yak-141 (which sounds impossible and wild in itself nowadays). The agreement lasted just long enough for them to rip everything off and was then dissolved.
That's a massive exaggeration at best. The F-35B variant borrows the lift fan design from the Yak-141. That's a single feature of a single variant of an aircraft that has a half-dozen other completely unrelated features. The Yak-141 didn't have helmet-mounted displays, it wasn't stealthy, it didn't have the new combat information management systems, it wasn't built out of modern composite materials, and so forth.
Would be quite a feat to have all those things in late 80s, don't you think? :-) It's not an "exaggeration" The planes even look similar, and Lockheed got $1.5T in government money for a few million they spent bribing government officials in Moscow.
> Would be quite a feat to have all those things in late 80s, don't you think? :-)
The F-35 has them. The Yak-141 didn't. Therefore, it absolutely is an exaggeration to say the F-35 was "lifted wholesale" from the Yak-141. Two of the three F-35 variants don't even have the lift fan!
There is most likely some kind of division here where 5% here is working with the best tools on the biggest problems, 60% are working with old and non optimal tools on crud making money, 15% is working with the latest and coolest at a well funded startup and the rest is just following hypes making peanuts trying to fill their resume. Here best & brightest depends on your definition; if you are in it for the money and do not live in the valley, I think brightest might be java or c# if you want to make money.
In the majority of companies it's simply not possible to operate on the bleeding edge the way HN articles would have you believe you should. Besides the obvious issues around the value of rewriting stable legacy systems on new platforms, there are also man power issues. You need tier 1 developers to live on the bleeding edge because any problem that comes up (and they will come up) largely requires you to solve it yourself sans the help of the greater internet. On a legacy system an average dev can generally Google any issues that arise because they are known problems.
When dealing with new tech it's a lot more likely to be the first person to run into some obscure use case no one has ever experienced before. And in that case you need devs who are not only capable but willing to invest in solving the problem. Sometimes that means, re-architect something in the stack and sometimes it may even require making a PR to the original project. That's a lot of investment that may make your devs happier but probably provides little concrete value to the business.
That said I'm still building on elixir so what do I know.
Good points here. Which is why HN is oriented toward startups with Tier 1 engineers. PG and his cofounders invented the web app, using a combination of old tech (lisp) and new (the internet).
There are plenty of other forums and sites to read about conventional tech. HN is where I find the bleeding edge. 90% of it is just fascinating. But the other 10% offer tantalizing possibilities for making something novel, which is to say: solving an unsolved problem.
“How to Become a Hacker” puts it plainly: no problem should have to be solved twice. Drudgery is evil. And by those axioms, a ‘Hacker’ is just uninterested in old solutions to old problems. We need to live in the future so that we can build the future. Although HN’s content has suffered over the last 5 years with the influx that accompanied a wider awareness of startups, it still is the best place I know of to dip your toes into the various futures we may one day encounter.
Having said that, lately I’ve found that Google Scholar is often more thought-provoking. If only there was a HN for Google Scholar.
Oh, for christ's sake. I don't want to get all "get off my lawn" but HN is full of early-20-somethings rediscovering things and calling them 'bleeding edge'.
The highest paid people in our industry are working on drudgery full-time for FAANG. And that's fine, people have families, I'm not judging anyone. But let's not fool ourselves.
Strong static types have always been awesome, because there are no mysteries, no surprises. A chair is a chair. A wheel is a wheel. Fire is hot and water is wet.
But, hey, fucking JavaScript, so look at my bullshit variable! Is it a function? Sure! Does it have properties! You bet! Is it a chair? Who the fuck knows! The 'legs' array is undefined... Can we make it a chair? Of course! I need a wheel, can we make it a wheel too? You betcha! Just assign more fucking properties! Yayyyyyyyyyyyyy!!!
Hey, can I post this retarded data bag right the fuck back over to two different API endpoints? Why the fuck not? Okay, assholes, check out my greasy, cheese filled, swiss army bullshit unicycle or whatever the fuck this is, I don't even fucking care anymore, because I can't wait to just become an amnesiac, dump my client side session cache and pretend this whole fucking nightmare never even happened.
Yeah, but I think the kind of static typing that was 'shat on' for years is not the same as the one being praised today.
The shat on one is the old Java, verbose, obtrusive style. The newly praised one is Haskell-style, type inferred, expressive...
Now you could say that's not new, BUT what is new is marrying ML style type system to languages whose other concepts devs are largely familiar with and packaging it the right way to get into production, instead of just academia and that being the case even for historically impenetrable low-level programming and such.
These are the kind of comments that make HN so special: knowledgeable and insightful, due to deep experience with the past and critical understanding of the present. It isn’t just a rush to what is shiny and new, but is capable of identifying what is novel and valuable, and is articulate enough to explain why.
Normally my comment would be an unnecessary back-slapping, but since the conversation veered this way, I think it is appropriate to call out your comment as something that represents the spirit that makes HN unique and wonderful.
Current-day HN strikes me as very similar to early 00s Slashdot, albeit more self-serious and with an ideology more informed by SV capitalism/entrepreneurialism than the convoluted politics of open source software.
Agreed. The article that opened my eyes to this shows (IMO) a serious deficiency in C#'s type system compared to F#'s, which includes the concept of tagged-union types. It shows a very simple shopping cart program that can't be modeled cleanly in c# without using the visitor pattern....which is difficult to read IMO.
Hacker News ranks at #959 in the US. It didn’t get that rank from just being geared toward startups with Tier 1 engineers.
Look on the front page right now and see how many stories are about startups. That didn’t change in the last five years. It’s always been about technology in general.
We’re both making points based off anecdotal experience, so who knows. I have been a reader for the last 7 or 8 years, but my experience is just one subjective data-point.
Having said that, the most apparent change to me is in the tone and substance of the comments rather than the front page. And it isn’t a huge change. Just noticeable for me.
HN archives are stored in BigQuery, so it would be possible to do an analysis that was more rigorous than a human reading the thousands of front pages to see a pattern of difference.
You are assuming "tier 1 engineers" are also the ones using the bleeding edge technologies. This is not true in my experience. The best developers care a lot about using the best tools available for a particular task - which is very different from using the newest tools avaialbe. In reality it typically takes a long time for a tool to become mature enough for productive use, at which point it is not cutting edge anymore.
In case of open source, everyone wants someone to (beta) test their solutions in production. Only after few years of that such testing a tech product becomes usable for the rest of the industry and thats when it becomes profitable.
Im not surprised the leaders of IT, ppl who create those new technologies, push for a narrative to use those new shiny things.
Really good points. IMO the web-surfing crowd's taste for news (as opposed to their capability when it comes to work) is deceiving. Their excitement for prospective high-leverage information creates a demand that biases community sites like HN and Reddit toward novelty, and the result is this massive FOMO loop: "Read it, remember to try it, forget to try it, aw damn a new thing already came out and it's better because X! Read it..." I love that the author of the article really speaks to this situation.
I have a relative who got really into this mindset. In fact he picked the "HN's Choice" software framework of the day for one of our co-creative projects a couple years ago. Mostly a fun project, but it could have gone somewhere, maybe. He got as far as setting it up so that we had some scaffolding, then basically he flamed out. I don't blame him at all; he'd never even used it before and expected himself to be able to just run with it. And this guy was a _master_ at a certain language starting with the letter P, but he was ashamed to use it. It made me so upset to see him feel all this pressure and then collapse.
Personally I feel that pressure myself sometimes but being aware of it helps a lot. As a hobby side project, I decided to go back and do some 1990s MS-DOS programming and experiencing this FOMO stuff was part of the motivation. I needed to be free to work deep instead of thinking broad, so to speak.
Are we reading same HN? It seams majority of people advocate fairly sane proven choices for majority of projects e.g. start with the monolith default to PostgreSQL for dbms etc.
The concrete value doing such things add to our business is happy staff (which you mentioned), which means the best people don't leave, and stat excited and productive for the long term. Also, when hiring, because it helps us get the best people to join us in the first place.
It's not just about "bleeding edge", it's about giving dev teams the freedom to do that if they want to. Some do more than others, but the point is, if they get it wrong, things break and they get called at the weekend or whatever and they soon change track.
1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.
2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.
I always hear people warn about these things, but haven't seen it in practice at all, as long as those who write the systems are also responsible for operating them and not subjected to inappropriate external interference.
Of course, letting someone write whatever and then move on and leave it to someone else is a problem, but that's a problem regardless of whether they used bleeding edge tech or not.
For example, I've personally seen more tech-debt sins in more traditional monolithic Java + rdbms applications than I have an any of the Go based micro-services + nosql/etc I've seen over the years. I'm not trying to prove that "bleeding edge" is therefore better because it's not. I'm saying it's irrelevant.
The problem of leaving behind unmaintainable crap isn't about the tech, it's about the management, the team processes, the prioritisation process etc.
Is the story about Tesla's infrastructure true? I seem to remember it was posted before, and the consensus then was that it was a great work of fiction.
HN is basically Reddit for tech founders, so it tends to skew toward hype. And it's a small place, which makes for great echo chambers. Anything that makes it to the front page without being killed by admins, bots or users will probably be over-hyped.
Wrt over-using new tech: I've mostly seen this with hype directed at C-levels. Maybe one or two people on a team will pick up Rust or Go because they saw it on HN, but a year-plus slog will be initiated to implement a single Kubernetes platform that everyone must use, because a jagoff in a suit read a Wired article that said Kubernetes is the future of the internets. (Meanwhile, most of the devs don't use containers, pipelines are stood up in one-off Jenkins on shitty infra, the new "microservices" are really "distributed monoliths", and the security team is a guy nobody knows whose main occupation is writing drafts of best practices that nobody reads)
I think this will continue as long as we build tech by winging it, rather than doing case studies, analyzing solutions, and setting industry standards. And I'd argue another problem is cobbling together our own tools rather than paying for well-made ones. Because we're so interested in either getting things for free or writing them ourselves, really solid tools are rare.
This touches on something I've been thinking about a bit recently. It seems like software is undergoing a crisis of delivery, though I doubt that's new it still feels like there has not been much progress in delivering software that matters where it's needed.
Of course such systems tend not to be taking advantage of the newest tech but it feels like there's a lot of talk about how to achieve Netflix scale for simple websites with a few 100,000s of users and not much progress on delivering tangible, socially useful, software. Maybe it's selection bias and Rust is perhaps promising in this space but a lot of hyped technologies feel ephemeral or not useful outside of Web.
Incremental improvements to an infrastructure or rather the software ecosystem of a company isn't something many people talk about, indeed. Shiny new tools are interesting and flashy to look at.
For example, I'm very happy with the development of the company I work for over the last 2 or 3 years. I've pushed them from old unmanaged systems to mutable systems managed through chef. There's still some really ugly things, it's mutable, it's not shiny, it's VMs running tomcat running java 8. I like to call it really 2000s and/or vintage. It took time to migrate all systems, to gain trust of stake holders, to educate and convince the ops team. And I guess in some cases, we're running a really ugly mess of a system, but it's a reproducible mess.
But this was a massive improvement and value gain for the company. Suddenly we have an ops team with a lot of leverage and competence to manage an ever growing SaaS setup. And overall, the mindset of most people involved has changed over time towards standards, automation and the value of this. Automation has improved the cost efficiency of some default projects dramatically. We're still old school overall, but we're generating value.
And now the wheel of time has turned some. We've been bought, now there's 8 more development teams, now there's new products being brought in. At this point we're picking up containers at a larger scale because we have to move faster than the config management can handle with the current manpower. So now we're handling some stuff we can using the config management, some stuff with containers.
Overall, moving slow and deliberately in an infrastructure is a very valuable skill. Solve the important problems. Sometimes a trusty, ugly, old java application server isn't your important problem.
Sure, it's true that you can get work by learning "unsexy" stuff. If you want literally just a job, any job, knock yourself out I guess.
Better questions to ask: Is it good work? Will you find it fulfilling? Will they treat you well or will they treat you like a cost center? Sure, 80% of places don't use whatever newfangled tech you care to name, but that's not the whole picture.
80% of places are probably places you don't want to work, so what good is it to say "80% of places <literally anything goes here>"? You don't care about the majority of places, you care about the ones you would actually want to work at. What do people in those places do?
The point I'm driving at is not exactly that you should learn new stuff to work in a good place. Rather, the more options you have, the better chance you have at getting into a line of work you actually want to be in. And sure, it is possible that you will end up using Java in that line of work.
There are reasons people use newer tech. And not all of those reasons have to do with being addled by ADHD and obsessed with shiny things. I get tired of that implication.
Remember that Java 8 (or whatever tech you care to name) was once upon a time the new shiny stuff.
That was an enjoyable read. Just funny. Alright, I might not be a "dark" employee but we do run our shop on... FileMaker! Since 1993 as best I can tell.
It's pretty sweet. I just fielded a full online order system and did it in 30 calendar days flat. It wins five-star reviews from my users and raving compliments.
555 comments
[ 4.0 ms ] story [ 344 ms ] threadOr it might be overly focused on things that will never take the world by storm.
...and all of the failed futures as well.
1 languages or tech promoted by companies like Google, MS or FB
2 developers that self promote by creating a side project using the latest buzzwords and coolest languages of the month and sharing it, some do it for the CV but others do it for learning to see what is all about.
HN can't predict the future, good tech can die because is not supported by a company with money, or the company that controls it is incompetent and kills it. I am still thinking that C# and .Net could have been more popular only if MS could have just open source it from the beginning, maybe we would have now a way to do cross platform WPF apps and running them in browser with an open source Silverlight
This is not a criticism, but probably an unavoidable by-product of how it works and the audience it attracts.
Edit: Disclaimer: I am one of moderators and this is a blatant advertisement.
Not everyone chases the hype cycle.
If it's the later, and seeing how much enterprise has shifted in the last 30 years... if I were a betting fellow I'd say big systems will still be Java 8 in ten years time. Mayyyybe a freshly discovered catastrophic flaw in the jvm causes them to upgrade a version!
HN is about the interesting parts of tech, pushing at the edges. Yet the vast majority of developers are developing vanilla IT processes in shops where they want it to be the most benign, easily transferable solution possible. The differential between the two isn't surprising or particularly interesting. It's an obvious outcome.
And in ten years the stuff that people talked about on HN become the normal stuff at those IT shops, and HN will be onto something else. And on your "legacy" shops you'll be using frameworks that incorporated the best of those ShinyNewThings. Or do people really think the Java ecosystem today (or the .NET ecosystem, etc) hasn't changed over that time.
And that's okay. It's okay to wait until it matured. What isn't okay is that it's usually coached in derisive, defensive terminology that denigrates whatever is "Trendy". That part isn't cool
Does this problem play out in respect to experimental medicine I wonder?
j2ee+oracle == aspirin? isomorphic reactjs+node == S100A9 vaccine?
Oh, don't forget COBOL.
My team spent a whole quarter on converting R code into Python, because we wanted to use Tensorflow for machine learning(). When they finally got the thing running, they found out it wasn't performing as fast as R. I thought, that couldn't be possible, they use pretty much the same linear algebra libraries. So I peeked into the code to see what went wrong and found out that they writing it the wrong way: (1) calculated on Pandas dataframe directly instead of extracting the values first when doing matrix calculation, (2) instead of plain ndarray, were using matrix instead, which is slower. Both of which someone without experience in Python wouldn't have known.
() On a hindsight, did it have to be Tensorflow? Besides, there's already an interface for R[1]. Maybe the team decided on Python anyway in case they want to try out the plethora of ML libraries available for that language.
[1] https://tensorflow.rstudio.com/
The list is very long.
It's a biproduct IMO of working on boring problems or supporting morally ambiguous corps. That thing that you need to keep yourself busy and keep going in the rat race.
Unfortunately, this creates a whole host of long-term issues. For example, it create the situation where complex tools have their fervent advocates, while simple tools do not (because they don't provide job security). It also create an incentive to start a sort of complexity Ponzi scheme: you add tools to manage tools to manage other tools and so on. Each new layer reinforces the job security of people working on the previous one.
It's important to keep in mind that stuff like Java 8 and C are also tools, susceptible to the same problem.
The first time I seen a job title of "Kubernetes Keeper" I died a little inside. It's not that these jobs didn't exist before, and sysadmin is a perfectly good role which I personally don't have the skills or desire to do, but we keep pretending that we've build a way of replacing some of the effort which just moves it around a little.
Yes, tooling is a huge deal in day-to-day life. When I think about drains on my time and productivity, I've never been too setback by having to deal with a "for" loop instead of something more monadic. However, I HAVE spent days doing painful refactoring work, that could have been done in minutes with a few right-clicks in an IDE. Build tools and CI/CD pipelines, profiling and troubleshooting tools, etc etc etc.
I can't believe that any of this stuff requires defending oneself from having "sold out to The Man".
I think your examples betray your inexperience with what you're criticizing. A for loop isn't somehow corresponding to "something monadic" and safe refactoring (actual refactoring, not just renaming things, though that's obviously trivial as well) is extremely easy to do and produces great results in languages like Haskell, OCaml, etc.. Primarily this is because moving grouped things is nowhere near as sensitive as in a language like Java or the like.
But yeah, you can right-click rename all day, for sure... Never mind that other languages can let you safely re-architect the very bones of the solution with almost zero fear of coming out on the other side in failure.
Java has great tools, but let's not bring up refactoring as a real strength. It's kid's level stuff in comparison to languages that allow you to do that and more without tooling.
Haskell et al. have crap tooling and that has real consequences, but refactoring isn't one of the casualties at all. They're still better at refactoring, re-architecting and repurposing than any of the big name languages.
At least bring up debugging, system interaction or something.
There's every reason to think that software engineers and system administrators do their job much more quickly and correctly when they have the support of rich editor support, understandable compiler errors, usable interactive debuggers, profilers, dependency management that won't set your hair on fire, etc. For whatever reason, it seems like businesses often aren't interested or successful in creating these products, so frustrated developers step in to create the tools they dream of in their own work after too many days spent refactoring with regex.
It's possible that people might be drawn to tooling projects because of some kind of internalized revulsion in response to the social impact of their employer, but I think you'd expect to see developers working on tooling regardless of whether or not this is the case because of how a lot of development tooling just wouldn't exist if it weren't for individual FOSS contributors' efforts.
That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing.
If I went in for a root canal and the dentist said "We're gonna kick it old school today, sniff this rag of ether, I'm bored with all these tools!" I would grab the nearest scalpel and slowly back away. But yeah, if you're working on boring problems the tools won't do much to mask it.
A software developer's job is to create software. Almost like an author. Some more than others. At the end of the day, no matter how good your pen is, it will not write a great book for you.
Most software created itself is a tool, a tool which typically leverages the speed of computing to perform a task hundreds, thousands, or millions of times faster than a human could. Think making a bank transfer - I can do this in 5 seconds on my phone now, which would take me over an hour to physically head into a branch and do it in person, and even then we are relying on computing power at the branch itself.
Why would we, as software developers, act like we aren't going to use tools ourselves? For productivity, for a more pleasant (or even just less frustrating) experience?
I initially was a vim + printf debugging stalwart, but having been in a Java environment grew to realise the immense power of an IDE like IntelliJ and how beneficial it is. You can detect errors in the code almost immediately, so spelling mistakes and missed semicolons aren't a thing. You can fix them in a fraction of a second. If I write a function that could be written in a clearer way, or I'm not sure what type I should write for a variable, it will suggest it immediately and I can follow that suggestion with a press of a key.
Yes, it cannot write great software for me. But if you have worked with software where there is no autocompletion, poor debugging and profiling tools, then I find it hard to believe that you don't think that the addition of these tool can help you write at the least MORE software, and probably even BETTER software.
It is not the same as writing a novel, as much as I would like to romanticise that it is. It is about organising and coordinating components to work together, and for this tools can be a tremendous help.
Why? Because the tooling is what ends up being used every day in so many ways. A minor improvement in tooling can lead to drastically better quality of life. It's like getting a fancy but expensive office chair - no, I don't need it, but my back will thank me at the end of every day.
The catch here is that this applies across the board. For example, many new languages try to sell you on a better language design that is more convenient - and it may well be, but it doesn't matter when there's no good IDE, no good debugger, no smooth deployment story etc. PL and API design is important, but it's not more important than everything else. The languages that are the best for "quality of coding" are the ones that balance it all, and usually they have to dial some advanced aspects down to enable other areas to work. Or at least move slower with language evolution, so that new fancy features get full support across the board. It's no coincidence that languages like Java and C# - which lag behind on bleeding edge language features - have the best code completion and refactoring in the industry.
There is a special place in my heart to hate the new shiny lambdas. Makes code too difficult for reading, nowhere compatible when needing to use Java 7 every now and then.
With the article would just disagree on Sharepoint, would say Confluence has finally replaced that one.
Or are you just saying that lambdas are as bad as anonymous classes?
Quick, what does this do (in Scala)?
(1 to 100).map(x => x * x).reduce(_ + _) ?
Or if you don't like the underscores we could make it more explicit:
(1 to 100).map(x => x * x).reduce {case (x, y) => x + y }
Let's look at the iterative alternative:
var (i, sum) = (0, 0)
while (i < 100) { sum = i * i; i = i + 1 }
You could argue about performance or whatever, but closures are safer, more powerful, easier to read, and more concise.
Using a language without anonymous closures is like programming blind-folded and with one hand behind your back. It's pretty much the definition of Paul Graham's "Blub" languages[1]
Of course, classes are closures and closures are classes. But classes without closures are verbose, stupid, and ugly.
http://www.paulgraham.com/avg.html
Adding more logic to the loop also doesn't make the code more complex.
Depending on a pre-compiled jar that is not compatible with Java 8 :(
That's because these are marketing websites, meant to show off the newest and shiniest things, with an agenda. We like them because by our nature we like new and shiny things, but their content isn't representative of real life, like at all.
> That the loudest voices get the most credibility, and, that, as a result, we are listening to complicated set-ups and overengineering systems of distributed networking and queues and serverless and microservices and machine learning platforms that our companies don’t need, and that most other developers that pick up our work can’t relate to, or can even work with.
This is also part of human nature and my experience in the tech world confirms to me that the loudest voices are usually somewhere in the top of the bell curve of correctness or usefulness. Make friends with people who are working on real products every day and stay grounded in reality by talking to them, like knives that sharpen each other. The less they want to talk about tech or share their opinions, the more likely they are to have sane, reasonable and useful ones.
I still use Java 8 even on personal projects. I'm migrating those to Kotlin, so I'm at least not held back with regard to programming language features. I could upgrade those to Java 11 (or 12), just haven't prioritized taking the time to do that over other tasks, and the benefit would be minimal for these particular projects.
When using Java 8 language, I'm just happy to have lambdas and streams. Java 8 was the biggest improvement to Java language since 5 -- and I'd say it's a bigger leap that 5 was.
Generics, in terms of scope, is a bigger feature, for sure. And generics make lambdas more usable. But the distance between generics and their alternative - manual casts throughout - is larger than the distance between lambdas and anonymous inner classes.
Speaking of dark matter coding, story time: a spare time project of mine involves bringing an actual, pre-generics codebase into the not quite as distant past. That beast still has real, living users! Surprisingly, a frequent complaint is running out of heap memory, so they are happily sharing their magic -Xmx incantations with values that would have been outrageously high when the code was written.
IT maybe just another industry similar to bio or agriculture and not part of the startup tech.
Maybe IT crowd should simply avoid sharing common forums like HN with startup and SV people.
I have a friend who, until very recently, was working on a system based on Java 6, which coincidentally was the latest version back when the both of us were in college.
I'm currently in a not-that-old project(2 years old) the front-end of which was built using Angular 1.x.
I have to admit I like this, because my biggest gripe with this framework was that the API changes from version to version were so intense, that you couldn't find a working tutorial for some stuff.
Now that it's not being updated that fast it's much easier.
The best & brightest in tech are working with the best tools on the biggest problems, and that's what gets talked about, regardless of what the mass is doing.
Incidentally, it's the same curiosity that has the current article near the top of HN right now. It's not a point that has been articulated so often, or so recently, or so well, so it's fresh. Even if we already know it, it's a fresh reminder. (And also, of course, there's the catnip of the meta dimension.)
I don't think that's true—there is a subset of the best and brightest who work on greenfield projects very decoupled from existing customer bases, and they get to blog / present / post a lot about what they're doing. There are quite a few "best and brightest" people who are in large companies or slow-moving industries. They're often constrained to existing tooling, because moving to fancy new tooling is a huge risk and time sink for limited reward. They might be using cool personal tools—fancy editors and keyboards and window managers—but the stack they work on is generally "legacy".
And usually the problem of "How do we make this work slightly better for millions of end users" ends up being a bigger problem than "How do we do something really cool as a demo."
You can handle a lot of restrictions if the domain/problem is interesting enough and the constraints put on you don't feel too taxing, e.g. because they aren't enforced for your role or team very much. I feel like company size just isn't a good indicator for personal enjoyment/growth/$whatever, lots of research oriented divisions in larger corporations will let you work on interesting topics and hand off the engineering part to teams with people that enjoy that particular aspect of our world, both working for the same company.
Two, they have their pick of workplaces and focus on finding the biggest problem or perhaps the biggest paycheck, not the most freedom in tools. I have perfect freedom in tools hacking on OSS by myself; I don't look for that in a job.
Why do you assume it's impossible to have a fulfilling career writing Java 8 CRUD apps for Windows Server 2000?
I work with Java 8 on a greenfield high-frequency transaction platform for a very large company. It is extremely satisfying to build the "world's largest" of something, and no amount of shiny features in a cute new language would deter me from this work.
[1] https://youtu.be/lQSac0Jpz0Y
https://carcostcanada.com/Canada/Prices/2019-Honda-Civic_Sed...
1x $100 eBay turbocharger
1x $1000 misc expenses
27x $1000 JDM long-block
There's probably less fun ways to spend $30k on a Civic too
Example A - Honda Civic 1.6 i-VTEC
Basic Cost of Car - S$82,460 (~ 60k USD)https://www.sgcarmart.com/news/writeup.php?AID=171
We should be so lucky. Nobody knows who's the best, what the best tools are, or what the biggest problems are. We only know the ones that get written about.
Writers cover what's flashy, who's the best self-promoter, and what makes the most money.
Sites like HN and Reddit are aggregators in the literal sense. They take a large volume of data points and reduce it to a select few that get shown to most users. that aggregation function is "most interesting", not "most representative". Those are direct opposites of each other: interesting is almost by definition unusual.
I always find the subreddits that try to explicitly not target polar extremes the most fascinating from a sociology perspective. For example, this photo of a sink faucet is the most mildly interesting submission of the past year:
https://www.reddit.com/r/mildlyinteresting/comments/9ykoe4/t...
Does that mean all other submissions were less interesting, or less mild?
That doesn't have to mean new and shiny.
By way of analogy: the F-117 stealth fighter--the world's first operational stealth aircraft--was developed by the best and brightest (Lockheed Martin Skunk Works) and solved the biggest problem (visibility to radar). Aside from having a weird polyhedral shape and innovative radar-absorbing material, nothing about the plane was the "best", "latest", or "cutting-edge" at all. Much of it consisted of parts from other aircraft hacked together. If you actually do want to have the best cutting-edge technology all in one plane, you spend 25 years designing the damn thing--that's the F-35.
http://aviationintel.com/yak-141-freestyle-the-f-35b-was-bor...
The F-35 has them. The Yak-141 didn't. Therefore, it absolutely is an exaggeration to say the F-35 was "lifted wholesale" from the Yak-141. Two of the three F-35 variants don't even have the lift fan!
When dealing with new tech it's a lot more likely to be the first person to run into some obscure use case no one has ever experienced before. And in that case you need devs who are not only capable but willing to invest in solving the problem. Sometimes that means, re-architect something in the stack and sometimes it may even require making a PR to the original project. That's a lot of investment that may make your devs happier but probably provides little concrete value to the business.
That said I'm still building on elixir so what do I know.
There are plenty of other forums and sites to read about conventional tech. HN is where I find the bleeding edge. 90% of it is just fascinating. But the other 10% offer tantalizing possibilities for making something novel, which is to say: solving an unsolved problem.
“How to Become a Hacker” puts it plainly: no problem should have to be solved twice. Drudgery is evil. And by those axioms, a ‘Hacker’ is just uninterested in old solutions to old problems. We need to live in the future so that we can build the future. Although HN’s content has suffered over the last 5 years with the influx that accompanied a wider awareness of startups, it still is the best place I know of to dip your toes into the various futures we may one day encounter.
Having said that, lately I’ve found that Google Scholar is often more thought-provoking. If only there was a HN for Google Scholar.
The highest paid people in our industry are working on drudgery full-time for FAANG. And that's fine, people have families, I'm not judging anyone. But let's not fool ourselves.
Fucking JavaScript.
Strong static types have always been awesome, because there are no mysteries, no surprises. A chair is a chair. A wheel is a wheel. Fire is hot and water is wet.
But, hey, fucking JavaScript, so look at my bullshit variable! Is it a function? Sure! Does it have properties! You bet! Is it a chair? Who the fuck knows! The 'legs' array is undefined... Can we make it a chair? Of course! I need a wheel, can we make it a wheel too? You betcha! Just assign more fucking properties! Yayyyyyyyyyyyyy!!!
Hey, can I post this retarded data bag right the fuck back over to two different API endpoints? Why the fuck not? Okay, assholes, check out my greasy, cheese filled, swiss army bullshit unicycle or whatever the fuck this is, I don't even fucking care anymore, because I can't wait to just become an amnesiac, dump my client side session cache and pretend this whole fucking nightmare never even happened.
The shat on one is the old Java, verbose, obtrusive style. The newly praised one is Haskell-style, type inferred, expressive...
Now you could say that's not new, BUT what is new is marrying ML style type system to languages whose other concepts devs are largely familiar with and packaging it the right way to get into production, instead of just academia and that being the case even for historically impenetrable low-level programming and such.
Normally my comment would be an unnecessary back-slapping, but since the conversation veered this way, I think it is appropriate to call out your comment as something that represents the spirit that makes HN unique and wonderful.
Hackernews has an _instagram filter_ where everybody brags about how smart they are.
Then there's a bunch of fresh grads who fanboy their favourite tech companies.
Then every so often you get a gem of a comment from knowledge leader in the industry.
But that's quickly overshadowed by 'my Startup, my Startup, mah Startup' and how everybody wants to be rich one day.
But like every larger community in the internet, it eventually derives itself into an echo chamber.
https://fsharpforfunandprofit.com/csharp/union-types-in-csha...
Look on the front page right now and see how many stories are about startups. That didn’t change in the last five years. It’s always been about technology in general.
HN’s front page 10 years ago:
https://news.ycombinator.com/front?day=2009-05-10
HN’s front page 5 years ago
https://news.ycombinator.com/front?day=2014-05-10
Having said that, the most apparent change to me is in the tone and substance of the comments rather than the front page. And it isn’t a huge change. Just noticeable for me.
Or engineers who've convinced themselves that they're Tier 1 engineers...
Im not surprised the leaders of IT, ppl who create those new technologies, push for a narrative to use those new shiny things.
I have a relative who got really into this mindset. In fact he picked the "HN's Choice" software framework of the day for one of our co-creative projects a couple years ago. Mostly a fun project, but it could have gone somewhere, maybe. He got as far as setting it up so that we had some scaffolding, then basically he flamed out. I don't blame him at all; he'd never even used it before and expected himself to be able to just run with it. And this guy was a _master_ at a certain language starting with the letter P, but he was ashamed to use it. It made me so upset to see him feel all this pressure and then collapse.
Personally I feel that pressure myself sometimes but being aware of it helps a lot. As a hobby side project, I decided to go back and do some 1990s MS-DOS programming and experiencing this FOMO stuff was part of the motivation. I needed to be free to work deep instead of thinking broad, so to speak.
Prolog?
What a shame he couldn't use his best language! It has such nice web frameworks.
https://en.wikipedia.org/wiki/List_of_programming_languages#...
(There may be some overlap)
The concrete value doing such things add to our business is happy staff (which you mentioned), which means the best people don't leave, and stat excited and productive for the long term. Also, when hiring, because it helps us get the best people to join us in the first place.
It's not just about "bleeding edge", it's about giving dev teams the freedom to do that if they want to. Some do more than others, but the point is, if they get it wrong, things break and they get called at the weekend or whatever and they soon change track.
1. Half-done projects started by some happy staff who then went on to start the next project in the next shiny new thing and either more-or-less completed by someone who was just about capable of cut-n-pasting without understanding or who decided that some new shiny thing needed to be added to make the rest wonderful.
2. A monstrous stack of projects in 637 different programming languages, frameworks, ideologies, coding styles, and indentation levels, guaranteed to require rewriting for any change. Result: 638 different things.
Of course, letting someone write whatever and then move on and leave it to someone else is a problem, but that's a problem regardless of whether they used bleeding edge tech or not.
For example, I've personally seen more tech-debt sins in more traditional monolithic Java + rdbms applications than I have an any of the Go based micro-services + nosql/etc I've seen over the years. I'm not trying to prove that "bleeding edge" is therefore better because it's not. I'm saying it's irrelevant.
The problem of leaving behind unmaintainable crap isn't about the tech, it's about the management, the team processes, the prioritisation process etc.
Wrt over-using new tech: I've mostly seen this with hype directed at C-levels. Maybe one or two people on a team will pick up Rust or Go because they saw it on HN, but a year-plus slog will be initiated to implement a single Kubernetes platform that everyone must use, because a jagoff in a suit read a Wired article that said Kubernetes is the future of the internets. (Meanwhile, most of the devs don't use containers, pipelines are stood up in one-off Jenkins on shitty infra, the new "microservices" are really "distributed monoliths", and the security team is a guy nobody knows whose main occupation is writing drafts of best practices that nobody reads)
I think this will continue as long as we build tech by winging it, rather than doing case studies, analyzing solutions, and setting industry standards. And I'd argue another problem is cobbling together our own tools rather than paying for well-made ones. Because we're so interested in either getting things for free or writing them ourselves, really solid tools are rare.
I'm thinking specifically about the Crossrail project here in the UK where signalling has completely screwed the project https://www.google.com/amp/s/amp.theguardian.com/uk-news/201...
Of course such systems tend not to be taking advantage of the newest tech but it feels like there's a lot of talk about how to achieve Netflix scale for simple websites with a few 100,000s of users and not much progress on delivering tangible, socially useful, software. Maybe it's selection bias and Rust is perhaps promising in this space but a lot of hyped technologies feel ephemeral or not useful outside of Web.
For example, I'm very happy with the development of the company I work for over the last 2 or 3 years. I've pushed them from old unmanaged systems to mutable systems managed through chef. There's still some really ugly things, it's mutable, it's not shiny, it's VMs running tomcat running java 8. I like to call it really 2000s and/or vintage. It took time to migrate all systems, to gain trust of stake holders, to educate and convince the ops team. And I guess in some cases, we're running a really ugly mess of a system, but it's a reproducible mess.
But this was a massive improvement and value gain for the company. Suddenly we have an ops team with a lot of leverage and competence to manage an ever growing SaaS setup. And overall, the mindset of most people involved has changed over time towards standards, automation and the value of this. Automation has improved the cost efficiency of some default projects dramatically. We're still old school overall, but we're generating value.
And now the wheel of time has turned some. We've been bought, now there's 8 more development teams, now there's new products being brought in. At this point we're picking up containers at a larger scale because we have to move faster than the config management can handle with the current manpower. So now we're handling some stuff we can using the config management, some stuff with containers.
Overall, moving slow and deliberately in an infrastructure is a very valuable skill. Solve the important problems. Sometimes a trusty, ugly, old java application server isn't your important problem.
Better questions to ask: Is it good work? Will you find it fulfilling? Will they treat you well or will they treat you like a cost center? Sure, 80% of places don't use whatever newfangled tech you care to name, but that's not the whole picture.
80% of places are probably places you don't want to work, so what good is it to say "80% of places <literally anything goes here>"? You don't care about the majority of places, you care about the ones you would actually want to work at. What do people in those places do?
The point I'm driving at is not exactly that you should learn new stuff to work in a good place. Rather, the more options you have, the better chance you have at getting into a line of work you actually want to be in. And sure, it is possible that you will end up using Java in that line of work.
There are reasons people use newer tech. And not all of those reasons have to do with being addled by ADHD and obsessed with shiny things. I get tired of that implication.
Remember that Java 8 (or whatever tech you care to name) was once upon a time the new shiny stuff.